2009/7/8 Andres Valloud <avalloud@smalltalk.comcastbiz.net>:
The answer is true on 7.6, and I don't think anything changed that for 7.7. Â Historical background aside, I think it's wrong anyway... in the hash book, exercise 7.20 asks to find two different fractions that are equal to the same float. Â In other words, if f is a float, and r1 and r2 are fractions, then r1 ~= r2 but r1 = f and r2 = f. Â And those do exist...
Andres.
Il y a même une infinité de Fractions r telles que f-0.5*ulp < r < f+0.5ulp Anyway, Andres, tell me what how you can bear this VW behaviour I exposed to Michael L.S. 9.9999730e20 printString -> '1.0e21' 9.9999731e20 printString -> '9.99997e20' 9.9999731e20 >= 9.9999730e20. false To me, this is a clear violation of ISO/IEC 10967-2 http://www.cs.chalmers.se/~kent/ISOStandards/SC22/WG11/LIA-2/N424.ps I guess "we Smalltalk guys are smarter and did not change things for 30 years, so why bother now" is our best argument :) Nicolas
Stéphane Ducasse wrote:
so andres what will be the value of
(13/10) = 1.3
in VW7.7
On Jul 7, 2009, at 11:18 PM, Andres Valloud wrote:
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