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

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

"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

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

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.

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

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.

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

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.

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

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.

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

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.