comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado

Home » Public Forums » archive » Re: a BUG or not a BUG in IDL ?
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Return to the default flat view Create a new topic Submit Reply
Re: a BUG or not a BUG in IDL ? [message #6629] Fri, 19 July 1996 00:00 Go to previous message
hahn is currently offline  hahn
Messages: 108
Registered: November 1993
Senior Member
"Luis E. Liziola" <liziola@piura.colorado.edu> wrote:

> I have a "warning in loops" for you guys...
> Check this "stupid" routine:

(snip]

> The first loop if OK, the second loop stops after the first
> iteration, but the last loop, just keeps going forever...

I checked this on IDL 4.01 for Windows but replaced the print statement by help.
It reflects that the type was changed. The 1st loop was ok., the second one
was terminated after the first iteration and *after* that a floating point
underflow was reported. The last loop was executed 10 times while variable
i was changed in type from fix to long.

> Any comments ?

As IDL is an interpreter it should either execute the loop as programmed
(changing the loop variable and the upper limit) or report an error. I would
prefer reporting an error because changing the type of a loop variable
is usually due to a programing error!

> At least should be a "WARNING" in the manual...

Well, a bug in the program is worth two in the documentation...

A "warning" in the manual is not sufficient. Who reads the manual
if he suffers from an infinite loop ?

What we see here is a clear bug in the interpreter. It should be reported to
RSI and fixed! No excuses accepted!

> Luis
> University of Colorado

Norbert Hahn
[Message index]
 
Read Message
Read Message
Read Message
Read Message
Previous Topic: missing data
Next Topic: reading files into arrays

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Wed Oct 08 19:57:49 PDT 2025

Total time taken to generate the page: 0.00384 seconds