Sorry, but I often find it difficult to understand what you are asking.

So I can't tell if you are looking for something like this.

> CrossRatio:=proc(L1,L2)
> local expr,sol;
>   expr:=(a*z+b)/(c*z+d);
>   sol:=solve({seq(eval(expr,z=L1[i])=L2[i],
>                   i=1..nops(L1))},{a,b,c,d});
>   if nops([sol])=1 then
>     unapply(simplify(subs(sol,expr)),z);
>   else
>     NULL;
>   end if;
> end proc:

> f := CrossRatio([0,I,-I],[1,-1,0]);
                                         z + I
                              f := z -> --------
                                        -3 z + I
 
> f~([0,I,-I]);
                                  [1, -1, 0]
 
> CrossRatio([z1,z2,z3,z4],[z1,z2,z4,z3]); # no solution

> CrossRatio([z1,z2,z3,z4],[z2,z1,z4,z3]);
           -z z4 z3 + z z2 z1 - z2 z1 z4 + z3 z1 z4 + z3 z4 z2 - z3 z2 z1
      z -> --------------------------------------------------------------
                     -z z4 - z z3 + z z1 + z z2 + z4 z3 - z2 z1
 
> CrossRatio([z1,z2,z3,z4],[z2,z3,z4,z1]); # no solution

> CrossRatio([z1,z2,z3,z4],[z4,z3,z2,z1]);
           -z z2 z3 + z z4 z1 - z3 z1 z4 + z3 z4 z2 + z3 z2 z1 - z2 z1 z4
      z -> --------------------------------------------------------------
                     -z z3 - z z2 + z z4 + z z1 + z3 z2 - z4 z1

> f(z):

> collect(numer(%),z)/collect(denom(%),z);
        (-z3 z2 + z4 z1) z - z3 z1 z4 + z3 z4 z2 + z3 z2 z1 - z2 z1 z4
        --------------------------------------------------------------
                    z (-z3 - z2 + z4 + z1) + z3 z2 - z4 z1

The main distinction is that diff acts on expressions while D acts on procedures/operators.

> diff(4,x); # or any other unassigned name you prefer
                                       0
 
> D(x->x);
                                       1

You could use command-completion to cut down on the typing of long routine names. Or you could use an alias.

The main distinction is that diff acts on expressions while D acts on procedures/operators.

> diff(4,x); # or any other unassigned name you prefer
                                       0
 
> D(x->x);
                                       1

You could use command-completion to cut down on the typing of long routine names. Or you could use an alias.

It seems more like yanking it out than factoring it out.

> ffactor:=(expr,z)->z*expand(1/z*expr):

> ffactor( a*x + b*x^(-1), a*x );
                                    /     b  \
                                a x |1 + ----|
                                    |       2|
                                    \    a x /
 
> ffactor( exp(t) + exp(-t), exp(t) );
                                    /       1   \
                             exp(t) |1 + -------|
                                    |          2|
                                    \    exp(t) /

If you don't want any side-effects of `expand` acting on the expression then you could edit it to distribute instead (ie. over added terms).

It seems more like yanking it out than factoring it out.

> ffactor:=(expr,z)->z*expand(1/z*expr):

> ffactor( a*x + b*x^(-1), a*x );
                                    /     b  \
                                a x |1 + ----|
                                    |       2|
                                    \    a x /
 
> ffactor( exp(t) + exp(-t), exp(t) );
                                    /       1   \
                             exp(t) |1 + -------|
                                    |          2|
                                    \    exp(t) /

If you don't want any side-effects of `expand` acting on the expression then you could edit it to distribute instead (ie. over added terms).

The code fragment that I posted above does the job without multiplying and dividing by exp(t).

My code is ugly in other ways... It uses this result of normal@expand below. But then it has to deal with things being "flipped".

> normal(expand(exp(t) + exp(-t)));
                                        2
                                  exp(t)  + 1
                                  -----------
                                    exp(t)

The code fragment that I posted above does the job without multiplying and dividing by exp(t).

My code is ugly in other ways... It uses this result of normal@expand below. But then it has to deal with things being "flipped".

> normal(expand(exp(t) + exp(-t)));
                                        2
                                  exp(t)  + 1
                                  -----------
                                    exp(t)

> ee:=ln(cosh(t)):
> EE:=t+ln(1/2+1/2*exp(-2*t)):

> # one direction, easy
> simplify(convert(ln(expand(exp(EE))),trigh));
                                  ln(cosh(t))

> # other direction, ugh
> subs(t=-t,combine(expand(ln(normal(expand(exp(
>   convert(subs(t=-t,ee),exp)))))))) assuming real;
                          t + ln(1/2 + 1/2 exp(-2 t))

> ee:=ln(cosh(t)):
> EE:=t+ln(1/2+1/2*exp(-2*t)):

> # one direction, easy
> simplify(convert(ln(expand(exp(EE))),trigh));
                                  ln(cosh(t))

> # other direction, ugh
> subs(t=-t,combine(expand(ln(normal(expand(exp(
>   convert(subs(t=-t,ee),exp)))))))) assuming real;
                          t + ln(1/2 + 1/2 exp(-2 t))

In Maple 13.01,

> solve(x^2-4,x,UseAssumptions) assuming x::positive;
                                       2

See the ?solve,details help page.

In Maple 13.01,

> solve(x^2-4,x,UseAssumptions) assuming x::positive;
                                       2

See the ?solve,details help page.

Usually, you can override the use of evalhf for floating-point evaluation while plotting by increasing Digits. Alternatively, this can be done just by wrapping with evalf.

For example,

zx:=2000-1.520540265*ln(cosh(39.28976704*x)):

plot(t->evalf[50](eval(zx,x=t)), 0..38);

plot(evalf[50]@(unapply(zx,x)), 0..38);

Digits:=50:
plot(zx, x = 0..38);

Usually, you can override the use of evalhf for floating-point evaluation while plotting by increasing Digits. Alternatively, this can be done just by wrapping with evalf.

For example,

zx:=2000-1.520540265*ln(cosh(39.28976704*x)):

plot(t->evalf[50](eval(zx,x=t)), 0..38);

plot(evalf[50]@(unapply(zx,x)), 0..38);

Digits:=50:
plot(zx, x = 0..38);

In your muladd procedure, i and j are declared as local, and so get treated as such in each subthread of the parent Threads:-Add call. That makes sense. I would not expect any special treatment of other names whose values are obtained from lexical scoping (except if your 'distinct'={} idea were implemented).

But I keep getting this nagging feeling that for `mul` and `add` the treatment of their indexing parameter could be special. We already have the following situation, where the i used in the `add` and `mul` calls does not get the higher level (scoped) assigned value:

> i:=4:

> add(i,i=1..3);
                                       6
 
> mul(i,i=1..3);
                                       6

Here, the higher level value of i does not affect the i used as indexing parameter in the `add` and `mul` calls. Hence I wonder why the i used in each `add` and `mul` call within each subthread of Threads:-Add cannot also be made to be unaffected by any other. I guess that, in this situation, distinctness in parallel seems as justified to me as does distinctness due to level.

Note that these three similar utility routines which have been exported from the Threads package, Add, Mul, and Seq, are mirrored by three global routines add, mul, seq, which all have this special local-index-behaviour-by-level (which is why they each have special evaluation rules).

Also, consider how the code is nested. This is pretty common usage, to have code like mul(add(seq(...))). It would be useful to be able to safely replace any of those by the Threads version.

I have a question. If Threads:-Add is to be a truly useful (close to "drop-in" as possible) replacement for :-add, then couldn't it handle that currently "shared" i variable automatically?

Does the fact that `add` and `mul` have special evaluation rules give such a plea more weight? I mean, their special evaluation rules are there partly so that their index gets treated as a new local of sorts regardless of any assignment to that name at the next level outward. Is there any reasonableness to asking whether Threads:-Add could somehow treat the index of any `add` and `mul` instances as super-local (ie. distinct within each subthread, which in any case are split according to the entirely different Threads:-Add indexing name)?