It seems that when the source and destination of mpz_nthroot are the same the result is _sometimes_ incorrect.
I'm linking with a static lib build of MPIR based on a slightly old February 2014 commit (94c011b8a3b096f91dd2eb9fbfaae53d6de045ee), which I built for Windows x64 with MS VC2012 and got all the tests to pass. (I have not been able to build the latest commit for some time presumably because the Windows build updates have not been pulled from Gladman's fork). Here is my test code (forgive the naive C): mpz_t a, cube, r; char c[100]; mpz_init_set_str(a, "8984948281360922385394772450147012613851354303", 10); mpz_get_str(c, 10, a); cout << "a = " << c << endl; mpz_init(cube); mpz_mul(cube, a, a); mpz_mul(cube, cube, a); mpz_init_set(r, cube); mpz_nthroot(r, r, 3); mpz_get_str(c, 10, r); cout << "nthroot(r,r,3) returns " << c << endl; mpz_nthroot(r, cube, 3); mpz_get_str(c, 10, r); cout << "nthroot(r,c,3) returns " << c << endl; This produces the following output: a = 8984948281360922385394772450147012613851354303 nthroot(r,r,3) returns 8984948281360922385394772450147012613851354302 nthroot(r,c,3) returns 8984948281360922385394772450147012613851354303 The result is 1 too small when source and result are the same. This does NOT happen with mpz_root(r, r, 3) or mpz_rootrem(r, rem, r, 3) for this particular value of a. I have no idea what exactly about this random value causes this; it does calculate correctly, for example, with a=3. Is this an exception to the general rule that source and destination can be the same as long as one of them is SRCPTR? If so I'd like to know what other exceptions exist. -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
