Decrease default value to prevent overflow in 32-bit.
Fixes https://github.com/patrick-kidger/lineax/issues/175#issuecomment-3530551020.
Created a dev branch.
We're failing pre-commit checks due to a new version of pyright, I'll fix this when I have time.
Should this be something like jnp.finfo(jnp.float32).max? If nothing else to document the choice here.
Sure, I can add a comment! A jnp anything in a default value of a public function causes JAX to initialise upon import of the library, I'm not exactly sure if this would be triggered here as well and will check if that would be the case.
This one should be safe from JAX initialisation, I believe. :)
Indeed it is. To address the pyright complaints, I've added ignore statements wherever I could not find an ergonomic way to use astype or cast.
Regarding our two_norm, it looks like pyright now disregards the Scalar return type and looks at what the function may return on all code paths, which leads to a union that includes a None, due to an assert False branch. Is that what pyright should be doing, seeing as assert False, if ever hit, cannot lead to a type-related bug? It probably has no concept of what happens in a branch other than checking what it may return (?), but I'm not sure why it only started picking up on this starting from the newest version.
We're getting the test failure reported here, which seems to be due to numerical bad luck: https://github.com/patrick-kidger/lineax/issues/172
...and another one in GMRES, although I don't see how that one could be due to the changes I made.
@PTNobel could you take a look at this? We're getting test failures for LSMR from tests that involve the computation of a JVP. The generated matrices should have permissible condition numbers: we've previously set a cutoff for the condition number at 1e3, which is the default we use for solvers that do not normalise the equations, and conlim is 1e8 for LSMR.
Right now I'm decreasing condition numbers to see at which values these tests will pass, but that is a little empirical and unsatisfactory. Besides, if there is a numerical problem underneath this that we should catch, then this is maybe a good canary in the coal mine.
Happy to look at it. It is Thanksgiving here in the US, so I'm a bit busy the next few days. Feel free to ping me if it haven't finished in a week.