eclib test suite fails when compiled with clang due to tolerance problems

[kiwifb]

Testing comptest...
5c5
< AGM((3.125,4.25),(1,0)) = (2.07831617217326684,1.5633615899065958201)
---
> AGM((3.125,4.25),(1,0)) = (2.07831617217326684,1.56336158990659582)
14c14
< whose cube is    (2.9999999999999999998,3.9999999999999999999)
---
> whose cube is    (2.9999999999999999999,4)
16c16
< whose cube is    (2.9999999999999999997,3.9999999999999999999)
---
> whose cube is    (2.9999999999999999996,3.9999999999999999998)

I actually don't know if there are other failures since it stops right after this one.

[JohnCremona]

This sort of thing is very tedious. It obviously does not matter at all but shows that the testing framework based on exact text comparison of output is not so useful. I would appreciate a constructive suggestion, other than not allowing any floating point output in test programs. Unlike Sage I (eclib) never guarantee precision.

On 22 April 2017 at 06:07, François Bissey notifications@github.com wrote:

Testing comptest... 5c5 < AGM((3.125,4.25),(1,0)) = (2.07831617217326684,1.5633615899065958201)

AGM((3.125,4.25),(1,0)) = (2.07831617217326684,1.56336158990659582) 14c14 < whose cube is (2.9999999999999999998,3.9999999999999999999)

whose cube is (2.9999999999999999999,4) 16c16 < whose cube is (2.9999999999999999997,3.9999999999999999999)

whose cube is (2.9999999999999999996,3.9999999999999999998)

I actually don't know if there are other failures since it stops right after this one.

Perhaps "make -k check" would reveal more.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/JohnCremona/eclib/issues/19, or mute the thread https://github.com/notifications/unsubscribe-auth/AC9N6b7ofjznDgr7ZHqaHPODAfiOww_Bks5ryYsFgaJpZM4NE-eh .

[kiwifb]

sage shouldn't and in most case cannot guarantee precision. In most cases it is even absurd. Looking for more failures now. Putting something in place for this is not trivial and I'd rather it not be like gsl where it is extremely difficult to find out where is the tolerance of which test.

[kiwifb]

OK there are more errors and some may be more worrying or more difficult to deal with than just precision

Testing telog...
59,61c59,61
< Periods: [w_1,w_2] = [(-0.51317082433770156405898300169308452073251780098017e-48,-0.63277902985143330237168013012161275230207585428624),(2.0131613909534741204308876218764326959565176646346,-0.31638951492571665118584006506080637615103792714312)]
< tau       = (0.49999999999999999999999999999999999999999999999742,3.1814603455271474113187811974948516017119213527377) (abs(tau)=3.220510818202869536114214880382970192586945735383)
< w_R = (4.0263227819069482408617752437528653919130353292697,0) w_IR = (2.0131613909534741204308876218764326959565176646351,0.31638951492571665118584006506080637615103792714312)
---
> Periods: [w_1,w_2] = [(0,0.6327790298514333023716801301216127523020758542864),(-2.0131613909534741204308876218764326959565176646351,-0.3163895149257166511858400650608063761510379271432)]
> tau       = (-0.5,3.1814603455271474113187811974948516017119213527374) (abs(tau)=3.2205108182028695361142148803829701925869457353831)
> w_R = (4.0263227819069482408617752437528653919130353292703,0) w_IR = (2.0131613909534741204308876218764326959565176646351,0.3163895149257166511858400650608063761510379271432)
65c65
< Elliptic log of P is (2.1525156669616024162853317818644956119079357950699,0)
---
> Elliptic log of P is (2.1525156669616024162853317818644956119079357950702,0)
68c68
< Elliptic log of P is (3.4017204102584996326696274231234087985780021511049,0)
---
> Elliptic log of P is (3.4017204102584996326696274231234087985780021513184,0)

worry:

Testing tmrank...
23,27c23
< Curve [0,0,0,-532,-4374] :    
< 
< !!! Fatal error in mwrank: n3 =6 not a power of 2
< This is a bug: please report!
< Failed to compute rank

more worry

Testing tmanin...
/bin/sh: line 1: 15437 Segmentation fault      ./${prog} < ./in_ntl/${prog}.in > ${prog}.testout 2> /dev/null
make[4]: *** [Makefile:1320: check_g0n] Error 139

and

Testing nfhpcurve...
/bin/sh: line 1: 17213 Segmentation fault      ./${prog} < ./in/${prog}.in > ${prog}.testout 2> /dev/null
make[4]: *** [Makefile:963: check_g0n] Error 139

really the same apparently. Lots of warnings saying you are using c++11 features, probably orthogonal and may not help but I think you may just want to switch eclib to use c++11.

[JohnCremona]

I am now compiling eclib 2-170711 with clang-3.8...and had not a single error or warning in either "make" or "make check". All I did was "make clean" then export CC=clang export CXX=clang++ then configure and make. The compilation and linking commands certainly used clang.

[kiwifb]

It may fail if ntl is not compiled with clang++ as well.

[JohnCremona]

(Sorry to edit my comment after you replied -- I had forgotten to press the "update" button.)

[kiwifb]

Hum... what kind of clang install do you have? Do you know if it uses clang's libcxx by default or gcc's libstdc++?

[JohnCremona]

Here's a sample from a link stage:

/bin/bash ../libtool --tag=CXX --mode=link clang++ -std=gnu++11 -g -O2 -o tnfd tnfd.o ../libsrc/libec.la -lflint -lpari -lntl
libtool: link: clang++ -std=gnu++11 -g -O2 -o .libs/tnfd tnfd.o ../libsrc/.libs/libec.so -lflint -lpari -lntl

Is it the gnu++-11 which you think makes the difference?

[kiwifb]

No, it is more subtle than that. It depends on how clang has been built. Can you do ldd -r on one of the executable or libraries produced?

[JohnCremona]

I installed clang on my laptop (ubuntu 16.04) which I don't have with me today but will try later. I did not rebuild any of the dependencies of eclib, which were built using gcc. I was a little afraid that installing clang would break things by making itself the default, which is one reason I did that on my laptop only, as the other machines I could install it on are used rather a lot by others. But I will now try on one of those now (also ubuntu 16.04).

[JohnCremona]

Building on the other machine -- compiler warnings about use of register in header files from libpari. I did not notice those on my laptop but perhaps they went past without my noticing. Anyway, only warnings. Also after libtool: link: ar cru .libs/libec.a (...) we see ar: u' modifier ignored sinceD' is the default (see `U')

[JohnCremona]

$ ldd -r bin/mwrank linux-vdso.so.1 => (0x00007ffd889fb000) libec.so.3 => /home/jec/eclib/lib/libec.so.3 (0x00007f9cf2683000) libflint.so.13 => /usr/local/lib/libflint.so.13 (0x00007f9cf1fa2000) libpari-gmp.so.5 => /usr/local/lib/libpari-gmp.so.5 (0x00007f9cf1604000) libntl.so.31 => /usr/local/lib/libntl.so.31 (0x00007f9cf11e2000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f9cf0e60000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f9cf0b56000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f9cf0940000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9cf0576000) libmpfr.so.4 => /usr/local/lib/libmpfr.so.4 (0x00007f9cf0313000) libgmp.so.16 => /usr/local/lib/libgmp.so.16 (0x00007f9cf009b000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f9cefe7e000) /lib64/ld-linux-x86-64.so.2 (0x0000557f1b425000) libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f9cefbfd000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f9cef9f9000)

[kiwifb]

All right, your installed clang is using g++'s C++ standard library. This is why you don't see the problem. You would need to use llvm/clang version of the C++ standard library (libcxx) to spot those problems. And once you do use libcxx you cannot mix stuff compiled with g++ with stuff compiled with clang++.

I am not sure how to set all that up on ubuntu. But libcxx is the default on OS X.

[JohnCremona]

It looks as if the ubuntu package libc++-helpers is what I need -- I did not install that originally. The brief description is "libc++ is a new implementation of the C++ standard library, targeting C++11." I am installing that and will reconfigure and rebuild to see what changes,

[JohnCremona]

It does not use the new libc++ library. It seems from http://libcxx.llvm.org/docs/UsingLibcxx.html that there is no easy way to make this happen. I tried CXXFLAGS='-std=c++11 -stdlib=libc++ -nostdinc++ -nodefaultlibs' ./configure --with-flint --prefix=/$PWD but it complains about not being able to compile NTL. If sorting this out requires building all the dependencies again with clang then I am not sure that I can be bothered. I would have to install them all in a separate place from the system-wide ones.

[kiwifb]

I am afraid the rebuilding of C++ dependencies like ntl is necessary.

[JohnCremona]

You are right of course. It leaves me without any selfish reason for doing this time-consuming task...but I don't promise not to!

[isuruf]

@JohnCremona, you need libc++-dev for the libc++ headers.

[JohnCremona]

@isuruf thanks I have that. I have been building the dependencies with clang so should have a better report soon.

[JohnCremona]

All the dependencies are built with clang, with no problems (make check passed in all cases). Now I go back to eclib, do make clean and then CXXFLAGS='-std=c++11 -stdlib=libc++ -nostdinc++ -nodefaultlibs' ./configure --with-flint=$HOME --with-ntl=$HOME --with-gmp=$HOME --prefix=$HOME produces the same problem as before, namely checking NTL/ZZ.h usability... no checking NTL/ZZ.h presence... yes configure: WARNING: NTL/ZZ.h: present but cannot be compiled configure: WARNING: NTL/ZZ.h: check for missing prerequisite headers? configure: WARNING: NTL/ZZ.h: see the Autoconf documentation configure: WARNING: NTL/ZZ.h: section "Present But Cannot Be Compiled" configure: WARNING: NTL/ZZ.h: proceeding with the compiler's result configure: WARNING: ## ------------------------------------- ## configure: WARNING: ## Report this to john.cremona@gmail.com ## configure: WARNING: ## ------------------------------------- ## checking for NTL/ZZ.h... no configure: error: Could not find NTL, you might want to use --with-ntl= to point to its location

Suggestions? All the newly built dependencies were installed with prefix=$HOME and certainly ~/lib and ~/include contain what I would expect.

[isuruf]

Can you try without -nostdinc++ -nodefaultlibs ? If that fails, can you post config.log?

[JohnCremona]

That's no better. I can post the whole log if you need but the relevant part seems to be configure:19108: checking NTL/ZZ.h usability configure:19108: clang++ -c -std=c++11 -stdlib=libc++ -I/home/jec/include conftest.cpp >&5 In file included from conftest.cpp:57: In file included from /home/jec/include/NTL/ZZ.h:19: In file included from /home/jec/include/NTL/tools.h:13: In file included from /usr/include/c++/v1/iostream:38: In file included from /usr/include/c++/v1/ios:216: In file included from /usr/include/c++/v1/locale:15: /usr/include/c++/v1/string:1938:44: error: 'basic_string<_CharT, _Traits, _Allocator>' is missing exception specification 'noexcept(is_nothrow_copy_constructible::value)' basic_string<_CharT, _Traits, _Allocator>::basic_string(const allocator_type& a) ^ /usr/include/c++/v1/string:1326:40: note: previous declaration is here _LIBCPP_INLINE_VISIBILITY explicit basic_string(const allocator_type& __a) ^ 1 error generated. configure:19108: $? = 1 configure: failed program was:

[kiwifb]

Was ntl compiled with all the same flags, including -std=c++11?

[JohnCremona]

@kiwifb I don't think so. I could not find any config.log so I ran configure again and am rebuilding. The NTL configure line is now

./configure NTL_GMP_LIP=on SHARED=on CXX=clang++ CXXFLAGS='-std=c++11 -stdlib=libc++' DEF_PREFIX=$HOME NTL_THREADS=on TUNE=generic

but the make fails. The first failure is

./libtool-build/libtool --tag=CXX --mode=compile clang++ -I../include -I. -std=c++11 -pthread -march=native -std=c++11 -stdlib=libc++ -c FFT.cpp libtool: compile: clang++ -I../include -I. -std=c++11 -pthread -march=native -std=c++11 -stdlib=libc++ -c FFT.cpp -fPIC -DPIC -o .libs/FFT.o In file included from FFT.cpp:2: In file included from ../include/NTL/FFT.h:5: In file included from ../include/NTL/ZZ.h:19: In file included from ../include/NTL/tools.h:13: In file included from /usr/include/c++/v1/iostream:38: In file included from /usr/include/c++/v1/ios:216: In file included from /usr/include/c++/v1/locale:15: /usr/include/c++/v1/string:1938:44: error: 'basic_string<_CharT, _Traits, _Allocator>' is missing exception specification 'noexcept(is_nothrow_copy_constructible::value)' basic_string<_CharT, _Traits, _Allocator>::basic_string(const allocator_type& a) ^ /usr/include/c++/v1/string:1326:40: note: previous declaration is here _LIBCPP_INLINE_VISIBILITY explicit basic_string(const allocator_type& __a) ^ 1 error generated.

[kiwifb]

Right.... Very similar to the thing you get from eclib in fact. I suspect that's a bug in your installed libcxx*. Note that with clang 3.8 on OS X, 3.9.1 and 4.0.1 on linux I get a segfault in nfhpcurve somewhere in iostream (IIRC) too, so there is something fishy going on around there.

[isuruf]

Looks like https://bugs.launchpad.net/ubuntu/+source/libc++/+bug/1610168. I've managed to compile ntl using conda's clang and libc++ (4.0) on Ubuntu 16.04. It fails in eclib, but builds fine with the following patch,

diff --git a/libsrc/eclib/interface.h b/libsrc/eclib/interface.h
index b8eff26..127b48e 100644
--- a/libsrc/eclib/interface.h
+++ b/libsrc/eclib/interface.h
@@ -161,8 +161,7 @@ inline int is_approx_zero(const RR& x)
 }
 } // namespace NTL
 #ifdef _LIBCPP_VERSION
-namespace std {
-inline namespace __1 {
+namespace NTL {
 inline bool isinf(const RR& z) {
   return false;
 }
@@ -183,7 +182,6 @@ inline RR fmax(const RR& x, const RR& y)
   return x < y ? y : x;
 }
 }
-}
 #endif

 #include <complex>

Note that because of ADL, you don't need to declare in std namespace and declaring in NTL namespace is fine.

When I run make check it segfaults in comptest

[kiwifb]

It is almost the same as what Dima reported at https://trac.sagemath.org/ticket/12426#comment:316 but he didn't open an issue for that I think. It had zero impact on me on OS X or Gentoo [build but nfhpcurve segfault during self test]. I guess I could try your variant.

[kiwifb]

For the record this is the backtrace of nfhpcurve when it segfault

#0  0x00007f61ac2377d6 in strlen () from /lib64/libc.so.6
#1  0x00007f61ae642f90 in std::__1::char_traits<char>::length (__s=0x0) at /usr/include/c++/v1/__string:215
#2  std::__1::operator<< <std::__1::char_traits<char> > (__os=..., __str=0x0) at /usr/include/c++/v1/ostream:866
#3  single_curve_filename (N=11) at oldforms.cc:64
#4  0x0000000000403a1d in main () at nfhpcurve.cc:77

[JohnCremona]

I can tell you what is happening on line 84 of oldforms.cc: I read the value of environment variable TCURVES which if nonempty should be a directory name (relative to the working directory), otherwise the default name used is "tcurves". But in Makefile.am (both in progs and tests directories) the environment variable set is TCURVE_DIR not TCURVES. So when the code tests the value of TCURVES it will be empty and it will use the default. However the Makefile does create the directory called tcurves so although there is a mix-up which I should fix, it should not cause a problem when running the tests?

[JohnCremona]

That thing in interface.h was a contribution from someone called Keno (see https://github.com/JohnCremona/eclib/commit/6ad4e875f26798fb260e6b988400c3b3bdc4be53) which I accepted since it did not break things for me. Feel free to correct that.

[kiwifb]

Yes the directory tcurves exists in the tests folder. But as a physicist I am inclined to check empirical evidence. So if you provide what you think should be a fix I'll try it.

[JohnCremona]

Simplest is to change TCURVES to TCURVES_DIR on line 64 of oldforms.cc (and also in the comments on lines 56, 57). Otherwise it would mean changing several places in two Makefile.am files and a lot of reconfiguring etc.

[kiwifb]

OK I got a new failure in nhpcurve this time at line 49 of oldforms.cc where it looks for ECDB. I think there is a pattern of mishandling of getenv. It is supposed to return a pointer to a char and when the environment variable doesn't exist it return the NULL pointer. Code compiled with clang++ seems to object when s << is feed the NULL pointer on the right.

[kiwifb]

So, up to coding style I am suggesting this for oldforms.cc

string ecdb_filename(long N)
{
  long a = N/10000; // rounded down
  stringstream s;
  if (getenv("ECDB") != NULL) {
      s << getenv("ECDB");
  } else {
      s<<"./curves";
  }
  //  cout << "Filename for curves of conductor " << d << " is " << s.str() << endl;
  return s.str();
}

// returns a filename of the form "$TCURVE_DIR/curves.N" where N is a
// conductor.  The environment variable TCURVE_DIR should be set to point
// to a suitable ubdirectory, for example one where curves are output
// by progs/nfhpcurve; if it is not set then a subdirectory ./tcurves
// of the current directory is used.
string single_curve_filename(long N)
{
  stringstream s;
  if (getenv("TCURVE_DIR") != NULL) {
      s << getenv("TCURVE_DIR");
  } else {
      s<<"./tcurves";
  }
  s << "/curves." << N;
  //  cout << "Filename for curves of conductor " << N << " is " << s.str() << endl;
  return s.str();
}

I don't get segfault anymore with this.

[kiwifb]

And the list of errors in make -k check is now

Testing comptest...
5c5
< AGM((3.125,4.25),(1,0)) = (2.07831617217326684,1.5633615899065958201)
---
> AGM((3.125,4.25),(1,0)) = (2.07831617217326684,1.56336158990659582)
14c14
< whose cube is    (2.9999999999999999998,3.9999999999999999999)
---
> whose cube is    (2.9999999999999999999,4)
16c16
< whose cube is    (2.9999999999999999997,3.9999999999999999999)
---
> whose cube is    (2.9999999999999999996,3.9999999999999999998)
make[2]: *** [Makefile:1289: check_procs] Error 1

Testing telog...
59,61c59,61
< Periods: [w_1,w_2] = [(-0.51317082433770156405898300169308452073251780098017e-48,-0.63277902985143330237168013012161275230207585428624),(2.0131613909534741204308876218764326959565176646346,-0.31638951492571665118584006506080637615103792714312)]
< tau       = (0.49999999999999999999999999999999999999999999999742,3.1814603455271474113187811974948516017119213527377) (abs(tau)=3.220510818202869536114214880382970192586945735383)
< w_R = (4.0263227819069482408617752437528653919130353292697,0) w_IR = (2.0131613909534741204308876218764326959565176646351,0.31638951492571665118584006506080637615103792714312)
---
> Periods: [w_1,w_2] = [(0,0.6327790298514333023716801301216127523020758542864),(-2.0131613909534741204308876218764326959565176646351,-0.3163895149257166511858400650608063761510379271432)]
> tau       = (-0.5,3.1814603455271474113187811974948516017119213527374) (abs(tau)=3.2205108182028695361142148803829701925869457353831)
> w_R = (4.0263227819069482408617752437528653919130353292703,0) w_IR = (2.0131613909534741204308876218764326959565176646351,0.3163895149257166511858400650608063761510379271432)
65c65
< Elliptic log of P is (2.1525156669616024162853317818644956119079357950699,0)
---
> Elliptic log of P is (2.1525156669616024162853317818644956119079357950702,0)
68c68
< Elliptic log of P is (3.4017204102584996326696274231234087985780021511049,0)
---
> Elliptic log of P is (3.4017204102584996326696274231234087985780021513184,0)
make[2]: *** [Makefile:1295: check_qcurves] Error 1

This one looks different from numerical noise

Testing tmrank...
23,27c23
< Curve [0,0,0,-532,-4374] :
< 
< !!! Fatal error in mwrank: n3 =6 not a power of 2
< This is a bug: please report!
< Failed to compute rank
---
> Curve [0,0,0,-532,-4374] :    Rank = 1  
make[2]: *** [Makefile:1301: check_qrank] Error 1

Testing h1curve...
19c19
< tau       = (-0.0702834613166299234479926,0.9975270598161003196814262) (abs(tau)=1)
---
> tau       = (-0.07028346131662992344799259,0.9975270598161003196814261) (abs(tau)=0.9999999999999999999999998)
22c22
< c4 = -278.9999999999999999999986
---
> c4 = -278.9999999999999999999985
43c43
< tau       = (-0.5,1.398032057678869145976114) (abs(tau)=1.484753728501064551755562)
---
> tau       = (-0.5,1.398032057678869145976115) (abs(tau)=1.484753728501064551755562)
70,71c70,71
< c4 = -638.9999999999999999999911
< c6 = 49598.99999999999999999978
---
> c4 = -638.9999999999999999999905
> c6 = 49598.99999999999999999972
make[2]: *** [Makefile:963: check_g0n] Error 1

[JohnCremona]

About getenv(): there are other places where this is used, in all but one the system is similar, i.e. there's a default I use unless the user has set it to something else: $ grep -r getenv libsrc | grep getenv libsrc/xsplit.cc: s << getenv("ECLIB_EXT_NUM_THREADS"); libsrc/moddata.cc: s << getenv("OF_DIR"); libsrc/moddata.cc: s << getenv("NF_DIR"); libsrc/moddata.cc: s << getenv("SNF_DIR"); libsrc/oldforms.cc: s << getenv("ECDB"); libsrc/oldforms.cc: s << getenv("TCURVES"); libsrc/GetOpt.cc: else if (getenv ("_POSIX_OPTION_ORDER") != 0)

I think that a good way to deal with this is to write a little function wrapping your idea, arguments are the env string and a default value, returning a string . I can implement that.

You are right that the tmrank failure is not numerical noise. I would want to investigate by running mwrank itself on the curve in the test with a higher verbosity level, and compare the output with the gcc-compiled version. It does not seem fair to ask someone else to do that, but...

[kiwifb]

Just give me some instructions and I'll do the mwrankstuff....

In other news I was trying the default c++11 enabled eclib as per #23 and the build broke in bizarre way on linux with clang 4.0.1. I will check clang 3.8 shipped with OS X later.

[JohnCremona]

Can you send me the output of echo [0,0,0,-532,-4374] | mwrank -v3 ? As you can see from the output there is some use of (self-coded) bit-strings in here to do fast linear algebra mod 2 (of a very limited kind). I am betting that's where the issue lies.

[kiwifb]

OK, done on OS X

(sage-sh) fbissey@Mirage:sage-clang$ echo [0,0,0,-532,-4374] | mwrank -v3
Program mwrank: uses 2-descent (via 2-isogeny if possible) to
determine the rank of an elliptic curve E over Q, and list a
set of points which generate E(Q) modulo 2E(Q).
and finally saturate to obtain generating points on the curve.
For more details see the mwrank documentation.
For details of algorithms see the author's book.

Please acknowledge use of this program in published work, 
and send problems to john.cremona@gmail.com.

Version compiled on Jun 29 2017 at 22:15:21 by GCC 4.2.1 Compatible Apple LLVM 8.1.0 (clang-802.0.42)
using NTL bigints and NTL real and complex multiprecision floating point
Using NTL multiprecision floating point with 15 decimal places.
Enter curve: Curve [0,0,0,-532,-4374] : Using (a,b,c) search with (a,h) sieve and algebraic method
(with bigints to solve the syzygy)
Basic pair: I=1596, J=118098
disc=2314289340
2-adic index bound = 2
2-adic index = 2
Two (I,J) pairs
(a,h) sieving using 15 moduli: 
p:  9   7   17  23  29  37  41  43  47  61  73  79  83  89  101 
k_p:        2   1   1   1   1   2   1   2   1   1   2   1   1   1   
phi1:       3   9   16  17  25  17  7   26  3   28  6   46  47  11  
phi2:       -2  *   *   *   *   -13 *   -11 *   *   7   *   *   *   
phi3:       -1  *   *   *   *   -4  *   -15 *   *   -13 *   *   *   
finished aux_init()
Before sorting, phi = (30.7208530646208,0.28421709430404e-13),(-79.2366497318428,-0.4736951571734e-14),(48.515796667222,-0.18947806286936e-13)
starting flag_init()
finished flag_init()
Looking for quartics with I = 1596, J = 118098
Looking for Type 2 quartics:
Search range for a: (-12,1)
Trying positive a from 1 up to 1 (square a first...)
Trying positive a from 1 up to 1 (...then non-square a)
Trying negative a from -1 down to -12
(-6,-4,24,13,-12)   (ipivot = 1, type = B)  (11:1:1:1:1:01:1:00:1:1:01:1:1:0)   --nontrivial...locally soluble...no rational point found (limit 10) --new (B) #1
Finished looking for Type 2 quartics.
Looking for Type 1 quartics:
phi1 = 48.515796667222
phi2 = 30.7208530646208
phi3 = -79.2366497318428
hmax0 = 6243.26221430233
Search range for a: (1,14)
Trying positive a from 1 up to 14 (square a first...)
Trying positive a from 1 up to 14 (...then non-square a)
(10,5,21,11,11) (ipivot = 1, type = B)  (01:1:0:0:1:10:0:11:1:1:01:0:1:1)   --nontrivial...locally soluble...no rational point found (limit 10) --new (B) #2
(10,-16,30,-13,11)  (ipivot = 1, type = B)  (10:0:1:1:0:11:1:11:0:0:00:1:0:1)   --nontrivial...locally soluble...no rational point found (limit 10) --new (B) #3
(11,-11,21,-5,10)   (ipivot = 1, type = B)  (01:1:0:0:1:10:0:11:1:1:01:0:1:1)   --nontrivial...locally soluble...no rational point found (limit 10) --new (B) #4
(11,13,30,16,10)    (ipivot = 1, type = B)  (10:0:1:1:0:11:1:11:0:0:00:1:0:1)   --nontrivial...locally soluble...no rational point found (limit 10) --new (B) #5
Finished looking for Type 1 quartics.
Looking for quartics with I = 25536, J = 7558272
Looking for Type 2 quartics:
Search range for a: (-48,7)
Trying positive a from 1 up to 7 (square a first...)
(1,0,-210,1128,-1547)   (ipivot = 4, type = B)  (00:0:0:1:1:11:0:01:0:1:10:0:0:0)   --nontrivial...(x:y:z) = (1 : 1 : 0)
Point = [35:141:1]
    height = 3.87338326943971
Doubling global 2-adic index to 2
global 2-adic index is equal to local index
so we abort the search for large quartics
Rank of B=im(eps) increases to 1 (pivotal prime =29)
Exiting search for large quartics after finding enough globally soluble ones.
1202     (a,b,c) triples in search region
224  failed c-divisiblity,
970  failed syzygy sieve,
8    passed sieve.
0    failed syzygy after sieving,
7    failed d-integrality,
1    failed e-integrality,
0    failed extra-2 divisibility conditions,
6    passed all and produced quartics.
After getquartics(): 
n1 = 1
n2 = 1
n3 = 5
B-rank = 1

!!! Fatal error in mwrank: n3 =6 not a power of 2
This is a bug: please report!
Mordell rank contribution from B=im(eps) = 1
Selmer  rank contribution from B=im(eps) = 4
Sha     rank contribution from B=im(eps) = 3
Mordell rank contribution from A=ker(eps) = 0
Selmer  rank contribution from A=ker(eps) = 0
Sha     rank contribution from A=ker(eps) = 0

Warning: Selmer rank = 4 and program finds 
lower bound for rank = 1 which differs by an odd
integer from the Selmer rank.   Hence the rank must be 1 more
than reported here.  Try rerunning with a higher bound for
quartic point search.

Summary of results (all should be powers of 2):

n0 = #E(Q)[2]    = 1
n1 = #E(Q)/2E(Q) >= 2
n2 = #S^(2)(E/Q) = 16
#III(E/Q)[2]     <= 8

1 <= rank <= selmer-rank = 4

Failed to compute rank
Enter curve: 

[JohnCremona]

Thanks that gives me something to work on -- some things which should test to be equivalent are failing that test.

[JohnCremona]

Next could I see the output of this run of the program tequiv (in tests directory)? echo 1 2 11 -11 21 -5 10 10 5 21 11 11 | ./tequiv

I get

Checking equivalence of (10,5,21,11,11) and (11,-11,21,-5,10) u-poly = [1,0, -5334230, -150935400, 6798600758125] Root u = -1705

-- it computes a quartic poly using exact arithmetic (that's the u-poly) which is unlikely to be a problem, but then needs to know if it has a rational root.

[kiwifb]

(sage-sh) fbissey@Mirage:tests$ echo 1 2 11 -11 21 -5 10 10 5 21 11 11 | ./tequiv
Verbose? How many quartics to check? 

Enter quartic coefficients a,b,c,d,e ?
1: (11,-11,21,-5,10)
 new
Enter quartic coefficients a,b,c,d,e ?
2: (10,5,21,11,11)
Checking equivalence of (10,5,21,11,11) and (11,-11,21,-5,10)
u-poly = [1,0, -5334230, -150935400, 6798600758125]
No integral roots

[JohnCremona]

OK so it is a numerical issue. The code which extracts rational (in fact integral) roots from this monic quartic is in libsrc/mequiv.cc which first finds the complex roots and only proceeds with any if they pass the test is_approx_zero(imag(u)). But I have a much better function uses NTL to factor the polynomial over ZZ and should use that instead. I will make a patch for that, along with the one for the getenv() issue. Thanks!

[JohnCremona]

I just pushed to a branch called equiv the revised code which I hope will fix the errors you got from tmrank? Running the manual test on tequiv would not hurt either (in fact I will add the example to to the test file for that --done).

[kiwifb]

Yes tmrank is now passing on OS X (and tequiv does too I applied the two commits on that branch).

[JohnCremona]

Thanks -- I'll now merge the first of the two pull requests I just made while you test the getenv() one.

[kiwifb]

All good with the stuff on the getenv branch on OS X no segfaults just the numerical noise.

[JohnCremona]

Good -- I now merged both into the master branch.

The fix I used for the equiv testing was very much worth doing anyway -- so that's good -- but the previous failure is a sign that "numerical noise" can have serious consequences when one is computing quantities known to be exact, using floating point arithmetic. There are other places in eclib where this is done, and they certainly cannot be avoided! For example when one computes an elliptic curve with integer coefficients from a modular form, it is a hard theorem that the number coming out are integers at all.

Would it be possible for you to provide a complete list of the numerical noise test failures? I can check that none is serious and think about changing the tests -- all I do is an exact diff, so no tolerance testing is available.

[kiwifb]

I am conducting checks with clang++ + c++11. @isuruf patch is needed in its exact form for the compilation to work. The left over numerical noise is the same as in my previous comment https://github.com/JohnCremona/eclib/issues/19#issuecomment-315219838 apart from tmrank now passing.

The most interesting diff is for telog where we have some sign flips which would make a more sophisticated comparison up to a tolerance fail.

[isuruf]

@JohnCremona, would you like travis-ci integration, so that you can check your PRs against linux and osx? I have a branch ready.