On Sat, May 31, 2008 at 3:33 PM, Jason Grout
<[EMAIL PROTECTED]> wrote:
>
> 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'>
The parent of SymbolicConstant is SymbolicRing. The parent
is what matters for coercion.
sage: parent(SR(3))
Symbolic Ring
It would be conceivable that we could have a SymbolicConstant
ring that is a subring of the full SymbolicRing. I haven't thought
through at all how this would work, but it might address the
OP's confusion. Note that it would problematic in Sage, since
e.g., if x = var('x'), then x + 1 - x is the symbolic 1, so we have
that the sum of two elements of SR would be in SC, i.e., rings
wouldn't be closed under addition. This would take a lot of care
to actually do. I'm not saying any of this should be done.
William
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
