Decimal floating point would be a great addition at some point. There isn't hardware support (yet) on X86 architectures, but there is an IEEE standard (or a set of them) and increasing library support for it - including an (optional) Annex F in C11/C11++.
Doug On Sun, Dec 23, 2012 at 8:07 PM, Neil Toronto <neil.toro...@gmail.com> wrote: > I'm working on those now. There are some well-known double-rounding-error > cases I can use, and I've found more test cases by randomized testing using > bigfloats. > > I wanted to avoid exact floating-point tests, but it seems there's no way > around it now. I hope DrDr's FPU is IEEE-compliant. We'll find out. > > Neil ⊥ > > > On 12/23/2012 06:17 PM, Robby Findler wrote: >> >> Could you formulate some test cases to check for this behavior? >> >> Robby >> >> >> On Sun, Dec 23, 2012 at 7:07 PM, Neil Toronto <neil.toro...@gmail.com >> <mailto:neil.toro...@gmail.com>> wrote: >> >> On 12/22/2012 10:24 AM, Michael Filonenko wrote: >> >> Also, long double arithmetic requires setting "extended mode" >> flag on >> FPU, which forces the FPU to use 80-bit registers. The side >> effect on >> that flag is that the FPU gives slightly different (more >> accurate, but >> not IEEE-compliant) results for 64-bit operations. That is usually >> not a problem on machines who have SSE2 (introduced in Pentium 4 >> in >> 2001). In presense of SSE2, Racket performs 64-bit operations >> solely >> on 64-bit SSE2 registers (see MZ_USE_JIT_SSE and --mfpmath=sse), >> so the >> results are IEEE-compliant. 80-bit operations are done on FPU >> anyway >> as SSE2 can not do them. Therefore, by setting the "extended >> mode" on >> FPU, we introduce a subtle difference in ordinary flonums, but >> only on >> old machines that do not have SSE2. >> >> >> Where is a good place to read more about this? In particular, I'm >> interested in how IEEE-compliant SSE2 implementations tend to be >> compared to FPUs. >> >> About half the new flonum functions in the math library rely on >> perfectly compliant rounding for good accuracy in difficult parts of >> their domains. A few use double-double arithmetic to extend >> precision from 53-bit significands to 106 in these subdomains; most >> use a combination of precisions. >> >> If rounding isn't IEEE-compliant, these functions could suddenly >> become much less precise: from just one least significant digit >> wrong to four or five. That includes computations done *entirely in >> 80-bit registers*, which seems like it should be more accurate. For >> example, there's a heavily used macro that computes the result of >> `fl+' and its rounding error. If it were done entirely in 80 bits >> and then rounded to 64, the error computation would be totally bogus. >> >> I'd like to verify independently that this won't happen on machines >> with an Intel FPU manufactured within the last 12 years or an AMD >> FPU manufactured within the last 10 (i.e. those with SSE2). That >> would keep me happy, since FPUs older than those tended to rounding >> incorrectly anyway. >> >> Thanks! >> Neil ⊥ >> >> >> _________________________ >> Racket Developers list: >> http://lists.racket-lang.org/__dev <http://lists.racket-lang.org/dev> >> >> > > _________________________ > Racket Developers list: > http://lists.racket-lang.org/dev _________________________ Racket Developers list: http://lists.racket-lang.org/dev