One more comment: This used to work by accident before Nicolas actually made use of the contract (established in 1999) in Fraction >> #=. Is this actually a matter of backwards compatibility?

Best,
Marcel
Am 31.12.2021 14:33:36 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:
Ha! Reading the comment in #numerator:denominator:, this isn't really a bug but an inconvenience:

NOTE: This primitive initialization method will not reduce improper fractions,
so normal usage should be coded as, eg,
(Fraction numerator: a denominator: b) reduced
or, more simply, as
a / b

-- di 8/31/1999

:-)

No transitive law broken here. Not sure how we can avoid using #numerator:denominator: without #reduced ... sounds like a linting rule to enforce ...

Best,
Marcel
Am 31.12.2021 14:30:39 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:
Hi Chris --

> Fraction numerator: 5 denominator: 1.

I think that the issue is that this line does not answer an Integer but a Fraction. Numbers are special in the object-oriented world in that they can change their class without notice. :-)

This works:

| a b c |
a := 5/1.
b := 5.0.
c := 5.
self assert: a=b; assert: b=c.   "Pass"
self assert: a=c.    "Fail"


Best,
Marcel
Am 31.12.2021 01:30:25 schrieb Chris Muller <ma.chris.m at gmail.com>:
__________
“If a is equal to b and b is equal to c, then a is equal to c.”

__________

| a b c |
a := Fraction numerator: 5 denominator: 1.
b := 5.0.
c := 5.
self assert: a=b; assert: b=c.   "Pass"
self assert: a=c.    "Fail"

__________


I understand this is not a normal way to create Fractions, but serializers must often construct objects in other-than-normal ways.  This constructor on Fraction is actually a valid API, but leaves an inconsistent comparison contract with other Numbers.


I fixed it by reverting Fraction>>#= to the (nice 3/28/2006 23:41) edition.

Comments?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20211231/c3049d25/attachment.html>