Thanks. The example that shows the difference is at the issue.
```
package main
import "fmt"
func main() {
nNeg := 10.0
fpr := 10.0
invNeg := 1 / nNeg
fpr = 1 - fpr*invNeg
fmt.Println(fpr)
}
```
And, yes, it looks like it could be constant propagation.
For the generation of FMA, the reason I ask is to know whether we're
going to hit the same kind of effects between Go versions that we are
now bumping into between architecture. I'm happy to not see this happen
for the near term.
Dan
On Mon, 2020-01-13 at 18:52 -0800, Keith Randall wrote:
> On Mon, Jan 13, 2020 at 5:45 PM Dan Kortschak <d...@kortschak.io>
> wrote:
>
> > Thanks for linking this here.
> >
> > One thing that I did not follow up at the issue; why do we see the
> > FMA
> > being applied when the value is a slice element, but not when it's
> > a
> > single float64 value?
> >
> >
>
> I'd have to see an example to be sure. Possibly everything gets
> constant-propagated in the compiler, which has its own very high
> accuracy
> floating point (256 bits of mantissa, I think?).
>
>
> > Second query, are there plans for adding FMA support to amd64 akin
> > to
> > how it is on arm64?
> >
> >
>
> Not from code like this. Our minimum amd64 architecture has no FMA,
> so
> anything generated by the compiler would need to be conditioned by a
> runtime test, which would probably defeat the point of the
> optimization.
> The optimization only saves one instruction, and having to add a load
> /
> compare / branch, plus a fallback runtime call, it almost certainly
> isn't
> worth it.
> Our arm64 minimum architecture has FMA.
>
> If you use the new math.FMA, you will get the conditioned hardware
> instruction. Use of this function is advised when you really need the
> extra
> bits, not just when it might be faster than a separate multiply and
> add
> (which on amd64, it probably isn't).
>
>
> > Dan
> >
> > On Mon, 2020-01-13 at 15:45 -0800, 'Keith Randall' via golang-nuts
> > wrote:
> > > Note: discussion at https://github.com/golang/go/issues/36536 .
> > > TL;DR
> > > fused
> > > floating point multiply-add gives higher precision results.
> > >
> > > On Sunday, January 12, 2020 at 8:19:54 PM UTC-8, kortschak wrote:
> > > >
> > > > I am going through failures that I see in Gonum tests when we
> > > > build
> > > > on
> > > > arm64 (Travis now provide this).
> > > >
> > > > In many cases there are slight differences that I'm OK with
> > > > adding
> > > > a
> > > > tolerance to accept, but in one case (stat.ROC[0][1]) I see an
> > > > error
> > > > that can be completely avoided by changing the expression from
> > > > what
> > > > is
> > > > at [1] to
> > > >
> > > > ```
> > > > for i := range tpr {
> > > > tpr[i] = 1 - tpr[i]/nPos
> > > > fpr[i] = 1 - fpr[i]/nNeg
> > > > }
> > > > ```
> > > >
> > > > Should I expect `inv := 1/c; v *= inv` and `v /= c` to give the
> > > > same
> > > > results for reasonable cases? (or at least to match the
> > > > behaviour
> > > > on
> > > > amd64/386/arm - which all agree).
> > > >
> > > > thanks
> > > > Dan
> > > >
> > > > [0]https://godoc.org/gonum.org/v1/gonum/stat#ROC
> > > > [1]
> > > >
> > > >
> >
> >
https://github.com/gonum/gonum/blob/683ee363d56e77121c6640345bb9d40644f02a1f/stat/roc.go#L107-L114
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/1e8f4d5220b07649e89c4af92a3d50b8bd0c38b4.camel%40kortschak.io.
