Frank Shearar uploaded a new version of Kernel to project The Trunk:
http://source.squeak.org/trunk/Kernel-fbs.752.mcz ==================== Summary ==================== Name: Kernel-fbs.752 Author: fbs Time: 30 March 2013, 10:09:47.906 pm UUID: 0724a0a2-6b96-4e07-94ed-79bdc4e2466b Ancestors: Kernel-eem.751 Increase the "polymorphitude" of numbers by supplying a default implementation of #zero, together with a few per-type specialisations to go with those we already have. =============== Diff against Kernel-eem.751 =============== Item was added: + ----- Method: Float class>>zero (in category 'constants') ----- + zero + ^ 0.0.! Item was added: + ----- Method: Fraction class>>zero (in category 'constants') ----- + zero + ^ self numerator: 0 denominator: 1.! Item was added: + ----- Method: Number class>>zero (in category 'constants') ----- + zero + ^ 0.! |
I wonder about the Fraction implementation. Since any Integer isFraction I think it's better to simply let super ^0. Synthetizing an unreduced Fraction should be restricted to very specific case. Do you have such specific usage? Nicolas 2013/3/30 <[hidden email]> Frank Shearar uploaded a new version of Kernel to project The Trunk: |
No, just following ScaledDecimal's example. (0 / 1 is the simplest
zero fraction.) But I'm not strongly in favour of what I wrote: if 0 (the integer) is a more sensible zero for Fraction, I'd be perfectly happy with removing it and so falling back to Number >> #zero. I'm much more interested in the protocol. frank On 30 March 2013 22:35, Nicolas Cellier <[hidden email]> wrote: > I wonder about the Fraction implementation. > Since any Integer isFraction I think it's better to simply let super ^0. > Synthetizing an unreduced Fraction should be restricted to very specific > case. Do you have such specific usage? > > Nicolas > > > 2013/3/30 <[hidden email]> > >> Frank Shearar uploaded a new version of Kernel to project The Trunk: >> http://source.squeak.org/trunk/Kernel-fbs.752.mcz >> >> ==================== Summary ==================== >> >> Name: Kernel-fbs.752 >> Author: fbs >> Time: 30 March 2013, 10:09:47.906 pm >> UUID: 0724a0a2-6b96-4e07-94ed-79bdc4e2466b >> Ancestors: Kernel-eem.751 >> >> Increase the "polymorphitude" of numbers by supplying a default >> implementation of #zero, together with a few per-type specialisations to go >> with those we already have. >> >> =============== Diff against Kernel-eem.751 =============== >> >> Item was added: >> + ----- Method: Float class>>zero (in category 'constants') ----- >> + zero >> + ^ 0.0.! >> >> Item was added: >> + ----- Method: Fraction class>>zero (in category 'constants') ----- >> + zero >> + ^ self numerator: 0 denominator: 1.! >> >> Item was added: >> + ----- Method: Number class>>zero (in category 'constants') ----- >> + zero >> + ^ 0.! >> >> > > > > |
Yes, 0 is more sensible. From the outside that does not matter, because Integer is (or should be) fully polymorphic to Fraction and we don't really care about internal representation.That's an implementation detail. From the inside, having all Fraction reduced is a valuable invariant: this assumption enables some simplifications of various algorithms (less gcd: computations etc...)IMO, #zero is too general for answering such a Fraction that does not respect the invariants. It's the same as having: LargePositiveInteger>>zero ^self basicNew: self basicSize 2013/3/30 Frank Shearar <[hidden email]> No, just following ScaledDecimal's example. (0 / 1 is the simplest |
Free forum by Nabble | Edit this page |