Dear RJF,
Dear list,
This was an interesting read and I have learnt some things:
* I wrongly assumed floating point in computer context to mean sign
bit, fixed range for mantissa, fixed range for exponent, special
cases for -inf, +inf, +0, -0, nan.
* I think Sage's RealField(prec) is more accurately called
fixed-precision floating-point than arbitrary-precision floating-point,
since range of mantissa and exponent are fixed once prec is known.
* Priest's Algorithms for Arbitrary Precision Floating Point Arithmetic
is an interesting read, and made me realize the above.
* I wrongly assumed the "truncated power series" to be QQ[[t]]/t^n for
some fixed non-negative integer n.
* I should not be participating in threads like these. They take too
much time that should be spent on work.
I also have a question:
* Is there a definition of computational domain? If so, do you have some
pointers? That'd be interesting.
Regards,
Erik Massop
On Wed, 20 Aug 2014 16:47:03 -0700 (PDT)
rjf <fate...@gmail.com> wrote:
>
>
> On Saturday, August 9, 2014 7:35:13 PM UTC-7, Erik Massop wrote:
> >
> > ....
> >
>
>
> > Similarly I would call RealField(prec) a field, because it represents
> > the field of real numbers (e.g. Dedekind cuts). At the same time I am
> > sure that some mathematical properties that I know from the mathematical
> > field of real numbers will not hold in RealField(prec).
>
>
> So it seems to me that you should not call it a Field.
>
> Here's the inverse. Or maybe contrapositive. As a riddle:
>
> How many legs does a sheep have if you call its tail a leg?
> (Answer later...)
>
>
> > Luckily Sage
> > readily admits that RealField(prec) is not an exact representation of
> > the mathematical field of real numbers:
> > sage: F = RealField(100)
> > sage: F.is_exact()
> > False
> >
>
> Hardly luck, but random insertion of a fact in a way similar to the riddle.
> (Answer later)
>
>
> >
> > I agree that it is imprecise that when using F.is_field(), we are
> > asking whether the mathematical object of real numbers is a field, while
> > when using F.is_exact() we are asking whether the representation is
> > exact.
> >
> > By the way, there also is AA or AlgebraicRealField() in Sage, which is
> > an exact representation of the real closed field of algebraic real
> > numbers.
> >
> > ...
> > > The domain of arbitrary-precision integers is an excellent model of
> > > the ring of integers. It is true that one can specify a computation
> > > that would fill up the memory of all the computers in existence. or
> > > even all the atoms in the (known?) universe. Presumably a
> > > well-constructed support system will give an error message on much
> > > smaller examples. I assume that your Real Field operation of
> > > division would give an error if the result is inexact.
> >
> > RealField(prec) is an inexact approximation of a field (as witnessed by
> > is_exact), so I never expect the division to be exact.
>
>
> Oh, so it just gives wrong answers without a clue.
>
>
> > In fact I don't
> > expect addition, negation, multiplication, or subtraction to be exact
> > either. Indeed, they are not exact:
> > sage: a = 1e-58
> > sage: a
> > 1.00000000000000e-58
> > sage: (1+a)-1
> > 0.000000000000000
> >
>
> That's because it is not a field, and you know it. So why call it a field?
>
>
> >
> > > > > > > Does Sage have other um, approximations, in its nomenclature?
> > > > > >
> > > > > > Sure. RealField(123)[x]. Power series rings. P-adics.
> > > > >
> > > > > These approximations are approximations by their nature. If you
> > > > > are computing with a power series, the concept inherently includes
> > > > > an error term which you are aware of. Real Field is (so far as I
> > > > > know) a concept that should have the properties of a field. The
> > > > > version in Sage does not. It's like saying someone isn't pregnant.
> > > > > well only a little pregnant.
> > > >
> > > > They're no more approximate by nature than the real numbers.
> > >
> > > Huh? How so? I was not aware that real numbers (at least the ones
> > > that you can construct) are approximate by nature. But maybe you
> > > can direct me to some reference on this.
> >
> > What do you mean by "can construct"? The computable reals perhaps? Those
> > would indeed form an actual field. I am very unsure about how practical
> > they are though.
> >
>
> How about the rational numbers? Those you can easily construct.
> The computable reals are not fun to compute with in most "application"
> circumstances.
>
>
> >
> > Might we then not also have a ring of computable power series? That is,
> > those power series given by an algorithm that given n returns the n'th
> > term in finite time?
> >
>
> It is not usually phrased that way, but given a collection of base
> functions as explicit power series
> and operations like composition, there is a computational domain of
> truncated power series.
> It is usually set up to NOT be a ring because of truncation issues.
>
>
> > ...
> > > > Power series (to make things concrete, say the power series in one
> > > > variable over the integers) form a ring.
>
> For any choice of
> > > > representation some of them can be represented exactly on a
> > > > computer, most can't. When doing computations with power series one
> > > > is typically chooses a precision (e.g. how many terms, not unlike a
> > > > choice of number of bits) to use.
> > >
> > > Truncated power series with coefficients that are typically exact
> > > rational numbers (but could be, you say , elements of a finite field)
> > > form a computation structure that has exact operations. Just because
> > > you associate some other concept that is outside the computer with
> > > that TPS doesn't mean the TPS is approximate.
> >
> > I would argue that a ring of truncated power series with rational
> > coefficients is an inexact representation of the ring of (untruncated)
> > power series with rational coefficients, just as RealField(prec) is an
> > inexact representation of the field of real numbers.
> >
>
> Well then, I would argue that it is not. It is a computational domain
> with its own useful properties that can be nicely characterized, and
> happens not to be a ring.
>
>
> >
> > It is important to realize that my use of "inexact" here refers to
> > TPS/RealField(prec) as a representation of the ring of (untruncated)
> > power series with rational coefficients/the field of real numbers, and
> > not to TPS/RealField(prec) itself.
> >
>
> Basically, this is analogous to saying that floating point numbers
> form a field, which they don't. Let the coefficients be 0 or 1, and the
> base of the power series x is 1/2.
>
> or maybe p-adics.
>
>
> >
> > The object PowerSeriesRing(QQ, 'x') in Sage is not a ring of truncated
> > power series QQ[x]/x^n. In it not a ring at all. In fact == is not even
> > transitive:
> > sage: R.<x> = PowerSeriesRing(QQ, 'x')
> > sage: a = O(x^20)
> > sage: a in R
> > True
> > sage: (0 == x^30 + a) and (x^30 + a == x^30)
> > True
> > sage: 0 == x^30
> > False
> >
> >
> As is the case for every computer algebra system I know about that
> implements
> truncated power series. Incidentally, Macsyma implements a different,
> additional, notion
> of power series wehre they are represented by a formula for the arbitrary
> nth term.
>
> Since we agree that TPS do not form a ring, why does Sage lie about it?
>
>
>
>
> > > > Real numbers form a field. For any choice of representation some of
> > > > them can be represented exactly on a computer, most can't. When
> > > > doing computations with real numbers...
> > >
> > > So you would say that 3 is approximate, because maybe it is pi, but pi
> > > cannot be represented as an integer. This point of view seems to me
> > > to be peculiar.
> >
> > Indeed, I would argue that 3 in RealField(100) is approximate.
>
>
> I can't see why you would think so.
>
>
> > For
> > instance the (computable) real number 3.00...001, where the ellipsis is
> > 1000 zeroes, gets mapped to 3 in RealField(100), but is not equal to 3
> > as an actual real number.
> >
>
> So the number k = 3.000....1 is not in RealField(100). Who cares?
> That does not justify treating 3 as a huge fuzzball.
> After all if you believe that all the numbers in RealField are fuzzballs,
> why not represent k as the number 5 in RealField(100)?
> Do you have a theory of error in RealField(100)? I suspect not.
>
>
> > When speaking of exact/inexact I think it is important, to keep track of
> > what is to be represented.
>
> Nope.
> Absolute nonsense.
>
> Arithmetic is done on what you are given, not on what someone in the back
> room is thinking.
> If you want to compute with numbers that have error bounds or error
> distributions, there
> are ways of representing them and doing arithmetic on them.
>
>
> > Hence the element 3 of RealField(100) is an
> > inexact approximation of a real number since there are many reals that
> > become 3 in RealField(100).
>
>
> Nonsense.
>
>
> > The element 3 of IntegerRing() is an exact
> > approximation of an integer, since there is only one integer that
> > becomes 3 in IntegerRing().
> >
>
> Why do you know that? What if the integer is read off a (weight) scale that
> has gradations at (say) 150, 155, 160, ... and so the integers
> 153,154,155,156,157 all become 155.
>
>
> > ....
> > > > to only being able to read 3 significant (decimal) figures.
> > >
> >
> (RJF said this....)
>
> > > Actually this analogy is false. The 3 digits (sometimes 4) from a
> > > slide rule are the best that can be read out because of the inherent
> > > uncertainty in the rulings and construction of the slide rule, the
> > > human eye reading the lines, etc. So if I read my slide rule and say
> > > 0.25 it is because I think it is closer to 0.25 than 0.24 or 0.26
> > > There is uncertainty there. If a floating point number is computed as
> > > 0.25, there is no uncertainty in the representation per se. It is
> > > 1/4, exactly a binary fraction, etc. Now you could use this
> > > representation in various ways, e.g. 0.25+-0.01 storing 2 numbers
> > > representing a center and a "radius" or an interval or ..../ But the
> > > floating point number itself is simply a computer representation of a
> > > particular rational number aaa x 2^bbb Nothing more, nothing less.
> > > And in particular it does NOT mean that bits 54,55,56... are
> > > uncertain. Those bits do not exist in the representation and are
> > > irrelevant for ascertaining the value of the number aaa x 2^bbb.
> > >
> > > So the analogy is false.
> >
> > I think it is again important to remember what is to be represented. If
> > you use floats to express numbers of the form aaa x 2^bbb (with
> > appropriate conditions on aaa and bbb), then sure, floats are an exact
> > representation. However there are many real numbers that are not of
> > this form.
>
>
> So you cannot represent them, and it is mostly pointless to discuss what
> you would do with them arithmetically. If I said that I can't represent a
> shoe in floating-point, and then proceeded to describe how to do arithmetic
> on shoes, socks, etc, you would probably find this dubious.
>
>
> > So, if you use floats for real numbers, then they are an
> > inexact representation. In that case the bits 54, 55, 56, ... of the
> > real number are lost in the 53 bit floating point representation. Hence
> > given the 53 bit floating point representation, the bits 54, 55,
> > 56, ... of the real number that it is supposed to represent, are indeed
> > uncertain. (This is simplified since the bit-numbering depends on the
> > exponent.)
> >
>
> No they are not uncertain. They are not represented at all. They are
> not part of the number. If I told you that 3 was of uncertain color --
> it might be red, blue, green or some combination, would that enhance
> your arithmetic?
>
>
>
> >
> > If you happen to know that the real number that is represented is of the
> > form aaa x 2^bbb (with appropriate conditions on aaa and bbb), then you
> > can reconstruct all those extra bits, and the representation is arguably
> > exact.
>
>
> No, the number in the computer is exactly the number that is the number.
> It is not
> some other number.
>
> But how should Sage know that the represented real number is of
> > this form?
> >
>
> Because that is the number in the computer. If you want to represent a
> range,
> you might use two numbers. If the computer numbers are fuzzballs , you
> cannot
> represent a range because the endpoints are fuzzballs, so you need a range
> for
> them. Infinite recursion to represent one "real" number? Eh, not such a
> great idea.
>
>
>
> > ...
> > > > Or are you seriously proposing when adding 3.14159 and 1e-100 it
> > > > makes more sense, by default, to pad the left hand side with zeros
> > > > (whether in binary or decimal) and return 3.1415900000...0001 as the
> > > > result?
> > >
> > > If you did so, you would preserve the identity (a+b)-a = b
> >
> > How would the real number pi be represented in this system? Do you have
> > to explicitly say that you want the first n digits? Or is the padding
> > scheme smart enough to add pi's digits? In the latter case, how do you
> > keep checking (in)equality efficient?
> >
>
> Well, there is a large literature on how to represent large ranges with
> acceptable
> efficiency. Papers by Douglas Priest, and more recently, Jonathan Shewchuk.
>
> The real number pi is not a computer-representable floating-point number in
> base 2.
> There are other numbers that can be represented, like 22/7.
>
> >
> > How does (1/3)*3 give? Does it compare equal to 1? I mean, I would
> > imagine 1/3 to be 0.333..., with more digits 3 as I need them, coming
> > from larger and larger 0 paddings of 1 and 3. Supposing this, (1/3)*3
> > would be 0.999..., with more digits 9 as I need them. Will comparing
> > with 1 ever finish?
> >
> > ...
> > > Now if the user specified the kind of arithmetic explicitly, or even
> > > implicitly by saying "use IEEE754 binary floating point arithmetic
> > > everywhere" then I could go along with that.
> >
> > I think you can specify this to some extend. At least
> > sage: RealField?
> > gives mentions opportunities to tweak precision and rounding.
>
>
> There have been various efforts to axiomatize floating-point numbers.
> I don't know if the Sage people refer to any of this, but calling something
> RealField does not inspire confidence.
>
>
> > You can
> > use AA if you want exact arithmetic (of real algebraic numbers). I don't
> > think there is a field of computable reals in Sage.
> >
>
> I am not proposing to use computable reals in any practical sense.
> Sort of like Sashimi. I am happy to look at it, but not eat it.
>
>
> >
> > ...
> > > > > > > You seem to think that a number of low precision has some
> > > > > > > inaccuracy or uncertainty. Which it doesn't. 0.5 is the same
> > > > > > > number as 0.500000. Unless you believe that 0.5 is the
> > > > > > > interval [0.45000000000....01, 0.549999..........9] which you
> > > > > > > COULD believe -- some people do believe this.
> > > > > > > But you probably don't want to ask them about scientific
> > > > > > > computing.
> >
> > Again, I think you should keep track of ambient sets here. For sure, the
> > real numbers 0.5 and 0.5000000 are the same, and real numbers have no
> > uncertainty (when representing real numbers). However, users do not type
> > real numbers. They type finite strings of characters that they probably
> > mean to represent some real number. The _strings_ 0.5 and 0.5000000 are
> > not the same. Hence it might be reasonable to assign different meaning
> > to these strings, as long as the user also has a way to precisely
> > express what is meant. Yet, I'm no expert on scientific computing, so I
> > will leave this be.
> >
>
> I think I finally agree with you on that last sentence.
>
> >
> > ...
> > > > > > There's 0.5 the real number equal to one divided by two. There's
> > > > > > also 0.5 the IEEE floating point number, which is a
> > > > > > representative for an infinite number of real numbers in a small
> > > > > > interval.
> > > > >
> > > > > Can you cite a source for that last statement? While I suppose
> > > > > you can decide anything you wish about your computer, the
> > > > > (canonical?) explanation is that the IEEE ordinary floats
> > > > > correspond to a subset of the EXACT rational numbers equal to
> > > > > <some integer> X 2^<some integer> which is not an interval at all.
> > > > > (there are also inf and nan things which are not ordinary in that
> > > > > sense)
> > > > >
> > > > > So, citation? (And I don't mean citing a physicist, or someone
> > > > > who learned his arithmetic in 4th grade and hasn't re-evaluated it
> > > > > since. A legitimate numerical analyst.)
> >
> > I am not a numerical analyst, so perhaps the following is naive, but I
> > would really like know where it is flawed or why my assumptions are
> > unreasonable.
> >
> > I call a real number exactly representable when it occurs as an exact
> > value of a float with some bounded number of bits for its exponent.
> > Then when using floats to represent real numbers, you have to decide
> > for each real number x by which exactly representable real number f(x)
> > it should be represented.
>
>
> OK, you are positing (a) not representable real number x and (b)
> representable number y.
>
> You cannot compute representable e = x-y because then x is
> representable by y+e.
>
> So whatever you mean by x you cannot represent. It because pointless to
> talk about
> it.
>
>
>
>
> > I can think of two desirable properties:
> > * exactly representable real numbers should be represented by
> > themselves,
> >
>
> All floating point numbers exactly represent themselves.
>
>
> > * the relation <= should be preserved.
> > These properties yield that for each exactly representable real number y
> > the set {x real : f(x) = y} is an interval around y.
>
>
> What's f?
>
> If you are doing interval arithmetic, please read up on it. the literature
> is
> for the most part quite accessible.
>
>
> > Moreover this
> > interval is contained in every interval (a, b) where a and b are exactly
> > representable real numbers with a < y and y < b.
> >
> > Okay, we need some condition on the mantissa and exponent, for if the
> > mantissa and exponent are allowed to be arbitrary integers, a function
> > with these properties fails to exists: Let f be a partial function with
> > the required properties, then the intervals {x real : f(x) = y}, being
> > contained in the intervals (a,b) with a and b exactly representable
> > with a < y < b, necessarily contain only y. Since there are only
> > countable many exactly representable real numbers, each with preimage
> > containing only itself, the domain of definition of f is countable. In
> > particular f is not a total function.
> >
>
> huh? I read this twice, and refuse to read it again.
>
>
> >
> > ...
> > > What this means is that the numbers in the system A and b often come
> > > from the real world and you don't know their true values, just the
> > > values that you measured.
> >
>
>
>
>
> > > When you enter the data into the computer you put the values for A and
> > > b that are the closest numbers to what you believe. A major question
> > > in computational linear algebra is how to measure the sensitivity of
> > > the computed solution to slight changes in the initial data. The
> > > numbers used in solving the system are exactly the represented
> > > floating-point numbers.
> > >
> > > > They're representatives for the actual (either unknown or impossible
> > > > to represent) elements of your data. And, yes, they're also exact
> > > > rational numbers--once again they can be both--but the point is that
> > > > the input and output floating point numbers are viewed as
> > > > perturbations of the (actual) real field elements you care about.
> > >
> > > That does not give you or anyone else permission to say "oh, this
> > > data might not be right so instead of solving the system as best as
> > > I can, I will use some off-hand rule to clip bits off, since it's just
> > > a perturbation of something". No, you compute the best you can
> > > with the data you have.
> >
> > You cannot just assume either that the data is exact.
> >
>
> If you think that there is a better assumption that gives you more
> information than
> computing the best you can, plus condition numbers, you are free to offer it
> to the numerical linear algebra specialists who have been laboring under
> this
> model for, oh, 60 years.
>
>
> >
> > Also it makes more sense to me not to do the best you can, but the best
> > you can do efficiently. Trying to do the best you can is of no use if it
> > means running out of memory or taking a year. If doing things
> > efficiently involves some clipping, then that's okay with me,
> > especially if the clipping is configurable.
>
>
> Since the cost of a floating-point operation is generally constant
> these days, you do not get higher efficiency by zeroing-out trailing bits.
>
> Finding results to particular accuracy, e.g. finding a bounding interval
> for the root of a
> polynomial, can be done by specifying the polynomial and a width. In this
> case
> "the best" makes no sense.
>
> Assuming that floating-point numbers are dirty out of ignorance, without
> context,
> is fundamentally a bad idea.
>
> RJF
>
>
> >
> >
> > Regards,
> >
> > Erik Massop
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
