|
From: Ethan M. <merritt@u.washington.edu> - 2008-05-20 00:46:03
|
On Monday 19 May 2008 17:28, Lutz Maibaum wrote:
> Hi Ethan,
>
> > I've made this change in scanner.c get_num().
> > It fixes the overflows on a system that handles stderr properly (linux)
> > and does no worse that the previous code on a system that doesn't (sunos
> > 4.1).
>
> I just tried the current CVS build, and the problems with interactive
> zooming remain, except that I don't get an error message anymore ;)
I confess that I am mystified.
What compiler and glibc versions are you using?
What hardware? You probably said before, but I've forgotten.
Does the man page for strtol on your system claim that it will
set errno on overflow?
> As you mentioned before, the problem is that large numbers, such as those
> generated by apply_zoom() when using logarithmic axes, are not recognized
> as floating point values when they do not contain a decimal point:
>
> gnuplot> set yr[313136844993:1.8789321221e+13]
> gnuplot> show yr
> set yrange [ -3.95768e+08 : 1.87893e+13 ] noreverse nowriteback
On my machine (32-bit, rather old AMD athlon) I get
gnuplot> set yr[313136844993:1.8789321221e+13]
^
warning: integer overflow; changing to floating point
gnuplot> show yr
set yrange [ 3.13137e+11 : 1.87893e+13 ] noreverse nowriteback
I assume that you also get something else for the simpler test case:
gnuplot> t = 313136844993
^
warning: integer overflow; changing to floating point
gnuplot> print t
313136844993.0
> This obviously doesn't work when the y-axis is logarithmic.
> Changing "%.12g" to "%.12E" in apply_zoom() fixed this issue for me.
>
> Thanks for looking into this,
But changing the format in the zoom code won't fix the general case.
I would rather figure out how to make it work everywhere!
Ethan
--
Ethan A Merritt
|