x/website: SumNumbers depends on map iteration order with float64

[niaow]

What version of Go are you using (go version)?

Go 1.18 via playground.

What did you do?

I added extreme float64 values to the input of the SumNumbers function from https://go.dev/doc/tutorial/generics.

https://go.dev/play/p/aQ1cotOVsEc

What did you expect to see?

The function returns the same value consistently.

What did you see instead?

Across 4 runs:

0 62.97 35.98 0

Re-running this may provide different results.

The function works correctly with int64 because integer addition is associative. Addition is not associative with float64 values, so the map order changes the result dramatically.

[ALTree]

On one hand, I agree the example is unfortunate, in that map iteration is not deterministic and thus in the float64 case the procedure exhibits numerical instability... on the other hand, it's supposed to be a quick introduction to type parameters. The kind of people that may care about the algorithm's numerical stability also probably understand that the example is not meant to be used in a numerical simulation in production.

I don't think it's worthwhile to add code to sort the map. Replacing a map with a slice would also fix the issue, but then we would lose the chance to also show what comparable is (it's used in the signature as K comparable).

[seankhliao]

I don;t think we need to change anything, overflows are always going to be a problem.