Number types in Lisp
in [Lisp]
|
Prev: lisp port
Next: Disjoint sets
From: Paul Wallich on 26 May 2010 09:07 Tim Bradshaw wrote: > On 2010-05-26 07:58:14 +0100, Barry Margolin said: > >> Real scientists use explicit statements of uncertainty, e.g. 10.3 +/- >> .03. Just using a particular number of significant digits implicitly >> assumes that the uncertainty is .0....5, which is unlikely to be the >> actual case (although if the measuring equipment has a digital readout, >> I guess you have to assume that). And when you combine these numbers in >> a formula, the uncertainties have to be added, multiplied, etc (so even >> if you started with .0....5, it will shift as they're combined). > > I agree with this - all I really meant is that you *wouldn't* say, for > instance "10.50000 +0.02 -0.03" or something, still less "10.5000" to > mean "10.5 +/- 0.05" - there is information implicit in the number of > digits you quote. I think +/- .5 in last significant place is fairly > common, as you say, with digital instruments like multimeters etc, > though when I used these in serious things, they'd all be calibrated and > typically were less accurate than the precision they could display > (though sometimes there was systematic error for which you could correct > to recover accuracy). In some cases, if you know the shape of the distribution quite well, it may make sense to pinpoint the center of it, but then you're probably not using the +- notation. paul
From: Vend on 26 May 2010 16:11 On 26 Mag, 14:54, Tim Bradshaw <t...(a)tfeb.org> wrote: > On 2010-05-26 12:13:32 +0100, Vend said: > > > I don't think this is correct. Efficiency is useless if you don't > > deliver a correct result, and in settings where approximate quantities > > and approximate computations are involved, a correct result requires > > bounded errors. > > That doesn't stop it being true. For instance a system designed for > precision would allow you to say things like "I want this result > accurate to so much" but FP systems don't allow that kind of operation. IEEE Floating point allow that in a coarse way, by choosing one of the specific format which is supported by the hardware. It is programmer's responsability to make sure that that format has enough precision for his needs. > There are systems which do allow that kind of thing (for instance in > Mathematica, you can say, for instance "N[Pi]" to get a (single-float?) > approximation to pi, but "N[Pi,100]" gives you an approximation good to > 100 significnt figures (not sure what deal is with the last digit, I > guess it is rounded). Yes, but this requires arbitrary precision arithmetics which is too impractical to implement in hardware.
From: Richard Fateman on 26 May 2010 16:16 Tim Bradshaw wrote: > On 2010-05-26 12:13:32 +0100, Vend said: > >> I don't think this is correct. Efficiency is useless if you don't >> deliver a correct result, and in settings where approximate quantities >> and approximate computations are involved, a correct result requires >> bounded errors. > > That doesn't stop it being true. For instance a system designed for > precision would allow you to say things like "I want this result > accurate to so much" but FP systems don't allow that kind of operation. The utility of a good FP system is that it can be used to write programs that provide useful results quickly. A well-designed FP system also allows you to build additional facilities for higher precision if that turns out to be useful. These can also be done with integer data and operations. (or Lisp bignums) as in the computer algebra system Maxima. There are libraries like MPFR that you can link to Lisp for multiple precision floating point (rounded) results too. > There are systems which do allow that kind of thing (for instance in > Mathematica, you can say, for instance "N[Pi]" to get a (single-float?) > approximation to pi, but "N[Pi,100]" gives you an approximation good to > 100 significnt figures (not sure what deal is with the last digit, I > guess it is rounded). The facility in Mathematica does not work as well as you might think, or as well as WRI might wish you to think. In particular, N[ <some_random_expression>, k] may get you k decimal digits, or far fewer, including no correct digits at all, and you might not know which. RJF > >
From: Tim Bradshaw on 26 May 2010 17:25 On 2010-05-26 21:16:55 +0100, Richard Fateman said: > The utility of a good FP system is that it can be used to write > programs that provide useful results quickly. A well-designed FP system > also allows you to build additional facilities for higher precision if > that > turns out to be useful. These can also be done with integer data and > operations. (or Lisp bignums) as in the computer algebra system Maxima. Yes, I hope no one thinks I am somehow against FP systems... > > The facility in Mathematica does not work as well as you might think, or > as well as WRI might wish you to think. In particular, .... and no one who has read my comments on Mathematica in this group[*] could think I had much time for it. All I meant was that the sort of facility a system designed for precision might give you would be "please give me more bits of precision" where "more bits" means "as many as I want, without restrictions based on register widths". And of course that is the sort of facility that algebra systems tend to provide. --tim [*] I originally wrote "forum" meaning it in the pre-intarweb sense, but it's now impossible to write that and not sound bad.
From: Thomas A. Russ on 26 May 2010 16:23
Vend <vend82(a)virgilio.it> writes: > Yes, but this requires arbitrary precision arithmetics which is too > impractical to implement in hardware. I'm not really sure about that. Certainly one could include hardware support, if there were a widely adopted standard for arbitrary precision arithmetic. Actually, arbitrary precision wouldn't really be needed to address most concerns. The general complaint seems to stem from the fact that there is a mismatch between human (base 10) and computer (base 2) number systems. If we worked with an internal base 10 representation, then you would really avoid most of the problems. I've often wondered if something like BCD would make a come-back. Particularly if you developed hardware support for computations in a base-10 representation, you should be able to get reasonable speed and avoid the "impedance-mismatch" between the users and the computer. After all, the complaint really comes from not having an exact representation of base-10 values, and the associated problems with calculations being (secretly to most users) carried out in binary. What we aren't seeing is any complaints about inexact base-10 fractions like 0.333333333333333 * 3.0 = 0.9999999999999999 although I imagine that people still won't like (1.0 / 3.0) * 3.0 != 1.0 -- Thomas A. Russ, USC/Information Sciences Institute |