Menu
▾
▴
gnuplot-beta
|
From: Harald H. <h.h...@tu...> - 2005-10-23 21:54:48
|
Ethan, I will also post this mail to the mailing list because at least parts of it can be interesting to the gnuplot community. On Sun, 23 Oct 2005, Ethan A Merritt wrote: > On Sunday 23 October 2005 01:50 pm, you wrote: > > I do not agree that (angle == 0) is sufficient. Many > > terminals switch from horizontal text to vertical text > > (angle 90) if the given angle is different from 0. If small > > rounding errors lead to vertical text instead of horizontal > > text, this is a severe bug. > > But where can these rounding errors occur? > Not internal to gnuplot, because gnuplot does not calculate > text rotation angle internally anywhere that I can think of. I don't trust C compilers that they will return exactly 0 when you set a variable to 0 in all cases. Does the ANSI C standard define that float a = 0.0; if (a == 0) ... always is true? I don't think so. May be, most architectures do so. But all? When learning programming I have always been told not to test against an exact value when using floating variables. > The only place a rotation angle gets set is in > parse_label_options(). > So it should be sufficient to check in that one place. > > --- gnuplot/src/set.c 2005-10-09 19:44:36.000000000 -0700 > +++ gnuplot-cvs/src/set.c 2005-10-23 14:27:18.995207128 -0700 > @@ -4741,7 +4788,9 @@ I find more: 3555, 4020 Sooner or later, this will also have to be added in line 3715 (by the way, funny that there still are texts not rotatable by arbitrary angles). With the approach in my patch, all newly introduced angles are covered automatically. And rounding errors of a bad C compiler implementation are eliminated. The number of calles to these functions is not too bad to slow down plots since normally, not too many texts are put into a plot (in comparison to lines, for instance). Another thing could be thought of: Terminals that can only set term horizontally or vertically should switch from horizontal to vertical text when exceeding 45 degrees, not when going from zero to one. What do you mean? But I think this could be a seperate patch after this one. And we really should find out which terminals are capable of arbitrary text angles but do not use it right now. I have found at least one of them. Best regards Harald -- Harald Harders h.h...@tu... http://www.harald-harders.de |
|
From: Harald H. <h.h...@tu...> - 2005-10-24 18:06:59
|
On Sun, 23 Oct 2005, Ethan A Merritt wrote:
> On Sunday 23 October 2005 03:00 pm, Harald Harders wrote:
> > float a = 0.0;
> > if (a == 0) ...
> >
> > always is true? I don't think so.
>
> IEEE standard guarantees this. Even in the case that an architecture
> can represent both +0 and -0, it is required that +0 == -0.
Good to hear. But as Petr sais, this does not count for angles
that are multiples of 90 deg. Thus, I think it is the saves way to
introduce a range in the test for horizontal or vertical texts.
> >> The only place a rotation angle gets set is in parse_label_options().
> > I find more: 3555, 4020
>
> True. This may be telling us that these places
> ("set tics" and "set {xyz}tics") should call parse_label_options()
> rather than duplicating the code locally.
Independent of this problem, yes.
> > Sooner or later, this will also have to be added in line 3715 (by the
> > way, funny that there still are texts not rotatable by arbitrary
> > angles).
>
> You want to rotate the time-stamp? That seems a little bit overboard.
> If you really want to write the data on a plot in a fancy font or
> rotated text, you can easily use some variant of set label "`date`".
I think all text objects should be handled equally. Thus, every text
object should be rotatable. This would eas handling and documentation. We
could say 'Text can be rotated by using the option `rotate by`'. If you or
I find it useful to rotate a specific type of text does not matter there.
With your argument that I could use an ordinary label I also could say
that the function timestamp was useless.
> > Another thing could be thought of:
> > Terminals that can only set term horizontally or vertically should
> > switch from horizontal to vertical text when exceeding 45 degrees, not
> > when going from zero to one. What do you mean?
>
> I think that if someone really wants 45 degree text, they will be
> equally unhappy with either 0 or 90.
45 Degrees was an arbitrary example. A user that gives 10 deg will be more
happy with horizontal text than with vertical text. And vertical text is
what happens at the moment.
Best regards
Harald
--
Harald Harders
h.h...@tu...
http://www.harald-harders.de
|
|
From: Hans-Bernhard B. <br...@ph...> - 2005-10-24 18:45:00
|
Harald Harders wrote:
> With your argument that I could use an ordinary label I also could say
> that the function timestamp was useless.
It quite possibly might be. That's what happens if you add generic
implementations of some features (the sprintf() function) several years
after other people added some very specifically target special cases
('set timestamp', my number-printing extension to 'set label').
OTOH, there are still some things that 'set timestamp' does, but a
similar 'set label' doesn't: it gets space reserved for itself by the
global layout function, boundary().
|
|
From: <mi...@ph...> - 2005-10-24 19:04:25
|
> rotated text, you can easily use some variant of > set label "`date`". This is not portable to Windows. --- PM |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-10-24 19:16:38
|
On Monday 24 October 2005 12:04 pm, mi...@ph... wrote: > > rotated text, you can easily use some variant of > > set label "`date`". > > This is not portable to Windows. Windows doesn't support rotated text to begin with, so this seems like a quibble. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Ethan A M. <merritt@u.washington.edu> - 2005-10-23 23:16:14
|
On Sunday 23 October 2005 03:00 pm, Harald Harders wrote:
> float a = 0.0;
> if (a == 0) ...
>
> always is true? I don't think so.
IEEE standard guarantees this. Even in the case that an architecture
can represent both +0 and -0, it is required that +0 == -0.
Yes, I know that not all C compilers require IEEE floating point.
But I am inclined to say that if your compiler is so broken that
it fails to store 0 as 0, then using it to build gnuplot will reveal
bigger problems than accurate text rotation :-)
>> The only place a rotation angle gets set is in parse_label_options().
> I find more: 3555, 4020
True. This may be telling us that these places
("set tics" and "set {xyz}tics") should call parse_label_options()
rather than duplicating the code locally.
> Sooner or later, this will also have to be added in line 3715 (by the
> way, funny that there still are texts not rotatable by arbitrary
> angles).
You want to rotate the time-stamp? That seems a little bit overboard.
If you really want to write the data on a plot in a fancy font or
rotated text, you can easily use some variant of set label "`date`".
> Another thing could be thought of:
> Terminals that can only set term horizontally or vertically should
> switch from horizontal to vertical text when exceeding 45 degrees, not
> when going from zero to one. What do you mean?
I think that if someone really wants 45 degree text, they will be
equally unhappy with either 0 or 90.
> And we really should find out which terminals are capable of arbitrary
> text angles but do not use it right now.
Sure. I originally added it to all the terminal types I could test
at the time. And there's a patch on SourceForge that adds it to metapost.
But there remain other terminal types I cannot test, or I do not have
documentation for their output device capabilities.
--
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742
|
|
From: <mi...@ph...> - 2005-10-24 05:38:53
|
>> But where can these rounding errors occur? >> Not internal to gnuplot, because gnuplot does not calculate >> text rotation angle internally anywhere that I can think of. > > I don't trust C compilers that they will return exactly 0 when you set a variable to 0 in all cases. The rounding error correction could be useful for all multiples of 90 deg rotations, if they were calculated from n*pi/2; mainly if there are special terminal routines for vertical text. --- PM |
|
From: Hans-Bernhard B. <br...@ph...> - 2005-10-24 14:02:35
|
Harald Harders wrote: > I don't trust C compilers that they will return exactly 0 when you set a > variable to 0 in all cases. Does the ANSI C standard define > that > > float a = 0.0; > if (a == 0) ... > > always is true? Pretty much so. For zero literals, that is. As soon as you use any kind of computation that your maths book says yields zero, all bets are off. > Another thing could be thought of: > Terminals that can only set term horizontally or vertically should switch > from horizontal to vertical text when exceeding 45 degrees, not when going > from zero to one. What do you mean? As part of your change from integer to float, which is a complete break of the existing terminal API anyway, that modification makes sense. As part of the previous extension, where we just extended the interpretation of an int argument that was meant to be boolean (rotate by 90 degrees or not), it wouldn't have. |
