I bumped the milestone on this one because there are other solvers that needs attention about deprecations. We can wait another 6 months on top of 15 years I think :)

I spoke to Pauli offline and went over about his preconditioning tolerance machinery. There is no problem as far as we can see. Also a tolerance initialization bug was causing some relaxation in the solution which is now fixed.

If everyone is happy, I'd like to add the Fortran code deletion commit on top and merge soon. Please let me know if you spot any issues in the meantime.

bicg(A, b, x0, None, 1000, M)

It's a bit better than that. if somebody was not using tol before, they don't get any warning because now tol=None and rtol is the new tol. Hence no disruption. When they want to fiddle with its value, they will get the warning. For the actual users that use a value for tol also get a warning and we move them to rtol. So I think we got covered this part.

may be worth updating the PR description with whatever results you have?

Yes, I should. I'll generate something .

It's a bit better than that. if somebody was not using tol before, they don't get any warning because now tol=None and rtol is the new tol. Hence no disruption.

That is a good idea in principle, however my point was that you can then not remove the keyword. Use of a positional None should be noisy first before it can be ripped out.

Here are some very funky results :)

I have no idea what is going on with cgs or gmres (possibly I'm measuring failure speed, I'll run those again) but in general we are in good shape The difference looks big but the scale is zoomed hence it's not that big.

The expensive parts of these solvers are the matvecs and preconditioner ops but they were already being done on the python side anyways hence the performance is pretty much the same if we don't stray away from inplace NumPy ops.

I'll check on GMRES one more time to see if I forgot some inplace linalg function but I'd take this PR against that sphagetti even if we lost 20% to be honest.

That is a good idea in principle, however my point was that you can then not remove the keyword. Use of a positional None should be noisy first before it can be ripped out.

Ah you mean you don't want to yank out a keyword from the middle to disturb the positional arguments if I understand correctly. But I think that kind of breakage is justified in this situation. Anyways let's continue when you are back 😃 I'll also need to reset myself from all this FORTRAN radiation I've been exposed lately. .

Just as a reminder, how should we proceed with the tol keyword here? Don't know a separate PR might be a better strategy to deal with it but I guess @rgommers saying is a better way to go once and for all.

Just as a reminder, how should we proceed with the tol keyword here?

The deprecation warning from #8400 (in gcrotmk & lgmres) has been warning for 5 years not to use tol= and recommends to use atol=.

In fact, it's warning as soon as atol=None, and since that argument's at the very end of the signature, someone would have to fill all arguments positionally and set atol to something non-None to both: not see that warning and be broken by removal of tol.

I think this is very unlikely usage, and considering the length of time this has been warning, it'd be defensible IMO to just remove tol.

Haven't looked how many other functions are affected by this though, and I can also see the argument that it'd be cleaner to deprecate positional usage completely (and then switch to keyword-only arguments).

@ @h-vetinari @rgommers @j-bowhay Should we merge this and deal with the _NoValue() right after this? I am a bit worried that it's too crowded in this PR to find all the occurences of the tol=None usage. I can submit something very quickly for that separately.

Fine by me¹

OK, I'll open the PR in a bit.