You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
julia>using StaticArrays
julia> M =@SMatrix [001f1; 000; 000]
3×3 SMatrix{3, 3, Float32, 9} with indices SOneTo(3)×SOneTo(3):0.00.010.00.00.00.00.00.00.0
julia>exp(M)
3×3 SMatrix{3, 3, Float32, 9} with indices SOneTo(3)×SOneTo(3):NaNNaNNaNNaNNaNNaNNaNNaNNaN
This is a duplicate of #785 up to this point, but some investigation reveals the underlying issue, which I discuss here.
The problematic calculation is in _exp where
julia> U =@SMatrix Float32[0.00.01.6191188f17; 0.00.00.0; 0.00.00.0]
3×3 SMatrix{3, 3, Float32, 9} with indices SOneTo(3)×SOneTo(3):
0.0 0.0 1.61912f17
0.0 0.0 0.0
0.0 0.0 0.0
julia> V =@SMatrix Float32[6.4764752f160.00.0; 0.06.4764752f160.0; 0.00.06.4764752f16]
3×3 SMatrix{3, 3, Float32, 9} with indices SOneTo(3)×SOneTo(3):
6.47648f16 0.0 0.0
0.0 6.47648f16 0.0
0.0 0.0 6.47648f16
julia> VmU = V - U; VpU = V + U;
julia> VmU \ VpU
3×3 SMatrix{3, 3, Float32, 9} with indices SOneTo(3)×SOneTo(3):
NaN 0.0 NaN
0.0 NaN 0.0
0.0 0.0 NaN
The issue is with _solve(::Size{(3,3)}, ::Size{(3,)}, a::StaticMatrix{<:Any, <:Any, Ta}, b::StaticVector{<:Any, Tb}) where {Ta, Tb}. The dependence of _solve on det makes it vulnerable to under/overflow. We can replicate the issue in Float64
julia> @SMatrix([1e20000; 01e2000; 001e200]) \@SVector([1e0,0,0])
3-element SVector{3, Float64} with indices SOneTo(3):
NaN
NaN
NaN
This issue is closely related to #959, but that issue has to do with numerical instability and not overflow. Although it is likely that finding a resolution to that would improve the situation here. This issue is most acute in the 3x3 case, but also affects the 2x2 specialization.
but to what extent is this worth it? Is there a way we can keep the performance of the closed-form inverse without overflow? For example, can we scale the values in an attempt to keep det from overflowing? Can lu be made faster? At the very least, it seems that using _exp in lu would close #785.
The text was updated successfully, but these errors were encountered:
Julia v1.11.1 with StaticArrays v1.9.8.
Discovered while attempting
This is a duplicate of #785 up to this point, but some investigation reveals the underlying issue, which I discuss here.
The problematic calculation is in
_exp
whereThis can be resolved by
The issue is with
_solve(::Size{(3,3)}, ::Size{(3,)}, a::StaticMatrix{<:Any, <:Any, Ta}, b::StaticVector{<:Any, Tb}) where {Ta, Tb}
. The dependence of_solve
ondet
makes it vulnerable to under/overflow. We can replicate the issue inFloat64
This issue is closely related to #959, but that issue has to do with numerical instability and not overflow. Although it is likely that finding a resolution to that would improve the situation here. This issue is most acute in the 3x3 case, but also affects the 2x2 specialization.
I see that
_solve
is much faster thanlu
but to what extent is this worth it? Is there a way we can keep the performance of the closed-form inverse without overflow? For example, can we scale the values in an attempt to keep
det
from overflowing? Canlu
be made faster? At the very least, it seems that using_exp
inlu
would close #785.The text was updated successfully, but these errors were encountered: