On Thursday, August 7, 2014 10:55:37 PM UTC-7, Robert Bradshaw wrote:
>
> On Thu, Aug 7, 2014 at 9:02 AM, rjf <fat...@gmail.com <javascript:>>
> wrote:
> >
> >
> > On Wednesday, August 6, 2014 8:11:21 PM UTC-7, Robert Bradshaw wrote:
> >>
> >>
> >>
> >> The are two representations of the same canonical object.
> >
> >
> > The (computer algebra) use of the term, as in "simplified to a canonical
> > form" means
> > the representation is canonical. It doesn't make much sense to claim
> that
> > all these
> > are canonical: 1+1, 2, 2*x^0, sin(x)^2+cos(x)^2 + exp(0).
>
> The point was that there's a canonical domain in which to do the
> computation.
>
I have not previously encountered the term "canonical domain". There is
a CAS literature which includes the concept of simplification to a
canonical form.
There is also a useful concept of a zero-equivalence test, whereby E1-E2
can be shown to be zero, although there is not necessarily a simplification
routine that will "canonically simplify" E1 to E3 and also E2 to E3.
>
> >> > And what structure is that? Does Sage know about Z_{nonprime} ?
> >>
> >> Of course, as illustrated.
> >>
> >> sage: Integers(13^1024)
> >> Ring of integers modulo 4764...1
> >
> >
> > How much does it know? Does it know that it is not a field, but that
> > Integers(13) is a field?
>
> sage: Integers(13).is_field()
> True
> sage: Integers(13^1024).is_field()
> False
>
> >> > I'm still confused. Is the term "Real Field" in Sage the (or some)
> >> > real
> >> > field?
> >> >
> >> > If it is an approximation to a field, but not a field, why are you
> >> > calling
> >> > it a field?
> >>
> >> Because it's shorter to type and easier to find/discover than
> >> ApproximateRealField or something like that.
> >>
> >> > If that doesn't get you in trouble, why doesn't it? Does Real Field
> >> > inherit
> >> > from
> >> > Field? Does every non-zero element have an inverse?
> >>
> >> Of course it suffers from the same issues that (standard) floating
> >> point numbers do in any language, user be aware (and we at least
> >> document that).
> >
> > And you know that everyone reads the documentation?
> > No, it doesn't suffer from the same issues as in other languages,
> because
> > those other languages probably don't refer to it as a field.
>
> The issues of floating point errors and rounding are much larger than
> the question of whether every element has an inverse. You seem very
> fixated on the name.
>
Just that for a mathematician to call something a field when it isn't
would, I think, be a serious mistake. You seem to think that it is
ok for a computer system to do so. I certainly agree that there are
more important issues with floating point computation than the
fact that these numbers do not constitute a real closed field.
>
> We also have an object called the ring of integers, but really it's
> the ring of integers that fits into the memory of your computer.
> Should we not call it a Ring?
>
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.
>
> >> > 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.
>
> The p-adic 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 p-adic numbers one is typically chooses a
> precision (e.g. how many digits, not unlike a choice of number of
> bits) to use.
>
> 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.
>
> 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.
>
> >> >> It is more conservative to convert operands to the domain with less
> >> >> precision.
> >> >
> >> > Why do you say that? You can always exactly convert a float number
> in
> >> > radix b to
> >> > an equal number of higher precision in radix b by appending zeros.
> >> > So it is more conserving (of values) to do so, rather than clipping
> off
> >> > bits from the other.
> >>
> >> Clipping bits (or digits) is exactly how one is taught to deal with
> >> significant figures in grade school, and follows the principle of
> >> least surprise (though floating point numbers like to play surprises
> >> on you no matter what). It's also what floating point arithmetic does
> >> when the exponent is different.
> >
> >
> > It is of course also taught in physics and chemistry labs, and I used
> this
> > myself in the days when slide-rules were used and you could read only
> > 3 or so significant figures. That doesn't make it suitable for a
> computer
> > system. There are many things you learn along the way that are
> simplified
> > versions of the more fully elaborated systems of higher math.
> > What did you know about the branch cuts in the complex logarithm
> > or log(-1) when you were first introduced to log?
>
> Only being able to store 53 significant bits is completely analogous
> to only being able to read 3 significant (decimal) figures.
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.
On the other hand, the
> I think
> the analogy is very suitable for a computer system. It can clearly be
> made much more rigorous and precise.
>
What you are referring to is sometimes called significance arithmetic,
and it has been thoroughly discredited.
Sadly, Wolfram the physicist put it in Mathematica.
>
> 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
If you round to some number of bits, say 53, with a=3.14159 and b=1e-100,
the left side is 0, and the right side is 1e-100. The relative error in
the answer
is, um, infinite.
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.
> >> >> We consider the rationals to have infinite precision, our
> >> >> real "fields" a specified have finite precision. This lower
> precision
> >> >> is represented in the output, similar to how significant figures are
> >> >> used in any other scientific endeavor.
> >> >
> >> > Thanks for distinguishing between "field" and field. You don't seem
> >> > to understand the concept of precision though.
> >>
> >> That's a bold claim. My Ph.D. thesis depended on understanding issues
> >> of precision. I'll admit explaining it to a layman can be difficult.
> >
> > Is your thesis available online? I would certainly look at it and see
> > how you define precision.
>
> Yes, it's online.
>
> I define precision (e.g. computing a value to a given precision) as
> the negated log of the absolute (respectively relative) error, but
> most importantly it's something you can have more or less of, and lose
> due to rounding, etc. Perhaps I could have used the term "accuracy"
> instead. I use the actual errors themselves in my analysis.
>
I looked at your thesis (we exchanged mail on this.)
Yes you could have used absolute error or relative error.
Taking a log is optional.
I think that if you said you increase the error by cancellation or rounding,
that would be OK.
>
> Generally, however, precision is something attached to a read "field"
> and specifies the number of bits used to represent its elements (and,
> consequently, exactly what rounding errors are introduced when doing
> arithmetic).
>
The number of bits used to represent a number n is one of the parameters
that determines the result of rounding, yes. Other parameters are the
presence
or absence of guard digits, and rules for resolving ties.
It does not say whether a number is accurate or not.
>
> >> > 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.
> >>
> >> No, I don't think that at all. Sage also has the concept of real
> >> intervals distinct from real numbers.
> >
> >
> > I suppose that the issue here is I don't know what you mean by "real
> > number".
> > Sage has something in it called "real". Mathematics uses that
> > term too (e.g. Dedekind cut). They appear to be different.
> >>
> >>
> >> 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.)
>
> How about the docs on error analysis for LAPACK, which are presumably
> written by an expert:
>
> https://software.intel.com/sites/products/documentation/hpc/mkl/mklman/GUID-51614DEE-9DF8-4D45-80F5-3B25CB7FF748.htm
>
>
> There it says "you often need to solve a system Ax = b, where the data
> (the elements of A and b) are not known exactly." So what are the IEEE
> floats sitting in your computer when you're doing this computation?
>
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.
>
> Here they also talk about "loss of precision" similar in spirit to the
> precision (of a value) as above.
>
eh, precision occurs once in the link you cite...
"..... then the error in the solution x is also large; you may even
encounter a complete loss of precision. ...."
The relevant term is actually "complete loss of precision" which does
have a useful meaning, which
is that the relative error is infinite.
> >> >> This is similar to 10 + (5 mod 13), where the right hand side has
> >> >> "less precision" (in particular there's a canonical map one way,
> many
> >> >> choices of lift the other.
> >> >>
> >> >> Also, when a user writes 1.3, they are more likely to mean 13/10
> than
> >> >> 5854679515581645 / 4503599627370496, but by expressing it in decimal
> >> >> form they are asking for a floating point approximation. Note that
> >> >> real literals are handled specially to allow immediate conversion to
> a
> >> >> higher-precision parent.
> >> >
> >> > What do you know when a user writes 1.3, really?
> >>
> >> Quite a bit. They probably didn't mean pi. If they really cared, they
> >> could have been more specific. At least we recognize this ambiguity
> >> but we can't let it paralyze us.
> >
> >
> > I think there is, in the community that consumes "scientific computing"
> > since 1960 or so, a set of expectations about "1.3". You can use
> this,
> > or try to alter the expectations for your system. For example, if you
> > displayed it as 13/10, that would be a change. Or if you displayed it
> > as [1.25,1.35]. But then you are using a notation 1.25, and what
> > does that mean, [[1.245,1.255], .... ] etc.
> >>
> >>
> >> > You want the user
> >> > to believe that Sage uses decimal arithmetic? Seriously? How far
> >> > are you going to try to carry that illusion?
> >>
> >> If they don't immediately specify a new domain, we'll treat it as
> >> having 53 bits. It's syntactic sugar.
> >
> >
> > So it sounds like you actually read the input as 13/10, because only
> then
> > can
> > you approximate it to higher precision than 53 bits or whatever. Why
> not
> > just admit this instead of talking
> > about 1.3.
>
> In this case the user gives us a decimal literal. Yes, this literal is
> equal to 13/10. We defer interpreting this as a 53-bit binary floating
> point number long enough for the user to tell us to interpret it
> differently. This prevents surprises like
>
> sage: RealField(100)(float(1.3))
> 1.3000000000000000444089209850
>
> or, more subtly
>
> sage: sqrt(RealField(100)(float(1.3)))
> 1.1401754250991379986106491649
>
> instead of
>
> sage: sqrt(RealField(100)(1.3))
> 1.1401754250991379791360490256
>
> When you write 1.3, do you really think 5854679515581645 /
> 4503599627370496, or is your head really thinking "the closest thing
> to 13/10 that I can get given my choice of floating point
> representation?" I bet it's the latter, which is why we do what we do.
>
I suspect it is not what python does.
It is what Macsyma does if you write 1.3b0 to indicate "bigfloat".
>
> - Robert
>
--
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.
