I have taking the liberty to provide here a working link to your preprint.

I have taking the liberty to provide here a working link to your preprint.

I produced the 2-D math like output, which is really just a gif image file, as pointed out by Israel, using the program Scientific Workplace with which I write research articles. After having posted and turned of my computer - actually, while laying in my bed - it hit me why I did not use the <maple> and </maple> tags, as referred to also by Israel. Next time maybe I'll try doing that instead.

I produced the 2-D math like output, which is really just a gif image file, as pointed out by Israel, using the program Scientific Workplace with which I write research articles. After having posted and turned of my computer - actually, while laying in my bed - it hit me why I did not use the <maple> and </maple> tags, as referred to also by Israel. Next time maybe I'll try doing that instead.

Clearly, what I was missing in my own approach was, as suggested by both of you, to separate the problem into the real and imaginary parts, respectively. I ask myself, why did that not strike me before posting? Anyway, the solve() construction of Israel works nicely, giving, as I expected, the linear independence of the 12 matrices with which I work. I was not aware of the GenerateMatrix() command. It too verifies my expectation, giving rank 12. Acer, I'm sorry to say, particularly because it seems that you have invested quite some efforts, but I have not tested your suggestion.

Very nice, Robert Israel! Before posting my result on the zero determinants I rechecked to be absolutely sure that it was not me having made some silly error. Unlike you, obviously, I was not able to understand the cause of the zero determinants. However, your explanation tallies nicely with the fact, which I did find yesterday when I was checking, that the determinants all vanish whenever n exceeds 2 in

Matrix(n,n+1,(i,j) -> diff(x^i+(x+1)^j,x));

Very nice, Robert Israel! Before posting my result on the zero determinants I rechecked to be absolutely sure that it was not me having made some silly error. Unlike you, obviously, I was not able to understand the cause of the zero determinants. However, your explanation tallies nicely with the fact, which I did find yesterday when I was checking, that the determinants all vanish whenever n exceeds 2 in

Matrix(n,n+1,(i,j) -> diff(x^i+(x+1)^j,x));

Here are some code lines you might try:

with(LinearAlgebra):
theGenerator := Vector([
   alpha*(diff(diff(x^alpha+(x+1)^beta, x), x)),
   beta*(diff(diff(x^alpha+(x+1)^beta, x), x)),
   alpha*(diff(x^alpha+(x+1)^beta, x)),
   alpha^2*(diff(x^alpha+(x+1)^beta, x)),
   beta*(diff(x^alpha+(x+1)^beta, x)),
   beta^2*(diff(x^alpha+(x+1)^beta, x)),
   alpha*beta*(x^alpha+(x+1)^beta),
   alpha*beta^2*(x^alpha+(x+1)^beta),
   alpha^2*beta*(x^alpha+(x+1)^beta)
]):
theSubs := [[1,1],[1,2],[1,3],[1,4],[2,1],[2,2],[2,3],[2,4]]:
M := Matrix(8,9,
   (i,j) -> subs({alpha = theSubs[i][1],beta = theSubs[i][2]},theGenerator[j])
);
theDets := Vector(9,(i) -> Determinant(DeleteColumn(M,i)));
theFactors := map(factor,theDets);

Here are some code lines you might try:

with(LinearAlgebra):
theGenerator := Vector([
   alpha*(diff(diff(x^alpha+(x+1)^beta, x), x)),
   beta*(diff(diff(x^alpha+(x+1)^beta, x), x)),
   alpha*(diff(x^alpha+(x+1)^beta, x)),
   alpha^2*(diff(x^alpha+(x+1)^beta, x)),
   beta*(diff(x^alpha+(x+1)^beta, x)),
   beta^2*(diff(x^alpha+(x+1)^beta, x)),
   alpha*beta*(x^alpha+(x+1)^beta),
   alpha*beta^2*(x^alpha+(x+1)^beta),
   alpha^2*beta*(x^alpha+(x+1)^beta)
]):
theSubs := [[1,1],[1,2],[1,3],[1,4],[2,1],[2,2],[2,3],[2,4]]:
M := Matrix(8,9,
   (i,j) -> subs({alpha = theSubs[i][1],beta = theSubs[i][2]},theGenerator[j])
);
theDets := Vector(9,(i) -> Determinant(DeleteColumn(M,i)));
theFactors := map(factor,theDets);

Sure, I wouldn't mind that, of course. Having not done so in the original post to you, I would like here to acknowledge the help of acer from which I originally learned these powerful things myself; see post1 and post2.

Sure, I wouldn't mind that, of course. Having not done so in the original post to you, I would like here to acknowledge the help of acer from which I originally learned these powerful things myself; see post1 and post2.

Yesterday evening I tried to solve your problem concerning to how many digits two floats agree. I failed (gave up) on grounds of the following two issues:

• Conversion: As you have discovered yourself the conversion from float to string can introduce the unwanted exponential notation. Is there any way to tell Maple not to do so?
• Conventions: I might be mistaken (it being years ago that I learned about these issues), but do floats like 0.0045 and 0.0046, say, not only agree to 3 digits (the decimals), whereas 1.0045 and 1.0046, say, agree to 4 digits?

It seems your code does not always give the correct answer:

• For the numbers 0.0045 and 0.0046, above, it gives 2, not 3.
• For the numbers 1.0045 and 1.0046, above, it gives 5, not 4.
• For numbers 1. and 10., say, it gives 1, not 0.

Granted, the first list item above is due to the unwanted exponential notation when converting the floats to strings. But the last two items seem erroneous.

Yesterday evening I tried to solve your problem concerning to how many digits two floats agree. I failed (gave up) on grounds of the following two issues:

• Conversion: As you have discovered yourself the conversion from float to string can introduce the unwanted exponential notation. Is there any way to tell Maple not to do so?
• Conventions: I might be mistaken (it being years ago that I learned about these issues), but do floats like 0.0045 and 0.0046, say, not only agree to 3 digits (the decimals), whereas 1.0045 and 1.0046, say, agree to 4 digits?

It seems your code does not always give the correct answer:

• For the numbers 0.0045 and 0.0046, above, it gives 2, not 3.
• For the numbers 1.0045 and 1.0046, above, it gives 5, not 4.
• For numbers 1. and 10., say, it gives 1, not 0.

Granted, the first list item above is due to the unwanted exponential notation when converting the floats to strings. But the last two items seem erroneous.

Actually, I believe that the shortcuts work for any Windows application, just as do Ctrl+C (for copy), Ctrl+V (for paste), Ctrl+X (for cut), etc.

I use Ctrl + Home to get to the top of a webpage, and Ctrl + End to get to the bottom (I'm using Explorer on a PC running Win XP).