comp.lang.idl-pvwave archive - RDF feed
type: channel
description: Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado
items: Re: A big BUG in PLOT, SURFACE, ...

Re: A big BUG in PLOT, SURFACE, ...
type: item
description: Philippe LATREMOLIERE <phlatrem@cnrs-orleans.fr> writes: > Try this : > d = FINDGEN(100) > d(10) = -1e15 > PLOT, d, YRANGE = [0, 100] > Don't you fing something strange ?. On my screen, the negative value is > transformed to a positive one > It is the same with SURFACE... > Is it a new bug from the great RSI ? Hm. Interesting. The error does not appear when I run this on SUN SPARCstations running Solaris 2.4 and SunOS 4.1.3. However, it does appear when I try it on a VAXstation running OpenVMS. Anyone see it on any other platforms? Joel -- "...And I am unanimous in this." - Mrs. Slocumbe Joel D. Offenberg | offenbrg@fondue.gsfc.nasa.gov Hughes STX, NASA/GSFC/LASP | (301)-286-5801
creator: offenbrg
date: 1995-06-16T07:00:00-00:00

Re: A big BUG in PLOT, SURFACE, ...
type: item
description: Running on sun4 with SunOs 4.1.3 I get the arithmetic error but the plot looks fine. when the yrange is large enough, the error goes away, so the error probably occurs when IDL tries to calculate where on the plot the -1e15 point should lie. I do not know what the plotting bug looks like in the other OS's but from what I read, I guessed that some number in the graphics interface with the OS wraps around positive in the OS end when it goes too far negative in the IDL end. I Tried the following experiment; I defined d=dindgen(100). I made a series of plots with d(10)=-1*double(10)^X, where X was a number I steadily increased. The X value where the plots start displaying improperly was 39, as in the first exponent which is beyond the range of a 32 bit float! So I made a series of plots where d(10)=-1*Y*double(10)^38 and incremented Y. I saw some plots with d(10) very negative and some with d(10) very positive; but never less than -3.40282E38. This is clearly some kind of wrap around problem when you reach the limit of a float. I decided that it is a probably a problem in IDL rather than the OS, because when I did not specify the yrange, IDL would supply a yrange that fit the DISPLAY and not the DATA. with out knowing details of how the plotting routines work I can't be sure; perhaps IDL feeds info to the graphics of what to plot; the graphics driver wraps around and then tells IDL what is about to draw and then IDL comes up with tick labels based on this. Perhaps there is some other sort of mischief afoot. Regardless, the problem seems to occur at the limit of a float on my system and probably the limit of a long 2147483647 on the pc's etc. MORAL: Don't stake your career on any plot if IDL complained while making it! If IDL does complain, find some other meaningful way to scale/display the data. -- David Theil campus box 389 Boulder, Colorado 80309 (303)492-0895 No guts, no glory.
creator: theil
date: 1995-06-16T07:00:00-00:00

Re: A big BUG in PLOT, SURFACE, ...
type: item
description: thompson@orpheus.nascom.nasa.gov (William Thompson) wrote: > There certainly > seems to be an OS dependence. > I am using version 3.6.1a under HP-Unix (hp-pa) here, should have mentioned before. Rolf
creator: Rolf P. W\"urtz
date: 1995-06-16T07:00:00-00:00

Re: A big BUG in PLOT, SURFACE, ...
type: item
description: "Rolf P. W\"urtz" <rolf> writes: > Philippe LATREMOLIERE <phlatrem@cnrs-orleans.fr> wrote: >> Try this : >> >> d = FINDGEN(100) >> d(10) = -1e15 >> PLOT, d, YRANGE = [0, 100] >> >> Is it a new bug from the great RSI ? >> -- > Well, it's not new. IDL 3.6.1 does the same. At least I get an error > message, namely two instances of "Program caused arithmetic error: > Floating overflow". Can't imagine what they're calculating there, though. > BTW, does anybody collect bugs like this -- would be good to scan that list > from time to time? In OSF/1 v2.0 I don't have any problems with IDL v3.6.1. In IDL 4.0 I do get the error messages, but the plot still comes out correctly. There certainly seems to be an OS dependence. Bill Thompson
creator: thompson
date: 1995-06-16T07:00:00-00:00

Re: A big BUG in PLOT, SURFACE, ...
type: item
description: Philippe LATREMOLIERE <phlatrem@cnrs-orleans.fr> wrote: > Try this : > > d = FINDGEN(100) > d(10) = -1e15 > PLOT, d, YRANGE = [0, 100] > > Is it a new bug from the great RSI ? > -- Well, it's not new. IDL 3.6.1 does the same. At least I get an error message, namely two instances of "Program caused arithmetic error: Floating overflow". Can't imagine what they're calculating there, though. BTW, does anybody collect bugs like this -- would be good to scan that list from time to time? Rolf +---------------------------------+------------------------- ------------------+ | Rolf P. W"urtz | URL: http://www.cs.rug.nl/~rolf/rolf.html | | Department of Computing Science | Email: rolf@cs.rug.nl | | University of Groningen | | | P.O. Box 800 | Phone: +31 50 63-6496 or | | 9700 AV Groningen | -3939 (dept. secr.) | | The Netherlands | Fax: +31 50 63-3800 | +---------------------------------+------------------------- ------------------+
creator: Rolf P. W\"urtz[1]
date: 1995-06-16T07:00:00-00:00

Re: A big BUG in PLOT, SURFACE, ...
type: item
description: In OpenVMS V6.1 and IDL V4.0, there are no error messages, but the negative number is plotted positive. Making d(10)=1e15 instead results in the off-scale value being plotted as though it were negative. Jonathan Boswell FDA/CDRH
creator: boswell
date: 1995-06-21T07:00:00-00:00