Upgrading your Java won't help an application from the fact of being implemented in Java in the first place.

And an OS Java upgrade won't help an application that gets bundled with (and is configured to use only) its very own Java. That's particularly true if the application has to rely on that particular bundled jvm in order to function properly, because Java forward/backward compatibility is a no-show.

Upgrading your Java also won't help an application which has been suboptimally implemented in Java.

Upgrading your Java won't help an application from the fact of being implemented in Java in the first place.

And an OS Java upgrade won't help an application that gets bundled with (and is configured to use only) its very own Java. That's particularly true if the application has to rely on that particular bundled jvm in order to function properly, because Java forward/backward compatibility is a no-show.

Upgrading your Java also won't help an application which has been suboptimally implemented in Java.

@Robert Israel Thanks.

I notice that A008918 is described as being generated (simply via multiplication by 2, and as 1-1) from A001232 which are the positive integers which are nine times themselves reversed. And the notes for the latter mention two things:

1) a(n)=11*(10^n -1)=11*A002283(n), for n>1 as a generator. (But that does not produce the whole of A001232, so isn't interesting.)

2) A claim (attributed to David W. Wilson) that all members of A001232 are 99*m where m has only digits of 1 and 0 in base 10 representation, with m palindromic, and m with no singleton 1's or 0's. And then an inference on how many k-digit elements there must be, on account of that. The inference suggests that these qualities characterize all such numbers. But the claim is worded more weakly, not implying 1-1. Maybe an oversight.

And so it turns out that there may be many more (fibonacci(14)=377?) 30-digits solutions than the eight I mentioned. Eg, 2*99*1100000000011111100000000011

If 2) is right (ie. if D.Wilson's Theorem in the notes of A001232 is correct, even in weak form) then there must be better approaches for generating A031877 then its (2010. purely exhaustive search) Mma code.

Apparently Hardy found this material devoid of appeal.

@Robert Israel Thanks.

I notice that A008918 is described as being generated (simply via multiplication by 2, and as 1-1) from A001232 which are the positive integers which are nine times themselves reversed. And the notes for the latter mention two things:

1) a(n)=11*(10^n -1)=11*A002283(n), for n>1 as a generator. (But that does not produce the whole of A001232, so isn't interesting.)

2) A claim (attributed to David W. Wilson) that all members of A001232 are 99*m where m has only digits of 1 and 0 in base 10 representation, with m palindromic, and m with no singleton 1's or 0's. And then an inference on how many k-digit elements there must be, on account of that. The inference suggests that these qualities characterize all such numbers. But the claim is worded more weakly, not implying 1-1. Maybe an oversight.

And so it turns out that there may be many more (fibonacci(14)=377?) 30-digits solutions than the eight I mentioned. Eg, 2*99*1100000000011111100000000011

If 2) is right (ie. if D.Wilson's Theorem in the notes of A001232 is correct, even in weak form) then there must be better approaches for generating A031877 then its (2010. purely exhaustive search) Mma code.

Apparently Hardy found this material devoid of appeal.

@herclau The selection criterion was that it produced the right answer. The methodology was more by staring than by programming. (Sorry, if that doesn't help much.)

@herclau The selection criterion was that it produced the right answer. The methodology was more by staring than by programming. (Sorry, if that doesn't help much.)

@Will They are once again not working (as of some time during 11/11/2010).

@herclau You are fsolving over only a subset of `N` the equations. Depending on which 12 equations of N you chose, the result from `fsolve` may 1) not satisfy the remaining 6 equations of N, and 2) vary from the `solve` result. (The subsystem may be underdetermined.)

> fsolve({seq(N[ii], `in`(ii, [1, 17, 18, 4, 5, 6, 7, 8, 9, 10, 16, 12]))},
>          {Zeta1, Zeta2, Zeta3, Zeta4, Zeta5, Zeta6,
>           lambda1, lambda2, lambda3, R0 = 10.0, a = -0.1e-3, b = 0.1e-3});

{R0 = 10.09705605, a = -0.0002187538890, b = -0.00002570166036, 

  Zeta1 = 10.09705600, Zeta2 = 0.01000000000, 

  Zeta3 = 19.10950601, Zeta4 = 231.9280000, Zeta5 = 25.93439900, 

  Zeta6 = 419.5270000, lambda1 = 0., lambda2 = 0., lambda3 = 0.}

> simplify(fnormal(eval(N, %), 9));

                           {0. = 0.}

@herclau You are fsolving over only a subset of `N` the equations. Depending on which 12 equations of N you chose, the result from `fsolve` may 1) not satisfy the remaining 6 equations of N, and 2) vary from the `solve` result. (The subsystem may be underdetermined.)

> fsolve({seq(N[ii], `in`(ii, [1, 17, 18, 4, 5, 6, 7, 8, 9, 10, 16, 12]))},
>          {Zeta1, Zeta2, Zeta3, Zeta4, Zeta5, Zeta6,
>           lambda1, lambda2, lambda3, R0 = 10.0, a = -0.1e-3, b = 0.1e-3});

{R0 = 10.09705605, a = -0.0002187538890, b = -0.00002570166036, 

  Zeta1 = 10.09705600, Zeta2 = 0.01000000000, 

  Zeta3 = 19.10950601, Zeta4 = 231.9280000, Zeta5 = 25.93439900, 

  Zeta6 = 419.5270000, lambda1 = 0., lambda2 = 0., lambda3 = 0.}

> simplify(fnormal(eval(N, %), 9));

                           {0. = 0.}

@PatrickT Sorry, Patrick. I slipped up with a `p` when I meant a `q`. (I tested something, but obviously not what I pasted here before. What I posted before was only ok for the square B examples.)

KPKP:=proc(A,B)
local m,n,p,q,i,j,res,CC,
      offi_l,offi_u,offj_u,offj_l;
  m,n:=op(1,A);
  p,q:=op(1,B);
  res:=Matrix(m*p,n*q);
  CC:=Matrix(p,q);
  for i from 1 to m do
    offi_l,offi_u:=p*(i-1)+1,p*i;
    for j from 1 to n do
      offj_l,offj_u:=q*(j-1)+1,q*j;
      ArrayTools:-Copy(p*q,B,0,1,CC,0,1);
      map2['inplace'](`*`,A[i,j],CC);
      res[offi_l..offi_u,offj_l..offj_u]:=CC;
    end do;
  end do;
  res;
end proc:

For amusement, while not as fast as compiled C (Maple's `Compiler`, or some dedicated external routine), here is a slight modification of KPKP that uses evalhf. It keeps your largest (float) example's result down to the minimal 800MB that LinearAlgebra:-KroneckerProduct also produces. (No wonder those other codes get an `object too large` error when the result object is not datatype=float[8]!). Of course, this version does not work with symbols.

KPKP8:=proc(inA,inB)
local m,n,p,q,i,j,res,CC,A,B,
      offi_l,offi_u,offj_u,offj_l;
  A:=Matrix(inA,datatype=float[8]);
  B:=Matrix(inB,datatype=float[8]);
  m,n:=op(1,A);
  p,q:=op(1,B);
  res:=Matrix(m*p,n*q,datatype=float[8]);
  CC:=Matrix(p,q,datatype=float[8]);
  for i from 1 to m do
    offi_l,offi_u:=p*(i-1)+1,p*i;
    for j from 1 to n do
      offj_l,offj_u:=q*(j-1)+1,q*j;
      ArrayTools:-Copy(p*q,B,0,1,CC,0,1);
      map2[evalhf,'inplace'](`*`,A[i,j],CC);
      res[offi_l..offi_u,offj_l..offj_u]:=CC;
    end do;
  end do;
  res;
end proc:

It would be not too hard to combine together an "exact" routine and a "float" routine (such as this pair above), so that whichever is appropriate for the data at hand is what gets dispatched. That's what LinearAlgebra:-LA_Main:-KroneckerProduct and many other LinearAlgebra routines do internally (except that their specialized "float" routines often call externally).

The guts of LinearAlgebra:-KroneckerProduct looks like KP below (exact case):

KP := proc(A::Matrix,B::Matrix)
local m,n,q,p,result,AA,AB,s,i,j,k,l,offi,offj,offl;
m, n := op(1,A);
p, q := op(1,B);
result := Array(0 .. m*p-1,0 .. n*q-1);
AA := ArrayTools:-Alias(A,[0 .. m-1, 0 .. n-1]);
AB := ArrayTools:-Alias(B,[0 .. p-1, 0 .. q-1]);
for j from 0 to n-1 do
   offj := q*j;
   for i from 0 to m-1 do
      offi := i*p;
      s := AA[i,j];
      for l from 0 to q-1 do
         offl := offj+l;
         for k from 0 to p-1 do
            result[offi+k,offl] := s*AB[k,l]
         end do
      end do
   end do
end do;
rtable_options(result,'subtype'=Matrix);
result;
end proc:

My humble submission is this:

KPKP:=proc(A,B)
local m,n,p,q,i,j,res,CC,
      offi_l,offi_u,offj_u,offj_l;
  m,n:=op(1,A);
  p,q:=op(1,B);
  res:=Matrix(m*p,n*q);
  CC:=Matrix(p,q);
  for i from 1 to m do
    offi_l,offi_u:=p*(i-1)+1,p*i;
    for j from 1 to n do
      offj_l,offj_u:=q*(j-1)+1,q*j;
      ArrayTools:-Copy(p*q,B,0,1,CC,0,1);
      map2['inplace'](`*`,A[i,j],CC);
      res[offi_l..offi_u,offj_l..offj_u]:=CC;
    end do;
  end do;
  res;
end proc:

[corrected p*j to q*j on line 8 of body of KPKP]

The key thing, in either Joe's or my suggestions, is that the sorting can be forced to get done according to numeric magnitude. Joe and I both showed that `evalf` may be used for that.

(I also showed that `is` may be used, although for comparison of exact quantities `is` itself may often utilize `evalf` internally.)

The thing to notice is that `sort` does not do a numeric magnitude comparison by default for exact radicals.

It's an understandable expectation, that `sort` would do magnitude comparison of real-valued objects all of type `constant`. But `sort` doesn't operate like that for all kinds of exact (real) constant objects.

As the help page ?sort explains, sorting by numerical magnitude is the default for lists of objects all of type `numeric`. The "gotcha" is that not all objects of type `realcons` are of type `numeric`.

> type(sqrt(2),And(constant,Non(imaginary)));
                              true
> type(sqrt(2),realcons);
                              true
> type(sqrt(2),numeric);
                             false

The key thing, in either Joe's or my suggestions, is that the sorting can be forced to get done according to numeric magnitude. Joe and I both showed that `evalf` may be used for that.

(I also showed that `is` may be used, although for comparison of exact quantities `is` itself may often utilize `evalf` internally.)

The thing to notice is that `sort` does not do a numeric magnitude comparison by default for exact radicals.

It's an understandable expectation, that `sort` would do magnitude comparison of real-valued objects all of type `constant`. But `sort` doesn't operate like that for all kinds of exact (real) constant objects.

As the help page ?sort explains, sorting by numerical magnitude is the default for lists of objects all of type `numeric`. The "gotcha" is that not all objects of type `realcons` are of type `numeric`.

> type(sqrt(2),And(constant,Non(imaginary)));
                              true
> type(sqrt(2),realcons);
                              true
> type(sqrt(2),numeric);
                             false

Using fsolve and its avoid option does not get other result, using the same full range of x=10^5..10^10. (If it did, the Student:-Calculus1:-Roots would find both since that's what it uses under the hood).

See rescaling Answer.

> restart:

> expr:=2.062648062*10^(-8)*sqrt(8.607207774*10^11*x+
>       2.976566118*10^18-5.312602135*10^9*x*ln(x))
>       -0.1721820163e-1*sqrt(x)-30. = 0:

> rng:=10^5..10^10:

> sol1:=fsolve(expr, x = rng);
                                      9
                        2.407472420 10 

> fsolve(expr, x=rng, avoid={x=sol1});

      /              -8 /              11                   18
fsolve|2.062648062 10   \8.607207774 10   x + 2.976566118 10  
      \                                                       

                   9        \                        (1/2)         
   - 5.312602135 10  x ln(x)/^(1/2) - 0.01721820163 x      - 30. = 

                                        /                  9\ \
  0, x, 100000 .. 10000000000, avoid = { x = 2.407472420 10  }|
                                        \                   / /

The problem appears to be that `fsolve` bases its guesses on random starting points in the stated range. But it (likely) chooses those uniformly (not after taking log[10]) and so most or all of the initial starting points are in too large like (on the scale of 10^9..10^10).

Using fsolve and its avoid option does not get other result, using the same full range of x=10^5..10^10. (If it did, the Student:-Calculus1:-Roots would find both since that's what it uses under the hood).

See rescaling Answer.

> restart:

> expr:=2.062648062*10^(-8)*sqrt(8.607207774*10^11*x+
>       2.976566118*10^18-5.312602135*10^9*x*ln(x))
>       -0.1721820163e-1*sqrt(x)-30. = 0:

> rng:=10^5..10^10:

> sol1:=fsolve(expr, x = rng);
                                      9
                        2.407472420 10 

> fsolve(expr, x=rng, avoid={x=sol1});

      /              -8 /              11                   18
fsolve|2.062648062 10   \8.607207774 10   x + 2.976566118 10  
      \                                                       

                   9        \                        (1/2)         
   - 5.312602135 10  x ln(x)/^(1/2) - 0.01721820163 x      - 30. = 

                                        /                  9\ \
  0, x, 100000 .. 10000000000, avoid = { x = 2.407472420 10  }|
                                        \                   / /

The problem appears to be that `fsolve` bases its guesses on random starting points in the stated range. But it (likely) chooses those uniformly (not after taking log[10]) and so most or all of the initial starting points are in too large like (on the scale of 10^9..10^10).