If the values that you are trying to print are not floating-point numbers, then why are you using what appears so similar to a floating-point format code (ie, `%12.5f` or your original `%12.5 f`)?

You might try `%a ` instead, or tell us what types of object you are actually trying to print.

If the values that you are trying to print are not floating-point numbers, then why are you using what appears so similar to a floating-point format code (ie, `%12.5f` or your original `%12.5 f`)?

You might try `%a ` instead, or tell us what types of object you are actually trying to print.

If the values that you are trying to print are not floating-point numbers, then why are you using what appears so similar to a floating-point format code (ie, `%12.5f` or your original `%12.5 f`)?

You might try `%a ` instead, or tell us what types of object you are actually trying to print.

Do you not have to raise the working precision for this example, in order to get an accurate result?

I'm rounding down results to 10 digits below (but you could remove the fnormal calls if the ensuing results add more insight for you.)

> restart:
>
> M:=Matrix([[0,2.986666666,-17.60000000,24,0,0,0,0],
> [-1.*lambda,-1.934222224,26.88000000,-105.6000000,120,0,0,0],
> [0.9333333334*lambda,0.3034074074-1.*lambda,-11.60533334,107.5200000,-352.0000000,360,0,0],
> [-0.1777777778*lambda,0.9333333334*lambda,1.517037037-1.*lambda,-38.68444447,298.6666667,-880.0000000,840,0],
> [0,-0.1777777778*lambda,0.9333333334*lambda,4.551111111-1.*lambda,-96.71111120,672.0000000,-1848.000000,1680],
> [1,-1.836019358*10^(-26),0,0,0,0,0,0],[0,2,6,12,20,30,42,56],[0,0,6,24,60,120,210,336]]):
>
> LinearAlgebra[Determinant](M);
                  4                     3                  15
39999.99998 lambda  - 86334.24942 lambda  - 0.5934525861 10
 
                      11       2                  14
     - 0.2603850286 10   lambda  + 0.2007044811 10   lambda
 
>
> W:=eval(M,lambda=x):
> LinearAlgebra[Determinant](W);
             4                3                  15                  11  2
39999.99998 x  - 86334.24942 x  - 0.5934525861 10   - 0.2603850286 10   x
 
                      14
     + 0.2007044811 10   x
 
>
> fnormal(evalf[20](LinearAlgebra[Determinant](M)));
                        4                  -5       3                  15
-0.00003400000000 lambda  - 0.3970397147 10   lambda  - 0.5934525860 10
 
                      11       2                  14
     - 0.2603833344 10   lambda  + 0.2007044801 10   lambda
 
>
> fnormal(evalf[30](LinearAlgebra[Determinant](M)));
                   15                  11       2                  14
   -0.5934525860 10   - 0.2603833344 10   lambda  + 0.2007044801 10   lambda
 
>
> fnormal(evalf[50](LinearAlgebra[Determinant](M)));
                   15                  11       2                  14
   -0.5934525860 10   - 0.2603833344 10   lambda  + 0.2007044801 10   lambda
 
> fnormal(evalf[50](LinearAlgebra[Determinant](W)));
                        15                  11  2                  14
        -0.5934525860 10   - 0.2603833344 10   x  + 0.2007044801 10   x
 
>
> with(LinearAlgebra:-Generic):
> Q[`0`], Q[`1`], Q[`+`], Q[`-`], Q[`*`], Q[`/`], Q[`=`] :=
>     0, 1, `+`, `-`, `*`, `/`, `=`:
>
> simplify(Determinant[Q](M,method=BerkowitzAlgorithm));
               14                         11       2                     3
0.2007050125 10   lambda - 0.2603839621 10   lambda  + 5387.642677 lambda
 
                          4                  15
     - 0.7335014400 lambda  - 0.5934521812 10
 
>
> fnormal(evalf[20](simplify(Determinant[Q](M,method=BerkowitzAlgorithm))));
               14                         11       2
0.2007044801 10   lambda - 0.2603833344 10   lambda
 
                      -6       3                  15
     + 0.1359287467 10   lambda  - 0.5934525860 10
 
>
> fnormal(evalf[100](simplify(Determinant[Q](M,method=BerkowitzAlgorithm))));
                   15                  11       2                  14
   -0.5934525860 10   - 0.2603833344 10   lambda  + 0.2007044801 10   lambda

Do you not have to raise the working precision for this example, in order to get an accurate result?

I'm rounding down results to 10 digits below (but you could remove the fnormal calls if the ensuing results add more insight for you.)

> restart:
>
> M:=Matrix([[0,2.986666666,-17.60000000,24,0,0,0,0],
> [-1.*lambda,-1.934222224,26.88000000,-105.6000000,120,0,0,0],
> [0.9333333334*lambda,0.3034074074-1.*lambda,-11.60533334,107.5200000,-352.0000000,360,0,0],
> [-0.1777777778*lambda,0.9333333334*lambda,1.517037037-1.*lambda,-38.68444447,298.6666667,-880.0000000,840,0],
> [0,-0.1777777778*lambda,0.9333333334*lambda,4.551111111-1.*lambda,-96.71111120,672.0000000,-1848.000000,1680],
> [1,-1.836019358*10^(-26),0,0,0,0,0,0],[0,2,6,12,20,30,42,56],[0,0,6,24,60,120,210,336]]):
>
> LinearAlgebra[Determinant](M);
                  4                     3                  15
39999.99998 lambda  - 86334.24942 lambda  - 0.5934525861 10
 
                      11       2                  14
     - 0.2603850286 10   lambda  + 0.2007044811 10   lambda
 
>
> W:=eval(M,lambda=x):
> LinearAlgebra[Determinant](W);
             4                3                  15                  11  2
39999.99998 x  - 86334.24942 x  - 0.5934525861 10   - 0.2603850286 10   x
 
                      14
     + 0.2007044811 10   x
 
>
> fnormal(evalf[20](LinearAlgebra[Determinant](M)));
                        4                  -5       3                  15
-0.00003400000000 lambda  - 0.3970397147 10   lambda  - 0.5934525860 10
 
                      11       2                  14
     - 0.2603833344 10   lambda  + 0.2007044801 10   lambda
 
>
> fnormal(evalf[30](LinearAlgebra[Determinant](M)));
                   15                  11       2                  14
   -0.5934525860 10   - 0.2603833344 10   lambda  + 0.2007044801 10   lambda
 
>
> fnormal(evalf[50](LinearAlgebra[Determinant](M)));
                   15                  11       2                  14
   -0.5934525860 10   - 0.2603833344 10   lambda  + 0.2007044801 10   lambda
 
> fnormal(evalf[50](LinearAlgebra[Determinant](W)));
                        15                  11  2                  14
        -0.5934525860 10   - 0.2603833344 10   x  + 0.2007044801 10   x
 
>
> with(LinearAlgebra:-Generic):
> Q[`0`], Q[`1`], Q[`+`], Q[`-`], Q[`*`], Q[`/`], Q[`=`] :=
>     0, 1, `+`, `-`, `*`, `/`, `=`:
>
> simplify(Determinant[Q](M,method=BerkowitzAlgorithm));
               14                         11       2                     3
0.2007050125 10   lambda - 0.2603839621 10   lambda  + 5387.642677 lambda
 
                          4                  15
     - 0.7335014400 lambda  - 0.5934521812 10
 
>
> fnormal(evalf[20](simplify(Determinant[Q](M,method=BerkowitzAlgorithm))));
               14                         11       2
0.2007044801 10   lambda - 0.2603833344 10   lambda
 
                      -6       3                  15
     + 0.1359287467 10   lambda  - 0.5934525860 10
 
>
> fnormal(evalf[100](simplify(Determinant[Q](M,method=BerkowitzAlgorithm))));
                   15                  11       2                  14
   -0.5934525860 10   - 0.2603833344 10   lambda  + 0.2007044801 10   lambda

Have you actually compared the various solutions, against eash other or against the data?

Try this: make a plots:-pointplot using the two Vectors of data. Then make a plot of each of the approximate solutions. Then overlay them all together using the plots:-display command. What do you think?

Then make a plot of one of the solution formulas minus the other one. Is it very small, relative to the previous plot of the data?

Now consider, why should there be only one unique set of values for the parameters for your nonlinear formula that solve the local (least squares fit) optimization problem?

Have you actually compared the various solutions, against eash other or against the data?

Try this: make a plots:-pointplot using the two Vectors of data. Then make a plot of each of the approximate solutions. Then overlay them all together using the plots:-display command. What do you think?

Then make a plot of one of the solution formulas minus the other one. Is it very small, relative to the previous plot of the data?

Now consider, why should there be only one unique set of values for the parameters for your nonlinear formula that solve the local (least squares fit) optimization problem?

This is just one way.

t:=readline("foo.txt"):
count:=0:
while t<>0 do
  count:=count+1;
  L[count]:=map(parse,StringTools:-Split(t," W "));
  t:=readline("foo.txt"):
end do:

eval(L);

Of course, you can do many other things with the parsed lines other than stuff them into a table such as L.

This is just one way.

t:=readline("foo.txt"):
count:=0:
while t<>0 do
  count:=count+1;
  L[count]:=map(parse,StringTools:-Split(t," W "));
  t:=readline("foo.txt"):
end do:

eval(L);

Of course, you can do many other things with the parsed lines other than stuff them into a table such as L.

I don't mind the separate existence of pages such as ?simplify,size

But I very much dislike the "details" pages like ?simplify,details and ?fsolve,details since far too often people overlook them (and they turn out to be just what contains the key point for the issue at hand). Someone probably thought that they had a Great Idea when splitting such pages into the basic and detailed versions. But it turns out to have been a Poor Idea. Far too often, it seems that the extra calling optional sequences are just what is wanted.

Unfortunately, it seems much more common human behaviour for mistakes to be made than for them to be correctly identified, admitted, and rectified.

I don't mind the separate existence of pages such as ?simplify,size

But I very much dislike the "details" pages like ?simplify,details and ?fsolve,details since far too often people overlook them (and they turn out to be just what contains the key point for the issue at hand). Someone probably thought that they had a Great Idea when splitting such pages into the basic and detailed versions. But it turns out to have been a Poor Idea. Far too often, it seems that the extra calling optional sequences are just what is wanted.

Unfortunately, it seems much more common human behaviour for mistakes to be made than for them to be correctly identified, admitted, and rectified.

Just a few possibilities:

expr:=1/(s^5+3.236067976*s^4+(1.*10^(-10)*I)*s^4+5.236067975*s^3+
(7.*10^(-10)*I)*s^3-(3.*10^(-10)*I)*s+5.236067975*s^2+3.236067977*s+1.000000000);

map(simplify,fnormal(expr));

simplify(fnormal(expr),size);

Just a few possibilities:

expr:=1/(s^5+3.236067976*s^4+(1.*10^(-10)*I)*s^4+5.236067975*s^3+
(7.*10^(-10)*I)*s^3-(3.*10^(-10)*I)*s+5.236067975*s^2+3.236067977*s+1.000000000);

map(simplify,fnormal(expr));

simplify(fnormal(expr),size);

The result from the command currentdir() might not be the same as the location to which you installed the .lib and .ind files, right? And you need it to be the same.

Try it like this, replacing XYZ with the explicit full path to the location of the actual folder or directory containing those files.

  libname: = "XYZ", libname;

By the way, it's not a good idea to have a space inside a function call, like you have between currentdir and the (). In 2D Math input, that gets parsed poorly.

The result from the command currentdir() might not be the same as the location to which you installed the .lib and .ind files, right? And you need it to be the same.

Try it like this, replacing XYZ with the explicit full path to the location of the actual folder or directory containing those files.

  libname: = "XYZ", libname;

By the way, it's not a good idea to have a space inside a function call, like you have between currentdir and the (). In 2D Math input, that gets parsed poorly.