From bug-octave-request at bevo dot che dot wisc dot edu Fri Mar 23 08:06:35 2001 Subject: Re: Is 0*Inf==NaN a good definition ? From: Christoph Spiel To: "'bug-octave UWISC'" Date: Fri, 23 Mar 2001 14:58:56 +0100 On Fri, Mar 23, 2001 at 10:32:56AM +0100, Rolf Fabian wrote: > John W. Eaton wrote: > > |Search google for "what every computer scientist should know about > |floating point arithmetic". That should turn up a paper that explains > |a lot about the rationale for IEEE floating point arithmetic rules. > |After you've read and understand it, then propose changes to the rules. > > I suppose the referenced article is > . > This article gives me the information that 0*Inf is set to NaN by IEEE754 > because it is defined as an invalid operation. But it doesn't provide any > rationale for the necessity of such a particular definition. Perhaps, > jwe may be right and I really didn't understand it correctly. If you need more rationale, W. Kahan's "Lecture notes on the status of IEEE Standard 754 for Binary Floating-Point Arithmetic", http://www.cs.berkeley.edu/~wkahan/ieee754status/ieee754.ps is a recommended reading. > Sorry for my ignorance, but I'm still deeply convinced, that with e.g. > the nilpotent matrices > > A = 0 Inf or B = 0 1 Inf > 0 0 0 0 1 > 0 0 0 You are opening Pandora's Box with your Infs. (1) Infs as well as NaNs are continuation values. They were introduced for computations to continue without the need for overly complicated flow control. Blindly interpreting them in the mathematical sense is problematic. (2) When I put on my porter hat, I see that continuation values are not supported on all systems; RS6K immediately comes to my mind. > the powers > > A^2 = 0 0 and B^2 = 0 0 1 B^3 = 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 > > make mathematical sense because A^2=ZERO and B^3==ZERO. ^^^^^^^^^^^^^^^^^^ We are dealing with numerics, and sometimes have to bite the bullet lim_{x -> 0} sin(x)/x = 1 is perfect, but 0/0 is not. > Of course, it's your choice to which kind of results you wish to > give preference. For the isolated operation 0 * Inf, the Standard is clear. For your particular case of multiplying very special matrices the behavior of NaNs could be used in your favor. NaNs were designed to carry information about their 'birthplace', to allow for later analysis. It is conceivable that you can postprocess the results of your matrix multiply and selectively act on NaNs with origin '0*Inf'. > Note, that I never proposed '0*Inf==0' to be the default setting, > but an experimental 'global do_non_IEEE_multiplication' (or similar) > switch would be of great help in this context. The definition goes right next to run_twice_as_fast = 1; use_less_memory = 1; only_produce_correct_results = 1; But seriously, it is not as easy as you might think it is. For you proposed flag to take effect, *every* multiplication operation must be mapped onto a library function which does the multiplication. This would include (i) all multiplications directly emitted by the interpreter, (ii) all built-in multiplications (e.g. inside libcruft), and (iii) each dynamically loaded (3rd party?) module. -cls -- Christoph L. Spiel Hammersmith Consulting, web: www.hammersmith-consulting.com Phone: +49-8022-662908, fax: +49-8022-662909 ------------------------------------------------------------- Octave is freely available under the terms of the GNU GPL. Octave's home on the web: http://www.octave.org How to fund new projects: http://www.octave.org/funding.html Subscription information: http://www.octave.org/archive.html -------------------------------------------------------------