On Mon, Jan 6, 2014 at 1:46 PM, Zimmermann Paul
<paul.zimmerm...@inria.fr> wrote:
> Nils,
>
>> Date: Mon, 6 Jan 2014 13:18:07 -0800 (PST)
>> From: Nils Bruin <nbr...@sfu.ca>
>>
>> On Monday, January 6, 2014 12:46:19 PM UTC-8, Zimmermann Paul wrote:
>>
>> > What about getting rid of real literals?
>> >
>>
>> I think they exist mainly to let
>>
>> RealField(200)(1e-20)
>>
>> work in the first place: The parser needs to generate code to instantiate
>> the constant 1e-20 somewhere and that constant should remember its original
>> string representation to allow convenient creation of an element in
>> RealField(200).
>
> but RealField(200)("1e-20") already does the job:
>
> sage: RealField(200)("1e-20")
> 1.0000000000000000000000000000000000000000000000000000000000e-20
>
>> Consider for instance
>>
>> sage: RealField(200)(a+(1e-800))
>> 9.9999999999999994515327145420957165172950370278739244710772e-21
>>
>> (adding this constant doesn't change the 53-bit representation of a but it
>> does ensure the resulting number is not considered a RealLiteral any more).
>
> this demonstrates another inconsistency:
>
> sage: a=1e-20
> sage: RealField(200)(a)
> 1.0000000000000000000000000000000000000000000000000000000000e-20
> sage: RealField(200)(a+0)
> 9.9999999999999994515327145420957165172950370278739244710772e-21
> sage: RealField(200)(1*a)
> 9.9999999999999994515327145420957165172950370278739244710772e-21
>
>> So back to your question: I expect that real literals can't be removed
>> because it would make creating high precision constants too much of a pain.
>
> I don't think so. We should educate the user:
>
> * if she/he writes 1e-20, she/he should be aware that (like in other
> languages)
> 1e-20 is not exactly representable in binary, thus will be approximated to
> the current precision
>
> * if she/he wants to define a high precision constant, use "1e-20"
By that logic, rather than preparsing 1/2 we should force the user to
write ZZ(1) / ZZ(2). I find
sage: RealField(200)(1e-20)
9.9999999999999994515327145420957165172950370278739244710772e-21
surprising, as I explicitly asked for 200 digits of precision, this is
a natural way to write a "literal" of high precision. I'll admit
sage: Reals(200)(RealField(53)(1e-20))
1.0000000000000000000000000000000000000000000000000000000000e-20
is probably wrong. BTW, it was intended not just for real fields but
exact ones as well (thought that seems to have changed, as now
sage: QQ(1e-20)
1/99999999999999990439
sage: ZZ(1e30)
1000000000000000019884624838656
though this should be an easy fix. (Yes, I see why that's true, but
for someone who's not a numerical analyst it's quite unfortunate.)
(FWIW, the problem with putting literals in another field, like
RealLazyField, is what to do when doing arithmetic like 1.2 + 1.7 one
wants arithmetic with reals of unspecified parent to be "fast." The
literalness of floating point literals is supposed to just affect
constructors. It almost makes one want to encode the desired precision
in the literal itself....)
- 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/groups/opt_out.
