Hi Jon, Jon Peirce, on 2024-07-16: > That's very surprising. The project is pure python (so shouldn't depend on > architecture) and hasn't had any commits to the computation code since Oct > 2022 (there have been some changes purely to the build/docs since then). So > I wonder if something else about the build environment has recent changed?
Previous push to Salsa and upload were in early 2023, so a lot
of things had the time to change in unstable. Other changes in
sid include, but are not limited to, upgrade to Python 3.12, and
several Numpy version bumps. Quick lookup at the test item
shows numpy code, which I believe is sensitive to floating point
unit precision of the underlying hardware.
The issue is also reproducible on the buildd network[1], so that
should not be too hard to reproduce. The result strikes me as
particularly far off 0.2 and yet so close 0.3. It feels like
there is a threshold or rounding error amplifying an originally
small loss:
> assert np.isclose(next_stim_1, expected_stim_1)
E assert False
E + where False = <function isclose at
0xf7184e00>(0.30000000000000004, 0.2)
E + where <function isclose at 0xf7184e00> = np.isclose
but I haven't looked closely at the code base, so may wrongly
interpret what I am seeing.
[1]: https://buildd.debian.org/status/package.php?p=python-questplus&suite=sid
> I know the maintainer so I'll nudge him to take a look if he can
That would be helpful, thanks for considering. Even if i386
were to not be supported upstream anymore, this particular issue
could be symptomatic of an algorithmic stability issues, that
might be of interest to tackle upstream.
Have a nice day, :)
--
.''`. Étienne Mollier <emoll...@debian.org>
: :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da
`. `' sent from /dev/pts/2, please excuse my verbosity
`- on air: Fair to Midland - A Wolf Descends Upon the Spa…
signature.asc
Description: PGP signature
