-1 To this idea. Better to try to improve the coercion system to
support something that interacts with symbolics better.
On Sat, May 31, 2008 at 5:23 PM, William Stein <[EMAIL PROTECTED]> wrote:
>
> 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
-~----------~----~----~----~------~----~------~--~---
