Re: Numpy-discussion digest, Vol 1 #112 - 8 msgs
Python has *got* to ignore underflow exceptions. Otherwise, virtually any numeric calculation that subtracts numbers will fail for no good reason. Worse, it will fail in a very sporadic, data-dependent manner. With double precision numbers, the failures will be rare, but anyone doing computations with floats will see unwanted exceptions with noticeable frequency. I once did a numeric calculation (a SVD classifier) on a system with IEEE-754 underflow exceptions turned on, and I lost a good square inch of hair and a solid week of life because of it. At one point, the numbers were converted from doubles to floats, and about 1 in every 10,000,000 of the numbers were too small to represent as a float. So, in about 1 in ten runs (an hour each), the code would crash for no obvious reason. It was a debugging nightmare. If python catches underflows, I'm going back to FORTRAN. On less crucial topics, I'm strongly in favor of preserving NaN and Inf. If I want my code to crash when some computation goes awry, I'll use assert, and crash it myself. Any serious numeric code should be loaded with assertions (any code at all, in fact). Asking the interpreter to do it for you is a crude and blunt instrument. If I may ask, what kind of platforms are there where people do math where the hardware *won't* support IEEE-754?
If I may ask, what kind of platforms are there where people do math where the hardware *won't* support IEEE-754? _______________________________________________ The problem isn't that the hardware doesn't support it, although there used to be some important machines that didn't. (Burton Smith once told me that adding this to a supercomputer architecture slows down the cycle time by a very considerable amount, he guessed at least 20% if I recall correctly.) The problem is that access to control the hardware has no standard. Usually you have to get out the Fortran manual and look in the back if you're lucky. I've had computers where I couldn't find this information at all. Probably things have improved in the last few years but this situation is still not great. Worse, it needs to be a runtime control, not a compile option. As everyone who has tried it found out, actually using the Infs and NaN's in any portable way is pretty difficult. I prefer algorithmic vigor to prevent their appearance. While my opinion is a minority one, I wish the "standard" had never been born and I had my cycles back. It isn't really a standard, is it?
So, in about 1 in ten runs (an hour each), the code would crash for no obvious reason. It was a debugging nightmare. If python catches underflows, I'm going back to FORTRAN.
hear hear. or is that here here ;) but it is a scarey concept isn't it? i've pieced together an interactive python visualization environment (a clone of RSI's IDL in fact - nickbower.com/computer/pydl) and although i didn't write the plot engine, surely there's no way to "make the algorithm better" if you have no idea if the user will try to graph asymptotic curves for example. it's just not realistic to expect the compiler to bomb out and force the user to tweak the calculation limits.
On less crucial topics, I'm strongly in favor of preserving NaN and Inf. If I want my code to crash when some computation goes awry, I'll use assert, and crash it myself.
i'm in favour of this too. i think favouring people who don't want to come back after hours of code execution to find Nan and Inf arrays may shaft a great deal of people (be it a minority or not). nick
participants (3)
-
Greg Kochanski -
Nick Bower -
Paul F. Dubois