@dohashi

Hi Darin:

here are the results of the code you posted. I should note that I see four CPU cores being active when I run it (as one would hope).

                    f := proc(x)  ...  end;
                             n := 4
                            1, 5.020
                            2, 5.025
                            3, 5.023
                            4, 5.031
                           5, 10.019
                           6, 10.027
                           7, 10.042
                           8, 10.030

The elements of the list are float[8], but the function also takes in other parameters (one of which is an array of say 5000 float[8] type numbers).

Right now i call Grid:-Map this way:

Grid:-Map(item->myComplicatedFun(item, long_array, other_param1, other_param2, other_param3), myDataArray):

... could it be sensitive to how the other parameters are being passed?

I will try to simplify my code and post a working example here.

Also could you verify that a compiled function should not cause any problems? Inside myComplicatedFun() I call a maple function which I compiled... (although I've tried with a non-compiled version as well with similar results).

thanks.

@dohashi 

thanks for getting back to me. 

1) I tried from 4 to ~12

2) It should take around the same time (+/- a little)

it would almost seem as something is blocking concurrent execution. 

@mehdi jafari

i mean the sum as in the infinite sum which is the result of this command:

int(cosh(t)/(cosh((17/15)*t)+cosh(t)), t = 0 .. infinity) ;

namely:

@mehdi jafari

i would say either the sum given by

int(cosh(t)/(cosh((17/15)*t)+cosh(t)), t = 0 .. infinity) ;

is a wrong representation of the integration... or evaluating it gives a wrong answer. 

As far as i can tell maple will return a sum unevaluated from evalf if it cannot determine what it converges to (and not "just approximate it with finate terms"). If that was the case, calling or not calling simplify could always give you random different answers.

mathematica gives

NIntegrate[Cosh[t]/(Cosh[(17/15)*t] + Cosh[t]), {t, 0, \[Infinity]}]

5.21062

which i assume is the correct answer.

Doing

int(cosh(t)/(cosh((17/15)*t)+cosh(t)), t = 0 .. infinity, numeric) ;

gives

5.210624833

but

int(cosh(t)/(cosh((17/15)*t)+cosh(t)), t = 0 .. infinity) ;

results in a sum... So it's probably the summation of that sum with evalf where the bug is.

You should report it.

thanks for posting. I always find your worksheets very useful.

@Alejandro Jakubi

@Preben Alsholm

thanks for your comments. Yes, I have been able to filter the list after 'solve' returns, but was expecting 'solve' with 'assuming' to do this "automagically".

I am puzzled why you don't see this as a bug. Maple is able to find the solutions (seemingly all solutions with the 'allsolutions' flag), but simply adding an assumption causes it to return nothing. In any case, I take it as a 'limitation' for now, and will just filter results afterwords.

@Majmaj

i am not able to download your worksheet (get the 404 page), but you should make sure the "restart" command is in its own execution group.

see this discussion:

http://mapleprimes.com/questions/145813-Plotsetup-Problem#answer145873

@nm

Alejandro already provided link with more info below, but just to explictely note, you can just use your favorite editor (say vim or emacs or whatever) to write maple code, and then use in the worksheet with a command

read "mycode.mpl"

where mycode.mpl is the name of the file with the code you've written. Of course this does not work for very interactive work, but for anything longer than a few lines might still be useful.

The new "editor feuatre" is a great start, but right now you might get better milage form external editors

@Markiyan Hirnyk 

thanks for the workaround.

do you know why? is there something particularly hard about this problem that it has not been fixed?

i am trying to use cauchyprincipalvalue=true for more complicated integrals.. I suppose that means I have do try to do them by hand anyway to be sure am getting correct results. Do you know cases where your workaround should not work?

@Andriy

ok, I see what you mean...

The integrals i'm trying to calculate are more complicated, and really tedious to do by hand - this was really just the simplest example that I could reduce the problem I was seeing to, to show what i think was a bug.

I will wait a day to see if anyone has anything else to say and submit an SCR.

@Andriy

thanks for your post... but what do you mean by "should not use any CAS for such type of tasks"?

This seems like a bug, and hopefully can get fixed, no?

great! - thanks a lot for taking the time to post!

i'll look into evalindets, and your updated collectExp works just as i needed.

great! - thanks a lot for taking the time to post!

i'll look into evalindets, and your updated collectExp works just as i needed.

Thanks for your reply, but I already have a an expression that I want to act on - if i was just building it, then of course applying collect first would make sense.

using applyop is also not optimal for me, because I have to explicitly specify which operator i want to act on. For example this works:

a2:=exp(a0);

applyop(collect, 1, a2, [x, t]);

but this doesn't:

a2:=A*exp(a0);

applyop(collect, 1, a2, [x, t]);  #here clearly the '1' argument is incorrect.

Basically i have expressions with maybe 20 or more terms, each somehow containing an exponential (multipled by something or divided by something or... )  and i need to collect terms in all those exponentials.

So that's why the 'applyrule' command would be optimal - but not sure why it's not working.