<html> <head> <meta content="text/html; charset=windows-1252" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#FFFFFF"> <div class="moz-cite-prefix">On 10/27/2014 12:00 PM, <a class="moz-txt-link-abbreviated" href="mailto:users-request@racket-lang.org">users-request@racket-lang.org</a> wrote: </div> <blockquote cite="mid:mailman.3.1414425603.11374.users@racket-lang.org" type="cite"> <pre wrap="">Re: [racket] Nice article on scientific computing in Racket</pre> </blockquote> Nice article. Some comments: 1. I don't have a login on hacker news, but someone should downvote the first comment! (You actually show in your Figure 4(b) that the comment is incorrect.) 2. In the example on page 94, I think the last two statements are a bit misleading: <blockquote>Racket’s math library exports functions that operate on double-doubles. Those that only return double-doubles have the suffix /error (read “with error”). For example, > (fl*/error 1.1 2.1) 2.3100000000000005 -2.1316282072803005e-16 The exact sum (not the floating-point sum) of these returned float values is the exact product of 1.1 and 2.1 . Alternatively, the first float value is an approximation, and the second is its signed rounding error. </blockquote> There is no way to represent "the exact product of 1.1 and 2.1" in base 2 floating-point arithmetic; what's being returned is "the exact product of the closest floating-point approximations to 1.1 and 2.1 in base 2 floating-point arithmetic". E.g: <blockquote>heine:~/text/courses/computation/computational-reals/src> gsc Gambit v4.7.3 > (load "exact-reals") "/home/lucier/text/courses/computation/computational-reals/src/exact-reals.o2" > (define a (->computable #e1.1)) > (define b (->computable #e2.1)) > (define x (computable-* a b)) > (define x1 (computable->inexact x)) > (define x2 (computable->inexact (computable-- x (->computable x1)))) > (define x3 (computable->inexact (computable-- x (computable-+ (->computable x1) (->computable x2))))) > x1 2.31 > x2 -5.329070518200751e-17 > x3 -1.9721522630525296e-33 > (define a (->computable 1.1)) > (define b (->computable 2.1)) > (define x (computable-* a b)) > (define x1 (computable->inexact x)) > (define x2 (computable->inexact (computable-- x (->computable x1)))) > (define x3 (computable->inexact (computable-- x (computable-+ (->computable x1) (->computable x2))))) *** INTERRUPTED IN ##bignum.div 1> > x1 2.3100000000000005 > x2 -2.1316282072803005e-16 </blockquote> I sometimes forget that certain things are not decidable in the computational reals, but after sitting for 20 seconds or so when the program was trying to compute x3 the second time, I remembered that converting to inexact an exact zero or a number with rounding error exactly 1/2 ulp is undecidable, and that was evidenced very concretely by the program going into an infinite loop, which I had to interrupt. 3. I like that you argue that: <blockquote>Second, so much other code usually surrounds floating- point computations—for example, code that shuffles data around, indexes arrays, or decides what to compute—that taking even a fourfold speed hit hardly matters. </blockquote> In other words, I agree with you, but I don't think that this hypothesis is shared by the High Performance Computing community. Again, nice article. Brad </body> </html>