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
