1 unit differences with v1.6.0

[miguelsousa]

Getting 1 unit differences after updating from 1.5.0 to 1.6.0.
Is this expected?
https://ci.appveyor.com/project/adobe-type-tools/afdko/builds/19349800
https://travis-ci.org/adobe-type-tools/afdko/builds/438769936

[anthrotype]

It could be the differences between Python and C division operator. I'll have a look tomorrow, thanks

[behdad]

It's probably because I replaced division by multiplication. I'll take a look. I know @anthrotype had to adjust the tests too. But yeah, could be C vs Python div as well, if the number is negative.

[anthrotype]

I didn’t change the expected test results, only changed from asserting strict equality to using math.isclose which is still very precise 1e-9 relative tolerance.

[anthrotype]

a807ab2

[anthrotype]

it can't be the differences in C vs python division operator, because that only applies for integer division, and here we are using floats and complex.
Also, even for integer division, Cython defaults to the python semantics unless one passes the compiler directive cdivision and set it to True (it's False by default).
I'll keep digging.

[anthrotype]

it was indeed the fact that Behdad had replaced division (x / 3.0) with multiplication (x * 0.33333333333). I'll revert that change and release 1.6.1

[behdad]

it was indeed the fact that Behdad had replaced division (x / 3.0) with multiplication (x * 0.33333333333). I'll revert that change and release 1.6.1

Does adding more 3s help? :D

[anthrotype]

question is does it make it faster enough to warrant the loss of precision and regression from previous cu2qu?

[behdad]

From a developer point of view it sucks that we cannot change the output of the algorithm. But guess we can call the algorithm set in stone now...

[miguelsousa]

For the record, I didn't do a visual check of the differences. If they don't represent a noticeable negative impact on the integrity of the outlines, I'm fine with using the new output results.