       Re: Bug in Mathematica 7.0.1.0 ?

• To: mathgroup at smc.vnet.net
• Subject: [mg109326] Re: Bug in Mathematica 7.0.1.0 ?
• From: "slawek" <a at b.c>
• Date: Thu, 22 Apr 2010 03:29:48 -0400 (EDT)
• References: <hqmd2g\$pro\$1@smc.vnet.net> <hqmoku\$4d7\$1@smc.vnet.net>

```U=BFytkownik "David Bailey" <dave at removedbailey.co.uk> napisa=B3 w wiadomo=B6ci
grup dyskusyjnych:hqmoku\$4d7\$1 at smc.vnet.net...
> 1)  The answer from 7.0.1 is not wrong - just not in the form you desired.

It is wrong because Mathematica should present results in the simplest form
and the Conjugate[a] is not the simplest form.

> 2)  Your code assumed that Conjugate called Im internally - this is the
> sort of assumption that may vary from one version to the next.

Mathematica should check all data on a symbol: is it real? is it complex? is
it a matrix? is it a constant? The Im[variable]^=0 was a well known practice
to define that a variable is real. Nevertheless you are right: Mathematica
degrade from older to 6.0 and 7.0 versions - no more RealsOnly, no ReIm, no
working Conjugate. Some changes was forced by poor implementation - e.g.
RealsOnly gives horrible wrong results in some cases.

> FullSimplify[Conjugate[a b], Im[a] == 0]

%/.Conjugate[a b]->a Conjugate[b] is far more simple anyway.

> Conjugate[b]) is actually no simpler than Conjugate[a b]

Your point of view. I have some nasty integrals, and Conjugate[a b] glue to
a^4 to give a^5 Integrate[Conjugate[b]...., ...]. I think that a^5 as a
factor is a little simpler than Conjugate[a b] inside Integrate.

> In:= complexity[expr_] := LeafCount[expr] +
>            10*Count[expr, Conjugate[x_ y_], {0, Infinity}];
>
> FullSimplify[Conjugate[a b], Im[a] == 0,
>  ComplexityFunction -> complexity]

A nice feature. Actually I really need to disable Integrate[], because
integrals are too complicated for Mathematica (and for me too), but the some
simplifications of the kernels of (multiple) integrals are ok. The complete
"notebook evaluation" took about an hour. Well, I would substitute:
%//.Integrate->dummyIntegration.

> Note that although that looks like a lot of work, you can wrap the
> process up in a function that you define at startup, or in a package,
> and then use as required.

The whole notebook (yes, it is about the plasma physics and so on, Very
Boring Things) have got about 150 input entries. Some are like this:

diff[f_, m_] :=
Module[{i},
D[f[\[Tau]], \[Tau]] ->
D[InterpolatingPolynomial[
Table[{i h, f[\[Tau] + i h]}, {i, -m, 0}], x], x] /. x -> 0 //
FullSimplify]

discretize2m[eq_, m_] := Solve[eq //.
{diff[Subscript[A, 1], m], diff[Subscript[A, 2], m],
HoldPattern[Integrate[f_, it_]] ->  \[ScriptCapitalI][f,
it/h + 1],
\[Tau] ->  (j - 1) h, \[Tau]a  ->  (k -
1)  h, \[Tau]b -> (l - 1)  h,
Subscript[A, \[Eta]_][x_] -> Subscript[Z, \[Eta]][x/h]} /.
Subscript[Z, \[Eta]_][j_] -> Subscript[Z, \[Eta]][j + 1] //
Simplify, {Subscript[Z, 1][j],
Subscript[Z, 2][j]}] /. \[ScriptCapitalI][h^n_ f_, lst_] ->
h^n \[ScriptCapitalI][f, lst] // Flatten // FullSimplify

The problematic was a one single line. Conjugate[a b]->a Conjugate[b] was
sufficient to fix this problem.

But I lost hours to debug .ma ported from 6.0 to 7.0.1.0 .

BTW, this particular notebook generate an crude Fortran code which solves
some integro-delayed-difference-equations.

slawek

slawek

```

• Prev by Date: NDSolve cannot solve set of ODEs
• Next by Date: Re: Adding the elements of a list sequentially
• Previous by thread: Re: Bug in Mathematica 7.0.1.0 ?
• Next by thread: Re: Bug in Mathematica 7.0.1.0 ?