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 <[email protected]>: > >> 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 <[email protected]> Twitter: >>> squeaker68882 >>> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >>> = >>> = >>> = >>> ======================================================================== >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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
