Re: Zooming issues in interactive terminals

[Ethan A M. <merritt@u.washington.edu>]

On Monday 19 May 2008 18:44, Lutz Maibaum wrote:
> Hi Ethan,
> 
> I just read that on many 32-bit systems the "int" and "long" datatypes are 
> the same, whereas on 64-bit system such as the AMD x86-64 I am 
> using "long" is 8 bytes, whereas "int" is 4 bytes. This would explain why 
> you don't see the effect of the long->int conversion on your system.

Right. I was assuming that v.int_val was a long, but it isn't.
That explains the intention of the previous test  if ((A=B) == B) that 
was puzzling me.  I thought A and B were both longs.

I wonder why int_value is not being kept as a long?
value.v is a union, and one other member of the union is a double,
so it wouldn't add any space to store a long rather than an int.
But changing it to

typedef struct value {
    enum DATA_TYPES type;
    union {
        long int_val;
        struct cmplx cmplx_val;
        char *string_val;
    } v;
} t_value;

might cause similar problems to pop up all over the place when
int_val is dereferenced.   Hmm.  For now I'll leave the change to atol(),
but also restore the earlier ((A=B)==B) test.

	Ethan


> 
>  Lutz
> 
> 
> On Monday 19 May 2008 17:46:08 you wrote:
> > 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
Biomolecular Structure Center
University of Washington, Seattle 98195-7742