[ANN] Reciprocal related methods relicensing

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

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

yes this is the right process.
Thanks

stef

On May 24, 2009, at 2:29 AM, Gabriel Cotelli wrote:


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

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:


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

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 <[hidden email]>:
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Hi Stef,



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

On May 24, 2009, at 5:51 PM, Gabriel Cotelli wrote:

I think that we should pay attention not to fall in stupidity because  
of license. :)



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

On May 24, 2009, at 23:05 , Stéphane Ducasse wrote:

Yes. Especially if the implementation is simple (or even trivial as in  
the case of returning 1.0), there is no problem if the new  
implementation is identical.

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