On Sat, Aug 2, 2014 at 11:16 PM, rjf <fate...@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"
Are you seriously claiming that "power series over a finite field" have no
applications?
>> > 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.
>> 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)".
> 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. That's why every single math software system with
any real algebraic sophistication has made this (same) choice.
> 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
>> 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.
>> 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/
> 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
>
>>
>> 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.
>
>>
>> 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. 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
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 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/.
William
--
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.
