Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.soft-sys.math.mathematica > #3468 > unrolled thread

Numerical accuracy/precision - this is a bug or a feature?

Back to article view | Back to comp.soft-sys.math.mathematica

Contents

  Numerical accuracy/precision - this is a bug or a feature? "slawek" <slawek@host.pl> - 2011-07-04 10:47 +0000
    Re: Numerical accuracy/precision - this is a bug or a feature? "Kevin J. McCann" <kjm@KevinMcCann.com> - 2011-07-04 11:14 +0000
      Re: Numerical accuracy/precision - this is a bug or a feature? "slawek" <slawek@host.pl> - 2011-07-05 09:17 +0000
        Re: Numerical accuracy/precision - this is a bug or a feature? "Kevin J. McCann" <Kevin.McCann@umbc.edu> - 2011-07-06 09:35 +0000
          Re: Numerical accuracy/precision - this is a bug or a feature? "slawek" <slawek@host.pl> - 2011-07-07 11:40 +0000
        Re: Numerical accuracy/precision - this is a bug or a feature? Daniel Lichtblau <danl@wolfram.com> - 2011-07-07 11:34 +0000
      Re: Numerical accuracy/precision - this is a bug or a feature? "Oleksandr Rasputinov" <oleksandr_rasputinov@hmamail.com> - 2011-07-06 09:39 +0000
        Re: Numerical accuracy/precision - this is a bug or a feature? Richard Fateman <fateman@cs.berkeley.edu> - 2011-07-07 11:33 +0000
      Re: Numerical accuracy/precision - this is a bug or a feature? Noqsi <noqsiaerospace@gmail.com> - 2011-07-08 08:51 +0000
        Re: Numerical accuracy/precision - this is a bug or a feature? "slawek" <slawek@host.pl> - 2011-07-12 11:01 +0000
      Re: Numerical accuracy/precision - this is a bug or a feature? "Oleksandr Rasputinov" <oleksandr_rasputinov@hmamail.com> - 2011-07-08 09:04 +0000
        Re: Numerical accuracy/precision - this is a bug or a feature? Richard Fateman <fateman@cs.berkeley.edu> - 2011-07-09 11:34 +0000
        Re: Numerical accuracy/precision - this is a bug or a feature? "slawek" <slawek@host.pl> - 2011-07-12 11:02 +0000
      Re: Numerical accuracy/precision - this is a bug or a feature? "Oleksandr Rasputinov" <oleksandr_rasputinov@hmamail.com> - 2011-07-09 11:37 +0000
        Re: Numerical accuracy/precision - this is a bug or a feature? Noqsi <noqsiaerospace@gmail.com> - 2011-07-13 07:11 +0000
          Re: Numerical accuracy/precision - this is a bug or a feature? Richard Fateman <fateman@cs.berkeley.edu> - 2011-07-14 09:23 +0000
          Re: Numerical accuracy/precision - this is a bug or a feature? Andrzej Kozlowski <akoz@mimuw.edu.pl> - 2011-07-15 01:19 +0000
          Re: Numerical accuracy/precision - this is a bug or a feature? "W. Craig Carter" <ccarter@mit.edu> - 2011-07-15 01:25 +0000
          Re: Numerical accuracy/precision - this is a bug or a feature? Andrzej Kozlowski <akoz@mimuw.edu.pl> - 2011-07-15 08:12 +0000
          Re: Numerical accuracy/precision - this is a bug or a feature? Andrzej Kozlowski <akoz@mimuw.edu.pl> - 2011-07-16 09:45 +0000
          Re: Numerical accuracy/precision - this is a bug or a feature? Andrzej Kozlowski <akoz@mimuw.edu.pl> - 2011-07-16 09:40 +0000
      Re: Numerical accuracy/precision - this is a bug or a feature? Noqsi <noqsiaerospace@gmail.com> - 2011-07-13 07:12 +0000
      Re: Numerical accuracy/precision - this is a bug or a feature? Noqsi <noqsiaerospace@gmail.com> - 2011-07-15 01:23 +0000
        Re: Numerical accuracy/precision - this is a bug or a feature? Richard Fateman <fateman@cs.berkeley.edu> - 2011-07-15 08:10 +0000
      Re: Numerical accuracy/precision - this is a bug or a feature? Noqsi <noqsiaerospace@gmail.com> - 2011-07-16 09:41 +0000
        Re: Numerical accuracy/precision - this is a bug or a feature? Richard Fateman <fateman@cs.berkeley.edu> - 2011-07-17 10:02 +0000
          Re: Numerical accuracy/precision - this is a bug or a feature? "slawek" <slawek@host.pl> - 2011-07-18 10:14 +0000
        Re: Numerical accuracy/precision - this is a bug or a feature? Andrzej Kozlowski <akoz@mimuw.edu.pl> - 2011-07-18 10:17 +0000
          Re: Numerical accuracy/precision - this is a bug or a feature? Richard Fateman <fateman@cs.berkeley.edu> - 2011-07-19 10:55 +0000
    Re: Numerical accuracy/precision - this is a bug or a feature? "Kevin J. McCann" <kjm@KevinMcCann.com> - 2011-07-04 11:18 +0000
      Re: Numerical accuracy/precision - this is a bug or a feature? Richard Fateman <fateman@cs.berkeley.edu> - 2011-07-05 09:15 +0000
        Re: Numerical accuracy/precision - this is a bug or a feature? "slawek" <slawek@host.pl> - 2011-07-06 09:34 +0000
        Re: Numerical accuracy/precision - this is a bug or a feature? Daniel Lichtblau <danl@wolfram.com> - 2011-07-07 11:35 +0000
          Re: Numerical accuracy/precision - this is a bug or a feature? Richard Fateman <fateman@cs.berkeley.edu> - 2011-07-08 08:53 +0000

Page 2 of 2 — ← Prev page 1 [2]

#3757

I should have added that actually Mathematica's significance arithmetic 
is considerably more sophisticated than the description as a "first 
order" approximation suggests. This is also explained by Sofroniou and 
Spaletta:

Numerical algorithms for computing elementary functions can be written 
in terms of addition and multiplication at some level. However, relying 
on the error propagation rules for these operations would often give 
very pessimistic error bounds in significance arithmetic. Much tighter 
bounds can be obtained by directly imposing error estimates based on 
properties of functions during their numerical computation.

In other words, Mathematica uses special estimates for a variety of 
functions, based on properties of these functions and thus obtains bounds 
are considerably tighter than a simple minded approach would produce.

Andrzej Kozlowski


On 15 Jul 2011, at 10:09, Andrzej Kozlowski wrote:

> You are clearly confusing significant digit arithmetic, which is not
> what Mathematica uses, with significance arithmetic, which is a first
> order approximation to interval arithmetic or distribution based
> approach. Obviously you don't read the posts you reply to and confuse
> both the posters and the contents of what they post. Here is a quote
> from Oleksandr Rasputionov that makes this completely clear:
>
>
> Unfortunately so, given that it is severely erroneous: see e.g.
> <http://www.av8n.com/physics/uncertainty.htm>. However, Mathematica's
> approximation of how these uncertainties propagate is first-order, not
> zeroth-order. This does not make it completely reliable, of course, but
> certainly it is not almost always wrong as is the significant digits
> convention. Within the bounds of its own applicability, Mathematica's
> approximation is reasonable, although it would still be a mistake to apply
> it to experimental uncertainty analysis given the much broader scope of
> the latter.
>
> Note the "first-order not zeroth-order". Also, do take a look at Sofroniou and Spaletta and then you may perhaps understand what "order" means and how "significance arithmetic" differs from the "significant digits" convention. Good grief, did you ever learn about the Taylor series? It must have been a long time ago, I take.
>
>
> Andrzej Kozlowski
>
>
> On 14 Jul 2011, at 19:55, Richard Fateman wrote:
>
>> On 7/14/2011 6:27 AM, Andrzej Kozlowski wrote:
>>> On 14 Jul 2011, at 11:21, Richard Fateman wrote:
>>>
>>>> On 7/13/2011 12:11 AM, Noqsi wrote:
>>>> ..
>>>>
>>>>>> see e.g.
>>>>>> <http://www.av8n.com/physics/uncertainty.htm>.
>>>>>
>>>> ..
>>>> Learning mathematics from a physicist is hazardous.
>>>> Learning computer science from a physicist is hazardous too.
>>>> Numbers in a computer are different from experimental measurements.
>>>>
>>>>
>>>> nevertheless, I like this article.  It says, among other things,
>>>>
>>>> 	The technique of propagating the uncertainty from step to step
>>>> throughout the calculation is a very bad technique. It might sometimes
>>>> work for super-simple textbook problems but it is unlikely to work for
>>>> real-world problems.
>>>>
>>> Well, here is a quote from a very well known book on numerical
> analysis by a mathematician (Henrici, "Elements of Numerical Analysis").
>>>
>>>
>>>> It is plain that, on a given machine and for a given problem, the local
>>>> rounding errors are not, in fact, random variables. If the same problem
>>>> is run on the same machine a number of times, there will result always the
>>>> same local rounding errors, and therefore also the same accumulated
>>>> error. We may, however, adopt a stochastic model of the propagation of
>>>> rounding error, where the local errors are treated as if they were random
>>>> variables. This stochastic model has been applied in the literature to a
>>>> number of different numerical problems and has produced results that are
>>>> in complete agreement with experimentally observed results in several
>>>> important cases.
>>>
>>> The book then describes the statistical method of error propagation of which Mathematica's approach can be regarded as a first order approximation (as pointed out by Oleksandr Rasputinov, who should not be confused with the OP of this thread so:
>>
>> So are we to conclude that Henrici recommends this as a general  numerical computational method?
>>
>> I don't see that here.  I think what he is saying is that if you do some mathematics (see below), then
>> you will get results consistent with what you will get if you actually run the experiment on the computer.
>> This is not surprising. It is a result that says that "theoretical" numerical analysis agrees with
>> "computer experiments" in arithmetic.  It doesn't say Henrici recommends running a computation this way.
>>
>> When Henrici says "adopt a stochastic model ...."  he doesn't mean to write a program. He means to
>> think about each operation like this..  (I show for multiplication of numbers P and Q with errors a b resp.)
>>
>> P*(1+a)  times Q*(1+b)   P*Q *(1+a)*(1+b)* (1+c)   where c is a new "error" bounded by roundoff, e.g. half unit in last place.
>>
>> For each operation in the calculation, make up another error letter... a,b,c,d,e,f,g...
>> assume they are uncorrelated.
>>
>> The fact that this theoretical approach and numerically running "several important cases" is a statement
>> about correlation of roundoff in these cases, not a statement of advisability of whatever for a model of
>> how to write a computer system.
>>
>> By the way, I think that Henrici was an extremely fine theoretical numerical analyst, and a fine writer too.
>>
>>
>>
>>>> Clearly Rasputinov thinks that if they are not equal they should not be
>>>> Equal.  Thus the answer is False.
>>> is *clearly* False. In fact Oleksander expressed something closer to the opposite view.)
>> This thread is too long.   I don't know at this point if you are agreeing that it is false or contradicting that "is False" is false.
>>> And if one quote is not enough, here is another, from another text on numerical analysis. (Conte, de Boor, ""Elementary Numerical Analysis).
>>> It describes 4 approaches to error analysis, interval arithmetic, significant-digit arithmetic, the "statistical approach" and backward error analysis. Here is what it says about the second and the third one:
>> Huh, if we are talking about the second and third one, why does he say third and fourth?
>> Are you using 0-based indexing and deBoor is using 1-based indexing????
>>
>>
>>>> A third approach is significant-digit arithmetic. As pointed out earlier, whenever two nearly equal machine numbers are subtracted, there is a danger that some significant digits will be lost. In significant-digit arithmetic an attempt is made to keep track of digits so lost. In one version
>>>> only the significant digits in any number are retained, all others being discarded. At the end of a computation we will thus be assured that all digits retained are significant. The main objection to this method is that some information is lost whenever digits are discarded, and that the results obtained are likely to be much too conservative. Experimentation with this technique is still going on, although the experience to date is not too promising.
>>>>
>> OK, so deBoor (who is retired and therefore not likely to revise the "experience to date")  says this method  "is not too promising".
>> This sounds to me like he is not endorsing what Mathematica does.
>>
>>>> A fourth method which gives considerable promise of providing an adequate mathematical theory of round-off-error propagation is based on a statistical approach. It begins with the assumption that round-off errors are independent. This assumption is, of course, not valid, because if the same problem is run on the same machine several times, the answers will always be the same. We can, however, adopt a stochastic model of the propagation of round-off errors in which the local errors are treated as if they were random variables. Thus we can assume that the local round-off errors are either uniformly or normally distributed between their extreme values. Using statistical methods, we can then obtain the standard devia- tion, the variance of distribution, and estimates of the accumulated round- off error. The statistical approach is considered in some detail by Ham- ming [1] and Henrici [2]. The method does involve substantial analysis and additional computer time, but in the ex!
> periments conducted to date it has obtained error estimates which are in remarkable agreement with experimentally available evidence.
>> deBoor is essentially quoting Henrici, and this statistical approach is to say that all those error terms I mentioned above,  a,b,c,d,e,f,...
>> can be chosen from some distribution   (the way I've written it,  a ,....,z ....   would essentially be chosen from {-u,u} where u  == 2^(-W) where the fraction part of the floating-point number is W bits.  )   and you can compute the final expression as ANSWER+<somehorrendousfunctionof>(a,b,c,....).
>>
>> What deBoor says is that this (theoretical numerical analysis) "method" promises to provide
>> a theory of round-off error propagation.   He is not saying this is a practical method for scientific computing.  When he uses the work "method"
>> he means a mathematical method for analyzing roundoff.
>>
>> In any case, Mathematica does not do this.  I would further argue that Mathematica makes it hard to carry out the experiments that might be done to demonstrate that  this theory applied in any particular sample computation.
>>>
>>> The fundamental paper of Mathematica's error propagation is "Precise numerical computation" by Mark Sofroniou and  Giulia Spaletta in The Journal of Logic and Algebraic Programming 64 (2005) 1139=6134. This paper describes Mathematica's "significance arithmetic" as a first order approximation to Interval Arithmetic. It makes no mention of distributions.
>> I thought I read this paper in some Mathematica documentation or conference proceedings.
>>> Oleksandr Rasputionov, in an earlier post here, interpreted  "significance arithmetic" as a first order approximation to the fourth method above.
>> Huh? First of all, the original poster was slawek.  Rasputinov seems to think that Mathematica numbers are like Intervals  (basically a good intuition until you think about equality.) and refers to them as distributions.  This is not deBoor's 4th "method" of theoretically analyzing round-off.
>> In fact it is deBoor's 1st method, interval arithmetic.  This has the advantage of being maybe 4 to 8 times slower than regular arithmetic, and also has a huge literature  (see "Reliable Computation") describing variations, advantages, disadvantages, etc.
>>
>>> I have not considered this very carefully, but it seems pretty clear that he is right, and that the two "first order" approximations are in fact isomorphic.
>> Uh, this is unclear, unless you mean that Mathematica's number system is essentially interval arithmetic, but with a confusing front end.
>>> The first order approach is, of course, justified on grounds of performance. It is perfectly "rigorous" in the same sense as any "first order" approach is (i.e. taking a linear approximation to the Taylor series of a non-linear function). It works fine under certain conditions and will produce nonsense when these conditions do not hold.
>>>
>>> The fact that significance arithmetic is "useful" needs no justification other than the fact that it is used successfully by NSolve and Reduce in achieving validated symbolic results by numerical methods which are vastly faster than purely symbolic ones.
>> Really?
>>
>> 1. This does not mean that other methods, e.g. validated methods for accurately evaluating polynomials (etc)  NOT based on significance arithmetic would not be faster and better.  DanL claims it is used and useful there, so that's nice.  BUT..
>>
>> 2. This does not mean that this arithmetic should be used by default by user arithmetic.
>>> It is also useful, for users such as myself, who sometimes need fast first order error anlysis.
>> OK, If you find it useful yourself, fine. I daresay you are not a typical user.
>>
>>> I have lots of posts by Richard on this topic (or perhaps it was the same post lots of time, it's so hard to tell), but I have never understood what his main point is.
>>
>> Main points:  Mathematica's number system is non-standard, peculiar, hard to explain,  capable of returning mysterious non-answers without indications of error to innocent users, a bad foundation for building higher-level functionality.
>>
>> I have other criticisms of Mathematica, but I think that the sentence above is enough for you to process today.
>>
>>> It seems to me that is because he himself has not yet decided this, although he has been posting on this topic for over 20 years (I think).
>>
>>> Sometimes he seems to be disparaging significance arithmetic itself.
>> I think deBoor did that.
>>
>>> When Daniel points out how effective it is in his implementation of numerical Groebner basis, or in Adam Strzebonski's work on Reduce, he either ignores this altogether or claims that Groebner bases, etc.  are themselves not "useful".
>> I think Reduce is a very nice program when it works. If I am not mistaken, all work on numerical Groebner basis should be reducible to the evaluation of polynomials, for which there are faster and more accurate methods available not using significance arithmetic.  On the other hand, I might be mischaracterizing DanL work, since I admit to not having studied it.
>>
>>
>>> On other occasions he takes on the role of the defender of the interest of the "naive user" (presumably like the OP, who however would be better described as "intentionally naive") who is going to be confused by the "quirky" nature of significance arithmetic (at low =
precision).
>> No, I don't think that slawek was a "troll".  I think he was =
genuinely confused, as might anyone be who has some prior computer =
arithmetic exposure and for the first time encounters a system with =
exact rational arithmetic.
>>> In doing so he conveniently ignores that fact of the existence of =
thousands of "naive users" who never become confused (sometimes because =
they always work with machine precision numbers and only use =
significance arrhythmic unknowingly, e.g. when using Reduce).
>> Most naive users don't tread near the dangerous spots. Some naive =
users never notice that their answers are nonsense.
>> Every so often we get a naive user who DOES notice, and he/she sends =
email to this newsgroup.
>>> And moreover, for those who do find a need for some sort of error =
analysis he offers no alternative, except perhaps to learn backward =
error analysis.
>> Actually, there's a whole bunch of libraries of methods with error =
estimates for common computations, where backward error analysis or some =
other method was used to provide extra information.
>>
>>> Except, of course, that should they do so they would no longer be =
"naive" and thus outside of Richard's area of concern.
>> They would probably not be writing in Mathematica.
>>> And in any case, anyone who needs and understands backward error =
analysis can use it now, and can't imagine that even Richard would claim =
that reducing users' options is a good thing.
>> I have no problem with Mathematica providing as an option, some other =
arithmetic.  It is WRI that has made it rather hard for the user to
>> figure out how to  "use the arithmetic of the rest of the world".
>>
>>> Finally, perhaps all that Richard is so upset about is simply =
Mathematica's habit of defining numbers as "fuzz balls" or =
"distributions".
>> I'm not sure that "upset" is the right term.  After all, I don't have =
to use Mathematica for numerical computation. And I rarely do.
>>> In other words, if Mathematica used a more usual "definition" of =
number, and used significance arithmetic for "error" propagation, that =
would be done by applying some separate function or turning on an =
option,  than everything would be fine?
>> Actually, that's pretty close to correct.
>>> If that is all, than it seems to me that Richard has for years been =
making mountains of molehills.
>> So why are you (and WRI)  so opposed to this notion?  Note that it =
would also have to affect other parts of the system including of course,
>> Equal and friends.
>>
>>
>>>
>>> Andrzej Kozlowski
>>>
>>>
>>>
>>>
>>
>>
>
>

[toc] | [prev] | [next] | [standalone]

#3697

On Jul 12, 4:01 am, "slawek" <sla...@host.pl> wrote:
> U=BFytkownik "Noqsi" <noqsiaerosp...@gmail.com> napisa=B3 w wiadomo=B6ci grup
> dyskusyjnych:iv6gf9$ru...@smc.vnet.net...
>
> > On Jul 7, 5:40 am, "slawek" <sla...@host.pl> wrote:
>
> >> The convention that 2.0 is less accurate than 2.00 is applied ONLY in
> >> Mathematica (the computer program).
>
> > Not true. This is a long-standing convention in experimental science.
>
> There is no such convention.

You mean you're not familiar with it. But it exists.

> There is always possible that 2.00 +- 0.53 .

That's a different convention. It also exists.

> Nobody should believe that 2.00 is more exact than 2.0 or even 2 . (If so,
> then 2 Pi have got 10% std. dev. ;)

There are different traditions here. Those who use the "2.00" to
indicate that further digits are unknown do generally not find "2 Pi"
confusing. The clash of conventions in engineering, though, is more
troublesome, where the units change by factors of 1000 and fractions
are often avoided. So, does "200 mm" mean "0.2 m" or "0.200 m"? Still,
this rarely causes serious confusion.

[toc] | [prev] | [next] | [standalone]

#3726

On Jul 14, 2:23 am, Richard Fateman <fate...@cs.berkeley.edu> wrote:
> On 7/13/2011 12:11 AM, Noqsi wrote:
> ..
>
> >> see e.g.
> >> <http://www.av8n.com/physics/uncertainty.htm>.
>
> ..
> Learning mathematics from a physicist is hazardous.

In some ways. But if you want to relate mathematics to reality, you
might do well to consider the viewpoints of physicists.

> Learning computer science from a physicist is hazardous too.

Learning computer science from computer scientists is in some ways
worse, unless your interest is pointless bit pushing. Matthew 23:24 is
very relevant (some things never change).

In extracting useful results from computers in the real world
ignorance of the application domain is more debilitating than
ignorance of computer science. One can muddle through the latter, but
not the former.

Consider the howler you yourself committed a little while ago,
discussing the role of computers in the Apollo moon landings:

> you've got to wonder how the Russians, probably WITHOUT much in the way
> of computers, put up an artificial satellite.

This illustrates a profound ignorance of the problem. If you don't
care what orbit you go into, the computations are readily performed by
slide rule ahead of time. But Apollo had to perform a series of
precise maneuvers using imprecise rockets, with repeated re-
computation of the trajectories. For the early missions, they didn't
even know the lunar gravity very well, so actual orbits diverged
rapidly from predictions even when the initial conditions were known.
Apollo's indirect "lunar orbital rendezvous" approach was thus a
triumph of computation. Even the Saturn V was not big enough to
support the less computationally intensive direct approach.

Perhaps the "programmer" I learned the most from in a long career was
a physicist whose code was littered with silly (from a CS point of
view) constructions like:

       TA=(COS(EA)-EC)/(1.-EC*COS(EA))
        IF(ABS(TA).GT.1.) TA=SIGN(.99999,TA)
        TA=ACOS(TA)

What was so great about his code? It's that every program he wrote was
an illuminating exercise in extracting important knowledge from
measurable information. The sloppy technique didn't matter so much. He
put rigor into the place it really counted: serving the needs of his
research. There were several much better technical programmers in that
research group, but they were not as good at conceptualizing how to
actually *use* the computer, rather than simply programming it.

> Numbers in a computer are different from experimental measurements.

But the experimental measurements relate much better to reality.

>
> nevertheless, I like this article.  It says, among other things,
>
>         The technique of propagating the uncertainty from step to=
 step
> throughout the calculation is a very bad technique. It might sometimes
> work for super-simple =93textbook=94 problems but it is unlikely to work =
for
> real-world problems.

Except that error propagation techniques are used successfully in many
fields. Your cell phone works because engineers found a good balance
of power consumption and radio sensitivity from error propagation
methods, rather than the impractical method of tracking each electron
through the circuits. Getting back to orbits, one extremely useful
application of error propagation is to use it "backwards" to determine
which observations would best improve knowledge of an orbit.

There is no universal method for tracking uncertainty that is accurate
and practical. Your own ideologically favored method, interval
arithmetic, yields unrealistically large estimates of error in many
cases, and that can be a very bad thing. Or it can be useful to have
an upper bound. What's good depends on what the *application* needs,
not some ivory tower ideology.

I am *really* tired of your smug, patronizing attitude. You're a blind
man attempting to explain a rainbow. Why not, instead of whining all
the time that Mathematica doesn't conform to your profoundly narrow
notions of what computation is, spend some time with it actually
computing something of relevance to the real world? If you were
actually interested in applications, you would *rejoice* in the fact
that there are a variety of approaches available. But instead, you
obviously see Mathematica as a threat to your narrow ideology.

[toc] | [prev] | [next] | [standalone]

#3741

On 7/14/2011 6:23 PM, Noqsi wrote:
> On Jul 14, 2:23 am, Richard Fateman<fate...@cs.berkeley.edu>  wrote:
>> On 7/13/2011 12:11 AM, Noqsi wrote:
>> ..
>>
>>>> see e.g.
>>>> <http://www.av8n.com/physics/uncertainty.htm>.
>>
>> ..
>> Learning mathematics from a physicist is hazardous.
>
> In some ways. But if you want to relate mathematics to reality, you
> might do well to consider the viewpoints of physicists.
>
>> Learning computer science from a physicist is hazardous too.
>
> Learning computer science from computer scientists is in some ways
> worse, unless your interest is pointless bit pushing. Matthew 23:24 is
> very relevant (some things never change).

I suppose it depends on what you mean by computer science.

>
> In extracting useful results from computers in the real world
> ignorance of the application domain is more debilitating than
> ignorance of computer science. One can muddle through the latter, but
> not the former.

I think you may be confusing "computer science"  with "applications of
computers to whatever [e.g. physics, engineering, business]"  which is 
usually taught in the department of 'whatever'.
>
> Consider the howler you yourself committed a little while ago,
> discussing the role of computers in the Apollo moon landings:
>
>> you've got to wonder how the Russians, probably WITHOUT much in the way
>> of computers, put up an artificial satellite.
>
> This illustrates a profound ignorance of the problem. If you don't
> care what orbit you go into, the computations are readily performed by
> slide rule ahead of time. But Apollo had to perform a series of
> precise maneuvers using imprecise rockets, with repeated re-
> computation of the trajectories. For the early missions, they didn't
> even know the lunar gravity very well, so actual orbits diverged
> rapidly from predictions even when the initial conditions were known.
> Apollo's indirect "lunar orbital rendezvous" approach was thus a
> triumph of computation. Even the Saturn V was not big enough to
> support the less computationally intensive direct approach.

Do you know for a fact that the Russians didn't care what orbit the 
first manned satellite had?
>
> Perhaps the "programmer" I learned the most from in a long career was
> a physicist whose code was littered with silly (from a CS point of
> view) constructions like:
>
>         TA=(COS(EA)-EC)/(1.-EC*COS(EA))
>          IF(ABS(TA).GT.1.) TA=SIGN(.99999,TA)
>          TA=ACOS(TA)
>
> What was so great about his code? It's that every program he wrote was
> an illuminating exercise in extracting important knowledge from
> measurable information. The sloppy technique didn't matter so much. He
> put rigor into the place it really counted: serving the needs of his
> research. There were several much better technical programmers in that
> research group, but they were not as good at conceptualizing how to
> actually *use* the computer, rather than simply programming it.

I think you are confusing application knowledge with computer science.
It is fairly clear that computer scientists cannot be held responsible 
for the content of all programs.
>
>> Numbers in a computer are different from experimental measurements.
>
> But the experimental measurements relate much better to reality.

The computation deals with representations in the computer.  Mapping 
those representations to the external world is a separate matter that 
deals with sensors, actuators (robots, displays, computer-controlled
instruments, sound boards, digital cameras, scanners, microphones...)
These are usually parts of some other engineering discipline.
>
>>
>> nevertheless, I like this article.  It says, among other things,
>>
>>          The technique of propagating the uncertainty from step to=
>   step
>> throughout the calculation is a very bad technique. It might sometimes
>> work for super-simple =93textbook=94 problems but it is unlikely to work =
> for
>> real-world problems.
>
> Except that error propagation techniques are used successfully in many
> fields.

A simple problem perhaps.

  Your cell phone works because engineers found a good balance
> of power consumption and radio sensitivity from error propagation
> methods, rather than the impractical method of tracking each electron
> through the circuits.

Of course there are many methods that can be programmed. You are 
assuming that analysis of signals is done by some kind of particle 
tracking?  I assume that programs are designed by persons familiar with
differential equations and electromagnetic radiation, as well as more
seat-of-the-pants stuff like antenna design and sun spots.

Also I assume
that cell phones use signal strength and feedback, and do not need great
accuracy.  Though maybe GPS stuff is tricky if you have few 
triangulation points.  Using 10 points, maybe not so tricky.  Not 
something I've cared to look at.

Anyway, after a few billion computations, significance arithmetic tends 
to lose.

Getting back to orbits, one extremely useful
> application of error propagation is to use it "backwards" to determine
> which observations would best improve knowledge of an orbit.
>
> There is no universal method for tracking uncertainty that is accurate
> and practical.

Ah, so you are saying that Mathematica is not accurate and practical??

  Your own ideologically favored method, interval
> arithmetic, yields unrealistically large estimates of error in many
> cases, and that can be a very bad thing. Or it can be useful to have
> an upper bound. What's good depends on what the *application* needs,
> not some ivory tower ideology.

It's not my favorite.  I point it out as a method that has been widely 
studied.  It does not provide estimates of error. It provides bounds on 
error, and those bounds may be very pessimistic.


>
> I am *really* tired of your smug, patronizing attitude. You're a blind
> man attempting to explain a rainbow. Why not, instead of whining all
> the time that Mathematica doesn't conform to your profoundly narrow
> notions of what computation is, spend some time with it actually
> computing something of relevance to the real world?

My concern is that someone attempting to compute something of relevance 
will fall into a real-world hole.

  If you were
> actually interested in applications, you would *rejoice* in the fact
> that there are a variety of approaches available. But instead, you
> obviously see Mathematica as a threat to your narrow ideology.

I am primarily interested in building systems appropriate for a range of 
applications.  (That's more computer science).  From that perspective I 
think that Mathematica falls short.  I don't see that as a threat, but I 
am inclined to object to statements that claim (in my view incorrectly) 
that Mathematica (arithmetically speaking) is the best, or even the only 
way to do floating-point calculations.   In some ways the Mathematica 
system is just fine, if you use its library routines for special 
functions for arbitrary precision, and you are within the appropriate 
ranges where they actually deliver what is promised.  (I have mixed 
experiences near singular points...)
But I think I've stated my perspective pretty clearly, even if 
patronizingly.

RJF

>
>

[toc] | [prev] | [next] | [standalone]

#3760

On Jul 15, 1:10 am, Richard Fateman <fate...@cs.berkeley.edu> wrote:

> > In extracting useful results from computers in the real world
> > ignorance of the application domain is more debilitating than
> > ignorance of computer science. One can muddle through the latter, but
> > not the former.
>
> I think you may be confusing "computer science"  with "applications of
> computers to whatever [e.g. physics, engineering, business]"  which is
> usually taught in the department of 'whatever'.

So, in your view, the substance is all in the departments of
'whatever'? Because without applications, what's left? Computers are
not natural objects: they are artificial, so without applications the
whole field is just a made-up story. A true science needs the
discipline of relating to *something* in the real world. You're
evading this discipline. Your view makes computer science
indistinguishable from religious scholasticism.

> > Consider the howler you yourself committed a little while ago,
> > discussing the role of computers in the Apollo moon landings:
>
> >> you've got to wonder how the Russians, probably WITHOUT much in the wa=
y
> >> of computers, put up an artificial satellite.
>
> > This illustrates a profound ignorance of the problem. If you don't
> > care what orbit you go into, the computations are readily performed by
> > slide rule ahead of time. But Apollo had to perform a series of
> > precise maneuvers using imprecise rockets, with repeated re-
> > computation of the trajectories. For the early missions, they didn't
> > even know the lunar gravity very well, so actual orbits diverged
> > rapidly from predictions even when the initial conditions were known.
> > Apollo's indirect "lunar orbital rendezvous" approach was thus a
> > triumph of computation. Even the Saturn V was not big enough to
> > support the less computationally intensive direct approach.
>
> Do you know for a fact that the Russians didn't care what orbit the
> first manned satellite had?

I know the consequences of getting it wrong. Basically, they knew if
they got the perigee high enough to go around once, nothing really bad
could result from the other orbital parameters. The rocket wasn't
powerful enough to do something silly like put Gagarin into an escape
trajectory. The limitations of the rocket combined with very basic
orbital mechanics guaranteed that about an hour and a half after
launch, the spacecraft would return to a point near overhead to where
the launch site had been. Consider the rotation of the Earth, and then
all they had to do was fire the retrorocket in roughly the right
direction at roughly the right time and Gagarin was guaranteed to come
down about 23 degrees west of where he was launched. The Soviet Union
was a huge place: they didn't need to do this accurately at all.

Satisfying a single inequality is enormously easier than rendezvous in
orbit around a body with poorly known gravity, where you must satisfy
six equations to high precision.

> I think you are confusing application knowledge with computer science.

Without applications, computer science is vacuous.

> Of course there are many methods that can be programmed. You are
> assuming that analysis of signals is done by some kind of particle
> tracking?  I assume that programs are designed by persons familiar with
> differential equations and electromagnetic radiation, as well as more
> seat-of-the-pants stuff like antenna design and sun spots.
>
> Also I assume
> that cell phones use signal strength and feedback, and do not need great
> accuracy.

How do you determine how large to make the transistors when
manufacturing the cell phone? This requires calculation. How would you
do that calculation?

> Though maybe GPS stuff is tricky if you have few
> triangulation points.  Using 10 points, maybe not so tricky.  Not
> something I've cared to look at.

If von Neumann was alive, he'd understand the issues completely before
you'd even finished describing the problem. He was a *real* computer
scientist.

> > There is no universal method for tracking uncertainty that is accurate
> > and practical.
>
> Ah, so you are saying that Mathematica is not accurate and practical??

Not universally. However, given a specific problem, it is often the
tool of choice.

> I am primarily interested in building systems appropriate for a range of
> applications.  (That's more computer science).

Without knowledge of applications, you have no foundation to stand on
here. And that's Wolfram's advantage: he and his people *do*
understand a very wide range of applications.

>  From that perspective I
> think that Mathematica falls short.

Since many of us find Mathematica a very effective tool in real
applications, this judgement is obviously based on nothing but
ideology. You have repeatedly demonstrated your complete lack of any
useful perspective here, and your unwillingness to do the necessary
studying to gain that perspective. Instead, you carefully define
"computer science" in a way that excuses you from studying anything
you don't wish to study.

>  I don't see that as a threat, but I
> am inclined to object to statements that claim (in my view incorrectly)
> that Mathematica (arithmetically speaking) is the best, or even the only
> way to do floating-point calculations.

There is no best. It depends on what you're doing. Mathematica is very
effective over a wide range of applications. It is not the right tool
for every application. But you need the application knowledge to
understand this.

[toc] | [prev] | [next] | [standalone]

#3774

On 7/16/2011 2:41 AM, Noqsi wrote:
> On Jul 15, 1:10 am, Richard Fateman<fate...@cs.berkeley.edu>  wrote:

...

>> I think you may be confusing "computer science"  with "applications of
>> computers to whatever [e.g. physics, engineering, business]"  which is
>> usually taught in the department of 'whatever'.
>
> So, in your view, the substance is all in the departments of
> 'whatever'? Because without applications, what's left? Computers are
> not natural objects: they are artificial, so without applications the
> whole field is just a made-up story. A true science needs the
> discipline of relating to *something* in the real world. You're
> evading this discipline. Your view makes computer science
> indistinguishable from religious scholasticism.

I think your comment might be more aptly directed toward the study of 
pure math.  Since I've raised the hackles of the physicists, why not 
poke the mathematicians in the eye too.  (My Phd is in Applied Math, my 
bachelor's degree is in Physics [&math]).

It is true that computer science without applications is mostly dealing 
with the artificial. Artificial languages to use to communicate 
algorithms to computers. The design of algorithms, which by and large 
take (artificial representations of numbers/data/) and after some 
processing, return (artificial representations ..).  The design of data, 
by which one can take some external something and encode it.
Music, personnel records, signals from outer space, commodity prices, 
etc. Computer security, networking, operating systems, cryptography, 
graph theory, some theoretical areas.  Some "general" tools, like 
graphics, robotics, sensors.   While some familiarity with the 
application domain is sometimes helpful, a deep understanding of each of 
most of the application domains of computers is not part of "computer 
science".

If you want to know more about what is taught in a department of 
computer science, look in the online catalog of some school.

If you look at Berkeley's you might be surprised that courses "in 
programming in language X" are typically given only 1 unit, not 3 or 4.
Also, CS majors usually don't take them, and I think at most one can be 
counted toward graduation.  It is not that CS majors don't know how to 
program, it is that programming in a particular language per se is 
incidental to the topics of CS, like data structures, compilers, design 
of programming languages. In the course of their studies, majors 
typically write programs in a variety of languages including Java, C, 
C++, Lisp, assembly language, Python, perhaps some "toy" programming 
languages.  Maybe prolog, postscript, ruby, ..

Now it has been argued that any "science" that has "science" in its name 
is not a true science.  E.g. political science, social science, 
management science, and computer science.  So one could try, as some 
have, to call it "informatics". Or something else.  Maybe Wolframatics?

....

>>
>> (RJF) Do you know for a fact that the Russians didn't care what orbit the
>> first manned satellite had?
>
> (nosqi) I know the consequences of getting it wrong. Basically, they knew if
> they got the perigee high enough to go around once, nothing really bad
> could result from the other orbital parameters. The rocket wasn't
> powerful enough to do something silly like put Gagarin into an escape
> trajectory. The limitations of the rocket combined with very basic
> orbital mechanics guaranteed that about an hour and a half after
> launch, the spacecraft would return to a point near overhead to where
> the launch site had been. Consider the rotation of the Earth, and then
> all they had to do was fire the retrorocket in roughly the right
> direction at roughly the right time and Gagarin was guaranteed to come
> down about 23 degrees west of where he was launched. The Soviet Union
> was a huge place: they didn't need to do this accurately at all.

I'm sure it would have been a great comfort to Gagarin to be told, 
"don't worry, you'll probably land somewhere in the USSR".

>
> Satisfying a single inequality is enormously easier than rendezvous in
> orbit around a body with poorly known gravity, where you must satisfy
> six equations to high precision.
>
>> I think you are confusing application knowledge with computer science.
>
> Without applications, computer science is vacuous.

You know any mathematicians?  No?  How about theologians?
>
>> Of course there are many methods that can be programmed. You are
>> assuming that analysis of signals is done by some kind of particle
>> tracking?  I assume that programs are designed by persons familiar with
>> differential equations and electromagnetic radiation, as well as more
>> seat-of-the-pants stuff like antenna design and sun spots.
>>
>> Also I assume
>> that cell phones use signal strength and feedback, and do not need great
>> accuracy.
>
> How do you determine how large to make the transistors when
> manufacturing the cell phone? This requires calculation. How would you
> do that calculation?

I assume that would be done by electrical engineers perhaps using tools 
in the field of "computer aided design of integrated circuits". Not my 
area of expertise.
>
>> Though maybe GPS stuff is tricky if you have few
>> triangulation points.  Using 10 points, maybe not so tricky.  Not
>> something I've cared to look at.
>
> If von Neumann was alive, he'd understand the issues completely before
> you'd even finished describing the problem. He was a *real* computer
> scientist.

Wow, I didn't know you had such powers that you could predict what John 
von Neumann (died in 1957) would have understood.
>
>>> There is no universal method for tracking uncertainty that is accurate
>>> and practical.
>>
>> Ah, so you are saying that Mathematica is not accurate and practical??
>
> Not universally. However, given a specific problem, it is often the
> tool of choice.
>
>> I am primarily interested in building systems appropriate for a range of
>> applications.  (That's more computer science).
>
> Without knowledge of applications, you have no foundation to stand on
> here. And that's Wolfram's advantage: he and his people *do*
> understand a very wide range of applications.

Indeed some of the people he hired understood relevant parts of computer 
science.  Unfortunately, Wolfram himself, and some of the people he 
hired did NOT know relevant parts of computer science, and that's why 
some of the design turned out relatively weak.

Wolfram had an earlier design, SMP, which was even worse in this respect.

>
>>    From that perspective I
>> think that Mathematica falls short.
>
> Since many of us find Mathematica a very effective tool in real
> applications, this judgement is obviously based on nothing but
> ideology.

You bring to mind the old joke about the man falling off the top of the 
Empire State building.  Asked, as he passed floor 50, how he was doing, 
he said "So far, so good"..




> You have repeatedly demonstrated your complete lack of any
> useful perspective here, and your unwillingness to do the necessary
> studying to gain that perspective.

Um, you seem to think that in order to understand how arithmetic should 
be done, I should study low-earth orbits, GPS triangulation, and , and 
everything else?

Instead, you carefully define
> "computer science" in a way that excuses you from studying anything
> you don't wish to study.

See above. Computer science is pretty well defined these days.
>
>>   I don't see that as a threat, but I
>> am inclined to object to statements that claim (in my view incorrectly)
>> that Mathematica (arithmetically speaking) is the best, or even the only
>> way to do floating-point calculations.
>
> There is no best. It depends on what you're doing. Mathematica is very
> effective over a wide range of applications. It is not the right tool
> for every application. But you need the application knowledge to
> understand this.

OK, let's hear it from your experience: tell us what applications you 
know about for which Mathematica is not suitable.

And then if you believe your own stance, you would have to concede that 
for areas that you are not expert in, your opinion on what is best is of 
no value.

RJF
>
>

[toc] | [prev] | [next] | [standalone]

#3789

Użytkownik "Richard Fateman" <fateman@cs.berkeley.edu> napisał w wiadomości 
grup dyskusyjnych:ivuc06$gqg$1@smc.vnet.net...
> Now it has been argued that any "science" that has "science" in its name
> is not a true science.  E.g. political science, social science,
> management science, and computer science.  So one could try, as some
> have, to call it "informatics". Or something else.  Maybe Wolframatics?

FYI, the term is the "informatyka" (informatics), which is a translation of 
the "computer science" into Polish.

I suggest also to read a short story "Trurl's machine" by S. Lem (see 
http://www.springerlink.com/content/t310542162241154/ , "How much is two 
plus two?")

In the science there is no rule that the error is "the last figure." If 
there is any tolerance or uncertainty, it must be explicitly marked. Any 
other presumption is wrong and therefore it is not allowed to leave the 
measured values ??without explicitly specified uncertainty. (See 
http://physics.nist.gov/cgi-bin/cuu/Value?tcomwl|search_for=atomnuc! for 
2010 CODATA, the Bohr radius is 0.529 177 210 92 x 10^-10 m with uncertainty 
0.000 000 000 17 x 10^10 m . This standard deviation is not "a last digit" 
or "a last pair" etc.)

Mathematica uses a different convention. By default, assumes that numbers 
such as 1.4 or 2.0 are inaccurate. It is even worse, because though a == b 
is True, then N [a] and N [b] are not the same. Hence we can prove that 1 == 
0, or if you prefer that 2 +2 == 7 .

It is a feature, but in my opinion it may leads to serious bugs.

slawek
 

[toc] | [prev] | [next] | [standalone]

#3793

On 17 Jul 2011, at 12:02, Richard Fateman wrote:

> I think your comment might be more aptly directed toward the study of
> pure math.  Since I've raised the hackles of the physicists, why not
> poke the mathematicians in the eye too.  (My Phd is in Applied Math, my
> bachelor's degree is in Physics [&math]).

Well, OK. Vladimir Arnold quotes Poincare as saying:

"There is no Applied Mathematics, there are only applications of mathematics."

Would that explain certain things?

Andrzej Kozlowski

[toc] | [prev] | [next] | [standalone]

#3798

On 7/18/2011 3:17 AM, Andrzej Kozlowski wrote:
> On 17 Jul 2011, at 12:02, Richard Fateman wrote:
>
>> I think your comment might be more aptly directed toward the study of
>> pure math.  Since I've raised the hackles of the physicists, why not
>> poke the mathematicians in the eye too.  (My Phd is in Applied Math, my
>> bachelor's degree is in Physics [&math]).
>
> Well, OK. Vladimir Arnold quotes Poincare as saying:
>
> "There is no Applied Mathematics, there are only applications of mathematics."
>
> Would that explain certain things?
>
> Andrzej Kozlowski
>

I can't think of one thing that it might explain.  Maybe it sounds 
better in the original French?

[toc] | [prev] | [next] | [standalone]

#3481

BTW, you can skip the outer N[]:

N[2,20]N[Sqrt[2],20]

produces:

2.8284271247461900976

Kevin

On 7/4/2011 6:47 AM, slawek wrote:
> Let Mathematica (6.x, 7.x) compute quite a simple product
>
> In[1]:= N[N[2.0, 20] * N[Sqrt[2] , 20], 20]
>
> Out[1]= 2.82843
>
> This is a bug.
>
> Why?
>
> Now we analyze it in details:
>
> 1. N[2.0,20] should give 2 with accuracy/precision/whatsever about 20
> decimal digits, i.e. 2.00000000000000000000
>
> 2. Sqrt[2] should give... Sqrt[2]
>
> 3. N[Sqrt[2]] should give 1.4142135623730950488 (this is copy-paste from
> Mathematica output to N[Sqrt[2]] )
>
> 4. The product 2.00000000000000000000 * 1.4142135623730950488 is
> 2.8284271247461900976 (again copy-paste)
>
> 5. BUT THE RESULT OF  N[2.0, 20] * N[Sqrt[2] , 20]  "truncated to 20 digits"
> is Out[1]= 2.82843
>
> Where are missing digits?!
>
> slawek
>
>
>
>

[toc] | [prev] | [next] | [standalone]

#3499

In brief:  yes to both.

On 7/4/2011 4:18 AM, Kevin J. McCann wrote:
...
>>
>> 1. N[2.0,20] should give 2 with accuracy/precision/whatsever about 20
>> decimal digits, i.e. 2.00000000000000000000
>

WRI will defend this as a feature.

You thought that the semantics of N[] were the same as SetPrecision
e.g.

N[SetPrecision[2.0, 20]*N[Sqrt[2], 20], 20]


works as you expected.

So from your perspective, and from the perspective of anyone else who 
thinks along the same lines, it is a bug.  I would prefer to call it
a design error.

2.0  (indeed, any floating point number) is a perfectly respectable way 
of denoting a number that can be expressed in higher precision by adding 
binary zeros. WRI doesn't agree.

RJF

[toc] | [prev] | [next] | [standalone]

#3507

U=BFytkownik "Richard Fateman" <fateman@cs.berkeley.edu> napisa=B3 w wiadomo=B6ci
grup dyskusyjnych:iuuko3$eqi$1@smc.vnet.net...
> 2.0  (indeed, any floating point number) is a perfectly respectable way
> of denoting a number that can be expressed in higher precision by adding
> binary zeros. WRI doesn't agree.

Mathematica is very simple to use. Of course, it is the entire programming
language, advanced concepts, etc. However it seems that in order to
calculate 2 Sqrt[2]  is need no special knowledge nor special care.

Nevertheless, it appears that although the language itself does not enforce
this, calculations require very formal definitions of all variables.

slawek

[toc] | [prev] | [next] | [standalone]

#3535

On Jul 5, 4:15 am, Richard Fateman <fate...@cs.berkeley.edu> wrote:
> In brief:  yes to both.
>
> On 7/4/2011 4:18 AM, Kevin J. McCann wrote:
> ...
>
>
>
> >> 1. N[2.0,20] should give 2 with accuracy/precision/whatsever about 20
> >> decimal digits, i.e. 2.00000000000000000000
>
> WRI will defend this as a feature.
>
> You thought that the semantics of N[] were the same as SetPrecision
> e.g.
>
> N[SetPrecision[2.0, 20]*N[Sqrt[2], 20], 20]
>
> works as you expected.
>
> So from your perspective, and from the perspective of anyone else who
> thinks along the same lines, it is a bug.  I would prefer to call it
> a design error.
>
> 2.0  (indeed, any floating point number) is a perfectly respectable way
> of denoting a number that can be expressed in higher precision by adding
> binary zeros. WRI doesn't agree.
>
> RJF

I don't think this holds up for all floats in the sense you seem to
indicate. Take 2.1 for example. We can (and will) use SetPrecision to
pad with binary zeroes, just as you use it above on 2.0.

In[606]:= N[SetPrecision[2.1, 20]*N[Sqrt[2], 20], 20]

Out[606]= 2.9698484809834997281

But this is not an accurate representation of 21/10 * Sqrt[2] to 20
places.

In[607]:= N[21/10*Sqrt[2], 20]
Out[607]= 2.9698484809834996025

They are off by arould a machine epsilon. No surprise here, I think.

In[608]:= % - %%
Out[608]= -1.256*10^-16

I also think that this sort of numeric discrepancy is inevitable* in
any program that uses decimal input and binary representation.

Daniel Lichtblau
Wolfram Research

*Perhaps more inevitable than these threads. Now that's pretty
inevitable.

[toc] | [prev] | [next] | [standalone]

#3575

On 7/7/2011 4:35 AM, Daniel Lichtblau wrote:
> On Jul 5, 4:15 am, Richard Fateman<fate...@cs.berkeley.edu>  wrote:
>> In brief:  yes to both.
>>
>> On 7/4/2011 4:18 AM, Kevin J. McCann wrote:
>> ...
>>
>>
>>
>>>> 1. N[2.0,20] should give 2 with accuracy/precision/whatsever about 20
>>>> decimal digits, i.e. 2.00000000000000000000
>>
>> WRI will defend this as a feature.
>>
>> You thought that the semantics of N[] were the same as SetPrecision
>> e.g.
>>
>> N[SetPrecision[2.0, 20]*N[Sqrt[2], 20], 20]
>>
>> works as you expected.
>>
>> So from your perspective, and from the perspective of anyone else who
>> thinks along the same lines, it is a bug.  I would prefer to call it
>> a design error.
>>
>> 2.0  (indeed, any floating point number) is a perfectly respectable way
>> of denoting a number that can be expressed in higher precision by adding
>> binary zeros. WRI doesn't agree.
>>
>> RJF
>
> I don't think this holds up for all floats in the sense you seem to
> indicate. Take 2.1 for example.

My contention is that 2.1, written that way, is a perfectly respectable 
way of denoting a number that can be expressed in higher precision by 
adding binary zeros.  2.1 is a double-float in most systems today.
What is that number?  In decimal, to higher precision, it looks like
2.10000000000000008881784197001....

A program that decodes a float into its component fraction, exponent, 
and sign gives this information for the fraction:
4728779608739021  or in binary
10000110011001100110011001100110011001100110011001101

That is the number to which we add binary zeros.

Let us call this number P.





>We can (and will) use SetPrecision to
> pad with binary zeroes, just as you use it above on 2.0.
>
> In[606]:= N[SetPrecision[2.1, 20]*N[Sqrt[2], 20], 20]
>
> Out[606]= 2.9698484809834997281
>
> But this is not an accurate representation of 21/10 * Sqrt[2] to 20
> places.


Just because you are doing arithmetic on numbers represented to 20 
digits does not mean that the result of the arithmetic will be right to 
20 digits, however, in the single operation of multiplication, you 
should not lose any digits.  What's going on here?

You simply computed two different quantities.  Let S= sqrt(2) to 20 
decimal places.  In line 606 you multiplied P*S and rounded it to 20 
digits  [ actually you did something to the binary reps, but it doesn't
matter here].
In line  607, below, you multiplied 21/10 by S.   Since P is not equal 
to 21/10, why should the results be the same?  Oh, Mathematica thinks 
that P ==21/10,  but that is merely the terribly broken notion of 
equality that Mathematica uses. We used to call that "close enough for 
government work".   But it is terribly broken because == fails to 
satisfy the axioms of "equivalence relations" such as a==b  and b==c 
implies a==c.


>
> In[607]:= N[21/10*Sqrt[2], 20]
> Out[607]= 2.9698484809834996025
>
> They are off by arould a machine epsilon. No surprise here, I think.
>
> In[608]:= % - %%
> Out[608]= -1.256*10^-16
>
> I also think that this sort of numeric discrepancy is inevitable* in
> any program that uses decimal input and binary representation.

Absent any interior calculations, I would tend to agree.  But there is 
something else going on. I think that Mathematica has embedded in it 
several design decisions that elevate the (typical) 
one-half-unit-in-last-place error in binary-to-decimal and 
decimal-to-binary conversion that happens in input or output,  into a 
global slush bucket that infects and propagates into all interior 
computations with "software floats".
>
> Daniel Lichtblau
> Wolfram Research
>
> *Perhaps more inevitable than these threads. Now that's pretty
> inevitable.
>
maybe so.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.soft-sys.math.mathematica

csiph-web