Dear Bo, Thank you very much for your response to my feedback concerning comparison of numbers. I gathered that you decided that the main problem involved was in the documentation. But I would like to request that the Rebol team consider providing more "primitive" comparisons, eg: >> greater? 1e-16 1e-32 == false ; not good! >> gt 1e-16 1e-32 ; my workaround == true ; better, but ... About the fastest comparison function I could provide is: >> eq: func [a b][zero? a - b] >> print now i: 0 while [i < 100000][equal? 2 2 i: i + 1] print now 1-Oct-1999/14:15:09+9:00 1-Oct-1999/14:15:13+9:00 ; 4 seconds >> print now i: 0 while [i < 100000][eq 2 2 i: i + 1] print now 1-Oct-1999/14:15:17+9:00 1-Oct-1999/14:15:24+9:00 ; 17 seconds and as you can see it's very slow compared to the native Rebol function. Now I realize that for a "messaging language" strict accuracy in comparison may not seem important. But I've found Rebol to be very useful as well for implementing numerical algorithms (once you've provided the necessary workarounds), and it seems a shame that Rebol should put such barriers in the way. Further, while it might seem useful to ignore slight differences at one point, I believe that it should always be the programmer to decide when to do the glossing over, not the language. Any simple criteria for what roundoff errors to ignore will always produce puzzling contradictions. There are always problems with floating-point roundoff errors, but the other languages I've used (C, awk, Perl, XLISP) offer pretty much the same pitfalls. Rebol just seems to add an extra level of complexity! Sorry to bother you with these complaints, but I would very much like to see Rebol accepted by as wide a community as possible. Yours, Eric
