Conversation
Codecov Report❌ Patch coverage is
... and 1 file with indirect coverage changes 🚀 New features to boost your workflow:
|
|
How about exactly following |
|
Because I don't necessarily have access to the runtime information here, the algorithm selection procedure is running on types, so the whole scaling with the size of the input is a bit annoying. I can set both an absolute and relative tolerance if you like, but honestly I am not that convinced by this, it all feels incredibly arbitrary. For the truncated svd we also don't really provide a default truncation scheme, and I think here a similar thing is happening, by default the QR is chosen, and otherwise you just specify your own tolerances? |
|
If we don't have access to |
|
Isn't the fact that you don't have access to runtime information exactly a reason for setting |
|
I guess that is true, but I think what is weird about this to me is that the implication is slightly different. I think what is bothering me is that for truncated decompositions, the natural notion of tolerances is something like the distance between On the other hand, a nullspace seems like I want to use the distance between What is annoying about this is that comparing to Really what I want is the exact nullspace, and some tolerance about how precise my computations are that allows me to reasonably assume what is zero up to the tolerance of my computation. |
|
Ok I see what you mean. But still, if I rescale julia> A = randn(10,5); B = A*A'; [svd_vals(B) svd_vals(1000*B)]
10×2 Matrix{Float64}:
24.7879 24787.9
10.6469 10646.9
9.05193 9051.93
4.0803 4080.3
2.28204 2282.04
1.45695e-15 1.50662e-12
8.17938e-16 7.77041e-13
3.89231e-16 5.64928e-13
2.58608e-16 2.41852e-13
3.0498e-17 3.5025e-14 |
|
Yeah, that is also completely fair. So how do you feel about me changing it to |
This PR changes the default
notrunctoatol = defaulttol()for SVD-based nullspace computations.Fixes #166.