do you allow the matrices to be of arbitrary dimension?

Its part of marketing, which is not quite the strength of Maplesoft ... BTW: comparing volume of sales - does somebody know (and can tell) the size for each of the competitors?

Its part of marketing, which is not quite the strength of Maplesoft ... BTW: comparing volume of sales - does somebody know (and can tell) the size for each of the competitors?

Acer, your nickname is well chosen :-)

I stumbled over it re-reading something in Corless et al "On the Lambert W function", in (3.12) they state a somewhat more general formula But instead of just quoting (which I forgot) I wanted to have some geometric insight, thus it became a bit longish. Thanks to Robert Israel: in case of an antiderivative (like in the examples) his way is even nicer (and easy to prove by differentiating).

... doing things by hand ... I post the recipe separately

If I did not make too many errors your desired result is 10652.94348.

Instead of computing the inverse and integrating one can integrate
the function and correct later, take  h:= y -> y/(1.+(-0.5*y)^0.8).

Compute
h(y)=-10; z0:=fsolve(%,y);
h(y)=-1;  z1:=fsolve(%,y);  # that actually equals -2

Plot
plot(h(y), y= z0 .. z1, view=[z0 .. z1, -10..0]);
plottools[reflect](%, [[0,0],[1,1]]);

The inverse is reflecting at the diagonal and your desired integral
is Int(h(y),y=z0..z1) minus a rectangle 10*z0:

Int(h(y),y=z0..z1); value(%); % - 10*z0;

                             10652.94348

You have 2 points in your question. 1) The correct syntax is v:=x->int(f(z),z=-10..x); Then you see some 1. in front, which stands for floats ... rules? It does hybrid work ... Or even better RootOf(y/(1.+(-0.5*y)^0.8)=z,y); g:=unapply(%,z); But that's not a function, there are multiple roots ... 2) Your sheet says "The solution works well with fsolve and a numerical integration" for g:=z->fsolve(y/(1.+(-0.5*y)^0.8)=z,y); v:=x->evalf(Int(g,-10..x)); v(-1); M does not know how to solve symbolical ... for me it is an answer, which I do not know how to interprete, since fsolve may return a 1st root only Compare your plot with plot(g(t), t=-10..-1); for RootOf(y/(1.+(-0.5*y)^0.8)=z,y); g=unapply(%,z); So: what do you actually want?

There is another solution, to which Dan Corbit points in a discussion in num-analysis newsgroup: "Fast computation of the Gauss hypergeometric function with all its parameters complex ...", by N. Michel, M.V. Stoitsov (2007) available via http://arxiv.org/abs/0708.0116

Hello Ignat,

The problem is caused by the magnitude of the parameters, the DLL
works with double precision only, therefore I wrote "Generally the
parameters should not be too large".

More or less the following happens: it involves to compute products
through the Pochhammer symbols, which is a 'generalization' of the
faculty n!, which you can compute exactly up to n=12 or 13 in double
precison. Now you need something like a!*b! / c! and run out of the
possibility to do it with acceptable exactness in double precision
(actually there are even more rounding problems). Roughly I would
not trust results, if a*b/c is far from 1 exceeding 10 in magnitude.

You can achieve that already simplier and using the test sheet:

  tstData:=[a = 16.7, b = 21, c = 17.7, z = -1.8];

  TstData:=preproc(tstData);
  testRoutine(TstData, Digits, check);
                                               -8
                     DLL = 0.862916627720363 10
                                               -8
                     MPL = 0.161734070206670 10

Also try it for positive z (which avoids a transformation).

Certainly one can improve by a more carefull implementation, but the
restrictions through (double) precision would always remain, at least
with an automatic routine:

one already has that for evaluating polynomials (or rational functions)
of moderate degree and ugly coefficients.

Other examples are given in the test sheet (Forrey's test cases).

No need to memorize - just get used to that, it holds for other stuff as well (like Sum vs. sum) and called the inert version. Well, do not know what to say for the manual. A student should not be assumed to by tons of books for each course, but if you are going to use it for longer: my personal taste is to have printed matter (I am a visual person and recover like "it was on the left side, bottom") to mark things and to have sheets of notes at some pages. At least for learning new stuff. May be a good thing would be to really work through the basic guide. You currently seem to jump around some topics, may be to get friend with the new tool, while you love your other tool. Some systematic intro should be better after the first hacks. Where I would suggest to use the 'classical' interface first (ok, I hate the 'standard' interface), it is easier to handle (for example highlight a command or word with the mouse and then press the F1 help key; at the bottom of the help page you will find related topics as well - very helpfull).

avoid the Real Domain package for first steps ... Hm ... not sure what your prof really said ... and what is your background. More or less that says: one can not consistently extend the usual operational meaning of x^a to 0^0 and gives a reason, yes? This can be said more educated as: the double limit does not exist (guess your prof wanted to avoid technical words). But this does not prevent you to *define* it, Maple uses 0^0 = 1 as convention, derived from x^0 = 1. That is based on the definition x^a = exp(ln(x)*a), where *x is assumed not to be 0*. So it is just a convention used in Maple. Your suggestion would be ok as well, practically one always has to check that x and a not both are 0. PS: such questions are better placed separately at the Student's section

ok, then I guess your problem is not the symbolics, you want a numerical answer?

To have a numerical answer use

  Digits:=14;  

  Int(sqrt(sin(x))/(sqrt(sin(x))+sqrt(cos(x))),x=0..Pi/2);
  evalf(%);

                           0.78539816339745

Note the UpperCase I for the integration command. This tells Maple to do
it numerical (except some symbolics in the integrand or the boundaries)

The answer is given immediately here (and it silently assures that some
error estimates for the result hold true)

If you input lOWER cASE i (and may some evalf later), then Maple will try
to find a symbolic answer (which sometimes needs very long and may be even
impossible without further help for the system).

Is it what bothered you?

No, its my typo, not your ignorance: I meant -2 ... To makes things clearer: inputting a range from 0 to 8 for x lets the online plotter show nothing between 2 and 6 while Maple does ( for simplicity only). The reason is as said above: complex evaluation and canceling the imaginary part:

[sqrt(sin(x)) , sqrt(cos(x))]; eval(%,x=4.0); %[1]/%[2];

                               1/2        1/2
                        [sin(x)   , cos(x)   ]

               [0.86994396101584 I, 0.80848229471251 I]

                           1.0760210417783

A real valued processing would not directly allow that, but Maple does:

eval(sqrt(sin(x)) / sqrt(cos(x)),x=4.0);

                           1.0760210417783

I hope that's what you wanted to know?

I still would like to have my questions in your other thread to be answered Hm ... you do not say, what is not correct with that plot ... No, Maple is not wrong. That online grapher seems to show results only if both sin(x) and cos(x) are positive, so the sqrt of it is defined over the Reals. Maple however works over the complex. For example in x = 2 one has [sqrt(sin(x)) , sqrt(cos(x))] ~ [0.95*I, 0.64*I], so the quotient is real. Hence Maple plots even for x in -Pi ... -Pi/2.