x/website: SumNumbers depends on map iteration order with float64 #51715
Labels
Documentation
NeedsDecision
Feedback is required from experts, contributors, and/or the community before a change can be made.
website
Milestone
Comments
|
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 |
ALTree
added
Documentation
NeedsDecision
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
SumNumbersfunction 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:
Re-running this may provide different results.
The function works correctly with
int64because integer addition is associative. Addition is not associative withfloat64values, so the map order changes the result dramatically.The text was updated successfully, but these errors were encountered: