Only one result gets returned at a time from fsolve, for multivariate problems.

To attempt to get a different solution point, try calling fsolve again, but with its avoid option. That should prevent it from returning the same point as before. See the fsolve,details help-page.

acer

> f3:=a/sqrt(x-y)+b+sqrt(x-y):

> subs({(x-y)^(-1/2)=1/g,(x-y)^(1/2)=g},f3);
                                  a/g + b + g

Of course, I'm not suggesting subs'ing for just (x-y) since you may want other powers of that to be untouched.

Q: what structured type would work (best) here, for use in subsindets say. (To me, subsindets is more apropos if you were using subs originally, whereas evalindets would be more akin to eval.

acer

> f3:=a/sqrt(x-y)+b+sqrt(x-y):

> subs({(x-y)^(-1/2)=1/g,(x-y)^(1/2)=g},f3);
                                  a/g + b + g

Of course, I'm not suggesting subs'ing for just (x-y) since you may want other powers of that to be untouched.

Q: what structured type would work (best) here, for use in subsindets say. (To me, subsindets is more apropos if you were using subs originally, whereas evalindets would be more akin to eval.

acer

That Error Message Guide would be a great place to explain the messages arising specifically from the "new" parameter-processing.

The example mentioned above where `$` is (or is not) used in the parameter sequence of the proc definition, is just one such case.

I will submit an SCR to suggest it.

acer

That Error Message Guide would be a great place to explain the messages arising specifically from the "new" parameter-processing.

The example mentioned above where `$` is (or is not) used in the parameter sequence of the proc definition, is just one such case.

I will submit an SCR to suggest it.

acer

If you post the Maple code here then someone might be able to pinpoint the sources of discrepancy.

acer

Actually, the mentioned object Vector(2...) was indeed present in the VectorField call. It was the second argument, which was <Fx,Fy>.

The problem was that that argument was unexpected, because something else came before it and the total number of arguments was too many. This is a general parameter-processing issue, rather than something particularly specific to VectorCalculus.

Consider,

> f := proc( v::identical(foo), $ ) "ok"; end proc:

> f( 2, foo );
Error, invalid input: too many and/or wrong type of arguments
passed to f; first unused argument is foo

> f( 2 );
Error, invalid input: f expects its 1st argument, v, to be of
type identical(foo), but received 2

> f( foo );
                                     "ok"

It takes a few attempts, to figure out that it was the first argument `2` which was wrong and that the argument `foo` was merely out of place as a consequence. It initially appeared that `foo` was altogether wrong and unexpected, judging by the printed error messages.

This behaviour is a consequence of the order in which arguments are processed (left to right) and the fact that "too many arguments" is elicited prior to checking the types of what preceded. One might reasonably argue that Maple is not justified in deciding that the last argument is the wrong ("unused") one, as opposed to merely indicating that the number of arguments is incorrect.

That was with Maple 12. Now, compare with Maple 10.06.

> f := proc( v::identical(foo), $ ) "ok"; end proc:

> f( 2, foo );
Error, invalid input: 2 arguments passed to f but only 1
positional parameter specified

Now look at what happens if `f` is defined without the parameter-terminator `$`, in either version.

> f := proc( v::identical(foo) ) "ok"; end proc:

> f( 2, foo );
Error, invalid input: f expects its 1st argument, v, to be of
type identical(foo), but received 2

Whether the error message from Maple 12 (when too many arguments are supplied to a procedure defined with `$` as the parameter-processing terminator) is justifiable, it's important that the behaviour is understood.

acer

Actually, the mentioned object Vector(2...) was indeed present in the VectorField call. It was the second argument, which was <Fx,Fy>.

The problem was that that argument was unexpected, because something else came before it and the total number of arguments was too many. This is a general parameter-processing issue, rather than something particularly specific to VectorCalculus.

Consider,

> f := proc( v::identical(foo), $ ) "ok"; end proc:

> f( 2, foo );
Error, invalid input: too many and/or wrong type of arguments
passed to f; first unused argument is foo

> f( 2 );
Error, invalid input: f expects its 1st argument, v, to be of
type identical(foo), but received 2

> f( foo );
                                     "ok"

It takes a few attempts, to figure out that it was the first argument `2` which was wrong and that the argument `foo` was merely out of place as a consequence. It initially appeared that `foo` was altogether wrong and unexpected, judging by the printed error messages.

This behaviour is a consequence of the order in which arguments are processed (left to right) and the fact that "too many arguments" is elicited prior to checking the types of what preceded. One might reasonably argue that Maple is not justified in deciding that the last argument is the wrong ("unused") one, as opposed to merely indicating that the number of arguments is incorrect.

That was with Maple 12. Now, compare with Maple 10.06.

> f := proc( v::identical(foo), $ ) "ok"; end proc:

> f( 2, foo );
Error, invalid input: 2 arguments passed to f but only 1
positional parameter specified

Now look at what happens if `f` is defined without the parameter-terminator `$`, in either version.

> f := proc( v::identical(foo) ) "ok"; end proc:

> f( 2, foo );
Error, invalid input: f expects its 1st argument, v, to be of
type identical(foo), but received 2

Whether the error message from Maple 12 (when too many arguments are supplied to a procedure defined with `$` as the parameter-processing terminator) is justifiable, it's important that the behaviour is understood.

acer

Good point, about inner assumptions not being inferred from the outer ranges.

But I still wonder why the example worked in version9.03 (and earlier) and then broke in version 9.5 (and later).

It's possible that it used to work "by accident", due to some bug that since got fixed. It does (rarely) happen that functionality relies on a chain of fortuitous bugs, such that a fix to one of the bugs breaks an apparently good example. But I don't know if that's the case here.

acer

Good point, about inner assumptions not being inferred from the outer ranges.

But I still wonder why the example worked in version9.03 (and earlier) and then broke in version 9.5 (and later).

It's possible that it used to work "by accident", due to some bug that since got fixed. It does (rarely) happen that functionality relies on a chain of fortuitous bugs, such that a fix to one of the bugs breaks an apparently good example. But I don't know if that's the case here.

acer

> printf("name\t%d\t%d\t=\t%g\n", 13,17,19.3457);
name    13      17      =       19.3457

See Maple's backslash help-page.

acer

> printf("name\t%d\t%d\t=\t%g\n", 13,17,19.3457);
name    13      17      =       19.3457

See Maple's backslash help-page.

acer

The ?sum help-page mentions that add is capable of such finite addition. And, indeed, it is usually preferred.

But the question may still be asked, why doesn't it work as follows for sum,

> sum(sum(1/k!/j!/m!,k=2-m-j..2-m-j),j=0..2-m);
                                    (2 - m)
                                   2
                                  -----------
                                  (2 - m)! m!

> sum(%,m=0..2);
                                      9/2

Also, note that you invoked limit(%%,N=2-m), but the previous line produced an error. So it looks as if limit was being applied to 0 the penultimate result and not to the expression containing hypergeom. Hence it is not clear why this produces 0 in Maple 12.02,

> sum(sum(1/k!/j!/m!,k=2-m-j..2-m-j),j=0..2-m);
                                       0

Indeed,

maple9.03> sum(sum(1/k!/j!/m!,k=2-m-j..2-m-j),j=0..2-m);
                                      4
                                --------------
                                             m
                                (2 - m)! m! 2

maple9.03> sum(%,m=0..2);
                                      9/2

while,

maple9.50> sum(sum(1/k!/j!/m!,k=2-m-j..2-m-j),j=0..2-m);

                                       0

acer

The ?sum help-page mentions that add is capable of such finite addition. And, indeed, it is usually preferred.

But the question may still be asked, why doesn't it work as follows for sum,

> sum(sum(1/k!/j!/m!,k=2-m-j..2-m-j),j=0..2-m);
                                    (2 - m)
                                   2
                                  -----------
                                  (2 - m)! m!

> sum(%,m=0..2);
                                      9/2

Also, note that you invoked limit(%%,N=2-m), but the previous line produced an error. So it looks as if limit was being applied to 0 the penultimate result and not to the expression containing hypergeom. Hence it is not clear why this produces 0 in Maple 12.02,

> sum(sum(1/k!/j!/m!,k=2-m-j..2-m-j),j=0..2-m);
                                       0

Indeed,

maple9.03> sum(sum(1/k!/j!/m!,k=2-m-j..2-m-j),j=0..2-m);
                                      4
                                --------------
                                             m
                                (2 - m)! m! 2

maple9.03> sum(%,m=0..2);
                                      9/2

while,

maple9.50> sum(sum(1/k!/j!/m!,k=2-m-j..2-m-j),j=0..2-m);

                                       0

acer

The apparent "powers" in the derivatives' output are simply artefacts of the notation -- it's just how they get printed but not how they are represented in the underlying structure.

You can use eval in the usual way, to evaluate after substitution,

> expr := sin(x)*diff(f(x),x,x)/sqrt(diff(f(x),x));
                                          / 2      \
                                          |d       |
                                   sin(x) |--- f(x)|
                                          |  2     |
                                          \dx      /
                           expr := -----------------
                                     /d      \1/2
                                     |-- f(x)|
                                     \dx     /

> lprint(expr);
sin(x)*diff(diff(f(x),x),x)/diff(f(x),x)^(1/2)
 
> eval(expr, [diff(f(x),x)=4.0, diff(f(x),x,x)=-17.0]);
                              -8.500000000 sin(x)

acer