pcp
[Top] [All Lists]

Re: [pcp] pcp update: fetchgroups v4: with event-field support

To: pcp@xxxxxxxxxxx
Subject: Re: [pcp] pcp update: fetchgroups v4: with event-field support
From: Nathan Scott <nathans@xxxxxxxxxx>
Date: Wed, 20 Jan 2016 19:09:45 -0500 (EST)
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <152148245.11905438.1453332764634.JavaMail.zimbra@xxxxxxxxxx>
References: <20160102052522.GB13026@xxxxxxxxxx> <568FAC70.5040506@xxxxxxxxxx> <56931A33.8000603@xxxxxxxxxx> <1222601165.10793219.1453171955611.JavaMail.zimbra@xxxxxxxxxx> <20160119152928.GB13054@xxxxxxxxxx> <2039224745.11117897.1453237884814.JavaMail.zimbra@xxxxxxxxxx> <20160120174347.GA10695@xxxxxxxxxx> <152148245.11905438.1453332764634.JavaMail.zimbra@xxxxxxxxxx>
Reply-to: Nathan Scott <nathans@xxxxxxxxxx>
Thread-index: /SCZq5Kh00iZKjOQYvHBG87dnm5xTTrapYNF
Thread-topic: pcp update: fetchgroups v4: with event-field support
Oh, and...

----- Original Message -----
> 
> > Remember, the point of sentinel values is to be convenient for
> > computation & output, should the application *not care* [...]
> 
> Firstly, reporting incorrect information is a big problem.  And zero
> as a numeric value is so often of meaning & importance that no matter
> how uncaring a tool author is about ENODATA, we cannot encourage it.
> [...]
> Secondly, above rationale is [] inconsistent with the approach taken
> for double/float which generates NaN instead of 0.0.  We need to pick
> one or the other, not half-and-half, and its important to not provide
> potentially-very-misleading zero values as defaults.
> 

Thirdly, zeroed metric values are a wonderful source of divide-by-zero
errors causing lazily-written applications to fail - these will end up
needing special-case handling that other sentinel values wouldn't (and
-1 has nice propagating properties as an alternative there too).

cheers.

--
Nathan

<Prev in Thread] Current Thread [Next in Thread>