[Discuss] Should we change default number format?

[timroes]

Currently our default number format, which will be used by the field formatter is 0,0.[000] and thus will render values by default to a precision of 3 decimal points. JavaScript itself will format numbers with 7 or more decimal points in scientific notation, when converting them to a string. This will lead to a bit weird format, that values with 3 or less decimal places are get presented correctly, and places above 7 get represented better again, but not between 4 and 6 decimal digits. You can see that behavior in the following documents containing increasingly more decimal digits for that one numerical field.

I wonder if we should actually change our default value of that advanced setting to 0,0.[000000], so that decimal points with a precision to 6 decimal digits get rendered precisely:

This would though effect all places we render numbers right now using field formatters, that have not configured their own formatting pattern, thus I would like to understand how people feel around this change.

[elasticmachine]

Pinging @elastic/kibana-app-services (Team:AppServicesSv)

[timroes]

cc @ghudgins @markov00 @flash1293

[flash1293]

Something to consider is y axes in charts - it's possible they will consume much more horizontal space than before. Not sure whether it's a problem though.

[markov00]

I'm all in to avoid ambiguous formatting outputs, the current conversion between 0.0001 into 0 looks a bit too hard and I think this should not be a concern about the horizontal space.
I don't know, but those number ranges are actually not very common.

Btw I'm not 100% sure that this relates to the number of decimal points but more on the floating-point error because with 0,0.[000000] number format and input of 0.0000001 you get 1e-7 but instead if you use 1.0000001 as the input you got 1 (that btw is printed without scientific notation by js)

[elasticmachine]

Pinging @elastic/kibana-data-discovery (Team:DataDiscovery)

[kertal]

We are closing this issue in order to provide better transparency of priorities. This issue won't be prioritized in the near future. We track it in #163011 for long term planning.