You didn't tell us the answers to the riddles. Or did I miss them.
On Thursday, 21 August 2014 01:47:04 UTC+2, rjf 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.
