On the other hand, asRational and asFraction are quite synonym to me. asFraction might as well be implementation dependent... And asRational can be interpreted this way only for historical reasons (st80). I want either a short approximated fraction like (13/10), or an exact fraction. Nicolas 2009/7/8 Andres Valloud <avalloud@smalltalk.comcastbiz.net>:
On the other hand, VW already has asRational, and it doesn't do what asFraction does. Â To some extent, I think #asExactFraction and selectors like that are misleading. Â Why would anyone want #asImpreciseFraction, or #asRationalMoreOrLess...
Nicolas Cellier wrote:
Hi Andres, That's great to see this addition, but it would have been even greater to call this method #asExactFraction or #asTrueFraction to get some minimal core API with other dialects...
Anyway, you see the kind of arguments you'll have to provide if you ever want to follow the path you once proposed...
Cheers
Nicolas
2009/7/7 Andres Valloud <avalloud@smalltalk.comcastbiz.net>:
VisualWorks introduced LimitedPrecisionReal>>asFraction. Â That message returns the actual floating point value represented by the receiver. Â Of course, I messed up and forgot * self sign... but that's the idea (and it's fixed for 7.7). Â So, in reality, you should compare
13/10 = 1.3 asFraction
which will answer false, like it should.
Andres.
John M McIntosh wrote:
Let me step back and say, ok you are possibly breaking existing code, and causing all sorts of confusion for an optimization change? Â So where is the justification from the optimization viewpoint? Does it make browser windows open in 1/2 the time?
If it takes more time milliseconds? to produce an answer that is what people expect, then t I think it's worth it. Yes I understand that floats are inexact but people think they know how they work thus expect to be able to say (13/10) = 1.3 Â without having to give clues with asFloat to indicate their intent.
Let me see squeak 3.10.x  (13/10) = 1.3  true Pharo 1037  (13/10) = 1.3  false VisualWorks (13/10) = 1.3  true
I would classify this as a bug
On 7-Jul-09, at 10:43 AM, Hernan Wilkinson wrote:
I added this new issue that happens on the latest image. I'm posting it here because I think it is an important bug because it affects the number model. The problem is related with all fractions who's denominator is not power of two. (130/100 = 1.3 or 1/5 = 0.2, etc) (See Float>>adaptToFraction: rcvr andCompare: selector where it does   ....   "Try to avoid asTrueFraction because it can cost"   selector == #= ifTrue: [    rcvr denominator isPowerOfTwo ifFalse: [^false]].
  ...)
Hernan.
-- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Â Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. Â http://www.smalltalkconsulting.com = = = ========================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project