[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gnuplot-info-beta
Subject:    Re: Feature request: configurable \times/\cdot and a bit about %h
From:       Mojca Miklavec <mojca.miklavec.lists () gmail ! com>
Date:       2013-10-09 13:26:29
Message-ID: CALBOmsY9sjKSZfzVp8d0eeVV3y3Ck77uDB-rS=btWFmJYCCu8A () mail ! gmail ! com
[Download RAW message or body]

On Wed, Oct 9, 2013 at 12:41 AM, Ethan A Merritt wrote:
>
>> I always use \cdot instead of \times. Would it be possible to make
>> this configurable?
>
> Yes.
> On the non-LaTeX side  %h differs from %H by the choice of "x" versus ""*".
> It would make sense on the LaTeX side to interpret this as \times versus \cdot.
>
> Obviously only one of these can be the default.
> If you want something other than the default you have to use the
> "set format" command.

What about something more in the spirit of decimalsign?
    set decimalsign ','

So something like
    set multiplicationsign '*'
and the code in TERM_IS_LATEX checking for the value of that
character: if equal to '*', it would replace it with '\cdot', but in
principle users could use anything, from normal dots to '\bigtimes' or
anything else they please to use.

This would allow a much better flexibility, also because one wouldn't
need to change the format at all. With your suggestion one would need
to set both
    set format x "%H"
    set format y "%H"
and maybe at some other places displaying numerical values while
setting multiplication sign could be done once and for all.


>> This is the line in src/util.c that prints the character:
>>     strcpy(&tmp2[j], "\\times");
>>
>> The other "problem" I have if I would use this handy shortcut is that
>> it annoys me to have the y axis labelled "1", "1.5", "2", "2.5", ...
>> Thus I always use something like
>>     set format y "%.1f"
>
> That was one of two issues I had with the patch also.
> See discussion attached to the patch tracker.
>    https://sourceforge.net/p/gnuplot/patches/637/

Thank you. I believe that your comment:
    "I think the only way to get consistent formatting is to look at
all the tic values first and then pick some single format that can be
used for all of them."

expresses the same feelings that I have.

Yes, I hate if the axes are labelled "0.1000", "0.2000", "0.2999",
"0.4000" which might happen with "%f", but users should really have a
way of getting a consistent number of decimal digits. Even if some
people prefer "%g" (I often use %g only because I'm too lazy to
specify how many numbers I want exactly and this usually prints
something that makes more sense than %f), there should be a way to get
"0.00", "0.05", "0.10", "0.15", ... automatically. Yes, using "%.2f"
is a viable workaround, but one needs to hardcode the number of
desired decimal places. I would really love to see that number being
calculated automatically.

Btw: how does the current code deal with cases such as:
a) 0.001, 0.01, 0.1, 1, 10, 100, 1000, 10000
b) 100, 200, 300, ..., 900, 1000, 1100
When does the code decide to use exponential notation and when would
it print a normal "1000" rather than 1x10^3?

> IMHO "%.1f" isn't quite right either. I prefer
>   set format  "%.1tx10^{%T}"
>
> The other side of the argument, and the rationale for the patch
> as written, is Craig DeForest's observation that some people actually
> like the %g format.   That seems fair enough.   I just don't happen to
> be one of those people.

Me neither. And most other programs use a consistent number of decimal
places for axes labeling. The compromise is to allow both, but I don't
know how complex it would be to support that.

>> I would really love to have a setting to turn on the functionality
>> that would automatically calculate the number of needed decimal places
>> and keep it constant on the whole axis. And possibly a similar setting
>> that would also stick with 1.0\times10^{0} to keep the numbers nicely
>> right-aligned when requested.
>
> See discussion.  I'd like that also, but it would require choosing the
> format at the level of the entire axis range, not tic-by-tic.

True, it's needed for the entire range, not just by looking at a
single tick. I don't know enough about gnuplot internals to be able to
judge what changes exactly that would require.

Mojca

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
_______________________________________________
gnuplot-beta mailing list
gnuplot-beta@lists.sourceforge.net
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
[prev in list] [next in list] [prev in thread] [next in thread]