Use pyproject.toml and Github Actions

[alexfikl]

Adds CI as for the other projects. It's running at
https://github.com/alexfikl/jitcdde/actions/runs/12123584420

The clang tests are failing again (with a different error) both on the CI and locally for me. Do they pass for you? You can see the failure here:
https://github.com/alexfikl/jitcdde/actions/runs/12123584420/job/33799396533

xref: neurophysik/jitcxde_common#4

[Wrzlprmft]

This also fails for me. I will try to look into this, but it may take some time.

[alexfikl]

This also fails for me. I will try to look into this, but it may take some time.

No problem. I tried debugging a bit, but was pretty lost. Thanks for looking into it!

[Wrzlprmft]

So, I finally looked at this. In short, there is no reasonable way to fix this test with Clang, but it’s also not a problem as it’s only the prerequisites of the test that are broken and not JiTCDDE itself. Thus, the solution is simply not to run the respective test with Clang.

The reasons are somewhat complex:

This test checks whether jitcdde_transversal_lyap produces the same result as jitcdde_restricted_lyap for synchronised oscillators. The former forces the oscillators onto the synchronisation manifold; the latter cannot do this, but one can only hope that the backend (Symengine plus compiler) implements all computations in a symmetric fashion (this is why the former supersedes the latter for these applications).

If the backend doesn’t work that way for whatever reason, that’s not a problem (outside of this test). JiTC*DE doesn’t need this behaviour – in fact, the test only works when disabling certain simplifications by JiTC*DE that are usually welcome optimisations.

What happens in the test case in question is that SymEngine rearranges some computations asymmetrically, specifically the order of some additions is changed, which is a problem when going numeric because floating-point additions are not associative. GCC’s optimisation fixes this “problem” by symmetrising them again, so we were lucky here (but this didn’t help with pinpointing the problem). Now, Clang does not resymmetrise these computations, which is why the test raises the error in question. The same applies to GCC without optimisation (-O0), by the way.

Since, AFAICT, there is no way to globally switch off associativity in SymEngine, this cannot be fixed. However, since this is just a prerequisite for the test and it’s very unlikely that such a high-level functionality in question degrades for one compiler only, this is not a problem.

[alexfikl]

So, I finally looked at this. In short, there is no reasonable way to fix this test with Clang, but it’s also not a problem as it’s only the prerequisites of the test that are broken and not JiTCDDE itself. Thus, the solution is simply not to run the respective test with Clang.

Thank you very much for looking into this! That all makes sense to me and there seem to be a few issues in symengine to ask for more flexible associativity rules, but it's probably a long way away.

I'm fine with merging this with your improved error message. Let me know if there's anything else that needs fixing.

[Wrzlprmft]

there seem to be a few issues in symengine to ask for more flexible associativity rules, but it's probably a long way away.

I am not entirely sure what you mean by this, but apart from that very test, I have no desire for meddling with associativity in SymEngine. I would also wager that doing anything of that kind would be a bad design decision on SymEngine’s part as it would decrease efficiency, etc.

I'm fine with merging this with your improved error message. Let me know if there's anything else that needs fixing.

Well, the test is still run in the current CI, isn’t it? I converted the error in question to a warning, which should ease running all the tests without implementing some weird exception.

Also, yesterday I changed something in JiTC*DE Common that requires Python 3.10 (see Issue #59). So, we can drop running tests in Python 3.6.

[alexfikl]

I am not entirely sure what you mean by this, but apart from that very test, I have no desire for meddling with associativity in SymEngine. I would also wager that doing anything of that kind would be a bad design decision on SymEngine’s part as it would decrease efficiency, etc.

I apologize for the confusion. I was just looking through their issue tracker and found symengine/symengine#1517. I definitely agree that it's not needed here and shouldn't be turned on by default.

Well, the test is still run in the current CI, isn’t it? I converted the error in question to a warning, which should ease running all the tests without implementing some weird exception.

Also, yesterday I changed something in JiTC*DE Common that requires Python 3.10 (see Issue #59). So, we can drop running tests in Python 3.6.

Thanks for the heads up! I updated ci.yml to run test on [3.10, 3.11 and 3.x] (which is the latest version supported by Github Actions -- currently 3.13) and bumped the minimum version required in pyproject.toml. Let me know if you spot anything else.

[Wrzlprmft]

I forgot to actually push that change to a warning, but now that I did the tests complete successfully.

Thanks for implementing this.

(By the way, once all the CIs are set up, I will make releases and try to hook PyPI into the CI.)

[alexfikl]

(By the way, once all the CIs are set up, I will make releases and try to hook PyPI into the CI.)

That would be great! It's pretty easy to set up automatic releases these days, e.g. when pushing a tag using
https://packaging.python.org/en/latest/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows/
which should look something like this (there's probably plenty of examples)
https://github.com/altaris/pyquill/blob/01769dc7d510de6dc078f9aa579f3d1f6897fc4d/.etc/pypi.yml