On Tuesday, August 5, 2014 7:59:00 PM UTC-7, Robert Bradshaw wrote:
>
> On Tue, Aug 5, 2014 at 6:36 PM, rjf <fat...@gmail.com <javascript:>>
> wrote:
> >
> >
> > 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> 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.
>
> Yes, they can "both" be canonical: they are equal (as elements of
> Z/13Z). There is the choice of internal representation, and what
> string to use when displaying them to the user, but that doesn't
> affect its canonicity as a mathematical object.
>
> I don't understand this.
I use the word canonical to mean unique distinguished exemplar.
So there can't be two. If there are two distinguishable items, then one or
the other or neither might be canonical. Not both.
> >> 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) .
>
> Nope. Or function fields. Or p-adics. Let alone more complicated
> objects like points on algebraic varieties.
>
OK, but of course any of these concepts could be added -- or built-in in
a future version. If someone cared.
>
> > 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.
>
> I can just see you sitting there wondering why Sage hasn't died the
> tragic death your crystal ball said it would ages ago...
>
No, I think that Sage is fairly moribund. Look around at the postings in
sage-devel.
>
> >> > 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)?
>
> Sure.
>
> sage: b = Integers(13^1024)(a); b
> 5
> sage: b^(4*13^1023)
> 1
>
> And what structure is that? Does Sage know about Z_{nonprime} ?
> >> >> 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?
>
> R is a (very well studied) approximation to a field.
>
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?
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?
Does Sage have other um, approximations, in its nomenclature?
>
> >> >> 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 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.
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. 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.
>
> 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? You want the user
to believe that Sage uses decimal arithmetic? Seriously? How far
are you going to try to carry that illusion?
You imagine a user who understands rings and fields, and knows that
Real Field is not a field, but knows so little about computers that he
thinks 1.3 is 13/10 exactly? (By the way, I have no problem if
1.3 actually produces 13/10, and to get a float, you have to try to
convert it explicitly, and the conversion might even come up with an
interval
or an error bound or something that leads to "reliable" computing.
Rather than some guessy-how-many-bits stab in the dark thing that
prints as 1.3
> sage: QQ(1.3)
> 13/10
> sage: (1.3).exact_rational()
> 5854679515581645/4503599627370496
> sage: a = RealField(200)(1.3); a
> 1.3000000000000000000000000000000000000000000000000000000000
> sage: a.exact_rational()
> 522254864384171839551137680010877845819715972979407671472947/401734511064747568885490523085290650630550748445698208825344
>
>
>
I assume it is possible to calculate all kinds of things if you carefully
specify them,
in Sage. After all, it has all those programs to call, including sympy.
The
issue iwe have been discussing is really what does it do "automatically".
>
>
> > 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?
>
> Yep, RealField(53)(0.04), which is a bit arbitrary.
>
> > And is there a difference between 0.10 and
> > 0.1000000000000000000000000000000000
>
> Yep.
>
> sage: a = 0.1000000000000000000000000000000000
> sage: a.precision()
> 113
>
So 0.1- 0.10000000000000000000000000000....
is 0.0????????????????? where ? = undetermined?
and anyone who writes x+0.1 is relegating that sum to 1 digit "precision"?
>
> > (There is a difference in Mathematica. Mathematica claims to be the
> best
> > system for scientific computing. :)
>
> Few systems don't make that claim about themselves :).
>
I've noticed.
>
> >> 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/.
> >
> >
> > 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...
>
> I've personally "applied" multiplying astronomically sized before
> (thought the result itself is squarely in the domain of pure math):
> http://www.nsf.gov/news/news_summ.jsp?cntn_id=115646/
>
Assume there is an application that involves multiplication of polynomials.
You can multiply polynomials by encoding them as large integers,
multiplying, and decoding. Sometimes called Kronecker's Trick.
So there are lots of applications. Are they stupid tricks? Probably.
RJF
>
> - 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.
