ln(exp(x)) does not always simplify, but why?

I was looking for how to handle complex variables on my hp50g and in
the search opened up "science and engineering mathematics with the
hp49g vol. 1" to chapter 5. Not finding what I was after, I was still
enjoying going through the information instead of just moving the
search on.
While reading on page 65 in the "expanding ln(z) section, it is
mentioned that ln(exp(i*theta)) does not get simplified to i*theta and
has the user manually edit it to such. I experimented a bit and found
that any case involving a complex part in the exponent does not
simplify if the inverse functions are in the order of ln(exp()) but
does if ln is in the inside. It does simplify okay if working with
reals.
When working with variables, the CASDIR directory contains the list
REALASSUME; any variables in that list will let the expression
simplify when in complex mode. I thought I have read about the
contents of that directory, but I do not recall where. Is there a
different way to keep a variable to always be interpreted as complex
other than both going to complex mode 'and' keeping it out of the real
list?
What is the mathematical reason for not simplifying ln(exp(x))
unless 'x' is handled as a variable of type real. Is the book's manual
edit correct or mathematically faulty in some cases; is there any
point at which it is undefined or causes other issues?
Numerically, ln(exp(i)) returns (1.15e-14,1) which appears to be
(0,1) with roundoff errors. Should I just round these results manually
or is there a suggested way to work with them to have had the results
come out as would be expected? Is this just accuracy limitations of
exp() and ln() functions showing themselves?
Thanks again,
Ed Sutton, III

"Edward Sutton" <mirror176@hotmail.com> wrote in message
news:96940ad1-6c06-446f-974a-dca3e743bce5@b38g2000prf.googlegroups.com...[color=blue]
> I was looking for how to handle complex variables on my hp50g and in
> the search opened up "science and engineering mathematics with the
> hp49g vol. 1" to chapter 5. Not finding what I was after, I was still
> enjoying going through the information instead of just moving the
> search on.
> While reading on page 65 in the "expanding ln(z) section, it is
> mentioned that ln(exp(i*theta)) does not get simplified to i*theta and
> has the user manually edit it to such. I experimented a bit and found
> that any case involving a complex part in the exponent does not
> simplify if the inverse functions are in the order of ln(exp()) but
> does if ln is in the inside. It does simplify okay if working with
> reals.
> When working with variables, the CASDIR directory contains the list
> REALASSUME; any variables in that list will let the expression
> simplify when in complex mode. I thought I have read about the
> contents of that directory, but I do not recall where. Is there a
> different way to keep a variable to always be interpreted as complex
> other than both going to complex mode 'and' keeping it out of the real
> list?
> What is the mathematical reason for not simplifying ln(exp(x))
> unless 'x' is handled as a variable of type real. Is the book's manual
> edit correct or mathematically faulty in some cases; is there any
> point at which it is undefined or causes other issues?
> Numerically, ln(exp(i)) returns (1.15e-14,1) which appears to be
> (0,1) with roundoff errors. Should I just round these results manually
> or is there a suggested way to work with them to have had the results
> come out as would be expected? Is this just accuracy limitations of
> exp() and ln() functions showing themselves
> Thanks again,
> Ed Sutton, III[/color]
EPSX0
"IF less than EPS in CASDIR THEN eXchange it to zero END" -function

On Oct 15, 6:05*am, Edward Sutton <mirror...@hotmail.com> wrote:[color=blue]
> * Numerically, ln(exp(i)) returns (1.15e-14,1) which appears to be
> (0,1) with roundoff errors. Should I just round these results manually
> or is there a suggested way to work with them to have had the results
> come out as would be expected? Is this just accuracy limitations of
> exp() and ln() functions showing themselves?
> Thanks again,
> Ed Sutton, III[/color]

These are not accuracy limitations of the EXP and LN functions
specifically. It just shows HP's philosophy on rounding. HP
calculators have algorithms to perform functions to 15-digit accuracy
and then round them to 12 digits for display. Unlike some other
brands, the HP's do not keep those 3 digits as "guard digits" --
instead, the next calculation is performed with only those 12 digits
(unless you are using eXtended reals or the LongFloat library).

An example method to gauge calculator accuracy is to take TAN(355/226)
in radians. The fraction 355/113 is very close to pi (it is the 4th
convergent in the continued fraction expansion of pi [3;7,15,1]), and
since the tangent function shoots to +/- infinity around pi/2,
TAN(355/226) = -7,497,258.1853... is very large in absolute value.

The HP48 series calculates TAN(355/226) as -7497089.06508, which
appears to be an accuracy error. But it is not taking the tangent of
355/226. Instead, it is taking the tangent of (355/226 to 12 decimal
places), or 1.57079646018 radians. Turns out that TAN(1.57079646018) =
-7,497,089.065076... so the HP48 series is DEAD ON! (Try this with the
TI-89 and you will be disappointed with a result of -7,497,089.2550967
-- here the TI-89 gives more significant figures than the HP48, but
only 7 out of the 14 digits are correct.)

S.C.

On Oct 15, 2:20*pm, "Veli-Pekka Nousiainen"
<velipekka.nousiai...@saunalahti.fi> wrote:[color=blue]
> "Edward Sutton" <mirror...@hotmail.com> wrote in message
>
> news:96940ad1-6c06-446f-974a-dca3e743bce5@b38g2000prf.googlegroups.com...
>
>
>[color=green]
> > *I was looking for how to handle complex variables on my hp50g and in
> > the search opened up "science and engineering mathematics with the
> > hp49g vol. 1" to chapter 5. Not finding what I was after, I was still
> > enjoying going through the information instead of just moving the
> > search on.
> > *While reading on page 65 in the "expanding ln(z) section, it is
> > mentioned that ln(exp(i*theta)) does not get simplified to i*theta and
> > has the user manually edit it to such. I experimented a bit and found
> > that any case involving a complex part in the exponent does not
> > simplify if the inverse functions are in the order of ln(exp()) but
> > does if ln is in the inside. It does simplify okay if working with
> > reals.
> > *When working with variables, the CASDIR directory contains the list
> > REALASSUME; any variables in that list will let the expression
> > simplify when in complex mode. I thought I have read about the
> > contents of that directory, but I do not recall where. Is there a
> > different way to keep a variable to always be interpreted as complex
> > other than both going to complex mode 'and' keeping it out of the real
> > list?
> > *What is the mathematical reason for not simplifying ln(exp(x))
> > unless 'x' is handled as a variable of type real. Is the book's manual
> > edit correct or mathematically faulty in some cases; is there any
> > point at which it is undefined or causes other issues?
> > *Numerically, ln(exp(i)) returns (1.15e-14,1) which appears to be
> > (0,1) with roundoff errors. Should I just round these results manually
> > or is there a suggested way to work with them to have had the results
> > come out as would be expected? Is this just accuracy limitations of
> > exp() and ln() functions showing themselves
> > Thanks again,
> > Ed Sutton, III[/color]
>
> EPSX0
> "IF less than EPS in CASDIR THEN eXchange it to zero END" -function[/color]


EPS defaults to 1e-10, but like almost everything else on the
calculator, you can customize it to your liking.

(System flag -54 toggles between "Tiny element --> 0" (cleared) and
"Use tiny element" (set). It does not seem to affect the EPSX0
command. Any thoughts?)

S.C.

On Oct 15, 6:05*am, Edward Sutton <mirror...@hotmail.com> wrote:[color=blue]
> * Numerically, ln(exp(i)) returns (1.15e-14,1) which appears to be
> (0,1) with roundoff errors. Should I just round these results manually
> or is there a suggested way to work with them to have had the results
> come out as would be expected? Is this just accuracy limitations of
> exp() and ln() functions showing themselves?
> Thanks again,
> Ed Sutton, III[/color]

These are not accuracy limitations of the EXP and LN functions
specifically. It just shows HP's philosophy on rounding. HP
calculators have algorithms to perform functions to 15-digit accuracy
and then round them to 12 digits for display. Unlike some other
brands, the HP's do not keep those 3 digits as "guard digits" --
instead, the next calculation is performed with only those 12 digits
(unless you are using eXtended reals or the LongFloat library).

An example method to gauge calculator accuracy is to take TAN(355/226)
in radians. The fraction 355/113 is very close to pi (it is the 4th
convergent in the continued fraction expansion of pi [3;7,15,1]), and
since the tangent function shoots to +/- infinity around pi/2,
TAN(355/226) = -7,497,258.1853... is very large in absolute value.

The HP48 series calculates TAN(355/226) as -7497089.06508, which
appears to be an accuracy error. But it is not taking the tangent of
355/226. Instead, it is taking the tangent of (355/226 to 12 decimal
places), or 1.57079646018 radians. Turns out that TAN(1.57079646018) =
-7,497,089.065076... so the HP48 series is DEAD ON! (Try this with the
TI-89 and you will be disappointed with a result of -7,497,089.2550967
-- here the TI-89 gives more significant figures than the HP48, but
only 7 out of the 14 digits are correct.)

S.C.

Tiny elements refers to array operations only
EPSX0 is a separate CAS functions
and yes, you can use some other value for EPS in CASDIR

<sc_usenet@hotmail.com> wrote in message
news:85b08c94-aa5a-4f7b-900f-ecf05ad8dac7@k30g2000hse.googlegroups.com...
X[color=blue]
> EPSX0
> "IF less than EPS in CASDIR THEN eXchange it to zero END" -function[/color]


EPS defaults to 1e-10, but like almost everything else on the
calculator, you can customize it to your liking.

(System flag -54 toggles between "Tiny element --> 0" (cleared) and
"Use tiny element" (set). It does not seem to affect the EPSX0
command. Any thoughts?)

S.C.

On Oct 15, 6:05*am, Edward Sutton <mirror...@hotmail.com> wrote:[color=blue]
> * Numerically, ln(exp(i)) returns (1.15e-14,1) which appears to be
> (0,1) with roundoff errors. Should I just round these results manually
> or is there a suggested way to work with them to have had the results
> come out as would be expected? Is this just accuracy limitations of
> exp() and ln() functions showing themselves?
> Thanks again,
> Ed Sutton, III[/color]

These are not accuracy limitations of the EXP and LN functions
specifically. It just shows HP's philosophy on rounding. HP
calculators have algorithms to perform functions to 15-digit accuracy
and then round them to 12 digits for display. Unlike some other
brands, the HP's do not keep those 3 digits as "guard digits" --
instead, the next calculation is performed with only those 12 digits
(unless you are using eXtended reals or the LongFloat library).

An example method to gauge calculator accuracy is to take TAN(355/226)
in radians. The fraction 355/113 is very close to pi (it is the 4th
convergent in the continued fraction expansion of pi [3;7,15,1]), and
since the tangent function shoots to +/- infinity around pi/2,
TAN(355/226) = -7,497,258.1853... is very large in absolute value.

The HP48 series calculates TAN(355/226) as -7497089.06508, which
appears to be an accuracy error. But it is not taking the tangent of
355/226. Instead, it is taking the tangent of (355/226 to 12 decimal
places), or 1.57079646018 radians. Turns out that TAN(1.57079646018) =
-7,497,089.065076... so the HP48 series is DEAD ON! (Try this with the
TI-89 and you will be disappointed with a result of -7,497,089.2550967
-- here the TI-89 gives more significant figures than the HP48, but
only 7 out of the 14 digits are correct.)

S.C.