Re: Re: Zero does not Equal Zero is a feature

*To*: mathgroup at smc.vnet.net*Subject*: [mg31541] Re: Re: Zero does not Equal Zero is a feature*From*: Daniel Lichtblau <danl at wolfram.com>*Date*: Fri, 9 Nov 2001 06:13:58 -0500 (EST)*Approved*: Steven M. Christensen <steve@smc.vnet.net>, Moderator*References*: <9rdg39$7ob$1@smc.vnet.net> <200111071029.FAA26256@smc.vnet.net> <3BE9BECE.C10B9BE2@wolfram.com> <3BE9D357.EF93D808@cs.berkeley.edu>*Sender*: owner-wri-mathgroup at wolfram.com

>Yep. J. Symbolic Computing vol 13, no 5, May 1992. Also on line. Computation. And I have a copy. >Well I am not a historian of Mathematica, but I recall that >there were substantial changes in Interval and/or RealInterval which >I assumed required substantial redesign. The meaning of >N[expression,d] changed from "do the arithmetic using precision d" >to "give me the answer accurate to d digits". This is a major >change in my view. In mine as well, but if it happened it was more than 10 years ago. Any change in RealInterval is a minor issue. I am certain of that because I do not recall what RealInterval is/was in Mathematica. Interval has not changed in any substantial way in at least 7 years. It is possible that Jerry keiper made changes not too long before that although to the best of my recollection they were not large. >The meaning of Accuracy and Precision seems to have been altered >so that these became floating-point numbers. I feel a bit like Mark Fuhrmann might have felt at the Simpson trial when confronted with his past use of a particular epithet. Ya got me. That change was indeed within the last 10 years. It was introduced in version 2.1, about 9 years and 9 months ago. Note that this was more to make the internals work than an issue in design. Significance arithmetic does not work well if you cannot treat these as lying in a continuum. My recollection is that Jerry claimed this flaw was what led to that model being abandoned for a generation or so. >Since actual numerical analysis texts do not use these words, but use >relative and absolute error, it is in my view confusing to >someone who is trained in numerical analysis. Perhaps mildly so. According to Mark Sofroniou, "Higham's book states that, usually but not universally, precision means number of digits and accuracy usually mean the amount of computed error. Precision is the scale of the relative error which is related to the number of digits. Accuracy is the scale of the absolute error so it is related to the computed error. Thus the terms used in Mathematica are not exactly the same but they are not entirely unrelated." Alot of detail about Mathematica's arithmetic may be found in: http://library.wolfram.com/tutorials/ (click on the "Numerics in Mathematica" item). and Keiper, J.B. 1994. New numerical features of Mathematica. Wolfram Research Technical Report. Also Mark Sofroniou is collaborating on an up-to-date article discussing, among other things, the history of significance arithmetic in Mathematica (as well as indicating some more general numeric computation history). Though not about Mathematica per se, it will elucidate in some detail the Mathematica implementation of significance arithmetic. You may recall he sent you a draft perhaps two years ago. >I think Max/Min precision were not in early Mathematicas; I'm not certain. I think they were here when I arrived in '91. >I also suspect that SetAccuracy and SetPrecision have changed but I >don't recall how. I will say that these are yet evolving. But they are not heavily used in the way that N is. >I think the intention of a floating-point design should be >(a) minimum number of surprises >(b) ease of modeling / understanding >(c) clear definition >(d) high accuracy, wide range >(e) speed >(f) control (e.g. of exceptions) >(g) access to libraries >.. at least off the top of my head. First I'll point out that your set of desired attributes of a floating point package, while nice, may not be entirely attainable in practice. Some of the items will be at odds with others. That said, it is a reasonable wish list. >Mathematica's approach leads to >(a) difficult to explain transition from machine to software >floats. I think this one is not so hard except for issues wherein e.g. N[e,p] works in machine hardware arithmetic for p<=16. This is something we are addressing in our development kernel. I would not categorize this as a major redesign (especially given that N[e] behavior remains unchanged), but I agree neither is it entirely minor. Other issues regarding the hardware/software transition tend to be related to ability to represent a result of intemediate step in hardware floats. These are not so hard to fathom, and are almost certainly faced in similar ways by all floating point implementations that offer arbitrary precision. They do not strike me as being peculiar to Mathematica. >(b) difficult to explain model of error transmission/control It may be harder than fixed precision, because the latter really has no such model. Specifically, in fixed precision this is entirely a function of the algorithm, and error estimation is the job of the programmer. As I recall significance arithmetic uses estimates of error bounds based on derivatives. >(c) difficult implications to programming language (e.g. >what does == or === mean) I'm gonna pass on this one. >(d) duplication of interval computation as float computation It is an approximation thereof, is MUCH faster in practice, and I believe it is much easier to make work in the realm of complex numbers. >(e) slow speed Not entirely. It really depends on what you are doing. Linear algebra, for example, generally reguires fast fixed precision BLAS. While this is certainly an area in which we could improve, what we have now is not bad. For many other purposes the speed of significance as opposed to fixed precision arithmetic is not a serious issue. An indication of hiw version 4 of Mathematica fares regarding bignum arithmetic speed may be found at http://www.loria.fr/projets/mpfr/timings-mpfr2001-gmp3.1.1.html >> We are of course in the business of extending useful capabilities of >> Mathematica. Specific examples in response to the above would be of >> interest for such work. >Undoubtedly. They might also present a competitive advantage >to WRI, compared to (say) Maple. >I would hope that in such circumstances your company would >be happy to pay for consultation on such matters. :) Of course there is also the possibility of making such examples (which I imagine would indicate weaknesses in many programs, not just Mathematica) generally available rather than just to WRI. Daniel Lichtblau Wolfram Research Opinions expressed herein are mine and not to be taken as those of my employer.

**References**:**Re: Zero does not Equal Zero is a feature***From:*Richard Fateman <fateman@cs.berkeley.edu>

**Re: Complex Number Simultaneous Equation 2 Unknowns**

**Re: Re: Zero does not Equal Zero is a feature**

**Re: Re: Zero does not Equal Zero is a feature**

**Re: Re: Zero does not Equal Zero is a feature**