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

Your post shows the wrong single-quote marks. They should both be left-quotes (name-quotes) and not right-quotes (unevaluation quotes) in order to use the postfix operator function `if`.

There are separate options settings for toggling Worksheet/Document and 1D/2D input modes, in the Standard GUI.

To set 1D input use the top menubar item Tools -> Options -> Display and use the top dropdown menu labelled "Input display". Set it to "Maple Notation" for 1D mode input.

In a Worksheet, the F5 function key toggles the cursor between 1D Maple input and 2D Math input (on Linux, so use the shortcuts for your OS). You can tell which mode the cursor is currently accepting visually: the cue is a slanted cursor for 2D and a vertical cursor for 1D mode.

acer

The name `&where` is that of a Library routine. You can use showstat() to look at its source.

I believe that it is used by pdsolve, and that it can appear in output as a mechanism for qualifying results. See ?pdsolve and look for references to PDESolStruc .

You may also already know this, but if you create a procedure whose name begins with & then it can be used as an infix operator. So in you example a &where b is pretty much the same as calling `&where`(a,b).

acer

> m:=[1,5,3]:

> p := proc(L::uneval)
> local thelist;
> thelist:=eval(L);
> seq( cat(L,thelist[i]), i=1..nops(thelist) );
> end proc:

> p(m);
                                  m1, m5, m3

acer

> kernelopts(printbytes=false):
>
> p := "(0.575849 Cos[0.383015 t] Sin[0.383015 t] -\
>     1.66533*10^-16 Cos[2.33523 t] Sin[0.383015 t] +\
>     1.11022*10^-16 Cos[0.383015 t] Sin[2.33523 t] +\
>     1.01122 Cos[2.33523 t] Sin[2.33523 t])^2 + (0.462311 Cos[\
>       0.383015 t]^2 + 3.33067*10^-16 Cos[0.383015 t] Cos[2.33523 t] +\
>     0.537689 Cos[2.33523 t]^2 - 0.462311 Sin[0.383015 t]^2 -\
>     1.38778*10^-16 Sin[0.383015 t] Sin[2.33523 t] -\
>     0.537689 Sin[2.33523 t]^2)^2 == 1":
>
> eq := MmaTranslator:-FromMma(p):
>
> Digits:=30:
> s1 := fsolve(eq, t);
                                                           -7
                  s1 := 0.111758779601256604676477981151 10
 
> eval(eq,t=s1);
                     0.999999999999999999999999999998 = 1
 
>
> s2 := fsolve(eq, t, avoid={t=s1});
                                                           -7
                 s2 := -0.111758779601256604676477981151 10

acer

Is t\[Tau] = 0 a solution? Did you need some other, nontrivial solution?

Did you want a real solution? (I'm not sure that one exists.) If not, then how about,

t\[Tau] = 1.0
HBar = -0.7334865113 - 0.7613376564*I

Or are you looking for some sort of characterization or parametrization of all the solutions as a relation between t\[Tau] and HBar?

ps. It is easier for us if you use Maple syntax.

acer

As shown above, solve() can deal with this example nicely. But LinearSolve does not handle the initial problem nicely, and won't produce an answer until the RHS is instantiated at some partial solution (ie. an instantiation of the RHS which makes the system's conditional consistency more apparent).

A natural question to ask is whether LinearSolve might be made smarter, to get the solution itself right away on the original input with the symbolic RHS.

For LinearSolve with method=LU, it might compute something like the following.

> LUDecomposition(Matrix([a,b]),output=':-U')[Rank(a)+1,1..-1];
[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
 
    -2 + exp(-2 B J_1 + B J_2) + exp(2 B J_1 + B J_2)]

The question then would be, how show a qualifying proviso alongside a returned result, that would usefully show that the augmented right-most entries of the above must equal zero for the result to hold?

And then there is method=solve to deal with. That is actually the method currently getting used for LinearSolve(a,b), as userinfo messages show. And it forms the equations and then calls SolveTools:-Linear. And that call is returning NULL. So it'd be desirable to figure out why, and how it might be avoided or followed up with a more general `solve` call, etc.

acer

I see no Matrix in use in this code. What I see are tables M and L, in the 2nd code.

Your claim, "changed my code to multi-threaded type" doesn't look true to me. Both 1st code and 2nd code use Threads in the same way, no? Isn't the only difference that of using tables versus using integers?

I don't know what paper you refer to, and what sort of data it deals with. Maybe it is discussing access of Maple's immediate integers versus other data. Maybe a more appropriate comparison would be with small integers versus entries of a pre-allocated datatype=integer[8] Matrix, But then, I'm not sure why you'd want to muddy the waters of a comparison of that issue by wrapping it all up in Threads use.

acer

Have a look at the help-page ?INTERFACE_HELP

I believe that a general strategy could be something like this,

• copy an entire existing help-page to an empty session Worksheet.
• edit it to taste
• save it as some new .mw file
• run INTERFACE_HELP on that .mw file

I'm not sure whether you have to worry about libname, and create a new empty .hdb help archive file (found first in libname), so as to ensure that the no previous "system" .hdb gets written to by mistake. The INTERFACE_HELP help-page suggests that it is so, however. So, before running INTERFACE_HELP make sure that some location owned by you is first in libname. (And then, it remains to be seen, whether it will form a new .hdb for you, or not...)

acer