1. Implementation of exp()
Mathematically, the exponential function is exactly power(E,x), which is how it
is implemented in the latest proposal for math,e ,
Probem os, this is not very accurate numerically. For x=100,0, the 12th decimal
pace and up are wrong, The discrepancy at the 15th place starts at x=10, roughly.
Should we go on with this inaccuracy? If not, exp() shoud be made a builtin,
like sqrt() or sin().
CChris
2. Re: Implementation of exp()
Hi there,
If you dont like the results of power(e,x) then the only alternative
is to implement your own power series. Taylors is the most popular
and easy to implement, so maybe start there and check the accuracy
of that and compare with power(e,x).
Most of the time when i use exp(x) i implement as power(e,x) unless
i need better accuracy then i go to a big number routine, but
either way i end up using x negative because that comes up so much
more in time domain studies of electrical networks and even networks
that represent other physical processes.
Example:
y=a*exp(-t/b)
where t is time and a,b are constants depending on circuit values
and b is almost always positive.
Take care,
Al
E boa sorte com sua programacao Euphoria!
My bumper sticker: "I brake for LED's"
From "Black Knight":
"I can live with losing the good fight,
but i can not live without fighting it".
"Well on second thought, maybe not."
3. Re: Implementation of exp()
Al Getz wrote:
>
> Hi there,
>
>
> If you dont like the results of power(e,x) then the only alternative
> is to implement your own power series. Taylors is the most popular
> and easy to implement, so maybe start there and check the accuracy
> of that and compare with power(e,x).
> Most of the time when i use exp(x) i implement as power(e,x) unless
> i need better accuracy then i go to a big number routine, but
> either way i end up using x negative because that comes up so much
> more in time domain studies of electrical networks and even networks
> that represent other physical processes.
>
> Example:
> y=a*exp(-t/b)
> where t is time and a,b are constants depending on circuit values
> and b is almost always positive.
>
>
> Al
>
> E boa sorte com sua programacao Euphoria!
>
>
> My bumper sticker: "I brake for LED's"
>
No need for such efforts, the standard C library has done it way before us. It
has a native exp() function, which I checked against arbitrary precision
computation: the native exp() doesn't have issues, only power(E,x) has. And i is
not because the value of E is inexact - things are ok as long as x is no greater
than 7 or something.
The implementation would duplicate the code for sin(), with a check for overflow
(the maximum allowable value for x is 1024*ln(2), which is about 694).
CChris
CChris
4. Re: Implementation of exp()
- Posted by Al Getz <Xaxo at aol.c??>
Aug 28, 2007
-
Last edited Aug 29, 2007
CChris wrote:
>
> Al Getz wrote:
> >
> > Hi there,
> >
> >
> > If you dont like the results of power(e,x) then the only alternative
> > is to implement your own power series. Taylors is the most popular
> > and easy to implement, so maybe start there and check the accuracy
> > of that and compare with power(e,x).
> > Most of the time when i use exp(x) i implement as power(e,x) unless
> > i need better accuracy then i go to a big number routine, but
> > either way i end up using x negative because that comes up so much
> > more in time domain studies of electrical networks and even networks
> > that represent other physical processes.
> >
> > Example:
> > y=a*exp(-t/b)
> > where t is time and a,b are constants depending on circuit values
> > and b is almost always positive.
> >
> >
> > Al
> >
> > E boa sorte com sua programacao Euphoria!
> >
> >
> > My bumper sticker: "I brake for LED's"
> >
>
> No need for such efforts, the standard C library has done it way before us.
> It has a native exp() function, which I checked against arbitrary precision
> computation: the native exp() doesn't have issues, only power(E,x) has. And
> i is not because the value of E is inexact - things are ok as long as x is no
> greater than 7 or something.
>
> The implementation would duplicate the code for sin(), with a check for
> overflow
> (the maximum allowable value for x is 1024*ln(2), which is about 694).
>
> CChris
>
> CChris
You mean only the Euphoria version of power(e,x) doesnt work
right?
Take care,
Al
E boa sorte com sua programacao Euphoria!
My bumper sticker: "I brake for LED's"
From "Black Knight":
"I can live with losing the good fight,
but i can not live without fighting it".
"Well on second thought, maybe not."
5. Re: Implementation of exp()
Al Getz wrote:
>
> CChris wrote:
> >
> > Al Getz wrote:
> > >
> > > Hi there,
> > >
> > >
> > > If you dont like the results of power(e,x) then the only alternative
> > > is to implement your own power series. Taylors is the most popular
> > > and easy to implement, so maybe start there and check the accuracy
> > > of that and compare with power(e,x).
> > > Most of the time when i use exp(x) i implement as power(e,x) unless
> > > i need better accuracy then i go to a big number routine, but
> > > either way i end up using x negative because that comes up so much
> > > more in time domain studies of electrical networks and even networks
> > > that represent other physical processes.
> > >
> > > Example:
> > > y=a*exp(-t/b)
> > > where t is time and a,b are constants depending on circuit values
> > > and b is almost always positive.
> > >
> > >
> > > Al
> > >
> > > E boa sorte com sua programacao Euphoria!
> > >
> > >
> > > My bumper sticker: "I brake for LED's"
> > >
> >
> > No need for such efforts, the standard C library has done it way before us.
> > It has a native exp() function, which I checked against arbitrary precision
> > computation: the native exp() doesn't have issues, only power(E,x) has. And
> > i is not because the value of E is inexact - things are ok as long as x is
> > no
> > greater than 7 or something.
> >
> > The implementation would duplicate the code for sin(), with a check for
> > overflow
> > (the maximum allowable value for x is 1024*ln(2), which is about 694).
> >
> > CChris
> >
> > CChris
>
>
> You mean only the Euphoria version of power(e,x) doesnt work
> right?
>
>
> Al
>
> E boa sorte com sua programacao Euphoria!
>
>
> My bumper sticker: "I brake for LED's"
>
Yes.
This has nothing to do with the precision of the E constant - everything is
correct as long as x is below 7 or 8, I'd have to check my test file precisely.
So E is correctly for a 64-bit double number.
I bet the C exp() function is implemented in a way that circumvent this
limitation, probably using powers of 2 rather than powers of an irrational atom,
then converting back. The FPU instruction set (for Inte processors at lest), has
a builtin FYL2X (power(y,ln_2(x)) instruction, which is probably used. I don't
know for sure. What I know is that the results are not exactly what they should
be as computed with arbitrary precision.
CChris
6. Re: Implementation of exp()
CChris wrote:
>
> Al Getz wrote:
> >
> > CChris wrote:
> > >
> > > Al Getz wrote:
> > > >
> > > > Hi there,
> > > >
> > > >
> > > > If you dont like the results of power(e,x) then the only alternative
> > > > is to implement your own power series. Taylors is the most popular
> > > > and easy to implement, so maybe start there and check the accuracy
> > > > of that and compare with power(e,x).
> > > > Most of the time when i use exp(x) i implement as power(e,x) unless
> > > > i need better accuracy then i go to a big number routine, but
> > > > either way i end up using x negative because that comes up so much
> > > > more in time domain studies of electrical networks and even networks
> > > > that represent other physical processes.
> > > >
> > > > Example:
> > > > y=a*exp(-t/b)
> > > > where t is time and a,b are constants depending on circuit values
> > > > and b is almost always positive.
> > > >
> > > >
> > > > Al
> > > >
> > > > E boa sorte com sua programacao Euphoria!
> > > >
> > > >
> > > > My bumper sticker: "I brake for LED's"
> > > >
> > >
> > > No need for such efforts, the standard C library has done it way before
> > > us.
> > > It has a native exp() function, which I checked against arbitrary
> > > precision
> > > computation: the native exp() doesn't have issues, only power(E,x) has.
> > > And
> > > i is not because the value of E is inexact - things are ok as long as x is
> > > no
> > > greater than 7 or something.
> > >
> > > The implementation would duplicate the code for sin(), with a check for
> > > overflow
> > > (the maximum allowable value for x is 1024*ln(2), which is about 694).
> > >
> > > CChris
> > >
> > > CChris
> >
> >
> > You mean only the Euphoria version of power(e,x) doesnt work
> > right?
> >
> >
> > Al
> >
> > E boa sorte com sua programacao Euphoria!
> >
> >
> > My bumper sticker: "I brake for LED's"
> >
>
> Yes.
> This has nothing to do with the precision of the E constant - everything is
> correct as long as x is below 7 or 8, I'd have to check my test file
> precisely.
> So E is correctly for a 64-bit double number.
>
> I bet the C exp() function is implemented in a way that circumvent this
> limitation,
> probably using powers of 2 rather than powers of an irrational atom, then
> converting
> back. The FPU instruction set (for Inte processors at lest), has a builtin
> FYL2X
> (power(y,ln_2(x)) instruction, which is probably used. I don't know for sure.
> What I know is that the results are not exactly what they should be as
> computed
> with arbitrary precision.
>
> CChris
Hi Chris,
Im not sure why you keep mentioning the precision of the E constant.
I never doubted that it was good enough.
As mentioned before, the exp() function could be implemented
using either a Taylor or Chebyshev series.
This brings up old memories...remember the old Sinclair computer?
That "Sinclair Basic" had all the transcendental functions implemented
using Chebychev in assembler. If i remember right, the theory is
that the Cheby's has the errors better distributed over the range
than the Taylors has.
Take care,
Al
E boa sorte com sua programacao Euphoria!
My bumper sticker: "I brake for LED's"
From "Black Knight":
"I can live with losing the good fight,
but i can not live without fighting it".
"Well on second thought, maybe not."
7. Re: Implementation of exp()
Al Getz wrote:
>
> CChris wrote:
> >
> > Al Getz wrote:
> > >
> > > CChris wrote:
> > > >
> > > > Al Getz wrote:
> > > > >
> > > > > Hi there,
> > > > >
> > > > >
> > > > > If you dont like the results of power(e,x) then the only alternative
> > > > > is to implement your own power series. Taylors is the most popular
> > > > > and easy to implement, so maybe start there and check the accuracy
> > > > > of that and compare with power(e,x).
> > > > > Most of the time when i use exp(x) i implement as power(e,x) unless
> > > > > i need better accuracy then i go to a big number routine, but
> > > > > either way i end up using x negative because that comes up so much
> > > > > more in time domain studies of electrical networks and even networks
> > > > > that represent other physical processes.
> > > > >
> > > > > Example:
> > > > > y=a*exp(-t/b)
> > > > > where t is time and a,b are constants depending on circuit values
> > > > > and b is almost always positive.
> > > > >
> > > > >
> > > > > Al
> > > > >
> > > > > E boa sorte com sua programacao Euphoria!
> > > > >
> > > > >
> > > > > My bumper sticker: "I brake for LED's"
> > > > >
> > > >
> > > > No need for such efforts, the standard C library has done it way before
> > > > us.
> > > > It has a native exp() function, which I checked against arbitrary
> > > > precision
> > > > computation: the native exp() doesn't have issues, only power(E,x) has.
> > > > And
> > > > i is not because the value of E is inexact - things are ok as long as x
> > > > is no
> > > > greater than 7 or something.
> > > >
> > > > The implementation would duplicate the code for sin(), with a check for
> > > > overflow
> > > > (the maximum allowable value for x is 1024*ln(2), which is about 694).
> > > >
> > > > CChris
> > > >
> > > > CChris
> > >
> > >
> > > You mean only the Euphoria version of power(e,x) doesnt work
> > > right?
> > >
> > >
> > > Al
> > >
> > > E boa sorte com sua programacao Euphoria!
> > >
> > >
> > > My bumper sticker: "I brake for LED's"
> > >
> >
> > Yes.
> > This has nothing to do with the precision of the E constant - everything is
> > correct as long as x is below 7 or 8, I'd have to check my test file
> > precisely.
> > So E is correctly for a 64-bit double number.
> >
> > I bet the C exp() function is implemented in a way that circumvent this
> > limitation,
> > probably using powers of 2 rather than powers of an irrational atom, then
> > converting
> > back. The FPU instruction set (for Inte processors at lest), has a builtin
> > FYL2X
> > (power(y,ln_2(x)) instruction, which is probably used. I don't know for
> > sure.
> > What I know is that the results are not exactly what they should be as
> > computed
> > with arbitrary precision.
> >
> > CChris
>
>
> Hi Chris,
>
> Im not sure why you keep mentioning the precision of the E constant.
> I never doubted that it was good enough.
>
> As mentioned before, the exp() function could be implemented
> using either a Taylor or Chebyshev series.
>
I expect this is how the hardware implements FYL2X and related opcodes.
> This brings up old memories...remember the old Sinclair computer?
I heard about it, but didn't have one. I was using a HP41C handheld at the time.
> That "Sinclair Basic" had all the transcendental functions implemented
> using Chebychev in assembler. If i remember right, the theory is
> that the Cheby's has the errors better distributed over the range
> than the Taylors has.
True. Taylor is good for small values (in magnitude) of the argument. For x
largish, the terms in the Taylor series grow noticeably before starting to show
exponential decay. Hence Chebyshev is certainly more robust.
CChris
>
>
> Al
>
> E boa sorte com sua programacao Euphoria!
>
>
> My bumper sticker: "I brake for LED's"
>
