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

[Dan Sebald]

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
rounding.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?54567>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/