| Re: Hex constants interpreted differently in IDL/v5.2 [message #15511 is a reply to message #15503] |
Tue, 25 May 1999 00:00   |
Martin Schultz
Messages: 515
Registered: August 1997
|
Senior Member |
|
|
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/
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
