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

Home » Public Forums » archive » Re: Patch to userlib/deriv.pro to add MAX_VALUE keyword
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
Re: Patch to userlib/deriv.pro to add MAX_VALUE keyword [message #1553] Mon, 27 December 1993 15:23
thompson is currently offline  thompson
Messages: 584
Registered: August 1991
Senior Member
schmitt@ccfsun.nrl.navy.mil (Andrew Schmitt) writes:

> This is somewhat besides the point of the original posting, but it has to do
> with a (granted, nitpicking) bug in the userlib routine deriv.pro.
> You might as well fix it when you make the posted patch.

> Basically, here's a use of "float(...)" in deriv.pro that is unneeded,
> and makes the resulting answer wrong and/or inaccurate if any other type
> of data (complex, double, ...&c) is passed as the Y value.
> The unneeded usage of float occurs about here:

>> d = float(shift(y,-1) - shift(y,1))/(shift(x,-1) - shift(x,1))
> ^^^^^
> remove the "float", and the applicability of the routine improves.

Not having looked at the original source code, I'm not sure if this is the
case, but one can imagine that problems could occur if the call to FLOAT is
removed and SHIFT is one of the integer types. Another way to get around this,
without leading to errors if SHIFT is double-precision or complex, is to insert
a multiplication by 1.0 somewhere, e.g.

d = (1.0*shift(y,-1) - shift(y,1))/(shift(x,-1) - shift(x,1))

Of course, this does lead to some inefficiencies.

Bill Thompson
Re: Patch to userlib/deriv.pro to add MAX_VALUE keyword [message #1554 is a reply to message #1553] Mon, 27 December 1993 02:50 Go to previous message
nowicki is currently offline  nowicki
Messages: 11
Registered: May 1993
Junior Member
In Article <thompson.757008292@serts.gsfc.nasa.gov>
thompson@serts.gsfc.nasa.gov (William Thompson) writes:
> rfinch@water.ca.gov (Ralph Finch) writes:
>
>> Following context diff, when run through patch, will add the MAX_VALUE
>> keyword to the userlib function deriv.pro. However, I still believe
>> it would be better if IDL had the fundamental notion of missing values
>> built-in to their basic mathematics; IEEE NaN might be a good choice.
>> If IDL understood NaN's, you wouldn't even need keywords for missing
>> values or max_value (presuming that most usage of MAX_VALUE really is
>> for missing values).
>
> However, not all computer platforms use the IEEE standard. A notable exception
> is Digital's VAX platform, which represents a large proportion of IDL's
> users--in fact IDL came out of the VAX/PDP world before it was ported to Unix,
> etc. As far as I know, there's no equivalent concept to NaNs in the VAX
> architecture.
>
> Bill Thompson
>
> P.S. Although Digital's Alpha workstations support both the VAX and IEEE
> floating point standards, my understanding is that IDL uses the VAX floating
> point representation, at least within OpenVMS, for backwards compatibility with
> the VAX/VMS architecture. I'm not sure which is used in OSF/1, although it
> would seem most advantageous to use the IEEE format for compatibility with
> MIPS/Ultrix workstations. I'm also not certain whether there's a performance
> tradeoff between using VAX and IEEE floating point numbers on the Alpha.

I can expand on some of the above. The AXP (Alpha) architecture supports
BOTH VAX (F and G) and IEEE (S and T) real formats. The conversion is done
in PAL code, (the equivalent of microcode on the CPU.) OpenVMS IDL 3.5.0
uses VAX real formats for I/O, I can't state for sure if the internal
representation is VAX (although, I'm pretty sure it is.)

OSF/1 uses IEEE exclusively, but I believe there's a compiler switch which
allows the reading and writing of VAX format in HLL's.

As far as I can tell, the performance tradeoff is nill due to the use of
PAL code routines for conversion.

-Greg

/* Greg Nowicki | Mail Stop 401A | LIDAR Applications Group */
/* NASA Langley Research Center | Hampton, Virginia 23681-0001 */
/* Voice: (804) 864-2713 | FAX: (804) 864-7790 */
/* nowicki@tardis.larc.nasa.gov | My opinions and mine alone . . . */
Re: Patch to userlib/deriv.pro to add MAX_VALUE keyword [message #1555 is a reply to message #1554] Mon, 27 December 1993 12:34 Go to previous message
schmitt is currently offline  schmitt
Messages: 3
Registered: December 1993
Junior Member
This is somewhat besides the point of the original posting, but it has to do
with a (granted, nitpicking) bug in the userlib routine deriv.pro.
You might as well fix it when you make the posted patch.

Basically, here's a use of "float(...)" in deriv.pro that is unneeded,
and makes the resulting answer wrong and/or inaccurate if any other type
of data (complex, double, ...&c) is passed as the Y value.
The unneeded usage of float occurs about here:

> d = float(shift(y,-1) - shift(y,1))/(shift(x,-1) - shift(x,1))
^^^^^
remove the "float", and the applicability of the routine improves.

---------------
Andy Schmitt / Code 6730 / Naval Research Lab / Washington DC 20375
schmitt@this.nrl.navy.mil
usual disclaimers apply
Re: Patch to userlib/deriv.pro to add MAX_VALUE keyword [message #1556 is a reply to message #1554] Mon, 27 December 1993 08:04 Go to previous message
thompson is currently offline  thompson
Messages: 584
Registered: August 1991
Senior Member
rfinch@water.ca.gov (Ralph Finch) writes:

> Following context diff, when run through patch, will add the MAX_VALUE
> keyword to the userlib function deriv.pro. However, I still believe
> it would be better if IDL had the fundamental notion of missing values
> built-in to their basic mathematics; IEEE NaN might be a good choice.
> If IDL understood NaN's, you wouldn't even need keywords for missing
> values or max_value (presuming that most usage of MAX_VALUE really is
> for missing values).

However, not all computer platforms use the IEEE standard. A notable exception
is Digital's VAX platform, which represents a large proportion of IDL's
users--in fact IDL came out of the VAX/PDP world before it was ported to Unix,
etc. As far as I know, there's no equivalent concept to NaNs in the VAX
architecture.

Bill Thompson

P.S. Although Digital's Alpha workstations support both the VAX and IEEE
floating point standards, my understanding is that IDL uses the VAX floating
point representation, at least within OpenVMS, for backwards compatibility with
the VAX/VMS architecture. I'm not sure which is used in OSF/1, although it
would seem most advantageous to use the IEEE format for compatibility with
MIPS/Ultrix workstations. I'm also not certain whether there's a performance
tradeoff between using VAX and IEEE floating point numbers on the Alpha.
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: FORTRAN Sbrs. to Read .xdr Formatted Files?
Next Topic: JHU/APL IDL library update notice

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

Current Time: Fri Oct 10 02:42:48 PDT 2025

Total time taken to generate the page: 0.64367 seconds