tag:blogger.com,1999:blog-9604963.post5751013442923678144..comments2023-03-29T21:05:16.669-07:00Comments on The Hitchhiker's Guide to ...: Arrrggghhhh .....Torstenhttp://www.blogger.com/profile/13672530882350688873noreply@blogger.comBlogger9125tag:blogger.com,1999:blog-9604963.post-66307234332520873272008-04-18T07:51:00.000-07:002008-04-18T07:51:00.000-07:00The aarghhh effect was caused by the different out...The aarghhh effect was caused by the different output I got:<BR/><BR/>My program was comparing calculations <BR/>and I had a LONG search in logs to find out that Java printed it like that. I expected it to print it as 42.77 as I knew from other languages/tools.Torstenhttps://www.blogger.com/profile/13672530882350688873noreply@blogger.comtag:blogger.com,1999:blog-9604963.post-14266432479305221562008-04-16T03:11:00.000-07:002008-04-16T03:11:00.000-07:000.1 asFraction -> (3602879701896397/3602879701896...0.1 asFraction -> (3602879701896397/36028797018963968)<BR/>0.1 asApproximateFraction -> (1/10)<BR/><BR/>I discover the float problem recently, and so I discovered scaled decimals: <BR/>0.1s1 asFraction -> (1/10)<BR/><BR/>My test was in squeak (3.9, 3.10)...<BR/>1 - 0.1 -0.1 -0.1 = 0.7 -> falsecdrickhttps://www.blogger.com/profile/01992092307214403698noreply@blogger.comtag:blogger.com,1999:blog-9604963.post-51697089378578504642008-04-16T00:03:00.000-07:002008-04-16T00:03:00.000-07:00In java note that running the following will give:...In java note that running the following will give: 42.77<BR/> float a = 50.0F - 7.23F;greedycathttps://www.blogger.com/profile/01304674584277867563noreply@blogger.comtag:blogger.com,1999:blog-9604963.post-62034224706396985092008-04-15T14:12:00.000-07:002008-04-15T14:12:00.000-07:00Have you tried looking at the actual bytes of all ...Have you tried looking at the actual bytes of all the floats to see if they're REALLY the same, as opposed to just printing the same?John Douganhttps://www.blogger.com/profile/17697319138259306921noreply@blogger.comtag:blogger.com,1999:blog-9604963.post-6053943278299672912008-04-15T12:40:00.000-07:002008-04-15T12:40:00.000-07:00After reading this post, I tried running the same ...After reading this post, I tried running the same code on my Scheme system, and I got the same result as Java:<BR/><BR/>> (- 50.0 7.23)<BR/>42.769999999999996<BR/><BR/>Later on, I found out that there's a way to get the 'right' answer:<BR/><BR/>> (exact->inexact (- #e50.0 #e7.23))<BR/>42.77<BR/><BR/>Also, starting with Java 1.5, you can use <BR/><BR/>System.out.printf (String format, Object... args)Duncanhttps://www.blogger.com/profile/13843763027842460609noreply@blogger.comtag:blogger.com,1999:blog-9604963.post-13840277775353725652008-04-15T12:27:00.000-07:002008-04-15T12:27:00.000-07:00Remember this: Float are special kind of fraction ...Remember this: Float are special kind of fraction with denominator being an exact power of 2 and numerator limited to 53 bits in double precision...<BR/>And thus Float will do inexact operations except in a limited number of cases...<BR/><BR/>So all you see is the rounding of this fraction to a certain number of digits in base 10.<BR/>There is no contradiction there.<BR/>I bet java did put enough digits by default such that the number can be re-interpreted unchanged.<BR/><BR/>You might want to test this:<BR/>50 - 7.23 = 42.77<BR/>In squeak 3.10 were correct parsing of Float is implemented, the answer is false, and:<BR/>50 - 7.23 = 42.769999999999996 -> true.<BR/><BR/>Unfortunately, unlike recent versions of Squeak, most Smalltalk don't interpret decimal floating point representation accurately. They fail to answer the nearest Floating point number due to cumulated round off errors caused by naive algorithm.nicolas cellierhttps://www.blogger.com/profile/13769333498003444630noreply@blogger.comtag:blogger.com,1999:blog-9604963.post-66645656010915208522008-04-15T12:12:00.000-07:002008-04-15T12:12:00.000-07:00Take time an read of http://docs.sun.com/source/80...Take time an read of http://docs.sun.com/source/806-3568/ncg_goldberg.html<BR/><BR/>Your example is just showing floating point arithmetic problems (feature), and by coincidence the C/C++ example did not showed that behavior, at least the Java example behave the same on every platform and does not depends on the C compiler and C runtime used<BR/><BR/>I know the Smalltalk way looks more polished, but I like the Java way to use Decimal arithmetic only when I need them (decimal arithmetic is slower). I only hope Java had a way to use BigDecimal instances with simple operator syntax instead of methods, look at the way new EcmaScript 4 will treat decimals, that is elegant in my opinion<BR/><BR/>http://dev.opera.com/articles/view/why-i-love-ecmascript-4-real-decimals/<BR/><BR/>By the way I am a Smalltalk developer (learned Object Orientation with it) so this is not anything against Smalltalk. only that I had many times the need to move code that requires high performance to native code (Smalltalk primitives) because the use of pure Decimal objects, at least at that time with VisualAge SmalltalkRoberthttps://www.blogger.com/profile/07307586601322852811noreply@blogger.comtag:blogger.com,1999:blog-9604963.post-82761711732587834132008-04-15T09:36:00.000-07:002008-04-15T09:36:00.000-07:00Note that the calculation stated will not be carri...Note that the calculation stated will not be carried out with the precision implied by seeing the numbers written in base 10 notation. Is this perhaps an issue of dissimilar printing policies?Andréshttps://www.blogger.com/profile/06869059697843349034noreply@blogger.comtag:blogger.com,1999:blog-9604963.post-22030413785933167072008-04-15T08:33:00.000-07:002008-04-15T08:33:00.000-07:00You don't even need the #asString. Transcript>>#s...You don't even need the #asString. Transcript>>#show: does that automatically. At least, it does in Squeak.Randal L. Schwartzhttps://www.blogger.com/profile/15769772519087568807noreply@blogger.com