Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Beware of Fast-Math

simonbyrne.github.io

Post reply on HN
Print view View original

1–10 of 233 posts

Re: Beware of Fast-Math

#3

Post by anthk »

Sophira wrote: post #2

Previously discussed at https://news.ycombinator.com/item?id=29201473 (which the article itself links to at the end).

On Forth, there's the philosophy of the fixed point:

https://www.forth.com/starting-forth/5-fixed-point-arithmeti...

With 32 and 64 bit numbers, you can just scale decimals up. So, Torvalds was right. On dangerous contexts (uper-precise medical doses, FP has good reasons to exist, and I am not completely sure).

Also, both Forth and Lisp internally suggest to use represented rationals before floating point numbers. Even toy lisps from https://t3x.org have rationals too. In Scheme, you have both exact->inexact and inexact->exact which convert rationals to FP and viceversa.

If you have a Linux/BSD distro, you may already have Guile installed as a dependency.

Hence, run it and then:

      scheme@(guile-user)> (inexact->exact 2.5)
      $2 = 5/2

      scheme@(guile-user)> (exact->inexact (/ 5 2))
      $3 = 2.5
Thus, in Forth, I have a good set of q{+,-,*,/} operations for rational (custom coded, literal four lines) and they work great for a good 99% of the cases.

As for irrational numbers, NASA used up 16 decimals, and the old 113/355 can be precise enough for a 99,99 of the pieces built in Earth. Maybe not for astronomical distances, but hey...

In Scheme:

         scheme@(guile-user)> (exact->inexact (/ 355 113))
         $5 = 3.1415929203539825
In Forth, you would just use

         : pi* 355 133 m*/ ;
with a great precision for most of the objects being measured against.

Re: Beware of Fast-Math

#4

Post by orlp »

I helped design an API for "algebraic operations" in Rust: https://github.com/rust-lang/rust/issues/136469>, which are coming along nicely.

These operations are

1. Localized, not a function-wide or program-wide flag.

2. Completely safe, -ffast-math includes assumptions such that there are no NaNs, and violating that is undefined behavior.

So what do these algebraic operations do? Well, one by itself doesn't do much of anything compared to a regular operation. But a sequence of them is allowed to be transformed using optimizations which are algebraically justified, as-if all operations are done using real arithmetic.

Re: Beware of Fast-Math

#8

Post by eqvinox »

orlp wrote: post #4

I helped design an API for "algebraic operations" in Rust: https://github.com/rust-lang/rust/issues/136469 >, which are coming along nicely. These operations are 1. Localized, not a function-wide or program-wide flag. 2. Completely safe, -ffast-math includes assumptions such that there are no NaNs, and violating that is undefined behavior . So what do these algebraic operations do? Well, one by itself doesn't do much…

Are these calls going to clear the FTZ and DAZ flags in the MXCSR on x86? And FZ & FIZ in the FPCR on ARM?

Re: Beware of Fast-Math

#9

Post by rlpb »

> I mean, the whole point of fast-math is trading off speed with correctness. If fast-math was to give always the correct results, it wouldn’t be fast-math, it would be the standard way of doing math.

A similar warning applies to -O3. If an optimization in -O3 were to reliably always give better results, it wouldn't be in -O3; it'd be in -O2. So blindly compiling with -O3 also doesn't seem like a great idea.

Re: Beware of Fast-Math

#10

Post by eqvinox »

Smaug123 wrote: post #6
eqvinox wrote: post #5

I wish the Twitter links in this article weren't broken.

They aren't, at least for the spot-check I performed; probably you need to be logged in.

All it says is "Something went wrong. Try reloading." — no indication having an account logged in would help (…and I don't feel like creating an account just to check…)
Post reply on HN