Re: Can somebody explain this? [message #40997] |
Thu, 16 September 2004 23:06 |
sandrokan
Messages: 20 Registered: September 2004
|
Junior Member |
|
|
"Mark Hadfield" <m.hadfield@niwa.co.nz> ha scritto nel messaggio
news:cid9nd$6g5
>> Thank you, but if this answer has come from any help desk, I would find
>> it extremely unsatisfying...
>
> str="Well to be fair to RSI, they *have* provided an option to disable
this"
print, strmid(str,0,strpos(str, 'option')-2)+' patch :-) ' ;
Ok, just jocking. Thank you for your code lines, I will follow your
suggestion.
Ale
|
|
|
|
Re: Can somebody explain this? [message #41005 is a reply to message #40998] |
Thu, 16 September 2004 17:04  |
Mark Hadfield
Messages: 783 Registered: May 1995
|
Senior Member |
|
|
sandrokan wrote:
> Thank you, but if this answer has come from any help desk, I would find
> it extremely unsatisfying
Well to be fair to RSI, they *have* provided an option to disable this
feature/oddity. What they're saying is "Yes, we did think it was a cool
idea at the time, but now we think you shouldn't use it. To avoid
breaking existing code, we're not going to remove it, but we're going to
let users disable it in new code." Well, they don't actually say that in
the documentation, but it's there between the lines. Pretty reasonable IMHO.
Me, I put these declarations in all my code:
compile_opt DEFINT32
compile_opt STRICTARR
compile_opt STRICTARRSUBS
compile_opt LOGICAL_PREDICATE
--
Mark Hadfield "Ka puwaha te tai nei, Hoea tatou"
m.hadfield@niwa.co.nz
National Institute for Water and Atmospheric Research (NIWA)
|
|
|
|
Re: Can somebody explain this? [message #41021 is a reply to message #41018] |
Thu, 16 September 2004 11:32  |
James Kuyper
Messages: 425 Registered: March 2000
|
Senior Member |
|
|
sandrokan wrote:
...
> If any behaviour is a "feature", what can cosidered a "reported bug"?
When a system has been deliberately designed to provide the feature,
because of someone's belief that it's a desireable feature, and that
feature is documented, then it's not a bug.
|
|
|
Re: Can somebody explain this? [message #41022 is a reply to message #41021] |
Thu, 16 September 2004 11:09  |
sandrokan
Messages: 20 Registered: September 2004
|
Junior Member |
|
|
> Well, like a number of IDL features, it is handy if you know about it,
> dangerous if you don't. ;-)
Thank you, but if this answer has come from any help desk, I would find
it extremely unsatisfying :-(. I know less than 1% of the fortran or Matlab
(4 example)
feeatures, but it never heppened to spend so much time searching for a code
bug.
If any behaviour is a "feature", what can cosidered a "reported bug"?
> My advice to students is simple: understand roundoff error and don't ...
Yes, it was an example. The next in the list is: print, "777" ...
Ciao
Ale
|
|
|
Re: Can somebody explain this? [message #41027 is a reply to message #41022] |
Thu, 16 September 2004 07:46  |
Craig Markwardt
Messages: 1869 Registered: November 1996
|
Senior Member |
|
|
Matt Feinstein <nospam@here.com> writes:
> On Thu, 16 Sep 2004 08:16:57 -0500, Kenneth Bowman
> <k-bowman@null.tamu.edu> wrote:
>
>
>>
>> This is an obscure feature of using arrays as subscripts. See Building
>> IDL Applications, p 133.
...
>
> Whoa. Is there some, umm, logic behind this?
Yeah, crazy mountain-man logic.
My guess is that this is an IDL 1.0 "wouldn't it be cool if" feature,
but it is really a dangerous feature that open to accidental abuse.
The wouldn't it be cool aspect is that when one is using the list form
of indexing as a 1D lookup table, IDL's behavior automatically does
cropping to the table boundaries. Of course, not everybody has 1D
lookup tables, and not everybody wants the cropping behavior.
Craig
--
------------------------------------------------------------ --------------
Craig B. Markwardt, Ph.D. EMAIL: craigmnet@REMOVEcow.physics.wisc.edu
Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response
------------------------------------------------------------ --------------
|
|
|
Re: Can somebody explain this? [message #41028 is a reply to message #41027] |
Thu, 16 September 2004 07:42  |
K. Bowman
Messages: 330 Registered: May 2000
|
Senior Member |
|
|
In article <41499b92$1@x-privat.org>,
"sandrokan" <mura@remove.ifsi.rm.cnr.it> wrote:
> Thank you. At least, it is reported somewhere; anyway, I find it quite
> dangerous to introduce
> such a feature for array subscripting and not for scalars.
Well, like a number of IDL features, it is handy if you know about it,
dangerous if you don't. ;-)
> It is similar to
> permit "for" loops for
> not-integer values without accuracy....
> for i=0., 10, .1 do print, i
>
> ............
>
> 7.70000
>
> 7.79999
My advice to students is simple: understand roundoff error and don't
index loops with FLOATs unless you know *exactly* what you are doing.
Ken
|
|
|
Re: Can somebody explain this? [message #41029 is a reply to message #41028] |
Thu, 16 September 2004 06:57  |
Matt Feinstein
Messages: 33 Registered: July 2002
|
Member |
|
|
On Thu, 16 Sep 2004 08:16:57 -0500, Kenneth Bowman
<k-bowman@null.tamu.edu> wrote:
>
> This is an obscure feature of using arrays as subscripts. See Building
> IDL Applications, p 133.
>
> Clipping
>
> If an element of the subscript array is less than or equal to zero, the
> first element of the subscripted array is selected. If an element of the
> subscript array is greater than or equal to the last subscript in the
> subscripted array, the last element is selected. This clipping of out of
> bounds elements can be disabled within a routine by using the
> STRICTARRSUBS option to the COMPILE_OPT statement. (See the
> documentation for �COMPILE_OPT� in the IDL Reference Guide manual for
> details.) If STRICTARRSUBS is in force, then array subscripts that refer
> to out of bounds elements will instead cause IDL to issue an error and
> stop execution, just as an outof-range scalar subscript does.
Whoa. Is there some, umm, logic behind this?
Matt Feinstein
--
There is no virtue in believing something that can be proved to be true.
|
|
|
Re: Can somebody explain this? [message #41030 is a reply to message #41029] |
Thu, 16 September 2004 06:43  |
sandrokan
Messages: 20 Registered: September 2004
|
Junior Member |
|
|
"Kenneth Bowman" <k-bowman@null.tamu.edu> ha scritto nel messaggio
news:k-bowman-02112F.08165716092004@news.tamu.edu...
Thank you. At least, it is reported somewhere; anyway, I find it quite
dangerous to introduce
such a feature for array subscripting and not for scalars. It is similar to
permit "for" loops for
not-integer values without accuracy....
for i=0., 10, .1 do print, i
............
7.70000
7.79999
............
Regards,
Alex
|
|
|
Re: Can somebody explain this? [message #41031 is a reply to message #41030] |
Thu, 16 September 2004 06:16  |
K. Bowman
Messages: 330 Registered: May 2000
|
Senior Member |
|
|
In article <cibvt8$qmt$1@canarie.caspur.it>,
"sandrokan" <mura@remove.ifsi.rm.cnr.it> wrote:
> (Sorry if it is a faw)
> I've spend days of dubbunging and then I've found that, on 5IDL.2:
>
> IDL> a=intarr(4)
>
> IDL> a(4)=1
>
> % Attempt to subscript A with <INT ( 4)> is out of range.
>
> % Execution halted at: $MAIN$
>
> IDL> a([4])=1
>
> IDL> print, a(3)
>
> 1
>
>
>
> Isn't it strange? Maybe it is reported somewhere in some idl guide, but I
> still can't believe
>
> it is real....
>
>
>
> Alex
>
>
>
This is an obscure feature of using arrays as subscripts. See Building
IDL Applications, p 133.
Clipping
If an element of the subscript array is less than or equal to zero, the
first element of the subscripted array is selected. If an element of the
subscript array is greater than or equal to the last subscript in the
subscripted array, the last element is selected. This clipping of out of
bounds elements can be disabled within a routine by using the
STRICTARRSUBS option to the COMPILE_OPT statement. (See the
documentation for �COMPILE_OPT� in the IDL Reference Guide manual for
details.) If STRICTARRSUBS is in force, then array subscripts that refer
to out of bounds elements will instead cause IDL to issue an error and
stop execution, just as an outof-range scalar subscript does.
Ken Bowman
|
|
|