The ssystem command does not work properly in the Standard GUI. I will submit an SCR.

A few examples, that work in both the commandline interface and the Classic GUI.

> interface(version);

  Classic Worksheet Interface, Maple 12.00, IBM INTEL LINUX, Apr 1\
        0 2008 Build ID 347164

> ssystem("echo hello; ls .bashrc");

  [0, "hello
        .bashrc

        "]

ssystem("ls | wc");
  [0, "   1377    1382   19267

        "]

while,

> interface(version);
Standard Worksheet Interface, Maple 12.0, Linux, April 10 2008 Build ID 347164

> ssystem("echo hello; ls .bashrc");
                          [0, "hello; ls .bashrc"]

> ssystem("ls | wc");
                                   [2, ""]

> system("ls | wc");
ls: |: No such file or directory
ls: wc: No such file or directory

The behaviour in Maple 13 seems the same.

Note that the shell escape with bang (!) is only supposed to work in the commandline interface.

acer

> kernelopts(version);
            Maple 12.01, X86 64 LINUX, Sep 23 2008 Build ID 363216
 
> ! echo "obase=12;scale=1100;sqrt(2)"|bc
1.4B79170A07B85737704B085486853504563650B559B8B79A401387B342380A998A\
173A951303434821B55419A068816958B64282342A358A8947369B97237B9B04B656\
A0723349328A219013A8B21AB42844A5758BA27B3A14317B17B28A4354B796260136\
269A55A79598A4619BA2352A310A3373251B0598676B4537681A191A6901560B1336\
2953A3B373054251593693051410425656527080871A620766432B006383A2728764\
09AB56025015471365346AA731A9248B86B009972A5059115A10537765A3727300B7\
1615798551101BB025B5A119781083699746484A9A0A5807960910B945AB250B74A6\
594723624594035156BB3A6A96559A453899500B6BB8811032B2332A74BB8070401B\
50A8A15BA2096184636714AB8894749356151A36BA8AA424B6511A6AA35635A55848\
B5B4A9953B96478B317223B62700B284559B59A0AA34B6724497A247B53B82568819\
93B18A90A575862342586554334ABAB283AA091186977782BB99734B16373A27B60A\
882935333325A1167A98A42B053831634948A444A7572A993929440A412296997B29\
7AA1810B79145B39974988B968B673134353226914236833678A02694B9A563B1017\
B953268692960AB384B15488A8B26808164413967B011056BA0A08BBAB3022935A1B\
6A096AA9A044836568294400477129BAA80481024829112B4B434A6189B4817322B9\
25
!

What seems lacking, is the reverse (or generalized) operation to convert(<string>,decimal,b) where the string represents a floating-point quantity.

> system("echo \"obase=12;scale=11;sqrt(2)\"|bc");
1.4B79170A079
                                       0
 
> ssystem("echo \"obase=12;scale=11;sqrt(2)\"|bc");
[0, "1.4B79170A079
 
    "]

I just noticed that the bc result for 11 dozenal digits above is not accurate to within 1 ulp. It is off by at least 1 1/2 ulps. Good behaviour would be accuracy to less than 1/2 an ulp.

acer

> kernelopts(version);
            Maple 12.01, X86 64 LINUX, Sep 23 2008 Build ID 363216
 
> ! echo "obase=12;scale=1100;sqrt(2)"|bc
1.4B79170A07B85737704B085486853504563650B559B8B79A401387B342380A998A\
173A951303434821B55419A068816958B64282342A358A8947369B97237B9B04B656\
A0723349328A219013A8B21AB42844A5758BA27B3A14317B17B28A4354B796260136\
269A55A79598A4619BA2352A310A3373251B0598676B4537681A191A6901560B1336\
2953A3B373054251593693051410425656527080871A620766432B006383A2728764\
09AB56025015471365346AA731A9248B86B009972A5059115A10537765A3727300B7\
1615798551101BB025B5A119781083699746484A9A0A5807960910B945AB250B74A6\
594723624594035156BB3A6A96559A453899500B6BB8811032B2332A74BB8070401B\
50A8A15BA2096184636714AB8894749356151A36BA8AA424B6511A6AA35635A55848\
B5B4A9953B96478B317223B62700B284559B59A0AA34B6724497A247B53B82568819\
93B18A90A575862342586554334ABAB283AA091186977782BB99734B16373A27B60A\
882935333325A1167A98A42B053831634948A444A7572A993929440A412296997B29\
7AA1810B79145B39974988B968B673134353226914236833678A02694B9A563B1017\
B953268692960AB384B15488A8B26808164413967B011056BA0A08BBAB3022935A1B\
6A096AA9A044836568294400477129BAA80481024829112B4B434A6189B4817322B9\
25
!

What seems lacking, is the reverse (or generalized) operation to convert(<string>,decimal,b) where the string represents a floating-point quantity.

> system("echo \"obase=12;scale=11;sqrt(2)\"|bc");
1.4B79170A079
                                       0
 
> ssystem("echo \"obase=12;scale=11;sqrt(2)\"|bc");
[0, "1.4B79170A079
 
    "]

I just noticed that the bc result for 11 dozenal digits above is not accurate to within 1 ulp. It is off by at least 1 1/2 ulps. Good behaviour would be accuracy to less than 1/2 an ulp.

acer

I wonder whether common subexpression management in printed output would have also allowed you to "see" the expression's structure. That is a feature of the Classic GUI and the comandline interface, but does not work (automatically, or even properly) in the Standard GUI.

Do you have an example where the simple suggestion to use subs([a^(-1)=1/g,a=g],expression) or its eval version would not suffice, and where none of the other suggestions in the recent thread would work either?

There may be some expense to using numer and denom and redividing.

acer

I wonder whether common subexpression management in printed output would have also allowed you to "see" the expression's structure. That is a feature of the Classic GUI and the comandline interface, but does not work (automatically, or even properly) in the Standard GUI.

Do you have an example where the simple suggestion to use subs([a^(-1)=1/g,a=g],expression) or its eval version would not suffice, and where none of the other suggestions in the recent thread would work either?

There may be some expense to using numer and denom and redividing.

acer

There was a recent thread on that question.

acer

There was a recent thread on that question.

acer

You have a syntax error.

The round-brackets in the following don't match,

{seq(seq([op(i),op(j)], j=fsolve(subs(i,sys)),i=S)};

acer

You have a syntax error.

The round-brackets in the following don't match,

{seq(seq([op(i),op(j)], j=fsolve(subs(i,sys)),i=S)};

acer

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

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