Filed 6624541 dtrace aggregations should assume signed arguments
> > > > > I was trying to get an average value of a bunch of numbers which could > > > > be > > > > either positive or negative to see whether the average is close to > > > > zero. It > > > > turns out that aggregations (including max, min and avg) treat values > > > > as > > > > unsigned and, thus. do not work as expected for negative values. Do you > > > > think > > > > it is a valid RFE to have version of these aggregations which work on > > > > signed > > > > data? > > > > > > Yes, definitely valid -- especially since quantize()/lquantize() already > > > correctly deal with negative values. Apologies for that; not quite sure > > > why I didn't address max()/min()/avg() when I was getting quantize() and > > > lquantize() to correctly deal with negative data... > > > > So do you think that "the right thing" to do is to fix max()/min()/avg() to > > treat arguments as signed or to keep these intact and have another set > > with different names (smax()?) to preserve compatibility with whatever > > scripts > > assume the old semantics? > > While I reserve the right to be wrong about this, I would say fix max()/ > min()/avg(). That's what I did to quantize()/lquantize(), and no one > noticed -- unsigned values that large are rather rare in the real world > and (as Chad points out on another thread), they're prone to overflow > silently today anyway. It's hard to imagine that fixing this will break > anyone... > > - Bryan _______________________________________________ dtrace-discuss mailing list [email protected]
