| Re: a BUG or not a BUG in IDL ? [message #6629] |
Fri, 19 July 1996 00:00 |
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
|
|
|
|
| Re: a BUG or not a BUG in IDL ? [message #6631 is a reply to message #6629] |
Fri, 19 July 1996 00:00  |
Peter Mason
Messages: 145
Registered: June 1996
|
Senior Member |
|
|
> I have a "warning in loops" for you guys...
<see original posting for routine>
> The first loop if OK, the second loop stops after the first
> iteration, but the last loop, just keeps going forever...
>
> Any comments ?
. With IDL 4.0.1 on DEC Alpha/OSF the first 2 loops work the same as on
your platform, but the third (setting counter to LONG) terminates
after 10 iterations.
. On Pentium/WinNT, the behaviour is the same as for Alpha/OSF, except that
a "floating point underflow" error gets reported.
. On SunOS 4.1.3, the behaviour is the same as on your platform, except that
the third loop actually terminates after 655361 iterations.
Something of a worry!
Are you using a "big-endian" machine by any chance?
Just a guess, but it would appear that FOR statements might be "compiled" in
such a way that there's no allowance for a change in the loop variables'
types. (Maybe for a little extra speed?) And, still guessing, if the loop
counter variable's type is changed within the loop, then just some of it
(e.g., the 16 bits at the lowest memory address for INT counters) is used
within the FOR statement. Finally, I'd guess that the FOR loop stores
something back into the actual loop-counter variable in a similarly weird
way. (This could account for FP loop-counters getting zapped into
denormals.)
Peter Mason
|
|
|
|
| Re: a BUG or not a BUG in IDL ? [message #6635 is a reply to message #6629] |
Fri, 19 July 1996 00:00 |
g.d.nowicki
Messages: 2
Registered: July 1996
|
Junior Member |
|
|
In article <4smb8g$5o@lace.colorado.edu>, liziola@piura.colorado.edu says...
>
> I have a "warning in loops" for you guys...
> Check this "stupid" routine:
>
> ;---------------------------------------
> print,'Integers'
> J = 0
> for I = 1,10 do begin
> print,I
> I = I + J
> endfor
>
[other code deleted]
> ;----------------------------------
>
> The first loop if OK, the second loop stops after the first
> iteration, but the last loop, just keeps going forever...
>
> Any comments ?
> At least should be a "WARNING" in the manual...
>
> Luis
> University of Colorado
>
HOLD IT!!!
You all seem to be missing the point. There is no language I know of that
recommends you modify a control variable within a FOR/DO loop. Results are
unpredictable. If fact, there are a fair number of compilers out there
that will produce an error if you mess with the control variable, not just a
warning.
As with any language, there are ways to shoot yourself in the foot. IDL
just allows you to do it differently.
-Greg
|
|
|
|
| Re: a BUG or not a BUG in IDL ? [message #6636 is a reply to message #6629] |
Fri, 19 July 1996 00:00 |
David Ritscher
Messages: 30
Registered: August 1995
|
Member |
|
|
> print,'Long'
> J = 0L
> for I = 1,10 do begin
> print,I
> I = I + J ; Here I am also changing the type of "I"
> ;if i gt 20 then stop
> endfor
> end
> ;----------------------------------
> The first loop if OK, the second loop stops after the first
> iteration, but the last loop, just keeps going forever...
> Any comments ?
> At least should be a "WARNING" in the manual...
I would call it not a bug, on philosophical grounds. IDL / PV-Wave is
not a strong-typed language. This has advantages and disadvantages.
One strong disadvantage is any strange behavior that results from
doing things one shouldn't do with crossing variable types.
Something I would like to see added to the language is some ability to
take more control over typing. For example, a system variable could
be created, !variable_typing. When set to 1, it would cause an error
each time that the type of a variable is changed, as in:
a = 1
a = 1.
% Assignment changes type of variable
I would also like to see a mechanism for controlling variable typing,
for example, !min_variable_type
where if this is set to the type of long integer, a=1 would create a
long integer, instead of the irksome and antiquated default of short
integer.
--
David Ritscher
Raum 47.2.401
Zentralinstitut fuer Biomedizinische Technik
Albert-Einstein-Allee 47
Universitaet Ulm
D-89069 ULM
Germany
Tel: ++49 (731) 502 5313
Fax: ++49 (731) 502 5315
internet: david.ritscher@zibmt.uni-ulm.de
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
