Facade Gauge int64 vs float

[TheAngryByrd]

Hey there!

I'm using the logary facade in one of my libraries however I noticed the gauge takes a int64 instead of a float. I'm wonder if this an oversight or a deliberate choice as the Gauge in logary proper is a float.

[haf]

It's based on influxdata/influxdb#3479 (comment) - the fact that int64 is less finicky to work with an better specified. The idea behind fraction was that you'd never need to round, since storing 8*2 bytes as a struct is not really a large memory footprint.

I need (and would welcome contributors to) go through the new v5 API before release; and perhaps make it more like the Facade in places.

/cc @lust4life

[TheAngryByrd]

Ah ok. So would be the recommended approach for using fractional values with gauge in the facade?

[haf]

It's most likely an oversight though. Unless you have specific requirements, like in the linked thread it should not matter whether you use float or int64, except float being easier to reason about for you as a programmer.

We can't change the public API of the Gauge just yet, but you can create another DU case with float and fraction.

That said, in Logary proper we've moved to boxed objects, to allow each thing (processing step, or target) to deal with it in its own way. The best way forward is to synchronise floats/fractions between them. Feel free to have a stab at that.

[haf]

I think we should go with float throughout. It's good enough and much easier to work with than the scaled/annotated int64.

[haf]

I've changed it to be a float in Facade v3 now.

[lust4life]

sorry for late reply, too busy at work's stuff.

Gauge in logary proper is a float. is because I use a client for prometheus which only have float/double as its gauge value, for the sake of convenience I change it from int to float . didn't expect them to be so different, learned from influxdata/influxdb#3479 .

I think we should go with float throughout. It's good enough and much easier to work with than the scaled/annotated int64.

i agree with it, since gauge is just a predefined type like any other normal object passing through message context. if an annotated int64 is need, the logging api has no limit with that.

[haf]

Have a look at 3b70c05 — I think it strikes a balance between the Value type of before and the dichotomy we need between high-res values and floating points.

[lust4life]

nice. make a gauge value have an explicit type (Value) can provider more constraint and convenience for pipe processing. and we have an enhanced formatting mechanism to deal with them.