sin_cos test suite failure

[rickyefarr]

I thought this issue was due to interference from MLK using the intel compiler, but when I installed using gcc on my univerisity linux server (icc is not installed), running the test suite gives errors for the sin_cos function.

I started out by locally installing gmp-6.0.0a, mpfr-3.1.3, and flint-2.5.2. To install gmp, I used the following commands:

(let MYPATH be the desired install directory, it doesn't change)

install gmp

./configure --prefix=MYPATH --disable-static make -j8 make check cd make tune make speed make tune make tune | tee tune.out

make a copy of the original gmp-mparam.h

cp ../mpn/x86_64/core2/gmp-mparam.h ../mpn/x86_64/core2/gmp-mparam.h~

I remove the first several lines of tune.out, so that it can be used as a new gmp-mparam.h file

afterwards, I can then replace with the contents of tune.out

cp tune.out ../mpn/x86_64/core2/gmp-mparam.h

gmp needs to be rebuilt since we tuned

cd .. && make -j8 make check

all tests pass

make install

---

Now, I install mpfr. I navigate to it's directory, and the path for installation will be the same as MYPATH above.

./configure --prefix=MYPATH --with-gmp-build=MYPATH/local/gmp-6.0.0 --disable-static make -j8 cd tune make check

ALL tests pass here

cd tune make tune cd .. make check

test one more time

make install

---

Now, I install flint similar to above using the commands:

./configure --prefix=MYPATH --with-gmp=MYPATH --with-mpfr=MYPATH --disable-static make -j8 make check

All tests pass

make install

---

Now, I make a local repository of my fork of arb: git clone https://github.com/rickyefarr/arb.git cd arb git remote add upstream https://github.com/fredrik-johansson/arb.git git fetch upstream git checkout master git merge upstream/master ./configure --prefix=MYPATH --with-gmp=MYPATH --with-mpfr=MYPATH --with-flint=MYPATH --disable-static make -j8 make check

The failure says:

sin_cos....FAIL: containment (sin) a = (-448128001983 * 2^14) +/- (536870912 * 2^-323) b = (157968445807803538695138812109622709659517717 * 2^-147) +/- (541065218 * 2^-177) make[1]: *\ [../build/arb/test/t-sin_cos_RUN] Aborted (core dumped)

Have I installed something incorrectly?

[fredrik-johansson]

Could you edit the test code as I suggested earlier to show the full inputs and outputs?

Just a thought: does it work if you use mpir instead of gmp?

[rickyefarr]

I haven't tried mpir yet. I will try that next. I am also going to install arb using the zip file, without using github, just to ensure git isn't doing something. I recall installing on a different branch than master once, and issues arose.

Here is the output of now with iter, prec, t, and q printed. sin_cos....FAIL: containment (sin)

a = (-448128001983 * 2^14) +/- (536870912 * 2^-323)

b = (157968445807803538695138812109622709659517717 * 2^-147) +/- (541065218 * 2^-177)

iter = 25104

prec = 148

t = 8.854437620890127434117089474783343059034701118750828169669355577398360124566e-1

q = -167144684969810616847165580982667164216323262353072428743188001167198312529113576739762509057159104455769932197441253906995174176432425066038190669171636001468391963/22765151738668687594606063680009494234301074808113947379805575907353868438633735710549379673165538037526712796556788876392125472049858375965877469184

[rickyefarr]

Using the zip file to install did not help, still have a issue with this one function. I'm going to remove the test file and see if I pass all the other functions.

[rickyefarr]

I thought that I'd get a failure when testing acb/t-sin_cos, but oddly enough, I did not.

Removing the arb/t-sin_cos.c file makes the test suite pass all tests.

Really surprised that the complex version worked, unless the complex version only tests non-real inputs.

[fredrik-johansson]

This is fishy.

At prec = 148, the mpfr variables should have a precision of 248 bits in this test, which is 74 digits.

Since q ~= 10^16, converting this to an mpfr should give an absolute error of about 10^-58, so mpfr_sin_cos should give an approximation of sin(q) accurately to about 58 digits.

However,

|sin(q) - t| is -6.67e-43

Is MPFR dropping 15 digits here? Or is there a bug in fmpq_get_mpfr?

Could you print the value of t after fmpq_get_mpfr, i.e. the input to mpfr_sin_cos?

[rickyefarr]

Sure. Do you know by chance how to only run that one test? I've been having to run all of them to get to sin_cos. I'm not sure what command I should type using make.

[fredrik-johansson]

There's no command to run just one test. You could rename the test file so that it appears first alphabetically.

[rickyefarr]

Before fmpq_get_mpfr is called, q = -167144684969810616847165580982667164216323262353072428743188001167198312529113576739762509057159104455769932197441253906995174176432425066038190669171636001468391963/22765151738668687594606063680009494234301074808113947379805575907353868438633735710549379673165538037526712796556788876392125472049858375965877469184

Computing t using fmpq_get_mpfr gives t = -7.342129184489471999999999999999999999999999999999999999998565070372531387319e15

Output of mpfr_sin_cos(t,u,t,MPFR_RNDN), t = 8.854437620890127434117089474783343059034701118750828169669355577398360124566e-1

Output of arb_sin_cos(b,c,a,prec), b = (157968445807803538695138812109622709659517717 * 2^-147) +/- (541065218 * 2^-177)

FAIL: containment (sin)

a = (-448128001983 * 2^14) +/- (536870912 * 2^-323)

b = (157968445807803538695138812109622709659517717 * 2^-147) +/- (541065218 * 2^-177)

iter = 25104

prec = 148

t = 8.854437620890127434117089474783343059034701118750828169669355577398360124566e-1

q = -167144684969810616847165580982667164216323262353072428743188001167198312529113576739762509057159104455769932197441253906995174176432425066038190669171636001468391963/22765151738668687594606063680009494234301074808113947379805575907353868438633735710549379673165538037526712796556788876392125472049858375965877469184

[rickyefarr]

In the test code, I'm confused as to what a is. arb_sin_cos is computed with a, but mpfr_sin_cos is computed with t, and we compare b and t.

[fredrik-johansson]

Ok, so it seems that the output from fmpq_get_mpfr is wrong. Do you think you could track down why? I would first check if you get the same result if you create an mpq_t, set it to the same fraction as q. Then check if mpfr_set_q gives the wrong answer when called directly on that.

[rickyefarr]

I would be happy to help track this down. I've got to step away from the computer, but I should be able to let you know something later tonight.

On Thu, Oct 22, 2015 at 3:26 PM, Fredrik Johansson <notifications@github.com

wrote:

Ok, so it seems that the output from fmpq_get_mpfr is wrong. Do you think you could track down why? I would first check if you get the same result if you create an mpq_t, set it to the same fraction as q. Then check if mpfr_set_q gives the wrong answer when called directly on that.

— Reply to this email directly or view it on GitHub https://github.com/fredrik-johansson/arb/issues/53#issuecomment-150329213 .

Ricky Eugene Farr University of North Carolina at Greensboro Mathematics Department

[rickyefarr]

Okay, I got a fix. This issue is due to the precision used to calculate t. Notice the number of 9's in the digits of q. I think this is because MPFR is using round to the nearest, but the arb variable is either using round up or round down (I can't remember).

Increasing the precision that t is initialized with fixes the error, so for example instead of using mpfr_init2(t, prec + 100), I used mpfr_init2(t, prec + 1000) (although this is way too much). The precision of 248 gives around 74 decimal digits, but around 120 decimal digits are needed to get the correct number of 9's in the expansion.

[rickyefarr]

I'll push a fix tonight for this test, but a new question is...how much precision is enough to compute t with? I'll think about this further later this evening, unless you have an idea for the amount of precision to guarantee t is accurate enough.

[fredrik-johansson]

That would fix the test, but it would not fix the bug. On my computer, I get:

t = -7.342129184489472000000000000000000000000000000000000000000000000000000000000e15 t = 8.854437620890127434117089474783343059034694449965068030378953410517556011930e-1

That's what the first t should be. There is either a bug in GMP, MPFR or FLINT that makes the fmpq -> mpfr conversion fail.

[rickyefarr]

I believe the issue is that the second t that is printed is after the sin is computed. So, in other words, the second number that you print is sin(t), where t=-7.34..., which seems to be correct.

[fredrik-johansson]

Yes, the first t is before the sine is computed and the second one is afterwards. But the values you are getting on your machine (the first one, and consequently also the second one) are incorrect. I suspect a GMP bug actually.

[rickyefarr]

Perhaps I'm misunderstanding why there is a bug. It seems that the answer that is computed is right, to the specified precision...it just needs to be more precise to agree.

What value of n are you using with mpfr_out_str? I'm using 0, which would print all digits up to precision.

[rickyefarr]

I think mpfr_out_str prints different results depending on if n is non-zero.

[fredrik-johansson]

Yes, I'm printing with n = 0. My machine gives

t = -7.342129184489472000000000000000000000000000000000000000000000000000000000000e15

Your machine gives

t = -7.342129184489471999999999999999999999999999999999999999998565070372531387319e15

These should be identical; yours has several incorrect digits.

[rickyefarr]

I see. Okay, I checked this result with sage and I get what you've got. I'm using mpfr-3.1.3, which was released on June 15. Just so that we are on equal set ups, what version of mpfr are you using? I'll downgrade to that version, if I get the results that you have...then there is a bug with the latest release of mpfr.

[fredrik-johansson]

I still have mpfr 3.1.2.

As I said, it would be worth trying with mpir instead of gmp. You could also try building gmp without make tune.

[ahrvoje]

I can try with rather new versions if you exactly specify where and what to print. I use GMP v6.0.0a, MPFR v3.1.3, FLINT v2.5.2, ARB v2.7.0+ (commit aaa4d86) without 'make speed' and 'make tune', just an ordinary build. All tests pass OK.

Config: Windows 7 64-bit, MSYS2 including, bash v4.3.42(2), grep v2.21, make v4.1, diffutils v3.3-3, gcc version v4.9.2 (i686-posix-dwarf-rev1, Built by MinGW-W64 project).

[rickyefarr]

Okay, here is an update. I installed mpir with the --enable-gmpcompat flag, uninstalled gmp. Reinstalled mpfr, flint, and arb using mpir's gmp heaader. After what feels like forever, Arb is finally passing all tests. This is without tuning of mpir and mpfr.

I checked if tuning gmp was the cause, but it also failed at the same spot. Checked if tuning mpfr was the cause with gmp, same problem. It appears as though, something with gmp caused mpfr to fail. I'm not sure what, but it appears that:

gmp-6.0.0, mpfr 3.1.3 (with or without tuning of gmp or mpfr), flint 2.5.2, causes Arb to fail the test suite with the arb_sin_cos function.

What works for me, is:

mpir-2.7.0 compiled with --enable-gmpcompat, mpfr 3.1.3, flint 2.5.2, and Arb.

It would be interesting to now tune mpir and mpfr and see if it works as we hope. I'll try to track the root cause, later tonight.

[fredrik-johansson]

Thanks. It would be great if you could produce a minimal failing example in the form of a .c file that only uses GMP and MPFR (e.g. doing an mpq -> mpfr conversion). If you manage to recreate the bug in that setting, we can report the problem upstream.

[rickyefarr]

Yeah, I'm working on that. The bug is dependent on how the libraries are compiled. I have yet to determine if it's the GMP tuning or the MPFR tuning. MPFR and MPIR appears to work with tuning both.

[rickyefarr]

Well, just as soon as I say that MPFR and MPIR appearrs to work with tuning both...I get a failure. GMP has been officially eliminated as the culprit, since I removed GMP and worked only with MPIR, MPFR, and Flint. Since this problem was experienced before I started using MPIR, the bug must lie in MPFR or Flint.

I believe that tuning MPFR is the problem. Then again, the issue occurred in the function fmpq_get_mpfr, which may imply Flint is to blame.

It's worth noting that I haven't patched MPFR with the latest patches, as earlier I had and still experienced the issue. Thus, the current patches won't fix this. I'm going to test without tuning, and that should give me a good idea of a minimal example.

[rickyefarr]

I committed a small c program at 52d0deb to illustrate the issue. @fredrik-johansson, does this suffice? I have other examples.

On my machine, I used gmp and mpfr automatically installed with gcc (older version) and then changed my search path to use the new gmp and mpfr installs (gmp 6.0.0 and mpfr 3.1.3). Running the program yields the following incorrect results:

With gmp and mpfr installed with gcc:

gcc -o mpfr_issue.o mpfr_issue.c -lgmp -lmpfr ./mpfr_issue.o approx = -7.342129184489472000000000000000000000000000000000000000000000000000000000000e15

After changing my search path to the newest installations of GMP and MPFR 3.1.3:

gcc -o mpfr_issue.o mpfr_issue.c -lgmp -lmpfr ./mpfr_issue.o approx = -7.342129184489471999999999999999999999999999999999999999998565070372531387319e15

[fredrik-johansson]

OK, it does seem like an MPFR bug now. I think you can report this to the MPFR development mailing list.

[rickyefarr]

I'll be sending a message out today about this.

In the mean time, I noticed that when tuning GMP it's quite easy to accidentally over write two parameters defined at the beginning of the gmp-mparam.h file. These two defines are:

define GMP_LIMB_BITS (some number)

define GMP_LIMB_BYTES (some number)

I don't recall seeing these when I used MPIR either. I'm checking to see if perhaps this could cause errors when these are not defined. I know for a fact that I over wrote them earlier, and I passed all checks. Granted, I know almost nothing about the implementation of the Flint library, but I remember seeing COEFF_IS_MPZ depending on the length of a word. Is that parameter dependent on the number of bits or bytes in a limb?

[ahrvoje]

output from arb/mpfr_issue.c

approx = -7.342129184489472000000000000000000000000000000000000000000000000000000000000e15

GMP v6.0.0a, MPFR v3.1.3, FLINT v2.5.2, ARB v2.7.0+ (commit aaa4d86), Windows 7 64-bit, MSYS2, bash v4.3.42(2), grep v2.21, make v4.1, diffutils v3.3-3, gcc version v4.9.2 (i686-posix-dwarf-rev1, Built by MinGW-W64 project)

build config for GMP, MPFR, FLINT & ARB respectively: ./configure --build=i686-w64-mingw32 --host=i686-w64-mingw32 --prefix=/local --enable-cxx ABI=32 ./configure --build=i686-w64-mingw32 --host=i686-w64-mingw32 --prefix=/local --with-gmp=/local ABI=32 ./configure --build=i686-w64-mingw32 --prefix=/local --with-gmp=/local --with-mpfr=/local ABI=32 ./configure --build=i686-w64-mingw32 --prefix=/local --with-gmp=/local --with-mpfr=/local --with-flint=/local ABI=32

make just with:

make

[rickyefarr]

I contacted MPFR development, and here is a snippet of the last email I received about the issue from Paul Zimmermann:

"a first analysis shows that the bug happens when MPFR_DIV_THRESHOLD <= 4. Thus there is a bug in our implementation of Mulders' short division, or in the error analysis. I will investigate next week."

Since this is an official MPFR bug, I'm going to go ahead and close this issue.

[fredrik-johansson]

I appreciate that you investigated this. Funny that Arb's test code for trigonometric functions now has turned up one bug in the division code in MPIR and one in MPFR, both related to tuning thresholds (but completely independent of each other, as far as I can tell).

[rickyefarr]

No problem, I enjoyed tracking it down.

I'm not surprised at all that your test code has caught those. Tuning GMP on my intel i5 haswell generation 5 CPU works the first time around, but oddly enough fails if I try to tune a second time or more. If I'm not mistaken, MPFR uses the same tuning mechanism that GMP uses, by using --with-gmp-build. Oddly, I can tune MPFR as many times as I desire after tuning GMP. Seems strange to me.

It would be interesting to use the Amazon AWS to build virtual machines of different CPU types, then use the test suite to see how many bugs are actually caught. I bet there would be quite a few. Hopefully, I'm wrong about that.

Rick

On Sat, Oct 24, 2015 at 5:40 PM, Fredrik Johansson <notifications@github.com

wrote:

I appreciate that you investigated this. Funny that Arb's test code for trigonometric functions now has turned up one bug in the division code in MPIR and one in MPFR, both related to tuning thresholds (but completely independent of each other, as far as I can tell).

— Reply to this email directly or view it on GitHub https://github.com/fredrik-johansson/arb/issues/53#issuecomment-150853383 .

Ricky Eugene Farr University of North Carolina at Greensboro Mathematics Department

[rickyefarr]

Excuse me, I just checked, I don't think Amazon AWS allows to pick CPU type. For some reason, I thought they did. You can pick operating system though.

Thanks,

Rick

On Tue, Oct 27, 2015 at 9:46 PM, Ricky Farr refarr@uncg.edu wrote:

No problem, I enjoyed tracking it down.

I'm not surprised at all that your test code has caught those. Tuning GMP on my intel i5 haswell generation 5 CPU works the first time around, but oddly enough fails if I try to tune a second time or more. If I'm not mistaken, MPFR uses the same tuning mechanism that GMP uses, by using --with-gmp-build. Oddly, I can tune MPFR as many times as I desire after tuning GMP. Seems strange to me.

It would be interesting to use the Amazon AWS to build virtual machines of different CPU types, then use the test suite to see how many bugs are actually caught. I bet there would be quite a few. Hopefully, I'm wrong about that.

Rick

On Sat, Oct 24, 2015 at 5:40 PM, Fredrik Johansson < notifications@github.com> wrote:

I appreciate that you investigated this. Funny that Arb's test code for trigonometric functions now has turned up one bug in the division code in MPIR and one in MPFR, both related to tuning thresholds (but completely independent of each other, as far as I can tell).

— Reply to this email directly or view it on GitHub https://github.com/fredrik-johansson/arb/issues/53#issuecomment-150853383 .

Ricky Eugene Farr University of North Carolina at Greensboro Mathematics Department

Ricky Eugene Farr University of North Carolina at Greensboro Mathematics Department

[rickyefarr]

Just an update, perhaps this should be added to documentation. Let me know if you desire for that, but with the newest patch with MPFR-3.1.3, Arb passes all tests on the problematic machines discussed above.

Just for future reference (for the curious) I have been able to install gmp-6.1.0, mpfr-3.1.3 (patched), flint-2.5.0, and Arb with the intel compiler. This is with gmp and mpfr tuned.

The tuning parameters that optimizes the code the most without breaking the test suites for each library that works for my machine is:

CC='icc' CXX='icpc' CFLAGS='-O3 -fPIC -fomit-frame-pointer -fp-model strict -ansi-alias -funroll-loops -ip -openmp -xhost'

To comile gmp, use --enable-cxx and take away -xhost.

If you're interested, I'm willing to write in the documentation about using the intel compiler to compile Arb and Flint/Arb.

[fredrik-johansson]

Sure, that would be a good addition.

I'm curious: how much of a difference does -O3 make versus -O2?

[rickyefarr]

That is a good question, do you mean -O3 vs. -O2 with gcc? Or, do you mean -O3 vs. -O2 with icc? Or both?

I created a quick program to look at this. The c program attached is very crude, but should work reasonably well to see the difference. I plan to add other operations, such as -, *, /.

I could use GMPBench, but I can easily adapt this code to time operations with other libraries, such as Arb.

I can't figure out how to generate a random number in GMP with exactly n digits. I can for at most n digits, but not exactly n digits...so I made my own random number generator which takes awhile for a huge number of digits.

Compiling GMP with GCC, with the flags -O2 -fomit-frame-pointer -fPIC, the algorithm yields the output

GMP 6.1.0 (Printed to ensure I linked correctly) Adding two 100000 digit numbers, 1000000 times, took 2.349089 seconds

Compiling GMP with GCC, with the flags -O3 -fomit-frame-pointer -fPIC, the algorithm yields the output

GMP 6.1.0 Adding two 100000 digit numbers, 1000000 times, took 1.786070 seconds

So, it does make a definite difference. Any suggestions to improve the timing function? I eventually will need to make a shell script to do this correctly.

Note: To link correctly use gcc bench.c -I/PATH TO GMP/include -L/PATH TO GMP/lib -lgmp -o bench

If you have a older version of gcc installed with a older version of GMP than GMP 6.1.0, then you'll know it linked correctly if the program prints gmp 6.1.0.

Rick

On Wed, Nov 4, 2015 at 10:59 AM, Fredrik Johansson <notifications@github.com

wrote:

Sure, that would be a good addition.

I'm curious: how much of a difference does -O3 make versus -O2?

— Reply to this email directly or view it on GitHub https://github.com/fredrik-johansson/arb/issues/53#issuecomment-153773494 .

Ricky Eugene Farr University of North Carolina at Greensboro Mathematics Department

[rickyefarr]

Okay, so I made a small shell script to automate this. Interestingly, I can't duplicate the results I said earlier. Perhaps I had linked the library file incorrectly.

Attached is a program, that I used to generate these results. It's pretty crude. Note that this program cleans up after itself, and leaves environment variables unchanged in the end. You may need to use chmod +x run_bench, if you can't execute run_bench.

To use, untar the file somewhere on your computer. Then, type ./run_bench. Follow directions from there, you'll be prompted to enter CC, CFlags, then eventually two numbers. As an example, to generate the O1 results below, do the following:

./run_bench Enter CC: gcc Enter Compiler Flags: -O2 (Wait For GMP to compile) Enter Number of Digits To Benchmark GMP with: 10000 Enter Number of Iterations to Benchmark each Operation: 1000000 (Results will be printed to screen)

With no flags set, I get the following results: Adding two 10000 digit numbers, 1000000 times: 0.285048 seconds Subtracting two 10000 digit numbers, 1000000 times: 0.250024 seconds Multiplying two 10000 digit numbers, 1000000 times: 56.141287 seconds

With -O1 flag set, I get: Adding two 10000 digit numbers, 1000000 times: 0.308287 seconds Subtracting two 10000 digit numbers, 1000000 times: 0.243419 seconds Multiplying two 10000 digit numbers, 1000000 times: 52.246122 seconds

With -O2 flag set, I get: Adding two 10000 digit numbers, 1000000 times: 0.238184 seconds Subtracting two 10000 digit numbers, 1000000 times: 0.236995 seconds Multiplying two 10000 digit numbers, 1000000 times: 51.488722 seconds

With -O3 flag set, I get: Adding two 10000 digit numbers, 1000000 times: 0.253178 seconds Subtracting two 10000 digit numbers, 1000000 times: 0.238849 seconds Multiplying two 10000 digit numbers, 1000000 times: 52.356090 seconds

With -Ofast flag set, I get (passes test suite with this option): Adding two 10000 digit numbers, 1000000 times: 0.237852 seconds Subtracting two 10000 digit numbers, 1000000 times: 0.237820 seconds Multiplying two 10000 digit numbers, 1000000 times:

52.597523 seconds

I've run tests many times, it appears that when compiling GMP, on my machine one should use -O2. Also, it appears that -fPIC flag makes no difference, and -fomit-frame-pointer doesn't either.

Eventually, I'll bench Arb.

Thanks,

Rick

On Fri, Nov 6, 2015 at 12:18 AM, Ricky Farr refarr@uncg.edu wrote:

That is a good question, do you mean -O3 vs. -O2 with gcc? Or, do you mean -O3 vs. -O2 with icc? Or both?

I created a quick program to look at this. The c program attached is very crude, but should work reasonably well to see the difference. I plan to add other operations, such as -, *, /.

I could use GMPBench, but I can easily adapt this code to time operations with other libraries, such as Arb.

I can't figure out how to generate a random number in GMP with exactly n digits. I can for at most n digits, but not exactly n digits...so I made my own random number generator which takes awhile for a huge number of digits.

Compiling GMP with GCC, with the flags -O2 -fomit-frame-pointer -fPIC, the algorithm yields the output

GMP 6.1.0 (Printed to ensure I linked correctly) Adding two 100000 digit numbers, 1000000 times, took 2.349089 seconds

Compiling GMP with GCC, with the flags -O3 -fomit-frame-pointer -fPIC, the algorithm yields the output

GMP 6.1.0 Adding two 100000 digit numbers, 1000000 times, took 1.786070 seconds

So, it does make a definite difference. Any suggestions to improve the timing function? I eventually will need to make a shell script to do this correctly.

Note: To link correctly use gcc bench.c -I/PATH TO GMP/include -L/PATH TO GMP/lib -lgmp -o bench

If you have a older version of gcc installed with a older version of GMP than GMP 6.1.0, then you'll know it linked correctly if the program prints gmp 6.1.0.

Rick

On Wed, Nov 4, 2015 at 10:59 AM, Fredrik Johansson < notifications@github.com> wrote:

Sure, that would be a good addition.

I'm curious: how much of a difference does -O3 make versus -O2?

— Reply to this email directly or view it on GitHub https://github.com/fredrik-johansson/arb/issues/53#issuecomment-153773494 .

Ricky Eugene Farr University of North Carolina at Greensboro Mathematics Department

Ricky Eugene Farr University of North Carolina at Greensboro Mathematics Department

[fredrik-johansson]

Where is the code? I don't think email attachments show up on github.

[rickyefarr]

Wow, I guess you're right. I'll email you the code directly.

If anyone else is interested, email me directly and I will send it to you.

On Fri, Nov 6, 2015 at 6:04 AM, Fredrik Johansson notifications@github.com wrote:

Where is the code? I don't think email attachments show up on github.

— Reply to this email directly or view it on GitHub https://github.com/fredrik-johansson/arb/issues/53#issuecomment-154381933 .

Ricky Eugene Farr University of North Carolina at Greensboro Mathematics Department