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

Home » Public Forums » archive » Re: Programming annoyances
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: Programming annoyances [message #45546 is a reply to message #45542] Fri, 09 September 2005 14:44 Go to previous message
Kenneth P. Bowman is currently offline  Kenneth P. Bowman
Messages: 585
Registered: May 2000
Senior Member
In article <1126300702.285794.90680@g43g2000cwa.googlegroups.com>,
swingnut@gmail.com wrote:

> I tried putting N_REFR into a separate pro file, but I got the same
> behavior. I eventually changed the function name to be N_refr, and now
> it seems to work but unreliably. I've fiddled with changing the
> function call to match, but the subtleties of case sensitivity seem to
> be showing up. This happens whether both at the IDL prompt and in
> idlde. In any case, what can cause this happen?

The function N_REFR should be in a file called n_refr.pro. Obviously
that file must be in IDL's search path. Internally IDL is case
insensitive, but filenames should be all lowercase for portability.

> Second, on the occasions when the program does run, when it reaches the
> end of the main procedure, IDL prints two or three error messages to
> the log:
>
> Program caused arithmetic error: Floating point divide by 0
> Program caused arithmetic error: Floating underflow
>
> and sometimes
>
> Program caused arithmetic error: Floating overflow
>
> I added a tracing statement to determine for sure that this happens at
> the end, and sure enough, it is not generated by anything in the code,
> though I could imagine it being generated by something being left ot at
> the end. Any ideas?

Floating underflow errors can usually be ignored safely.

Overflow and divide by zero errors generally should not be ignored
(unless you don't mind getting Inf's and NaN's for answers). You can
use the FINITE function to find Inf's and NaN's in your variables.
Personally, I make a point of ensuring that my programs do not generate
exceptions other than, possibly, underflows.

Check out the !EXCEPT system variable. Setting !EXCEPT = 2 forces IDL
to report exceptions after each IDL statement, which should help you
identify the exact location where the exception occurs.

Ken Bowman
[Message index]
 
Read Message
Read Message
Previous Topic: Fuzzy c Means algorithm implementation in IDL
Next Topic: Poscript Component Selection

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

Current Time: Sat Oct 11 08:53:24 PDT 2025

Total time taken to generate the page: 2.26957 seconds