@sand15 

The radii of the balls must be given, as I did in my solution.
It is actually a sphere packing problem.

@acer 

I agree that it is probably a wise decision, but should be documented.

BTW, the result is hfloat only for a Vector/Matrix, but not Array; even if datatype=algebraic.

@acer 

Is it documented?

UseHardwareFloats;
                            deduced

Vector([5.,1]): lprint(%);
Vector[column](2,{1 = 5., 2 = 1},datatype = anything,storage = rectangular,
order = Fortran_order,shape = [])

1/3 * Array([5.,1]): lprint(%);
Array(1 .. 2,{1 = 1.666666667, 2 = 1/3})

1/3 * Vector([5.,1]): lprint(%);
Vector[column](2,{1 = HFloat(1.66666666666666652), 2 = HFloat(.333333333333333315)},datatype = float[8],storage = rectangular,order = Fortran_order,shape = [])

# I would not expect 1/3 * 1 --> hfloat

@Carl Love 

You are right, sorry. I think I've read (partly) the code of your first proc ;-)

@Carl Love 

UniformRandPrime can be far from uniform. E.g., if p,q are two consecutive primes, then  UniformRandPrime(p,q) is constant (q). Note that q-p can be chosen arbitrarily large.
A uniform generator seems to be hard do obtain without knowing all the primes in R.

@Carl Love 

You are right. Anyway, it should be trivial to fix.

@ThU 

Nice, vote up, but it could differ by a constant.

@Adam Ledger 

It's simply a syntax error and the message is clear.

@tomleslie 

Anyway, "Daylight Saving" switch will be eliminated in 2021 at least in EU.

@acer

I have used the term "arguments" because Perm is used as a regular function. A user could be even not aware that it's actually an object (constructor).

So, in such situation it's not possible (in general) to retrive the "arguments".

By the way, in the presented case,  convert(p, string)  gives "(1, 2, 3)(4, 5)".
Do you know whether this works in general? Or is it based on ModulePrint?

Edit. OK, I have read about ModuleDeconstruct and everything seems to be clear.
Thank you.

@mmcdara 

In https://en.wikipedia.org/wiki/Student%27s_t-distribution appears: Parameters  ν>0 degree of freedom (real).

But if it makes you feel better, you may call it  "ν" parameter instead of degree of freedom.

@Carl Love 

I don't see a difficulty in formulation as a mixed optimization problem. But it is purely theoretical and useless without a capable optimization procedure (which cannot exist).

A,B = dimensions of the sheets
a[i], b[i] = dimensions for the rectangles (including kerf), i=1..n.

The unknowns are
x[i], y[i], z[i], t[i] the coordinates of a rectangle (output), i=1..n
K[i]   (integer) is the sheet number k where the i-th rectangle goes.
(k=1..m; m is the number of needed sheets; m is estimated using areas, then increased if the problem is not feasible)

Constraints:
0 <= x[i],  z[i]  <= A,  0 <= y[i],  t[i] <= B
( ( z[i] - x[i] - a[i] )^2  + ( t[i] - y[i] - b[i] )^2 ) * ( ( z[i] - x[i] - b[i] )^2  + ( t[i] - y[i] - a[i] )^2 ) * delta(K[i],k) = 0

(  abs( x[i]+z[i]-x[j]-z[j] ) - abs( x[i]-z[i] ) - abs(x[j]-z[j])  ) * delta(K[i],K[j]) >= 0.   # disjoint rectangles
(  abs( y[i]+t[i]-y[j]-t[j] ) - abs( y[i]-t[i] ) - abs(y[j]-t[j])  ) * delta(K[i],K[j]) >= 0.

(Here delta(i,j) is Kronecker delta (0/1) )

@mehdi jafari 

You cannot do much. Working with symbolic parameters could be very delicate.
Maple cannot allways use piecewise expressions because the final result would be huge and useless. That is why it works "generically". Very few commands generate such piecewice results (e.g. SemiAlgebraic, but with limitations).

For a correct & complete solution we must try to anticipate such problems, using carefully for example solve and singular.

In my example,

singular(ex);  # singular points
                {x = -1, y = y}, {x = -y, y = y}

So, x=0 followed by y=0  ==> problematic and x=0 must be treated separately.

In your case, look for the singularities in S_NEW.

The unpleasant fact is that a Maple result may not contain singularities (due to generic simplifications) and still may depend on special values for parameters. So, anticipate!

@Carl Love 

Because I know very little about objects (probably <  "necessary minimum") I'd use modules, with the advantage (for me at least) of being easier to read (almost like a pseudocode).

restart;
FW:=module()
export ModuleApply, Path;
local Next,dist, w, n:=0;
ModuleApply:= proc(G::GRAPHLN)  #FloydWarshallWithPathReconstruction
   local uv,u,v,i,j,k;
   w := `if`(GraphTheory:-IsWeighted(G), GraphTheory:-WeightMatrix(G), GraphTheory:-AdjacencyMatrix(G)); 
   n:=op([1,1],w);
   dist:=Matrix(n,fill=infinity);
   Next:=Matrix(n);
   for uv in indices(Matrix(w, storage=sparse)) do
      u,v:=uv[];
      dist[u,v] := w[u,v];  # the weight of the edge (u,v)
      Next[u,v] := v
   od;
   for v to n do
      dist[v,v] := 0;
      Next[v,v] := v;
   od;
   for k from 1 to n do ## standard Floyd-Warshall implementation
      for i from 1 to n do
         for j from 1 to n do
            if dist[i,j] > dist[i,k] + dist[k,j] then
               dist[i,j] := dist[i,k] + dist[k,j];
               Next[i,j] := Next[i,k]
            fi;
   od od od;
dist;
end proc:

Path:=proc(u0::posint, v0::posint)
   local u:=u0, v:=v0, path:= Array([u]);
   if u>n or v>n then error "Wrong vertex" fi;
   if Next[u,v] = 0 then return [] fi;
   path := Array([u]);
   while u <> v do
       u := Next[u,v];
       path ,=  u
   od;
   path
end proc;

end module:

G:= GraphTheory:-RandomGraphs:-RandomGraph([v||(1..9)], 0.5, connected, directed);
FW(G);
FW:-Path(2,3);

Could you please tell what are the benefits of using objects in this case?

Edit. An advantage seems to be the possibility to have several graphs. But the module could be adapted for this.

@tomleslie 

Thank you. For me the tip works only sometimes (but curiously, the font is not changed).
Not a big deal, Notepad always works.