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

In your first attempt, you are trying LinearSolve with the zero-vector as the right-hand-side. Maple is saying that that system is inconsistent. But then you use quite a different, nonzero rhs in your solve call.

The solve call (as below, and not wrapped in an assign call) produces three results. For each of those, the rhs seems to evaluate to a Vector with all entries equal to 1 (just with differing values of B, J_1, and J_2 to get that).

gl1 := t[11] + t[13] + t[31] + t[33] = exp(2*B*J_1 + B*J_2):
gl2 := t[21] + t[23] + t[31] + t[33] = 1:
gl3 := t[11] + t[13] + t[41] + t[43] = 1:
gl4 := t[12] + t[13] + t[32] + t[33] = 1:
gl5 := t[11] + t[14] + t[31] + t[34] = 1:
gl6 := t[21] + t[23] + t[41] + t[43] = exp(-2*B*J_1 + B*J_2):
gl7 := t[22] + t[23] + t[32] + t[33] = exp(2*B*J_1 - B*J_2):
gl8 := t[21] + t[24] + t[31] + t[34] = exp(-2*B*J_1 - B*J_2):
gl9 := t[12] + t[13] + t[42] + t[43] = exp(-2*B*J_1 - B*J_2):
gl10 := t[11] + t[14] + t[41] + t[44] = exp(2*B*J_1 - B*J_2):
gl11 := t[12] + t[14] + t[32] + t[34] = exp(-2*B*J_1 + B*J_2):
gl12 := t[12] + t[14] + t[42] + t[44] = 1:
gl13 := t[22] + t[24] + t[32] + t[34] = 1:
gl14 := t[21] + t[24] + t[41] + t[44] = 1:
gl15 := t[22] + t[23] + t[42] + t[43] = 1:
gl16 := t[22] + t[24] + t[42] + t[44] = exp(2*B*J_1 + B*J_2):
 
a,b:=LinearAlgebra:-GenerateMatrix(
 {gl1,gl2,gl3,gl4,gl5,gl6,gl7,gl8,gl9,gl10,gl11,gl12,gl13,gl14,gl15,gl16},
 [t[11],t[12],t[13],t[14],t[21],t[22],t[23],t[24],t[31],t[32],t[33],t[34],
  t[41],t[42],t[43],t[44]]);
                                                                                
LinearAlgebra:-LinearSolve(a,b);
 
s := solve({gl1, gl2, gl3, gl4, gl5, gl6, gl7, gl8, gl9, gl10, gl11,
            gl12, gl13, gl14, gl15, gl16});
 
nops([s]);
 
seq(eval(b,[s][i])^%T,i=1..nops([s]));
 
LinearAlgebra:-LinearSolve(a,eval(b,[s][1]));

acer

An important difference between,

(evalf@eval(f))/10^Digits;

and,

(evalf@f)()/10^Digits;

is that the latter involves a function call. The latter applies evalf@f to () which means it calls it with null arguments. That's why it returns a float when used in exactly that way inside `uniform`.

On the other hand, the former variant doesn't apply evalf@eval(f) to anything, and so just gives a procedure as the returned result from `uniform` instead of some specific float value. That procedure result is what gets assigned to U, in the programming guide. And calls to that U then result in varying numbers.

Your posted version of `uniform` contained the form (evalf@f)()/10^Digits , which doesn't match the version in the guide. But it differs in the way described above, by being a function call, as well as by omitting the eval().

Maybe you would be interested in forming procedure `uniform` with the variant,

(evalf@f)/10^Digits;

and then considering the behaviour from that? Or, has your understanding of the need for the eval() already been made clear? And it's just the difference between applying a proc and "applying" a number (which just returns that same number) which you wonder about?

acer

Are you after something like this,

> restart:
> assume(b > 0);
> x := b+1;
                                  x := b~ + 1
 
> x:=subs(b='b',x);
                                  x := b + 1
 
> b:='b';
                                    b := b
 
> about(b);
b:
  nothing known about this object

acer

What happens if you try to assign evalf(Pi,1000000) to a name (variable) and then end the line with a colon so as to supress printing of the result?

acer