Floating Point Precision

[cipriantarta]

I can understand why -1 was used here, but it can cause some pain when loading the message, say in elasticsearch with the value 0 instead of 0.00 for example.

For me, it creates a field of type long instead of what I really want it to be, a float and I'm sure there may be other specific cases.

I propose adding a FloatingPointPrecission variable somewhere around here with a default value of -1, then everyone is happy :)

[mitar]

In my case I have the opposite problem, I am getting too precise numbers, like 0.00000013312693498452013. Do I really have to log at all those digits? Probably not. It could be rounded to 0.000 just fine.

[mitar]

I made #663 to address this.

[rayjanoka]

I'm interested in this

[rayjanoka]

Hey, nice work.

I tried this out, but it doesn't seem to apply to Floats sent via the .Interface() field func, which is where most of my Floats are coming from.

Also, it appears there is a downside where floats that happen to be whole numbers that do not contain any decimals end up displaying with padded zeros when they previously displayed without them.
ex. set precision to 3, previously: 0 -> now: 0.000, previously: 1000 -> now: 1000.000

[mitar]

I tried this out, but it doesn't seem to apply to Floats sent via the .Interface() field func, which is where most of my Floats are coming from.

This is governed by the InterfaceMarshalFunc. You will have to implement your own function which does what you want. Currently it just calls into json.Marshal more or less.

Also, it appears there is a downside where floats that happen to be whole numbers that do not contain any decimals end up displaying with padded zeros when they previously displayed without them.
ex. set precision to 3, previously: 0 -> now: 0.000, previously: 1000 -> now: 1000.000

Yes, this is how strconv.FormatFloat works. Currently this option is just an argument to it. I think this is fine as it is, but feel free to argue the case why should we do more than just use strconv.FormatFloat.