@Lautrup Include the filename extension, which is .ms, at the end of that long string location "C:/...."

I switched from firefox to chrome a few months ago, for Mapleprimes. It suddenly stopped letting me post from firefox. (Win 7, forget which firefox version it was.)

@ABond Obtaining a single polynomial is not necessary for doing mosts sorts of further computation. And for many data points it would likely be either a poor approximation low order polynomial, or a high order polynomial that fits the many points by has far too many qualitatively unwanted inflections.

The piecewise polynomial returned diretcly from dsolve/numeric is effective. The degrees of the pieces is based on the interpolants used by the solver for each time step (ie. accurate, and reasonably compact). Typical degrees would reflect whether you'd used rkf45 or dverk78, etc (that's what those numbers in the name mean). The ArrayInterpolation apporach would use something like degree 3 pieces (but the querying process would act more like a black box).

In both cases discussed, interpolation is being set up for you, with degree not too high (which is good). And as I showed in the worksheet attached above, both can be used to obtain a procedure which take a float input x to a float output y. You can integrate that procedure with evalf/Int, you can plot it, you can Optimize is, you can numerically diferentiate it ith evalf/D, and you can use it in subequent dsolve/numeric computations by using the `known=` option.

Why do you think that you need to see the explicit algebraic form of such an interpolating procedure? For what exact purpose?

@ABond Obtaining a single polynomial is not necessary for doing mosts sorts of further computation. And for many data points it would likely be either a poor approximation low order polynomial, or a high order polynomial that fits the many points by has far too many qualitatively unwanted inflections.

The piecewise polynomial returned diretcly from dsolve/numeric is effective. The degrees of the pieces is based on the interpolants used by the solver for each time step (ie. accurate, and reasonably compact). Typical degrees would reflect whether you'd used rkf45 or dverk78, etc (that's what those numbers in the name mean). The ArrayInterpolation apporach would use something like degree 3 pieces (but the querying process would act more like a black box).

In both cases discussed, interpolation is being set up for you, with degree not too high (which is good). And as I showed in the worksheet attached above, both can be used to obtain a procedure which take a float input x to a float output y. You can integrate that procedure with evalf/Int, you can plot it, you can Optimize is, you can numerically diferentiate it ith evalf/D, and you can use it in subequent dsolve/numeric computations by using the `known=` option.

Why do you think that you need to see the explicit algebraic form of such an interpolating procedure? For what exact purpose?

@serena88 

restart:

se00:=Matrix([[4,2,-1],[2,16,2],[-1,2,4]]):

N:=LinearAlgebra:-RowDimension(se00);

number:=(33-1)/(N-1);

ie0:=Matrix(33):

for i from 1 to number do
   sz := (N-1)*(i-1)+1;
   ie0[sz..sz+N-1,sz..sz+N-1]:=ie0[sz..sz+N-1,sz..sz+N-1]+se00; # add corners
   ### ie0[sz..sz+N-1,sz..sz+N-1]:=se00; # overwrite corners
end do:

interface(rtablesize=33):

ie0;

@serena88 

restart:

se00:=Matrix([[4,2,-1],[2,16,2],[-1,2,4]]):

N:=LinearAlgebra:-RowDimension(se00);

number:=(33-1)/(N-1);

ie0:=Matrix(33):

for i from 1 to number do
   sz := (N-1)*(i-1)+1;
   ie0[sz..sz+N-1,sz..sz+N-1]:=ie0[sz..sz+N-1,sz..sz+N-1]+se00; # add corners
   ### ie0[sz..sz+N-1,sz..sz+N-1]:=se00; # overwrite corners
end do:

interface(rtablesize=33):

ie0;

@suitangi I'd like to add a comment

Even though evaluation of rtables is different from evaluation of lists and other expressions, when passed as arguments to procedures, access to individual rtable entries done inside procedures will still get a useful level of evaluation.

restart:
M:=Matrix([[s]]):

s:=77:

f:=proc(R) lprint(R); ToInert(R); end proc:

f(M); # f receives a M and not a fully evaluated copy of M

Matrix(1, 1, {(1, 1) = s}, datatype = anything, storage = rectangular, order = Fortran_order, shape = [])
_Inert_MATRIX(_Inert_RANGE(_Inert_INTPOS(1), _Inert_INTPOS(1)), 

  _Inert_RANGE(_Inert_INTPOS(1), _Inert_INTPOS(1)), _Inert_SET(_Inert_EXPSEQ(

  _Inert_EQUATION(_Inert_EXPSEQ(_Inert_INTPOS(1), _Inert_INTPOS(1)), 

  _Inert_ASSIGNEDNAME("s", "INTPOS")))), _Inert_EQUATION(

  _Inert_NAME("datatype"), _Inert_NAME("anything", _Inert_ATTRIBUTE(

  _Inert_NAME("protected", _Inert_ATTRIBUTE(_Inert_NAME("protected")))))), 

  _Inert_EQUATION(_Inert_NAME("storage"), _Inert_NAME("rectangular")), 

  _Inert_EQUATION(_Inert_ASSIGNEDNAME("order", "PROC", _Inert_ATTRIBUTE(

  _Inert_NAME("protected", _Inert_ATTRIBUTE(_Inert_NAME("protected"))))), 

  _Inert_NAME("Fortran_order")))

f:=proc(R) R[1,1]; end proc:

f(M); # access to entries of R get useful evaluation, nonetheless
                                     77


restart:
M:=[s]:  # a list!

s:=77:

f:=proc(R) dismantle(R); ToInert(R); end proc:

f(M); # 

LIST(2)
   EXPSEQ(2)
      INTPOS(2): 77


                _Inert_LIST(_Inert_EXPSEQ(_Inert_INTPOS(77)))

So accessing individual entries of Matrix R (Matrix M) inside the procedure f gets the assigned value of s.

It boils down to this question: how many entries of a Matrix will you want to access, inside f? If you want to access only a few, then it would be terrible for procedure performance if Maple had made the effort to fully evaluate all entries of Matrix argument R. Better to evaluate entries only on demand. The rtable_eval command provides finer grained control, in case this is not your scenario.

@suitangi I'd like to add a comment

Even though evaluation of rtables is different from evaluation of lists and other expressions, when passed as arguments to procedures, access to individual rtable entries done inside procedures will still get a useful level of evaluation.

restart:
M:=Matrix([[s]]):

s:=77:

f:=proc(R) lprint(R); ToInert(R); end proc:

f(M); # f receives a M and not a fully evaluated copy of M

Matrix(1, 1, {(1, 1) = s}, datatype = anything, storage = rectangular, order = Fortran_order, shape = [])
_Inert_MATRIX(_Inert_RANGE(_Inert_INTPOS(1), _Inert_INTPOS(1)), 

  _Inert_RANGE(_Inert_INTPOS(1), _Inert_INTPOS(1)), _Inert_SET(_Inert_EXPSEQ(

  _Inert_EQUATION(_Inert_EXPSEQ(_Inert_INTPOS(1), _Inert_INTPOS(1)), 

  _Inert_ASSIGNEDNAME("s", "INTPOS")))), _Inert_EQUATION(

  _Inert_NAME("datatype"), _Inert_NAME("anything", _Inert_ATTRIBUTE(

  _Inert_NAME("protected", _Inert_ATTRIBUTE(_Inert_NAME("protected")))))), 

  _Inert_EQUATION(_Inert_NAME("storage"), _Inert_NAME("rectangular")), 

  _Inert_EQUATION(_Inert_ASSIGNEDNAME("order", "PROC", _Inert_ATTRIBUTE(

  _Inert_NAME("protected", _Inert_ATTRIBUTE(_Inert_NAME("protected"))))), 

  _Inert_NAME("Fortran_order")))

f:=proc(R) R[1,1]; end proc:

f(M); # access to entries of R get useful evaluation, nonetheless
                                     77


restart:
M:=[s]:  # a list!

s:=77:

f:=proc(R) dismantle(R); ToInert(R); end proc:

f(M); # 

LIST(2)
   EXPSEQ(2)
      INTPOS(2): 77


                _Inert_LIST(_Inert_EXPSEQ(_Inert_INTPOS(77)))

So accessing individual entries of Matrix R (Matrix M) inside the procedure f gets the assigned value of s.

It boils down to this question: how many entries of a Matrix will you want to access, inside f? If you want to access only a few, then it would be terrible for procedure performance if Maple had made the effort to fully evaluate all entries of Matrix argument R. Better to evaluate entries only on demand. The rtable_eval command provides finer grained control, in case this is not your scenario.

@itsme 

Here is an Answer to the similar question of a few days ago. It illustrates that the issue is about evaluation rules for rtables, and not about assumptions.

So, if there were to be some extra Help examples, they would be better placed on pages like ?subs or ?eval or ?Vector than they would on ?assume

@itsme 

Here is an Answer to the similar question of a few days ago. It illustrates that the issue is about evaluation rules for rtables, and not about assumptions.

So, if there were to be some extra Help examples, they would be better placed on pages like ?subs or ?eval or ?Vector than they would on ?assume

@Christopher2222 That is interesting. Thanks. I think that quite a few good solutions and motivation for certain improvements in Maple have stemmed from the ideas and activity of this community.

Good point!

The attached worksheet has a comparison of two techniques. I was worried that doing many evaluations of a large piecewise would be relatively expensive. But the initial dsolve/numeric calculation take the bulk of the time.

I'm only do plots because I wanted to show timing for doing many subsequent computations using the results. It's not supposed to be seen as an alternative to DEplot or odeplot.

The output=piecewise is just easier to use. And there's not need to try and guess what kind of resolution is needed, unlike for the output=Array approach. (Presumably, the level of detail in the piecewise comes from dsolve/numeric's own cleverness about choosing step-sizes adaptively, and then forming piecewise interpolating polynomials.)

dscomp.mw

Good point!

The attached worksheet has a comparison of two techniques. I was worried that doing many evaluations of a large piecewise would be relatively expensive. But the initial dsolve/numeric calculation take the bulk of the time.

I'm only do plots because I wanted to show timing for doing many subsequent computations using the results. It's not supposed to be seen as an alternative to DEplot or odeplot.

The output=piecewise is just easier to use. And there's not need to try and guess what kind of resolution is needed, unlike for the output=Array approach. (Presumably, the level of detail in the piecewise comes from dsolve/numeric's own cleverness about choosing step-sizes adaptively, and then forming piecewise interpolating polynomials.)

dscomp.mw

The process looks similar to that used in this Maplesoft submission to the Application Center from April, 2011.

@brian bovril If it survives the try..catch then it augments the table of successes. If it hits an acceptable error (no solution found) then it advances to the next loop iteration. If it hits any other error then it rethrows the error so that the procedure can itself stop with that error. And it returns a sequence of the table entries.

restart:

SSP := proc(values::list)
local a, N, const, sumv, res, allsols, x;
  N := nops(values);
  const := add(x || i, i = 1 .. N);
  sumv := add(x || i*values[i], i = 1 .. N);
  for a to N do
    try
      res := Optimization:-LPSolve(sumv, {const = a, sumv = 0},
                                   assume = {binary}, depthlimit = 200);
    catch "no feasible integer point found":
      next;
    catch "no feasible point found for LP subproblem":
      next;
    catch: error;
    end try;
    allsols[a]:=res;
  end do;
  return seq([x,allsols[x]], x in indices(allsols,nolist));
end proc:

SSP([-7, -3, -2, -5, 5]);

      [2, [0, [x1 = 0, x2 = 0, x3 = 0, x4 = 1, x5 = 1]]], 

        [3, [0, [x1 = 0, x2 = 1, x3 = 1, x4 = 0, x5 = 1]]]

SSP([-7, -3, -2, 5, 8]);

       [3, [0, [x1 = 0, x2 = 1, x3 = 1, x4 = 1, x5 = 0]]]