you may want to post your *concrete* example (even if one might guess), it may be something around 'eval' or working with indexed variables

Still I think your way is too brute (and how would you go on if the matrix is populated?).

First use maplemint(A) before assigning the other constants, it will tell you that some variables
are not declared and others are not used (especially mat1i is not used ...)

Then you execute A and create a sequence - but your bound is n3 = 1000000, 1 Million ... and
it is not clear, whether you would ever use the sequence or just the result on the matrix. And
you just call the proc a million times.

Before doing that I would test *small* values (especially a smal size for the matrix), your code
does not allow that easily, you may wish it is possible.

So I called it just once (wanted to look into some coefficients). Already the that gave me an
error: "Error, (in A) unable to store '-1.333333333+.1e-5*ec(8,9)' when datatype=float[8]".

This says that your function ec is not defined. And all you have through this in 300 sec that
your matrix is not properly filled (I am astonished, that you did not receive such a message,
have you ever looked into some parts of your result? When do you think it is correct?).

Concerning memory you may wish to estimate how many entries are non-zero to get some
feeling how many memory would be needed only to store that.

Anyway: my advice would be to start with a small size, check everything is correct there and
then increase for a kind of 'stress test'.

And why 8000000^2 grid points? That would give tremendous runtimes.

Your input is not quite readable and not usable for copy&paste ...

Anyway: without 'sparse' you have 2 matrices of size 8000000^2 * 32/4 * byte ~ 500000 GB and even if they are very sparse you will run into pain by filling them, even if  in a sparse way.

My feeling (which may be wrong, of course) is that your approach is a bit brute and that Maple may be not the right tool for that.

M1(1/10); map(evalhf,%);  works as expected.

PS: if you input floats there is no need to use evalhf, since you already have floats ...

I can not read your input properly, but one should avoid indexed variables anyway.

If you feel the need to so, the be sure the integration variable has a different name.

In the form posted it is possible to 'understand' the structure of your function w - at least for me.

It may be better to break it up into the steps which finally result in that form: then there may be
a chance to look at it.

For example I think you often have the same Matrix, but it is represented by different objects.
You also may wish to use fraction instead of floating points (which can be done in the steps
before defining the result). And your piecewise should not have a branch 'otherwise' (if you
want performance, write something like 0.5 <= z for example).

exp is branched over the plane, so log is multi-valued (i.e. not a function) and for a concrete number x=5 the principal branch is taken

conversely any branching is mapped to the same base point, hence exp(ln(x)) = x

First: please post your equations and not images, since nobody is happy to type them in, yes? Copy + paste is not that difficult ...

Second: your problem with the last task (I have not looked at the others).

If you write f:= x -> (e^(1/x)+1)^x, then you are not talking about the usual exp and thus the answer depends on properties of e, which makes Maple refuse to give a specific answer:

> restart;
> f:= x -> (e^(1/x)+1)^x: 
> assume(0 < e, e < 1);
> limit(f(x),x=0,right);

                                  1

> restart;
> f:= x -> (e^(1/x)+1)^x: 
> assume(1 < e);
> limit(f(x),x=0,right);

                                  e

> restart;
> f:= x -> (e^(1/x)+1)^x: 
> e:=exp(1):
> limit(f(x),x=0,right);

                                exp(1)

> restart;
> f:= x -> (e^(1/x)+1)^x: 
> assume(e < -1); 
> limit(f(x),x=0,right);

                              undefined

It is some time ago I 'played' with such and it is a pain to write down
Maple commands in C (for example Alec's comment: you can not easily find
typos etc) and more or less I mostly used it the other way round (i.e.
calling from Maple). And the docu does not support that kind of sado-
masochims ...

May be an easy way is to write a procedure in Maple (taking the intended
parameters incl a Matrix) and test it first, the matrix should be of a
type known in Maple *and* C, cf my last needs discussed in the thread
www.mapleprimes.com/forum/externalcallingfeedingpointergsl

More or less: you provide floating point memory from C as matrix from C,
faking and telling Maple it is a Matrix to be used in the above procedure
and overwrite it. Then you have the result in C.

The reason is: you have a validated procedure and that is easisy to be
called, if you know, how to handle inputs. And: you can test the proc
off technical problems.

I would not use a type void, but integer=long to indicate succes (for
example elements, which have been processed).

Good luck :-)

PS. Concerning maintainace the way will torture in the long run and
you will have to care for all sides (Maple, C compiler and operating
system).

PPS. If Google is correct: greetings from Munich to Ulm ...

I am quite sure, that Alec will resist to possibly violate GPL by posting the 'translation' here (though I would not share his opinion here, but no need to discuss it).

But you may consider ways *off that board* ... where I ask myself: why would this guy spend kilo dollars buying Matlab to have it ...

The problem already occurs for J:=Int(exp(u*m*I)/(u^2+1),u=0 .. 1).

  value(J); eval(%, m=1); evalf(%);

                -0.47279431798389 + 0.32179354474106 I

while numerical integration gives

  eval(J, m=1); evalf(%);

                0.68293303180703 + 0.32179354474108 I

The latter is correct (real and imaginary part are positive over
the range of integration).


Decomposing in sin and cos gives a correct result (over the Reals):

  op(1,J): 
  evalc(%); # implicitely assumes all are Reals
  Int(%, u=0 .. 1);
  value(%): simplify(%); 
  eval(%, m=1): evalf(%);

                0.68293303180695 + 0.32179354474105 I


Converting the latter to Ei gives sign rules, which have had
probably been needed for eval(J).

If you are logged in for this forum you find "Submit Maple Software Change Request" below the Maple Primes Logo and can use that (my experience however is: do not expect any feed back - not even that your message was received, it is a total mess).

The other is: to contact your vendor (i.e. the company, from which you bought your product), for Germany this would be Scientific.de (but which one you ever contact: do not expect that anybody simply can heal bugs ...), they will forward it to Maple.

And a web search lets me guess you may have gotten Maple through your school or institution or similar - then you should ask your tutor for a contact person.

Anyway: quite often these pages are scanned by Maple people and some may answer (but there are holidays, even in Canada I guess).

Had to look it up, it simply means leading coefficient =1, quadratic term =0.

Lurking at Wikipedia this reduces to x^3-3*x-c using 
  0=z^3-3*p*z-q; eval(%,z=sqrt(p)*x); %/(p^(3/2)); expand(%);

Using Maple and writing R=(4*c+4*(-4+c^2)^(1/2))^(1/3) the solutions write as

U := [1/2*(R^2+4)/R, 
      1/4*((3^(1/2)*I-1)*R^2-4*I*3^(1/2)-4)/R, 
     -1/4*((3^(1/2)*I+1)*R^2-4*I*3^(1/2)+4)/R];

For the question "which are purely real?" the answer now depend on the c only
and it should be:

- if c is purely real and abs(c) <= 2, then all solutions are real
- otherwise (especially if imag(c) is not zero), then there is always
  a non-real solution (of course then there are 2 of them, conjugated)

In the latter case all solutions are non-real if imag(c) is not zero.

But certainly this is all classical and well-known (by the ancients).

May be M8 does not check enough and later versions hang up here,
so you may try a brute way:

  theAssumptions:=(1 > q, q > 0, 1 > p, p >0, q > p);

  Int(Int(Int(((xs-xr)^2+(ys-p)^2)*xr/(xs-xr),
    xr=0..(2-p)*xs/(2-ys),'continuous'),
    xs=0..q,'continuous'),
    ys=0..p,'continuous');
  value(%);
  simplify(%, size) assuming theAssumptions; 
  discont(%,p);

However it is hazardous (as it relies on continuous antiderivatives),
so you check it carefully and may be you modifiy that recipe by the
suggested "_EnvAllSolutions := true".

Note that older versions may have gotten results, but based on errors
(ok, newer ones as well ...), so cross check on numerical examples. 

Alec's observation may be a way for a work around:

  restart; # or just clear variables used in the next 2 lines
  convert(SphericalY(a,b,c,d),hypergeom);
  SY:=unapply(%,a,b,c,d);

Then

  SY(0,0,0,0);

                              / 1  \1/2
                              |----|
                              \ Pi /
                              ---------
                                  2