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

This is a discussion on ln(exp(x)) does not always simplify, but why? - Hewlett Packard ; 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 ...

+ Reply to Thread
Results 1 to 7 of 7

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

  1. 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

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

    "Edward Sutton" wrote in message
    news:96940ad1-6c06-446f-974a-dca3e743bce5@b38g2000prf.googlegroups.com...
    > 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

    EPSX0
    "IF less than EPS in CASDIR THEN eXchange it to zero END" -function



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

    On Oct 15, 6:05*am, Edward Sutton wrote:
    > * 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


    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.

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

    On Oct 15, 2:20*pm, "Veli-Pekka Nousiainen"
    wrote:
    > "Edward Sutton" wrote in message
    >
    > news:96940ad1-6c06-446f-974a-dca3e743bce5@b38g2000prf.googlegroups.com...
    >
    >
    >
    > > *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

    >
    > EPSX0
    > "IF less than EPS in CASDIR THEN eXchange it to zero END" -function



    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.

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

    On Oct 15, 6:05*am, Edward Sutton wrote:
    > * 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


    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.

  6. 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

    wrote in message
    news:85b08c94-aa5a-4f7b-900f-ecf05ad8dac7@k30g2000hse.googlegroups.com...
    X
    > EPSX0
    > "IF less than EPS in CASDIR THEN eXchange it to zero END" -function



    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.



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

    On Oct 15, 6:05*am, Edward Sutton wrote:
    > * 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


    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.

+ Reply to Thread