lineax icon indicating copy to clipboard operation
lineax copied to clipboard

Decrease default value to prevent overflow in 32-bit.

Open johannahaffner opened this issue 2 months ago • 5 comments

Fixes https://github.com/patrick-kidger/lineax/issues/175#issuecomment-3530551020.

johannahaffner avatar Nov 14 '25 08:11 johannahaffner

Created a dev branch.

johannahaffner avatar Nov 14 '25 08:11 johannahaffner

We're failing pre-commit checks due to a new version of pyright, I'll fix this when I have time.

johannahaffner avatar Nov 14 '25 08:11 johannahaffner

Should this be something like jnp.finfo(jnp.float32).max? If nothing else to document the choice here.

patrick-kidger avatar Nov 15 '25 05:11 patrick-kidger

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.

johannahaffner avatar Nov 15 '25 11:11 johannahaffner

This one should be safe from JAX initialisation, I believe. :)

patrick-kidger avatar Nov 15 '25 12:11 patrick-kidger

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.

johannahaffner avatar Nov 15 '25 18:11 johannahaffner

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

johannahaffner avatar Nov 15 '25 18:11 johannahaffner

...and another one in GMRES, although I don't see how that one could be due to the changes I made.

johannahaffner avatar Nov 15 '25 20:11 johannahaffner

@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.

johannahaffner avatar Nov 26 '25 00:11 johannahaffner

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.

PTNobel avatar Nov 26 '25 04:11 PTNobel