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

F:=(x,y)->sin(x)*cos(y);

M:= Matrix(2,3, (i,j) -> [i,2*i +j]);

map('t ->F(t[1], t[2])',M); 
evalf(%);

          [sin(1) cos(3)    sin(1) cos(4)    sin(1) cos(5)]
          [                                               ]
          [sin(2) cos(5)    sin(2) cos(6)    sin(2) cos(7)]

Your function a - please let us call it F - is defined on 'pairs', i.e. in IR^2.
So you have to provide that as input.

  F:=(x,y)->sin(x)*cos(y);

  [seq( [i,i/2], i = 0 .. 360, 45)];
  map('t ->F(t[1], t[2])',%);

I am a bit slow with typing, but as I already did here is my answer 
(even if now partially repeating others ...)

The help page for 'sum' recommends to use 'add':

  add(f(t), t = -2 .. 2);
                                  6

If you want to use 'sum' you can use quotation marks:

  sum('f'(t), t = -2 .. 2);
                                  6


Note however if using the upper case, inert, version it will fall
back to your initial problem if you are going to evaluate it:

  Sum('f'(t), t = -2 .. 2); value(%);

    Error, (in f) cannot determine if this expression is ...


You have to use 2 quotation marks then:

  Sum(''f''(t), t = -2 .. 2); value(%);

                                  6

A better way is to use some 'piecewise' definition:

  F:= i -> piecewise( 0<i, i, -i);
  sum(F(t), t = -2 .. 2);

                                  6

Compare the different behaviours:

  f(t);

    Error, (in f) cannot determine if this expression is ...

  F(t);

                        { t           0 < t
                        {
                        { -t        otherwise


The latter is possibly what you intend for your original F.


In any case it would be good to care for 'undecidable', as the
system does not work like it would do in common programming
(but do it with care for intended use):

  G:= i -> piecewise( 0<i, i, i<=0, -i, `doesNotWork`(i));

It does not know a priori that you want numerical inputs only
and would accept other stuff as well (where ' t < 0 ' makes no
sense, like complex numbers, matrices or functions) and 'sum'
does just that, contrary to 'add'.


Also you can provide the 'data type' like

  g:= proc(i::integer)
    if 0 < i then return i else return -i end if 
  end proc;

Using it will show the difference between sum and add.


A final example regarding the use of F and G from above using
complex numbers and variables:

  1/(x^2+1); convert(%, fullparfrac);

This gives you the partial fraction for 1/(x^2+1) in symbolic
form using the RootOf construct and it is a legal input for sum:

  'sum( F(-1/2*_alpha/(x-_alpha)), _alpha = RootOf(_Z^2+1))';
  allvalues(%); simplify(%);

                       - 1/(x^2+1)

Observe the minus sign: This is correct, since the inputs for F
are not Reals, especially can not be identified to be larger then
zero, so F takes the negative value.

Now do the same, but using G instead of F ... and after that do

  eval(%, `doesNotWork` =' z -> z');  simplify(%);

Up to a stupid simplification problem you get 1/(x^2+1).


Hope it helps: you have to care for intended use.