#616 conjugate(complex) wrong

closed
nobody
None
5
2005-09-07
2004-10-12
Stavros Macrakis
No

declare(z,complex)

conjugate(z) -> z -- should be nounform

(conjugate loaded from EIGEN)

Discussion

  • Robert Dodier
    Robert Dodier
    2005-01-29

    Logged In: YES
    user_id=501686

    The defn of conjugate is

    conjugate(x) := sublis('([%i = - %i]), x)$

    which is useful since it can be applied to lists and
    matrices (among other objects) but it seems too simple-minded.

    The defn above can yield a wrong answer if its argument is a
    real function of a complex variable. E.g.,
    conjugate('carg(a+b %i)) yields
    'carg (a-b %i) -- oops.

    Maybe the right answer is to kill off the existing defn and
    replace it with conjugate(x) := realpart(x) -
    %i*imagpart(x)$ ??
    realpart and imagpart know about lists and matrices, maybe
    other objects, so the convenience of the existing defn
    doesn't seem compelling. Also realpart and imagpart know
    about carg (as they should).

     
  • Logged In: NO

    I am not sure why you mention lists and matrices -- all
    Maxima functions are supposed to handle those cases (though
    admittedly they don't all do it).

    For all *analytic* functions and real variables, the current
    definition is correct, and often gives far smaller
    expressions than using rectform would. However, it is
    incorrect for non-analytic functions (like carg) and
    non-real variables.

    For that matter, rectform also assumes that functions it
    doesn't know always have pure-real values. Try, for
    example, realpart(f(%i)) or rp(%i!).

    It is straightforward enough to write a proper $conjugate
    function that takes that into account -- most of the work
    would in fact go into establishing the list of analytic
    functions!: though there is in principle a Maxima feature
    'analytic', it is not used at all currently.

    It is not clear what the right thing to do about unknown
    functions is. In general, Maxima assumes that functions and
    variables are real-valued -- even if the function arguments
    are non-real. We probably don't want rectform(f(x)) for
    unknown f and x to return 'realpart(f(x)) +
    'imagpart(f(x))*%i.... But returning that only if x is
    known non-real seems arbitrary, too.

    Consider realpart(f(x)) => f(x) ... where f turns out to be
    sqrt.

     
  • Logged In: YES
    user_id=588346

    I am not sure why you mention lists and matrices -- all
    Maxima functions are supposed to handle those cases (though
    admittedly they don't all do it).

    For all *analytic* functions and real variables, the current
    definition is correct, and often gives far smaller
    expressions than using rectform would. However, it is
    incorrect for non-analytic functions (like carg) and
    non-real variables.

    For that matter, rectform also assumes that functions it
    doesn't know always have pure-real values. Try, for
    example, realpart(f(%i)) or rp(%i!).

    It is straightforward enough to write a proper $conjugate
    function that takes that into account -- most of the work
    would in fact go into establishing the list of analytic
    functions!: though there is in principle a Maxima feature
    'analytic', it is not used at all currently.

    It is not clear what the right thing to do about unknown
    functions is. In general, Maxima assumes that functions and
    variables are real-valued -- even if the function arguments
    are non-real. We probably don't want rectform(f(x)) for
    unknown f and x to return 'realpart(f(x)) +
    'imagpart(f(x))*%i.... But returning that only if x is
    known non-real seems arbitrary, too.

    Consider realpart(f(x)) => f(x) ... where f turns out to be
    sqrt.

     
  • Robert Dodier
    Robert Dodier
    2005-09-07

    • status: open --> closed
     
  • Robert Dodier
    Robert Dodier
    2005-09-07

    Logged In: YES
    user_id=501686

    Defn of conjugate in eigen.mac is superseded by defn in
    share/linearalgebra/conjugate.lisp, which doesn't have the
    problems of the eigen.mac defn (nor the problems of the
    realpart/imagpart proposed alternative). Closing this bug
    report as fixed.