[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #54567] median(uint8) gives bad results

From: Dan Sebald
Subject: [Octave-bug-tracker] [bug #54567] median(uint8) gives bad results
Date: Sun, 26 Aug 2018 00:45:47 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:61.0) Gecko/20100101 Firefox/61.0

Follow-up Comment #9, bug #54567 (project octave):

That's fine with me.

On the matter of two numbers, for what it is worth, it seems the floating
point conversion (then sum, then divide) is the fastest.  Consider

octave:34> x = uint8(255*ones(100000,1));
octave:35> y = uint8(254*ones(100000,1));
octave:36> tic; zfloat = mean([x y], 2, "native"); toc
Elapsed time is 0.00436807 seconds.
octave:37> tic; zintwrong = bitshift(x + y + 1, -1); toc
Elapsed time is 0.00426006 seconds.
octave:38> tic; zintright = bitshift(uint32(x) + uint32(y) + 1, -1); toc
Elapsed time is 0.00503707 seconds.

So the additional conversion to uint32, rounding and division-by-bitshift
comes out slower than converting to float and doing the math.  Even when x and
y vectors are not converted, it is still on the order of converting to float
first.  I would think that in assembly code that the unsigned int conversion
might be "free", i.e., just a case of a different machine instruction that
treats the higher register bits as an extension from 8 bits to 32 bits.  I
suppose what the floating point instructions have going for them is inherent


Reply to this item at:


  Message sent via Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]