> > > 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
--------------------------------------------------------------------------
Bryan Cantrill, Sun Microsystems FishWorks. http://blogs.sun.com/bmc
_______________________________________________
dtrace-discuss mailing list
[email protected]
