hoyeung1 is very close to making sense. You just need to sepcify limits on the integral. But the integrand with x! in hoyeung2 looks very fishy.

.s

@asa12 you cannot expect us or Maple to guess what equation you want to solve.

.s

How is unkown supposed to depend on n?

Best,

Soren

Ok, I am a bit wiser now. First, I apologize to Carl for not understanding why he was discussing the priorities of mod and +. Since I knew the program worked before compiling, I did not see the relevance of that comment, but I must have been cutting and pasting from a version of the program made while desperately getting something that worked.

Here is the code from my book, which works uncompiled:

othergoldbach:=proc(sieve::Array(1..10000,datatype=integer[4]))
   local i,j,M; 
   M:=10000;
   for i from 1 to M do 
      if(sieve[i] mod 2=0) then 
         for j from 1 to iquo(M-i,2*i+1) do 
            sieve[i+j*(2*i+1)]:=
               2*iquo(sieve[i+j*(2*i+1)],2)+1;
         end do; 
         for j from 1 to floor(sqrt(M-i)) do 
            sieve[i+j*j]:=(sieve[i+j*j] mod 2)+2;
         end do;
      else 
         if(sieve[i]<2) then 
            printf("%d is a counterexample\n",2*i+1); 
         end if; 
      end if; 
   end do; 
end proc;

Fortunately I got the priorities right there. I changed to irem as suggested and compared the two c-files. The essential difference is

<       sieve.data[ mrt_aoff_F_1( ___k___, 1, 10000, mrt_iadd( ___k___, i, mrt_imul( ___k___, j, j ) ) ) ] = MRT_ICHECK32( mrt_iadd( ___k___, mrt_irem( ___k___, sieve.data[ mrt_aoff_F_1( ___k___, 1, 10000, mrt_iadd( ___k___, i, mrt_imul( ___k___, j, j ) ) ) ], 2 ), 2 ) );

---

>       sieve.data[ mrt_aoff_F_1( ___k___, 1, 10000, mrt_iadd( ___k___, i, mrt_imul( ___k___, j, j ) ) ) ] = MRT_ICHECK32( mrt_iadd( ___k___, mrt_mod( ___k___, sieve.data[ mrt_aoff_F_1( ___k___, 1, 10000, mrt_modadd( i, mrt_modmul( j, j, 2 ), 2 ) ) ], 2 ), 2 ) );

where indeed there is something fishy going on in the indexing of sieve.data corresponding to sieve[i+j*j] in the MOD version but not in the IREM version. It looks like it also tries to compute the index in Z/2.

I would suggest that Maplesoft looks at this, but I am also ready to leave it at "avoid mod if you want to compile". Unfortunately it is too late to change the book at this time, but I will put a discussion of this on the home page.

Thanks again to both of you.

Best,

Soren

I see now the suggestion to inspect the C-file, thanks, I did not know that trick. I have it and will inspect and report back.

Thanks again,

best,

Soren

@Carl Love, replacing mod by irem solves the problem - thanks a lot! Now I just wonder why breaking the mod computation into two lines with a dummy variable ALSO solves the problem?

Best,

Soren

@tomleslie, to answer the "why": I am the author of a forthcoming textbook published with Cambridge University Press where this example is given. Since it is unknown if more counterexamples exist, a large-scale search might be relevant, and thus the speedup from compiling would be valuable. But we mainly give the example for instructional purposes.

Your clarification of my problem is exactly on the mark, and I would love to understand how this can happen. 

Best,

Soren

Dear both,

Thanks a lot - I guess what you are saying is that Maple is reverting to some sort of heuristic which is then badly fooled by my little trick with an irrational number just below 20? It seems like a weakness that Maple does so, as indeed the original sequence converges pretty quickly and the tail is easily bounded as noted by vv.

Best,

Soren