@tomleslie  

First point : I can use all the Grid functions except Server, either on my parsonal Mac or either on my profesional PC.
Second point : When I speak about distributing computations I mean "distribute computations on the processors (nodes) of the same laptop"

To answer your question : 

• I don't know if my company have bought thr Grid package but I guess, regarding the phrase above, that it is the case
   
• For my personal case I have a perpetual license for Maple 2015, bought legally, and I don't know neither if this includes the access to Grid ... but here again I suppose it's the case for I can use all the other functions of this package.
   
• Years ago some MapleSoft's commercial told me that distributing computations on a cluster would require to buy as many licences than nodes on the cluster, but that distributing computations on the many nodes of the same machine can be done with a single license : could it be that Server is implicitely dedicated to use Grid on clusters and  that, without more licences, I can use it on a laptop ?
  
  
  Thanks for ypur attention

@acer @Joe Riel @tomleslie

Thank you all for your individual contributions 
(the mailing list is not ranked according to the interest of your answers, but just alphabetical )

@ahmeng 

You're right, there is something weird ...
Please have a look to the enclosed file : the two pieces of code (brown and pink) should give the same answer, but they don't.
I hope someone here will address the problem. 

evalb.mw
 

Download evalb.mw

PS :  I never use the document mode for I find the traditional worksheet mode safer (personal opinion)  

@acer 

Thank you acer for all these informations.

I'm going to take a close look to this.

@Preben Alsholm 

Ok, thank you Preben

@acer 

Could you say me where I can find some elements to help me analyzing the output of the procedure "ToInert"

Thank you for your patience


f := proc(x, y, n)
evalf(sqrt(x)*sqrt(y), n)
end proc:

ToInert(f(x,y,n))
    _Inert_PROD(_Inert_POWER(_Inert_NAME("x"), 

      _Inert_RATIONAL(_Inert_INTPOS(1), _Inert_INTPOS(2))), 

      _Inert_POWER(_Inert_NAME("y"), 

      _Inert_RATIONAL(_Inert_INTPOS(1), _Inert_INTPOS(2))))

@vv 

@acer

Could you look at my last mail to acer ?

In short I think I got sucked by the syntax evalf[8](sqrt(2)*sqrt(3)) which suggested to me that sqrt(2.) and sqrt(3.) were first computed with some precision, then was their product, and finally its 8 digits evaluation.

To be clearer:
Suppose you operate with Digits:=15:
I believed the sequence of operation was 

Digits := 15:
interface(displayprecision=8):
a1 := 2.0;            # a 15 digits floating point representation
b1 := 3.0;            # a 15 digits floating point representation
a2 := sqrt(a1);     # a 15 digits floating point representation
b2 := sqrt(b1);     # a 15 digits floating point representation
c1 := a2*b2;        # a 15 digits floating point representation
c2 := evalf[8](c1);
                              2.0
                              3.0
                        1.41421356237310
                        1.73205080756888
                        2.44948974278319
                           2.4494897

This seemed to me to be consistent with the sintactic graph of evalf[8](sqrt(2)*sqrt(3))

Drawing a parallel to what happens when you compute a=sqrt(2.0)*sqrt(3.0) in a Fortran code (IEEE rounding rules are correctly implemented), I can understand why the result MAPLE returns is 2.4494898.
This sequence mimics what would happen in a (more or less) single precision computation
 

Digits:=8:
a1 := 2.0;
b1 := 3.0;
a2 := sqrt(a1);
b2 := sqrt(b1);
c1 := a2*b2;
c2 := =c1;
                              2.0
                              3.0
                           1.4142136
                           1.7320508
                           2.4494898


I understand perfectely this last sequence of commands. Furthermore the result is consistent with the IEEE specification of "correct rounding".
But it is not obvious to understand why the sequence
Digits := 15:
evalf[8](sqrt(2.0)*sqrt(3.0))
mimics 
Digits:=8:
a1 := 2.0;
b1 := 3.0;
a2 := sqrt(a1);
b2 := sqrt(b1);
c1 := a2*b2;
c2 := =c1;​​​​​​​

@acer 

IEEE 75says that elementary operations, sqrt included, must be correctly rounded.
In my case I have a compound expression involving two sqrt and a multiplication.
Each of them has to be correctly rounded.

Ina "classical" programming language (Fortran, C, ...) all this stuff is implicitely done by the compiler and the precessor behind.
In such a lanquage something like a = sqrt(2) * sqrt(3) is decomposed i, a syntactic graph and each meave or branch is correctly rounded in the IEEE sense.
At the very end the rounding error is propagated along the graph up to the root "a".
Then a could be written as  round( round(sqrt(round(2)) *  round(sqrt(round(3)) ).

What puzzled me is that a := evalf[8](sqrt(2) * sqrt(3)) seems to hide this kind of recursive rounding and looks like some composite expression wher evalf[8] is the last function to apply.

When I write  a := sqrt(2.0)*sqrt(3.0), a is not a 8-digits evaluation of sqrt(6) but a 10-digits one. Then taking evalf[8](a) operates on a sinle number and rounds it correctly (=2.4494897).
But if I consider that MAPLE acts as Fortran or C (for instance), then it applies the rounding on each leave and branch of the syntactic graph of a = sqrt(2) * sqrt(3). Then a =evalf[8]( evalf[8](sqrt(evalf[8](2.0))) * evalf[8](sqrt(evalf[8](2.0)))  ) = 2.4494898

evalf[8](sqrt(evalf[8](2.0))):
evalf[8](sqrt(evalf[8](3.0))):
evalf[8](%*%%) ;
              2.4494898

So, ok you get the point and I was wrong.

Just a last question (put to the trash the question I asked in may last mail [evaluation.mw]) :  to understand how MAPLE actually works on this problem, I did this 

f := proc(x, y)
evalf[8](sqrt(x)*sqrt(y))
end proc;
proc(x, y)  ...  end;
dismantle(op(f));

PROC(11)
   EXPSEQ(3)
      NAME(4): x
      NAME(4): y
   EXPSEQ(1)
   EXPSEQ(1)
   EXPSEQ(1)
   FUNCTION(3)
      TABLEREF(3)
         NAME(4): evalf #[protected]
         EXPSEQ(2)
            INTPOS(2): 8
      EXPSEQ(2)
         PROD(5)
            FUNCTION(3)
               NAME(4): sqrt #[protected, _syslib]
               EXPSEQ(2)
                  PARAM(2): [1]
            INTPOS(2): 1
            FUNCTION(3)
               NAME(4): sqrt #[protected, _syslib]
               EXPSEQ(2)
                  PARAM(2): [2]
            INTPOS(2): 1
   EXPSEQ(1)
   EXPSEQ(1)
   EXPSEQ(1)
   BINARY(2)
      2
   EXPSEQ(3)
      LIST(2)
         EXPSEQ(5)
            STRING(4): ""
            INTNEG(2): -1
            INTPOS(2): 4
            INTPOS(2): 6
      LIST(2)
         EXPSEQ(5)
            STRING(4): ""
            INTNEG(2): -1
            INTNEG(2): -1
            INTPOS(2): 23

I can understand some part of the output "dismantle" returns but not the full output : where can I find informations to analyse the output.

Thanks for all

@acer 

I agree sqrt(2.0)*sqrt(3.0) is a compound operation.
I'm going to verify your answer

In the help pages for printf it's written that 
The fprintf command is based on a C standard library command of the same name

Would you be kind enough to explain me the results in the attached file ?
It seems to me that columns 1 and 3 are "in my words correct" and that column 2 is not.
Moreover, I understand the differences between columns 2 and 3 as different "floating point evaluations" for evalf and the C standard library cited above

evaluation.mw
 

Thanks in advance

Download evaluation.mw

What you say is :

1. X = evalf[3](2) = 1.41
2. Y = evalf[3](2) = 1.73
3. X*Y / 10000 = 2.4393
4. Then : Why evalf[3](6) would give 2.45 ?

This is not a demonstration to the fact that evalf[3](sqrt(2)*sqrt(3)) MUST return 2.44
What you say here is that 2.44 = evalf[3](sqrt(2)) * evalf[3](sqrt(3)), which is obviously not in agreement with the  IEEE 754 standard for arithmetic of computers.

What this standard says is that evalf[3](sqrt(2)*sqrt(3)) should return the value of evalf[3](sqrt(6)), then 2.45
If it is not the case, this is because MAPLE interprets evalf[3](sqrt(2)*sqrt(3))  as evalf[3](sqrt(2)) * evalf[3](sqrt(3)).

The IEEE754 standard says exactly what elementary mathematics says about composition of function : the inner operation (here `*`) must be evaluated before the outer one (evalf[3]).
 

I now the world « bug » is taboo here and I haven’t pronounce it. But if you want to prove me MAPLES does the thing correctly and I'm wrong (a thing  I am willing to accept because nobody, me in particular, is infallible), please give me a more solid explanation.

@Preben Alsholm 

Thanks for your answer Preben.
It lets me unsatisfied but  I should have probably expressed my question differently.

Please take a look at that:

for n from 10 to 3 by -1 do

  [evalf[n](sqrt(6.0)),evalf[n](sqrt(2.0)*sqrt(3.0))]

end do;

                   [2.449489743, 2.449489743]

                    [2.44948974, 2.44948974]

                     [2.4494897, 2.4494898]

                      [2.449490, 2.449491]

                       [2.44949, 2.44948]

                        [2.4495, 2.4495]

                         [2.449, 2.449]

                          [2.45, 2.44]

The operation evalf[n](sqrt(6.0)) respects the IEEE 754 « rounding to the nearest » rule (aka « RN » rule)

But the result of evalf[n](sqrt(2.0)*sqrt(3.0)) doesn’t seem to respect any rule (not the RN rule, neither the DR « towards -infinity » rule, 

neither the RU « towards +infinity » rule)

The only explanation I can give for explaining the differences in the lines above has to be searched in the way Maple does the operationevalf[n](sqrt(2.0)*sqrt(3.0)) 

Let E[n] the operation evalf[n], X = sqrt(2.0) and Y = sqrt(3.0)

In evalf[n](sqrt(2.0)*sqrt(3.0))  MAPLE does not realize the compound operation E[n](`*`(X, Y)) but the operation

`*`(E[n](X), E[n](Y)).

Is it correct ?

Let O some arithmetic operation, O[infinity] its result in infinite precision and O[n] its result in finite « n digits » precision 

The IEEE 754 standard requires that the result of O[n](X,Y) be equal to E[n](O[infinity](X,Y)).

Here 

• IEEE 754              :  O[infinity](`*`(X,Y) = sqrt(6.0)  
• IEEE 754 RN rule :  O[8](`*`(X,Y)) = 2.4494897  
• MAPLE                 :  E[8](`*`(X,Y)) i= 2.4494898

Unless I'm mistaken MAPLE does not respect the IEEE 754 standard  ???

It seems so odd that I can believe that.

Any answer ?

@acer  @vv

Thanks for the this little explanation.
By the way you two made me discover the function "value" and its key role in some circumstances.


From the value help pages I read "During computations, inert functions remain unevaluated (the operations they represent remain unperformed). The value command maps these inert functions, such as Int or %exp, into the corresponding active functions int and exp"
If I'm not mistaken value(r) here has the same role convert(r, sum) had in my code ?

Happy new year to both
 

@vv 

It was not at all obvious !
Thank you for the answer

@Kitonum 
Lack of concentration at the beginning of this year.

Surely this would have been a better answer 
   NewList := proc(L::list, treshold::{integer, float})::list:
      map(u -> if treshold <u then 2*u else u end if, L):
   end proc:

Thanks for you exercised eye.
By the way, I use to use map instead of `if ` (contrary to what is usually done here) : are the twos equivalent or does it exist some subtleties ?

Happy new year
 

Point 1 : I guess (see Kitonum's reply) a[1], a[3], p[3] are arbitrary functions of t ?
In this case you should write your ode this way :
edo := diff(r(t), t)-(diff(a__3(t), t))*r(t)/a__3(t)+a__1(t)*p__3(t)-3*r(t)*r(t) = 0;

Point 2 : every time dsolve doesn't give an answer, use infolevel :
Here 
infolevel[dsolve] := 4:
dsolve(edo, r(t))

What happens ? Maple works hard but doesn't find any solution.
Let us rewrite your ode on the form  edo := diff(r(t), t)+f(t)*r(t)+g(t)+c*r(t)^2 = 0;
This a non linear first order edo of Ricatti type (use infolevel[dsolve] := 4 to verify) and the problem is that, apart from special cases, there is no general technique for obtaining a solution (you can refer to "Advanced Mathematical Methods for Scientists and Engineers", Bender & Orsazg, paragraph 1.6 [the one the red text here comes from] ).
In this reference you will see that "many Ricatti equations can be solved" ... as soon as you are able to "guess just one [particular] solution"
In your case the 3 functions a[1], a[3], p[3] not being in closed form, there exist no mathematical way to obtain a solution !