Re: [Pyobjc-dev] NSDecimalNumber to the next level

[Ronald O. <ous...@ci...>]

On 10-mrt-04, at 16:09, Pierce T.Wetter III wrote:

>
> On Mar 9, 2004, at 11:55 PM, Ronald Oussoren wrote:
>
>>
>> On 10-mrt-04, at 7:41, Ronald Oussoren wrote:
>>> >>> Foundation.NSDecimalNumber.zero().decimalNumberByAdding_(1.0)
>>> 0
>>>
>>> The last one is a bug, it should raise TypeError just like:
>>
>> The problem seems to be in NSDecimalNumber not PyObjC:
>>
>> >>> Foundation.NSDecimalNumber.zero().decimalNumberByAdding_("a")
>> 0
>
>   Oh, don't get me started on NSDecimalNumber's failings. Here are 
> some:
>
>    [[NSDecimalNumber zero] decimalNumberByAdding: nil]; <--- bus error
>    [[NSDecimalNumber zero] decimalNumberByAdding: [NSNumber 
> numberWithInt:1]]; <-- bus error

Please file some bugs at bugreport.apple.com if you haven't done so 
yet, complaining here won't get these fixed :-)

>
>   Basically, NSDN dies if you do math with anything but another NSDN, 
> which is irritating
>  because you'd really like NSDN to be a full member of the NSNumber 
> class cluster.
>
>   However, I don't get to change NSDN. I can change PyObjC, so I'd 
> like to change it so that it knows how to build an NSDN when it needs 
> one.

I completely forgot to mention that the usual numeric operators do work 
correctly, as long as you manually convert floats to NSDecimal, e.g. 
``NSDecimalNumber.zero() + 4`` is valid code and will do what you want.

> I'm not overly worried about the loss of precision, because if you're 
> doing stuff in Python, then you should know that you're doing it with 
> Python arithmetic, which is based on double. For me (I realize this 
> isn't everyone) I use Python to write mini-tools based on our object 
> model frameworks. So I want convenience more then accuracy.
>
>   So of course, the ideal would be that if you do math in Python, it 
> implicitly converts it. If you don't do the math in python, it 
> doesn't.

I prefer explicit conversion for NSDecimal, because the interface seems 
to be meant for people that do care about loosing information. I will 
however keep an eye on the decimal number PEP, if this gets accepted 
and implemented I will update the NSDecimal support to have a simular 
interface as the decimal type (where appropriate).

>
>   Note that this wouldn't involve any loss of precision for instance:
>
>    Foundation.NSDecimalNumber.zero().decimalNumberByAdding_(1)
>
>   Because the bridge would build the 1 as an NSDecimalNumber.
>
>   This would:
>
>    z=Foundation.NSDecimalNumber.zero()
>    z= z+1
>
>    But that seems OK to me because z is now a python variable, and 
> python variables are
>    doubles.

No, no, no, python numbers need not be numbers. Instances of int() and 
long() are not, and instances of NSDecimal are not either. In your 
example 'z' is still an NSDecimalNumber.

the line 'z = z + 1' is syntactic sugar for 'z = z.__add__(1)', and 
that method is implemented for NSDecimal and NSDecimalNumber and will 
convert integer values (but not floats) to NSDecimal before performing 
the operation. The method returns an NSDecimal or NSDecimalNumber.


> If you don't want the loss of precision when you move to Python, you 
> should
>    use some sort of Python class that supports larger precision and do 
> the math in that.
>
>    Anyways, that's my $.02. (Does "That's my two cents translate to 
> .nl?)

Yes, to EUR 0.01something ;)


>
>    So anyways, is it possible for the bridge to look at the required 
> class for a parameter, and do different conversions? That is, if I'm 
> calling decimalNumberByAdding_(x)
> can the bridge tell that it needs an NSDecimalNumber * and so it needs 
> to do conversions where necessary?

Automaticly converting floats to NSDecimal is easy enough, it is a 
couple of extra lines in Modules/Foundation/decimal.m (I'm not 100% 
sure about the filename, but it should be close).

Ronald
--
X|support bv            http://www.xsupport.nl/
T:  +31 610271479       F:  +31 204416173