C
CBFalconer
Dik T. Winter said:
That isn't a value, it is an approximation.
That isn't a value, it is an approximation.
J
JosephKK
Actually (the initial use and) the shift away from CORDIC was a gate
count issue. No major current implementation uses CORDIC any more.
Not MIPS, not SPARC, not x86, not HP-PA, not Power, not 68K. CORDIC
is an effectve low gate/transitor count implementation. But in the
days of a billion gates; faster, more direct implemenations are
preferred.
J
JosephKK
While any particular implementation of log() may not have any visible
reference to the base of the logarithm it would quite impossible to
develop that algorithm without reference to that base value. Also e
has a specific representation in IEEE-754 or any other binary floating
specification.
P
Phil Carmody
JosephKK said:
Erm, what bit about the sentence partially underlined makes you think
that's news to me?
Having said that, Intel have repeatedly run out of gates and had
to cripple an otherwise very potent architecture, so they're not
an infinite resource by any means.
I'm starting to dabble with FPGA coding. I might try to see
how many hand-written cordic blocks I can squeeze into the
same space as one optimised fixed point operational block for
the usual CORDIC functions (log, exp, atan2, maybe sqrt if
I can remember how to do it). The only problem is that I have
no personal use for such a block, I'm more into discrete
mathematics.
Phil
J
James Kuyper
JosephKK said:
You can develop the entire power series for log(x) using the fact that
it's derivative is 1/x, and that log(1) is 0, without making any
reference to the fact that there exists a number 'e' such that
log(e)==1, and there's nothing particularly unnatural about doing so. I
believe that you can equally easily and naturally derive the details of
at least some of the more sophisticated techniques for implementing
log() that have been mentioned in this thread, without making any use of
'e', though I haven't verified that.
J
JosephKK
Was not quite where i was comming from. I expected it to still be
news to some of this threads posters. Oh, and thanks for the
validation.
Some possibly really nice sine/cosine cross interpolating tables to
feed coefficients to radix 4 arbitrary length FFT and DFT might be
quite useful.
Discrete math like commutative rings, or for other applications?
Trying to learn just what Lie groups are, is a back burner thing for
me.
J
JosephKK
In both cases the target value is the logarithm to the base e. Do you
get the same algorithm with the same constants if you calculate to a
logarithm base of 2, pi, 10, 8, 16, or sqrt(157)? Second and tougher
test, does your algorithm break down if you use complex numbers? It
might if the base is not e.
This is the concept i an driving at. All logarithms are to some
particular base. Most machine algorithms are to base e or 10 (and
often derive base 10 with a multiply after generating a log base e).
P
Phil Carmody
JosephKK said:
Actually that's a very good, if not perfect, example of the
where fast FPU operations would be very useful. FFTs traditionally
use huge precomputed arrays for such coefficients, and that tends
to waste cache. Smaller tables quickly interpolated would be great.
Might be rings, might commute... Computational Number Theory.
Phil
K
Keith Thompson
JosephKK said:
Yes, logarithms are to a particular base. The point is that, at least
if the base is e, you don't need the value of that base to compute the
logarithm. The same is true of the exp() function. In a sense, the
value of e comes from the algorithm, not vice versa.
J
James Kuyper
JosephKK said:
No, that's why log() is special. My comments, and as far as I can tell
all of the comments made on this thread, refer specifically to log().
We're not talking about log10(), log2(), logb(), ilogb(), logsqrt157(),
sytemlog(), or any other arbitrary function that happens to have 'log'
in the function name. This discussion has been very specifically about
the C standard library function named log().
The same power series works for complex numbers. Since the base for
log() happens, oddly enough, to be 'e', it's not an issue. And,
incidentally, the solution for calculating logarithms to a different
base is the same as for real numbers: clog(z)/clog(base); no reference
to the actual value 'e' is required.
J
JosephKK
We will have to talk some more some day somewhere.
J
JosephKK
This is clc, and your programmers point of view is noted for what it
is. It is not the mathematical POV. And somewhere they must meet or
the algorithm won't reliably work.
J
JosephKK
And a typical case of programmers versus mathmaticians. BOTH are
needed.
Mostly happenstance due to mathmatical properties of e itself. An
improper implementation can still mess it up.
J
James Kuyper
JosephKK said:
The fact that ln(x) means the logarithm of x to the base 'e' doesn't
mean that the algorithm needs to use 'e' in any way, nor does the
derivation of that algorithm. That's because 'e' isn't some random
number that you just happen to want to use as the base for your
logarithms. It is the very specific number that gives the logarithm to
that base the special property that the derivative is 1/x. That property
allows derivation of the algorithm without knowing or caring what the
value of 'e' actually is that makes that property true.
D
Dik T. Winter
No. Happenstance due to the mathematical proprties of log. The mathematical
definition of 'log' does not mention 'e' at all, neither does the mathematical
definition of 'exp'.
J
JosephKK
The derivitive of logarithim to any base is 1/x or a constant scalar
multiple of 1/x. It is intrinsic to the nature of the logarithm
function. ln(x) is not special in that way.
J
JosephKK
Please tell me what do you get for x^i*pi for x = 2, or 10? Explain
why and how it is different than e^i*pi.
J
James Kuyper
JosephKK wrote:
....
ln(x) is very special in the fact that the constant scalar is exactly 1.
That's indirectly what defines it to have a base of 'e', or to put it
another way, that's indirectly what defines 'e' to be the special number
that it is. To put it yet another way, if ln(x) is not special in that
way, then in exactly the same sense 'e' itself is not a special number;
I think Euler (and most other mathematicians, scientists, and engineers)
might object to that conclusion.
....
ln(x) is very special in the fact that the constant scalar is exactly 1.
That's indirectly what defines it to have a base of 'e', or to put it
another way, that's indirectly what defines 'e' to be the special number
that it is. To put it yet another way, if ln(x) is not special in that
way, then in exactly the same sense 'e' itself is not a special number;
I think Euler (and most other mathematicians, scientists, and engineers)
might object to that conclusion.
J
James Kuyper
JosephKK said:
How is that relevant to the issue? Yes, 'e' is a very special number,
with a number of interesting properties, including the fact that
ln(e)=1. But it is the properties of 'e', not it's actual value, which
are used in deriving and implementing algorithms for evaluating log(x).
D
Dik T. Winter
Irrelevant. The mathematical definition of exp is as follows:
exp is a function f(x) such that d/dx f = f and f(0) = 1
the mathematical definition of log is as follows:
log(x) = int{1, x} dx/x
Where in those definitions is 'e' mentioned?
x^i*pi has not a single value when x = 2 or 10. The mathematical definition
of the exponentiation operator is:
a^b = exp(b.log(a))
where that is well-defined. Where in that definition is 'e' used?