On Sat, Jan 11, 2014 at 9:11 AM, Nils Bruin <nbr...@sfu.ca> wrote: > On Saturday, January 11, 2014 6:26:59 AM UTC-8, Volker Braun wrote: >> >> Would it be possible to move real literals to their own parent? Arithmetic >> operations with other parents should always cast the literal to the other >> parent first, and arithmetic operations within the real literals would end >> up in RR. > That should be pretty straightforward, but it has an ugly wart: > > (hypothetical): > > hypothetical_sage: a=RR(71)(1e20) > hypothetical_sage: b=1e0 > hypothetical_sage: a+b+b > 1.00000000000000000002e20 > hypothetical_sage: b+b+a > 1.00000000000000e20
I think the primary wart here is that RR(1e20) is still a RealLiteral, leading to inconsistent behavior. I would propose we could special case this such that this cast actually changes it to a RealNumber(prec=53) which wouldn't have the wart above or the strangeness first mentioned in this ticket. (This could perhaps be done by making its own Parent, but I don't think we should coerce to the other on arithmetic--if the "true Parent" isn't specified quickly and explicitly we should treat is as a RealNumber(prec=53). > The fact that floating point operations aren't associative/commutative is > one thing, but making it so that the resulting parent even changes is quite > possibly a worse wart than having to write quotes around literals. > > From an advertising point of view I think some form of RealLiteral is a > great idea: It makes it really easy to demonstrate: look sage has > multiprecision floats and they are "natural" objects for it (no quotes > needed). It's just fundamentally underspecified if there is not a > "preferred" precision out there. Most other computer algebra system solve > that problem by having a preferred precision: a global setting. But it's > nasty to have global settings, of course (especially if you want to turn > code developed in an interactive session into library code) > > In effect we already have a global setting for this, i.e., this already > works: > > sage: RealNumber=lambda s: RealField(71)(s) > sage: 1e0+1e0+1e20 > 1.00000000000000000002e20 > sage: RealNumber=lambda s: RealField(53)(s) > sage: 1e20+1e0+1e0 > 1.00000000000000e20 > > and this would continue to work if we remove RealLiterals. So perhaps we > just need better tools to (temporarily) set RealNumber and/or change the > name that the preparser produces? We could then deprecate/remove the > RealLiterals that we have now. I generally like to avoid modifying the global environment to produce a local result. A with statement context could be a handy way to get this though. - 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.
