Rational Polynomials ft. Bugs

23 Jul 2016

Overview

Sorry I haven’t been able to report my work for about two weeks now. Things have become slower mainly due to the fact that my university has resumed and along with it a heavily packed timetable and assignments in the first week don’t help. I also caught a bad fever the past week which really hindered my progress, but it’s dying down and I will resume my work with full vigor eventually.

The work I did do has been summarized below.

Bug Fixes

While writing the code for the rational polynomials, as mentioned in the last blogpost, I encountered various bugs. Some of them caused other bugs to be exposed, which took a lot of time for me to debug.

pow(Poly, uint) was throwing a segmentation fault. After digging in and wasting more than four hours on unrelated checks I figured out that the eq inside the polynomial class was incorrect. Without checking whether the other parameter was a Poly or not, I was static_casting it which posed a problem.
The happiness was shortlived, as the bug persisted. On further inspection I found that the polynomial was being treated as a number! This was because is_a_Number relied on typecodes, and the polynomial types were defined before the NUMBERWRAPPER class, which deemed them numbers. The fix for this was simple, just move the polynomial type code definitions after the numbers.
The pow tests pass, but what’s this? All the MSVC builds on appveyor fail. They all fail a coeff test. Wow, I had not changed any code related to coeff at all, how does it affect that specific test and only on the MSVC compiler? This kept me wondering and looking at the source for a day. Finally, I had to login to the VM of appveyor running the tests. I was not familiar with windows development environment at all, which was the reason I failed a couple of times before I gave up debugging. The next morning I woke up determined to fix this Windows bug, I set the break points in Visual Studio and started the code execution. I found it! It was a bug in the CoeffVisitor itself. The code for the coeff function was incomplete. Why wasn’t this bug being captured before? Probably because the previous change (in the typecodes) caused a reordering in a map, which no other compiler was doing. Do read up here for more details.
An appveyor build was failing for unknown reason, which had to be shifted to allowed failures

This was basically the components of #1033. Less quantity of changes, but really important none the less.