Mostly a tongue in cheek comment but if you don't know log rules at all check out log tables [0]. And you'll see that if you use log values then multiplication and division become addition and subtraction and equally simply.
Relies on you either having stored the needed data or efficiently calculating logirithms and antilogirithims.
That's essentially how IEE 754 floating-point works. You can think of it as a piece-wise linear approximation of the base-2 logarithm.
For non-negative values, the exponent (upper) bits give the integer part of the logarithm and the significand (lower) bits approximate the fractional part (i.e., the mantissa).
In other words, you can do:
float approxLog2( float value )
{
assert( value > 0.0f );
auto bits = std::bit_cast< int32_t >( value );
auto exponent = ( bits >> 23 ) - 127;
auto significand = bits & ( ( 1 << 23 ) - 1 );
return exponent + significand / static_cast< float >( 1 << 23 );
}
This will be exact at powers of two, and within 0.0860748291 of the true value in between (always being slightly too low).
Actually, everything will work out fine if we just could pick the optimal algorithm for each situation. How? Use an oracle to pick the right algorithm!
Comments
Could you explain a little more of post a reference?
If
then And if then Mostly a tongue in cheek comment but if you don't know log rules at all check out log tables [0]. And you'll see that if you use log values then multiplication and division become addition and subtraction and equally simply.Relies on you either having stored the needed data or efficiently calculating logirithms and antilogirithims.
https://www.cuemath.com/algebra/log-table/
That's essentially how IEE 754 floating-point works. You can think of it as a piece-wise linear approximation of the base-2 logarithm.
For non-negative values, the exponent (upper) bits give the integer part of the logarithm and the significand (lower) bits approximate the fractional part (i.e., the mantissa).
In other words, you can do:
This will be exact at powers of two, and within 0.0860748291 of the true value in between (always being slightly too low).Ah, I get it now. All we need is a logarithm oracle and we're good to go :)
Actually, everything will work out fine if we just could pick the optimal algorithm for each situation. How? Use an oracle to pick the right algorithm!
Indeed, with lookup tables, if you've seen one, you've seen them all
Unfortunately, if you've seen them all, you also need to store them all :-)