Do you still have your original activation code? Would it be possible to try uninstalling and then reinstalling Maple? Just an idea.

acer

I figure that by "resolution" you mean Digits, the setting of the precision for floating-point calculation.

I'm not sure whether the following is useful to you,

> restart:
>
> p := Pi*csc(Pi*alp)
> *((E*x)^m*hypergeom([m],[1-alp,1+m],E*x)
> /(GAMMA(c)*GAMMA(1-alp)*GAMMA(1+m))
> -(E*x)^c*hypergeom([c], [1+alp, 1+c], E*x)
> /(GAMMA(m)*GAMMA(1+alp)*GAMMA(1+c)));
                    /     m
                    |(E x)  hypergeom([m], [1 + m, 1 - alp], E x)
p := Pi csc(Pi alp) |--------------------------------------------
                    \    GAMMA(c) GAMMA(1 - alp) GAMMA(1 + m)

            c                                      \
       (E x)  hypergeom([c], [1 + c, 1 + alp], E x)|
     - --------------------------------------------|
           GAMMA(m) GAMMA(1 + alp) GAMMA(1 + c)    /

>
> thisp := eval(subs(alp=c-m,p),[c=5,m=1/2,E=25]);
            /     1/2  1/2
            |35 25    x    hypergeom([1/2], [-7/2, 3/2], 25 x)
thisp := Pi |-- ----------------------------------------------
            \64                       Pi

                5                                \
       1562500 x  hypergeom([5], [11/2, 6], 25 x)|
     - ------- ----------------------------------|
         567                   Pi                /

>
> evalf[10](eval(thisp,x=40));
                                              23
                              -0.3141592654 10

> evalf[30](eval(thisp,x=40));
                                      0.

> evalf[50](eval(thisp,x=40));
             0.99999999999999999831055348863866510505212220867081

>
> newthisp:=expand(map(convert,convert(thisp,StandardFunctions),expln)):

> newthisp := simplify(newthisp) assuming x>0;

newthisp := -1/192

           (3/2)         1/2         2                              1/2
    (7000 x      + 1395 x    + 5000 x  + 4350 x + 192 - 192 exp(10 x   ))

             1/2
    exp(-10 x   )

>
> evalf[10](eval(newthisp,x=40));
                                 0.9999999999

> evalf[30](eval(newthisp,x=40));
                       0.999999999999999999999982319406

The following form may make it appear more clear,

> collect(expand(newthisp),exp(x^(1/2))^10);
                           3/2        1/2        2
                      875 x      465 x      625 x    725 x
                    - -------- - -------- - ------ - ----- - 1
                         24         64        24      32
                1 + ------------------------------------------
                                        1/2 10
                                   exp(x   )

acer

I get this too, with Maple 12 on an (old, FC2) Fedora Core Linux system. But I don't get it on a newer SuSE 10.1 machine.

acer

> restart:

> Units:-AddUnit(roung,prefix=SI,abbreviation=rg,context=SI,conversion=m/s^2);
> Units:-AddSystem(ChrisSI,Units:-GetSystem(SI),roung);
> Units:-UseSystem(ChrisSI);

> with(Units:-Standard):

> 5*Unit(watt*second)/Unit(m*kg);
                                    5 [rg]
 
> 50*Unit(krg)*Unit(s)/Unit(m);
                                  50000 [1/s]

Do you mean something other than the two units palettes? If you configure your left-bar's palettes to contain either (one for SI, and one for FPS), then you should see a generic "unit" entry which allows entry of any valid unit. That is one way to get the bracketed units in 2D Math input, say.

acer

The Units package is a module. It has both exports (such as UseSystem) and two submodules (Standard and Natural).

The exported routines are for administrating the package (redefining units, switching systems, etc). But it is the submodules which provide environments in which units may be used and recognized by (some) of Maple.

The Standard subpackage is one in which units are entered using the Unit() constructor routine. The Natural subpackage provides an environment in which units are stored internally as Units() calls, but in which units are actually entered or typed in by simply using the common symbols or names alone (eg. m, kg). The problem with Units:-Natural is that there are so very many such symbols that the global namespace is robbed of far too many common variable names.

Try initializing your session with the command with(Units:-Standard).

acer

Yes. But how to do that depends on which OS your are using.

acer

The rhs() routine expects an equation, and will not accept a set (even if its only member is an equation). So you could get your hands on that equation itself, or map the rhs() function over all the elements of the set.

> p1 := x^2+y;
                                        2
                                 p1 := x  + y

> e:=solve({p1}, {x});
                                    1/2             1/2
                      e := {x = (-y)   }, {x = -(-y)   }


> op(e[1]);
                                          1/2
                                  x = (-y)

> x1 := rhs(op(e[1]));
                                           1/2
                                 x1 := (-y)

> x1 := map(rhs,e[1]);
                                           1/2
                                x1 := {(-y)   }

> e[1][1];
                                          1/2
                                  x = (-y)

> x1 := rhs(e[1][1]);
                                           1/2
                                 x1 := (-y)

acer

> eq:=(m+M)=a^3/P^2;
                                              3
                                             a
                              eq := m + M = ----
                                              2
                                             P

> solve(algsubs(P^(-2)=Z,eq),Z);
                                     m + M
                                     -----
                                       3
                                      a

It can be very difficult to control the order of printing of terms in sums, unless one resorts to subverting the mechanism (using the `` operator, for example). I believe that it depends on the order in which the terms appear in some structure (simpl table) internal to the kernel, and that may be based on memory address and thus be session dependent.

> restart:
> eq:=(m+M)=a^3/P^2:
> expand(solve(eq,m));
                                          3
                                         a
                                   -M + ----
                                          2
                                         P

> restart:
> a^3/P^2-M:
> eq:=(m+M)=a^3/P^2:
> expand(solve(eq,m));
                                     3
                                    a
                                   ---- - M
                                     2
                                    P

acer

It's very difficult to give particular advice on what may be the cause without seeing the code. You can upload it in a file, on this site. (Use the green up-arrow FileManager icon on the editor pane's toolbar.)

acer

I'm not sure what you mean by the term "intergration"[sic] in this context..

Are you saying that you want an exact result, instead of a floating-point approximation? If so, then don't apply evalf to the result.

Are you also saying that you are seeking a purely real result, with no nonzero imaginary component? If so then read the help-page ?root and note the item describing the "principal root". Maybe you do not actually intend to use the power 1/5, which will behave according to that description.

> h := t-> (1+t^3*cos(t))^(1/5):
> res := ((D@@5)(h))(Pi):
> simplify(res);
        1/5                              3          2          10           6
- 3 (-1)    (12500 - 60000 Pi + 140000 Pi  - 3125 Pi  - 2856 Pi   - 90000 Pi
 
                4            7           9           8          5         12
     - 468000 Pi  - 244800 Pi  - 63200 Pi  + 20250 Pi  - 5000 Pi  + 700 Pi
 
               11         14    /               3 24/5
     - 13000 Pi   + 875 Pi  )  /  (3125 (-1 + Pi )    )
                              /
 
> evalf(%);
                        -0.1245723166 - 0.09050708583 I
 
> H := t-> surd( (1+t^3*cos(t)), 5 ):
> Res := ((D@@5)(H))(Pi):
> simplify(Res);
                               3          2          10           6
3 (12500 - 60000 Pi + 140000 Pi  - 3125 Pi  - 2856 Pi   - 90000 Pi
 
                4            7           9           8          5         12
     - 468000 Pi  - 244800 Pi  - 63200 Pi  + 20250 Pi  - 5000 Pi  + 700 Pi
 
               11         14    /               3 24/5
     - 13000 Pi   + 875 Pi  )  /  (3125 (-1 + Pi )    )
                              /
 
> evalf(%);
                                 0.1539798515

> evalf(-(-1)^(1/5));
                        -0.8090169944 - 0.5877852523 I
 
> % * %%;
                       -0.1245723167 - 0.09050708586 I

So, the second result, Res, is purely real, and exact.

Notice that the exact results res and Res differ by a factor of -(-1)^(1/5), and that Maple takes that using the principal root concept mentioned in that help-page.

Do you truly intent to convey that the answer should be an exactly equal to some rational number, and if so, why? Or did you simply intead "real", instead of "rational"?

acer

The T that you used in your decAdd operator is not the same as the T being used by G.

Try using G:-variable instead.

Note also that what you are passing to eval() may look (get printed) as a polynomial but underneath is a modp1(ConvertIn(..)) object. So it won't work properly, using eval that way, even with G:-variable. That's why Alec's suggestion to use G:-output is better.

acer

You might consider using option overload. See ?overload

acer

Maybe one of the (many) options to `identify` would need to be adjusted, in order to get success for other values N/Pi^4 .

Here's one idea (of many possible). Maybe it has to do with the default number or size of prime factors that might be involved in the rational part? Consider the size and number of prime factors that appear alongside the instances of success here next,

Digits:=20:
seq([[ifactors(i)],identify(evalf(i/Pi^4))],i=90..120);
seq([[ifactors(i)],identify(evalf(i/Pi^4))],i=1..30);

It appears as if the prime factor 7 is the highest that is present for success above. And 105 fits that, with factorization of 3*5*7, but 104, 106, etc, do not. (Digits might also figure in, I'm not sure.) I'm not sure which if any optional argument to `identify` might control that key value, if that interpretation is correct.

acer

Your result is in a Maple structure called piecewise (which it knows to print so nicely). You can pick it apart, or convert the form. For example,

op(2,Grand_result);
op(2,Grand_result)[1][1];
convert(Grand_result,list);

acer

Where does this "expression tree" come from, and what form is it in?

Is it available as a string? If so then you could do something like this. Assume that the string st comes into maple using sscanf or what have you (I enter it directly).

> st := "/ ( * (x1,x2) , + (x1,x1) )";

                    st := "/ ( * (x1,x2) , + (x1,x1) )"


> StringTools:-SubstituteAll(     
>    StringTools:-SubstituteAll(
>        StringTools:-SubstituteAll(
>            st,"/","`/`"),
>                "*","`*`"),                 
>                   "+","`+`");

                     "`/` ( `*` (x1,x2) , `+` (x1,x1) )"
> eval(parse(%));
                                        x2                                            
                                       ----
                                         2

You could write a Maple procedure to do all those substitutions more easily.

It's more difficult, if you also want to preempt Maple's automatic simplification, which is what makes the above result differ from, say,

>  "`/` ( ``(`*` (x1,x2)) , ``(`+` (x1,x1)) )";
                  "`/` ( ``(`*` (x1,x2)) , ``(`+` (x1,x1)) )"
 
> eval(parse(%));
                                    (x1 x2)
                                   --------
                                    (2 x1)

acer