Henryk Trappmann wrote: > On May 31, 10:55 pm, Carl Witty <[EMAIL PROTECTED]> wrote: >> Actually, there's no homomorphism either way; >> RR(R2(2)+R2(3)) != RR(R2(2)) + RR(R2(3)) > > Hm, thats an argument. I somehow thought that it is closer to a > homomorphism but perhaps this reasoning has no base. > >> IMHO, giving a+b the precision of the less-precise operand is better >> than using the more-precise operand, because the latter has too much >> chance of confusing people who don't understand floating point. For >> instance, if 1.3+RealField(500)(pi) gave a 500-bit number, I'll bet a >> lot of people would assume that this number matched 13/10+pi to almost >> 500 bits. > > Hm, yes, but this binary decimal conversion is another topic, I mean > nobody would assume that 0.3333333 coerced to 500 *decimal* digits > matches 1/3 to 500 digits? I anyway wondered why one can not specify a > base in RealField, or did I merely overlook the opportunity? > >> Of course, maybe there are other choices that are better than either >> of these. We could throw away RealField and always use >> RealIntervalField instead; but that's slower, has less special >> functions implemented, and has counterintuitive semantics for >> comparisons. We could do pseudo-interval arithmetic, and say that >> 1e6+R2(3) should be a 20-bit number, because we know about 20 bits of >> the answer; but to be consistent, we should do similar psuedo-interval >> arithmetic even if both operands are the same precision, > > At least RR would then be a ring ;) > >> and then RR >> becomes less useful for people who do understand how floating point >> works and want to take advantage of it. > > Ya, I dont want to change floating point, it just seems somewhat > arbitrary to me to coerce down precision, while coercing up precision > with integers. Of course if you consider integer with precision > infinity (as indeed there are no rounding errors and it is an exact > ring) then this makes sense again. > > But if so then I want to have something like SymbolicNumber which is > the subset of SymbolicRing that does not contain variables. And that > this SymbolicNumber is coerced automatically down when used with > RealField.
I hope this is not superfluous, but there is a SymbolicConstant class, which seems to be automatically used when dealing with numbers and not variables: sage: type(SR(3)) <class 'sage.calculus.calculus.SymbolicConstant'> sage: type(1.0*SR(3)) <class 'sage.calculus.calculus.SymbolicConstant'> Jason --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
