On Sunday, August 3, 2014 10:11:57 PM UTC-7, William wrote:
>
>
>
> On Sat, Aug 2, 2014 at 11:16 PM, rjf <fat...@gmail.com <javascript:>>
> wrote:
> > On Wednesday, July 30, 2014 10:23:03 PM UTC-7, William wrote:
> >> [1] http://maxima.sourceforge.net/docs/manual/en/maxima_29.html
> >>
> >> > Perhaps Axiom and Fricas have such odd Taylor series objects; they
> >> > don't
> >> > seem to be
> >> > something that comes up much, and I would expect they have some
> >> > uncomfortable
> >> > properties.
> >>
> >> They do come up frequently in algebraic geometry, number theory,
> >> representation theory, combinatorics, coding theory and many other
> >> areas of pure and applied mathematics.
> >
> >
> > You can say
> > whatever you want about some made-up computational problems
> > in "pure mathematics" but I think you are just bluffing regarding
> > applications.
>
> Let me get this straight -- you honestly thinking I'm bluffing regarding
> applications of:
>
> "power series in one variable over a finite field"
>
Yes.
I read your statement above to say, among other things, that
{such odd power series objects} come up frequently in ... many area of ...
applied mathematics.
>
>
> Are you seriously claiming that "power series over a finite field" have no
> applications?
>
I can imagine you could invent an "application", so I would not say these
objects
have "no applications". I can even invent one application for you. The
application is
"show a structure that can be created by a computer program that consists
of a power
series etc etc." This sort of smacks of the self referentiality that
comes from answering
the command:
Use X in a sentence.
by the response
"Use X in a sentence.
>
>
>
> >> > Note that even adding 5 mod 13 and the integer 10 is potentially
> >> > uncomfortable,
> >>
> >> sage: a = Mod(5,13); a
> >> 5
> >> sage: parent(a)
> >> Ring of integers modulo 13
> >> sage: type(a)
> >> <type 'sage.rings.finite_rings.integer_mod.IntegerMod_int'>
> >> sage: a + 10
> >> 2
> >> sage: parent(a+10)
> >> Ring of integers modulo 13
> >>
> >> That was really comfortable.
> >
> >
> > Unfortunately, it (a) looks uncomfortable, and (b) got the answer
> wrong.
> >
> > The sum of 5 mod13 and 10 is 15, not 2.
> >
> > The calculation (( 5 mod 13)+10) mod 13 is 2.
> >
> > Note that the use of mod in the line above, twice, means different
> things.
> > One is a tag on the number 5 and the second is an operation akin to
> > remainder.
>
> The answer from Sage is correct, and your remarks to the contrary are just
> typical of rather shallow understanding of mathematics.
>
Are you familiar with TeX's \bmod ?
It is possible to define anything that comes from Sage as correct.
Mathematica does that kind of thing often, declaring its reported bugs to
be features. Sometimes
I agree, sometimes not.
>
> >> It's basically the same in Magma and
> >> GAP. In PARI it's equally comfortable.
> >>
> >> ? Mod(5,13)+10
> >> %2 = Mod(2, 13)
> >>
> >>
> >> > and the rather common operation of Hensel lifting requires doing
> >> > arithmetic
> >> > in a combination
> >> > of fields (or rings) of different related sizes.
> >
> >
> > If you knew about Hensel lifting, I would think that you would comment
> here,
> > and that
> > you also would know why 15 rather than 2 might be the useful answer.
>
> The answer output by Pari is neither 15 nor 2. It is "Mod(2, 13)".
>
Well, if you simply insist that arithmetic requires the conversion of 10 to
a number in Z_13,
then that answer is OK.
>
>
> > coercing the integer 10 into something like 10 mod 13 or perhaps -3
> > mod 13 is
> > a choice, probably the wrong one.
>
> It is a completely canonical choice, and the only possible sensible one to
> make in this situation.
>
Which one, -3 or 10?
They can't both be canonical.
> That's why every single math software system with any real algebraic
> sophistication has made this (same) choice.
>
I think the issue comes up as to the definition of a system with "real
algebraic sophistication" and for that
matter, whether you are familiar with all of them.
While you are probably aware that I am not a big fan of Mathematica, it is
quite popular. This is what it
has in its documentation.
Modulus->n
is an option that can be given in certain algebraic functions to specify
that integers should be treated modulo n.
It seems that Mathematica does not have built-in functionality to
manipulate objects such as Mod(2,13) .
In fact, your whole premise seems to be that mathematically sophisticated
<whatever> must be based on
some notion of strongly-typed hierarchical mathematical categories, an
idea that has proven unpopular
with users, even if it has seemed to system builders, repeatedly and
apparently incorrectly, as the golden fleece,
the universal solvent, etc.
I think the historical record shows not only the marketing failure of
Axiom, but also mod Reduce, and some subsystem
written in Maple. Also the Newspeak system of a PhD student of mine,
previously mentioned.
Now you may think that (for example) Magma is just what you? the world?
needs (except only that it is not free).
That does not mean it should be used for scientific computing.
>
> > presumably one could promote your variable a to have a value in Z and do
> > the addition again. Whether comfortably or not.
>
> sage: a = Mod(5,13); a
> 5
> sage: a + 10
> 2
> sage: b = a.lift(); parent(b)
> Integer Ring
> sage: b + 10
> 15
>
Thanks. Can the lifting be done to another computational structure, say
modulo 13^(2^n)?
>
> >> There are many 1's.
> >
> >
> > that's a choice; it may make good sense if you are dealing with a raft
> of
> > algebraic structures
> > with various identities.
>
>
> We are.
>
> > I'm not convinced it is a good choice if you are dealing with the bulk of
> > applied analysis and
> > scientific computing applications amenable to symbolic manipulation.
>
> Sage is definitely not only dealing with the that.
>
Actually, I expect that Sage, as a front end to several systems, does not
adequately
"deal" with ideas like "1". Which might be used in any number of the
subsystems
for concepts like matrix identity under multiplication. Or a power series,
or a polynomial...
>
>
> >> It's not what Sage does. Robert wrote the wrong thing (though his
> >> "see above" means he just got his words confused).
> >> In Sage, one converts the rational to the parent ring of the float,
> >> since that has lower precision.
> >
> >
> > It seems like your understanding of "precision" is more than a little
> fuzzy.
> > You would not be alone in that, but writing programs for other people to
> > use sometimes means you need to know enough more to keep from
> > offering them holes to fall into.
> >
> > Also, as you know (machine) floats don't form a ring.
> >
> > Also, as you know some rationals cannot be converted to machine floats.
> >
> > ( or do you mean software floats with an unbounded exponent?
> > Since these are roughly the same as rationals with power-of-two
> denominators
> > / multipliers).
>
> Yes, Sage uses http://www.mpfr.org/
>
While that solves the problem of overflow or underflow, it still does not
allow
the representation of 1/3 as a (binary radix) float of some finite
precision.
>
>
> > What is the precision of the parent ring of a float?? Rings with
> > precision???
>
> sage: R = parent(1.399390283048203480923490234092043820348); R
> Real Field with 133 bits of precision
> sage: R.precision()
> 133
>
> I'm confused here. Are you now saying R is a Field? Is a Real Field a
kind of
Field? Is there a multiplicative inverse in R for the object 3.0 ? Or is
a Real Field
like a "Dutch Oven" which is actually not an oven, but a pot?
>
> >>
> >> sage: 1.3 + 2/3
> >> 1.96666666666667
> >
> >
> > arguably, this is wrong.
> >
> > 1.3, if we presume this is a machine double-float in IEEE form, is
> > about
> > 1.300000000000000044408920985006261616945266723633....
> > or EXACTLY
> > 5854679515581645 / 4503599627370496
> >
> > note that the denominator is 2^52.
> >
> > adding 2/3 to that gives
> >
> > 26571237801485927 / 13510798882111488
> >
> > EXACTLY.
> >
> >
> > which can be written
> > 1.9666666666666667110755876516729282836119333903...
> >
> > So you can either do "mathematical addition" by default or do
> > "addition yada yada".
> >
>
> In Sage both operands are first converted to a common structure in which
> the operation can be performed, and then the operation is performed.
>
Well, there are a large number of common structures.
One that gets the exact answer is to convert to arbitrary-precision
rationals.
One that does not always get the exact answer is some kind of
floating-point representation.
It is of course possible to convert these object to (say) polynomials or
Taylor series..
>
>
>
>
> >
> >>
> >> Systematically, throughout the system we coerce from higher precision
> >> (more info) naturally to lower precision. Another example is
> >>
> >> Z ---> Z/13Z
> >>
> >> If you add an exact integer ("high precision") to a number mod 13
> >> ("less information"), you get a number mod 13 (as above).
> >
> >
> > This is a choice but it is hardly defensible.
> > Here is an extremely accurate number 0.5
> > even though it can be represented in low precision, if I tell you it is
> > accurate to 100 decimal digits, that is independent of its
> representation.
> >
> > If I write only 0.5, does that mean that 0.5+0.04 = 0.5? by your
> rule of
> > precision, the answer can only have 2 digits, the precision of 0.5, and
> so
> > correctly rounded,
> > the answer is 0.5. Tada. [Seriously, some people do something very
> close
> > to this.
> > Wolfram's Mathematica, using software floats. One of the easy ways of
> > mocking it.]
>
> The string representation of a number in Sage is not the same thing as
> that number.
>
I think that is kind of taken for granted as the relationship between
input/output forms
and whatever is in the computer. Electrons. And even those are not the
abstraction
"number".
> Here's an example of how to make the image of 1/2, but stored with very
> few bits of precision, then add 0.04 to it:
>
> sage: RealField(2)(0.5) + 0.04
> 0.50
>
Hm. Can one change the meaning of "+" so that returns 0.54?
What is the abstraction behind 0.04 ? RealField(n)(0.04) for some
integer n?
And is there a difference between 0.10 and
0.1000000000000000000000000000000000
(There is a difference in Mathematica. Mathematica claims to be the best
system for scientific computing. :)
>
>
> If one needs more precision tracking regarding exactly what happens when
> doing arithmetic (and using functions) with real or complex numbers, Sage
> also have efficient interval arithmetic, based on, e.g.,
> http://gforge.inria.fr/projects/mpfi/.
>
I think that mpfi is probably a fine interval arithmetic package, but I
think it
is not doing precision tracking, really. It's doing reliable (if
pessimistic)
arithmetic.
>
>
> >
> > I think that numbers mod 13 are perfectly precise, and have full
> > information.
> >
> > Now if you were representing integers modulo some huge modulus as
> > nearby floating-point numbers, I guess you would lose some information.
> >
> > There is an excellent survey on What Every Computer Scientist Should Know
> > About Floating Point...
> > by David Goldberg. easily found via Google.
> >
> > I recommend it, often.
>
> Paul Zimmerman writes many useful things about what mathematicians should
> know about floating point -- http://www.loria.fr/~zimmerma/papers/
> <http://www.google.com/url?q=http%3A%2F%2Fwww.loria.fr%2F~zimmerma%2Fpapers%2F&sa=D&sntz=1&usg=AFQjCNGKaRFH-Brnh1SCpowc-FDHgt1ikQ>
> .
>
I have enjoyed reading some of Zimmerman's papers, and he and his authors
have
said many interesting things. The Goldberg article tries to dispel commonly
held
myths about machine floating-point arithmetic. Myths often held by computer
programmers and of course mathematicians. Zimmerman has addressed many
fun problems in clever ways.
Inventing fast methods is fun, although (my opinion) multiplying integers
of astronomical size is hardly
mainstream scientific computing.
Not to say that someone might claim that
this problem occurs frequently in many computations in pure and applied
mathematics...
RJF
>
--
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.
