Re: Floating point problem

[Martin Spier <mspier@xxxxxxxxxxx>]

I'm not familiar with PCP's code so I might be completely wide of the mark here, but my understanding is that it's a precision problem. Aren't int64 or GMP (https://gmplib.org/) options in this case? There's also the JSON conversion problem, but one option in this case is sending out a String in the JSON response instead of a number. It's not clean and nice, but it might work. On the client side (_javascript_) I can convert that to a BigDecimal and work with it.

On Mon, Jul 28, 2014 at 11:18 PM, Ken McDonell <kenj@xxxxxxxxxxxxxxxx> wrote:

On 29/07/14 10:28, Frank Ch. Eigler wrote:

...
This is possible (and can be encoded in a backward-compatible way).
As pmwebd is a PMAPI bridge, it is both a client and a server.
Indeed, this calculation may not be too difficult to code up in this
code, benefitting as it does from C++ and readily available context
usage statistics.

I suspect the effort is comparable for options 1. and 3. and 3. seems like 3. might be more generally useful. ÂI'll investigate the effort required here.

... (Just for completeness, I'd like to re-mention the

alternative of having libpcp do this, so this many individual PMAPI
clients don't have to.)

I am willing to reconsider my historical and philosophical objections here.

I think this would need to be _optional_ as there are a number of existing clients and plenty of use cases (especially for pmlogger) where the current semantics (no rate conversion) are preferred.

And probably needs to be a modifier to pmNewContext(), as the semantics need to be in place before the first metadata or pmFetch PMAPI call (the descriptors for the counter metrics need to be re-written between pmcd and the client, for example).