Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado
Re: Hex constants interpreted differently in IDL/v5.2
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 -- David Fanning, Ph.D. Fanning Software Consulting Phone: 970-221-0438 E-Mail: davidf@dfanning.com Coyote's Guide to IDL Programming: http://www.dfanning.com/ Toll-Free IDL Book Orders: 1-888-461-0155
thompson@orpheus.nascom.nasa.gov (William Thompson) writes: > A colleague of mine (Craig DeForrest) pointed this out to me, and I thought it > important enough to distribute more widely. Has anybody else run into this > one? > 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 Update -- I just heard that RSI considers this a bug, because v5.2 acts differently in this regard than all earlier versions of IDL. The next version of IDL should go back to the old behavior. Bill Thompson
In an earlier message, I had written > To be affected, the hexadecimal constant needs to be exactly four bytes long, ^^^^^^^^^^ Oops, I meant to say "four nibbles" (i.e. two bytes). :^) Bill Thompson
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/