Closed jfbu closed 2 years ago
This is no excuse but this bug was actually already there before my fix to #4. In fact both branches phi<1
and phi>1
use the same mathematical formula, albeit implemented differently to avoid arithmetic overflow for phi<1
, but this formula is wrong for phi=1
as it simply induces N-->N+1
at the sp
level....
[…] but this formula is wrong for
phi=1
as it simply inducesN-->N+1
at thesp
level....
I noticed this while I was writing the formal proof in the latex3 repo issue. I probably emphasized “formula works if and only if phi>1
” way too many times (but apparently not enough, LOL). The reason that the same formula works even when 0<phi<1
is because even if (2T+1)*(psi/2)
ends up equal to some other M
, which is not necessarily the same N
, we can still proceed to floor(M*phi)=floor(N*phi)
, since phi<1
now serves as a strict contraction.
When phi=1
exactly, the midpoint
is exactly half way in between two integers N
and N+1
, and midpoint+1/2
carries us to N+1
, and now we are stuck because floor((N+1)*phi)=floor(N+1)=N+1
… Glad this was caught and fixed!
well, I am a few months older than when creating the package (the \texdimenbothincm
is more challenging on all accounts...). And today I tried to do about 4 things distinct at the same time, one of them being texdimens, and initially at dawn, I was only going to produce some pdf doc... then I saw that the \texdimenwithunit
from a few days back had an issue, and I ended up doing a bugfix, a bugfix of the bugfix and finally a bugfix of the bugfix of the bugfix.
What an embarrassment. I fixed #4 by applying the
<1pt
branch to=1pt
as the former now handled correctlydim1=0pt
but this is of course definitely wrong inducing a shift of +1sp. Very stupid.edit: it was also very stupid before that change when the
=1pt
case was using the>1pt
branch, because this is same math as<1pt
albeit implemented differently, and the math is wrong for this special=1pt
case...alas... and I already pushed it to CTAN.