comp.lang.idl-pvwave archive: archive » Plot bug or another "strange feature" ?

Home » Public Forums » archive » Plot bug or another "strange feature" ?

Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend

Re: Plot bug or another "strange feature" ? [message #20119 is a reply to message #19980]

Tue, 16 May 2000 00:00

Nicolas Decoster
Messages: 34
Registered: March 2000

Member

Paul van Delst wrote:
>
> Nicolas Decoster wrote:
>>
>> Hi.
>>
>> Does anybody notice and, eventually, know how to handle this "strange
>> feature" of the plot procedure ?
>>
>> IDL> s = indgen(1000) + 1000000000
>> IDL> plot, s, /ynozero
>>
>> The plot is not a clean line joining down-left and up-right corners, but
>> an ugly stairway...
>
> I thought that sort of thing came about because:
>
> a) PLOT converts all its arguments to single precision floats. Do a
> PRINT, FLOAT(s[0:100]),FORMAT='(e20.13)' to see what happens to the
> float'd integers,
>
> b) people think they can represent numbers at the extremes of machine
> precision exactly. Your "s" array, when converted to single precision
> float, changes in the 8th or 9th d.p. While I think that IDL should
> allow users to set the PLOT conversion to double precision if they want
> (e.g. with a DOUBLE keyword or something), in general you can't expect
> these sorts of numbers to be represented well - in IDL or any language.
> That's not how floating point arithmetic works. All floating point
> numbers are approximations to their actual value.

I mainly agree with you. But "s" array is not a double array, it is a
long array:

IDL> help, s
S LONG = Array[1000]

I agree with you that plot converts everything to floating point number.
But I think that it is important to see exactly what are the values of
my integers (in fact my long integers) in a graph. And it is the same
with double precision floating point numbers: I am not talking about the
representation of real world numbers using floating point numbers.
Example:

IDL> b = [100000000.00000001d, 100000000.00000003d]
IDL> print, b, format = '(e22.16)'
1.0000000000000001e+08
1.0000000000000003e+08
IDL> plot, b, /ynozero
% PLOT: Data range for axis has zero length.
% Execution halted at: $MAIN$

Yes, perhaps a keyword would be fine, here. Or better, a plot procedure
that computes the data range according to the precision of the data.

Later,

Nicolas.

--
Tï¿½l. : 00 (33) 5 62 88 11 16
Fax : 00 (33) 5 62 88 11 12
Nicolas.Decoster@Noveltis.fr

Noveltis
Parc Technologique du Canal
2, avenue de l'Europe
31520 Ramonville Saint Agne - France

Report message to a moderator

[Message index]

		Plot bug or another "strange feature" ? By: Nicolas Decoster on Tue, 16 May 2000 00:00
		Re: Plot bug or another "strange feature" ? By: Paul van Delst on Tue, 16 May 2000 00:00
		Re: Plot bug or another "strange feature" ? By: Paul van Delst on Tue, 16 May 2000 00:00
		Re: Plot bug or another "strange feature" ? By: davidf on Tue, 16 May 2000 00:00
		Re: Plot bug or another "strange feature" ? By: John-David T. Smith on Tue, 16 May 2000 00:00
		Re: Plot bug or another "strange feature" ? By: Nicolas Decoster on Tue, 16 May 2000 00:00
		Re: Plot bug or another "strange feature" ? By: davidf on Tue, 16 May 2000 00:00
		Re: Plot bug or another "strange feature" ? By: Nicolas Decoster on Tue, 16 May 2000 00:00
		Re: Plot bug or another "strange feature" ? By: davidf on Tue, 16 May 2000 00:00
		Re: Plot bug or another "strange feature" ? By: Paul van Delst on Tue, 16 May 2000 00:00
		Re: Plot bug or another "strange feature" ? By: Paul van Delst on Tue, 16 May 2000 00:00

Previous Topic:	MIF Files
Next Topic:	Re: newbie:Volume Rendering on IDL

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

] [

]

Current Time: Sat Oct 11 20:05:46 PDT 2025

Total time taken to generate the page: 0.87859 seconds