On Wed, Aug 6, 2014 at 7:00 PM, rjf <fate...@gmail.com> wrote:
>> >> > 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.
The are two representations of the same canonical object.
>> >> > 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} ?
Of course, as illustrated.
sage: Integers(13^1024)
Ring of integers modulo 4764...1
>> >> > 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?
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).
> Does Sage have other um, approximations, in its nomenclature?
Sure. RealField(123)[x]. Power series rings. P-adics.
>> >> >> 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.
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.
>> 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.
> 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.
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.
>> 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.
> 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.
> 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
Again, it's syntactic sugar.
>> 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".
I don't think any answer is going to be right for everyone, given the
diversity of users we have. I personally think we've found a nice
happy medium, but you're free to disagree.
>> > 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?
sage: .1- 0.10000000000000000000000000000
0.000000000000000
sage: parent(_)
Real Field with 53 bits of precision
> and anyone who writes x+0.1 is relegating that sum to 1 digit "precision"?
As I mentioned previously, we default to the (somewhat arbitrary)
minimum of 53 bits of precision.
>> > 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.
You claim "this idea has practical implications for efficient
programs" in http://www.cs.berkeley.edu/~fateman/papers/polysbyGMP.pdf
Now you claim it's stupid. Maybe it's both.
- 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.
