Oh, If my blessing is required, then I would do what anyother would do:
- look at tests results,
- then at implementation.
I see ZeroDivide exceptions are raised.
They are raised a little later with different stack depth and
different dividend, but I don't know specifications about that.
I see implementation is simple and hard to attack (in a hacker's POV).
So please proceed and include this changes.

And post a copy of the .cs at http://bugs.squeak.org/view.php?id=6989


Just one remark about tests:
    self assert: Float one = 1.0.
might be completed with:
    self assert: Float one isFloat.
But personnally, I would not even include this in tests because I
don't really care of #one specification:
IMO, this is an implementation detail, not a usefull API, and has few
value per se.
The essential reason for that behavior, and that should be in tests is:
    self assert: (2.0 raisedTo: 0.0) = 1.0; assert: (2.0 raisedTo: 0.0) isFloat.

I also see this test is missing, but behavior is correct:
    self should: [SmallInteger maxVal + 1 / 0] raise: ZeroDivide.

Last, there are some IEEE 754 behaviors I will always find surprising,
like (0.0 raisedTo: Float infinity) and the like - see
http://bugs.squeak.org/view.php?id=6781 , but that was not the subject
:)
Don't know if we should write tests to document that behaviour...

Nicolas


2009/5/24 Stéphane Ducasse <[email protected]>:
> Hi gabriel
>
> I checked your code and what would be good is to do the following:
>
> Float class>>one
>        could be
>        ^ 1.0
>
> It would be nice if nicolas could have a look at them before I push
> them in the release stream
>
> Then it would be good to profile a bit them because with numbers it
> would be good to have
> the fastest we can.
>
> Stef
>
>
>
> On May 24, 2009, at 2:29 AM, Gabriel Cotelli wrote:
>
>> Hi,
>>
>> I re-implemented
>> Number>>reciprocal
>> Float>>reciprocal
>> Fraction>>reciprocal
>> Fraction>>one
>> Integer>>one
>> Float>>one
>>
>> so now are license clean.
>>
>> I push the changes on Pharo-Inbox (I hope, if I do the right
>> procedure) and open the Issue 843 in the tracker. According with the
>> instructions in the "How to contribute" wiki page I need to change
>> the state of issue to "Fixed", however I can't find that option.
>> Maybe I need to be a member of the project in google code?...
>>
>> Just in case find attached the.cs and Monticello packages generated.
>> Please somebody must review the changes..
>>
>> Thanks,
>> Gabriel
>> <MonticelloPackages.zip><RelicensingNumberRelated.
>> 1.cs>_______________________________________________
>> Pharo-project mailing list
>> [email protected]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply via email to