Re: Hex constants interpreted differently in IDL/v5.2

[Martin Schultz <mgs(at)io.harvard.edu>]

David Fanning wrote:
> 
> William Thompson (thompson@orpheus.nascom.nasa.gov) writes:
> 
> > Apparently, IDL/v5.2 interprets some hexadecimal constants differently than
> > previous versions.  For example, the statement
> >
> >       IDL> help,'aa7f'x
> >
> > under IDL/v5.1 produces the result
> >
> >       <Expression>    LONG      =        43647
> >
> > while under IDL/v5.2, the following is returned
> >
> >       <Expression>    INT       =   -21889
> 
> Yep. I think I reported this already. (Or meant to,
> if I didn't.)
> 
> I first noticed it with this kind of syntax:
> 
>    Plot, data, Color='00ffff'x
> 
> This used to draw a yellow plot, but started drawing
> white plots in IDL 5.2. Of course, the previous behavior
> was decidedly a bug (that I had gotten used to, darn it),
> but if you want a 24-bit number, you really do need to
> make it a long:
> 
>    Plot, data, color='00ffff'xL
> 
> I presume the bug was found and fixed when the programmers
> were implementing the unsigned integer data type. :-)
> 
> Cheers,
> 
> David

Why should this be a bug? With '00ffff'x you are specifying 3 bytes,
hence you need at least a long variable. I would think it's OK if this
is interpreted as such. For the cases that William mentions, it i
sarguable whether the correct behaviour should be to produce an unsigned
int instead of a 'normal' int. At least in my experience, hex numbers
are usually meant to be positive. And you could still force it as
fix('f000'x).

Regards,
Martin

-- 

|||||||||||||||\\\\\\\\\\\\\-------------------///////////////|||||||||||||||
Martin Schultz, DEAS, Harvard University, 29 Oxford St., Pierce 109,
Cambridge, MA 02138          phone (617) 496 8318   fax (617) 495 4551
e-mail mgs@io.harvard.edu    web http://www-as/people/staff/mgs/