Fix computation of norms of AbstractArray{<:Measurement}
#120
Conversation
Codecov Report
@@ Coverage Diff @@
## master #120 +/- ##
==========================================
- Coverage 95.54% 92.85% -2.69%
==========================================
Files 12 13 +1
Lines 741 546 -195
==========================================
- Hits 708 507 -201
- Misses 33 39 +6
Continue to review full report at Codecov.
|
In Julia v1.9 we currently have
```julia
julia> A = [(14 ± 0.1) (23 ± 0.2); (-12 ± 0.3) (24 ± 0.4)];
julia> norm(A * inv(A) - I, Inf)
0.0 ± 3.5e-19
julia> norm(A * inv(A) - I)
NaN ± NaN
```
This is due to the fact that the Inf-norm has now zero value with non-zero
uncertainty, but some checks in the computation of the p-norms assume that if a
number is non-zero then dividing by it wouldn't result in an overflow (or NaN).
However this is not true for numbers of the type `0 ± u` with `u != 0`, which
aren't the additive identity element but nevertheless would result in
overflow (or NaN) when dividing by them.
While a proper solution would be to have in the language two distinct traits for
"additive identity element" (which is already represented by `iszero`) and
"non-overflowing denominator" (which we currently miss, but I also don't know
any language implementing this trait), Daniel Wennberg pointed out that the
Inf-norm of an array should always have zero-uncertainty if the value is also
zero, thus resulting in a proper "additive identity element" zero which would
satisfy the assumptions in the computations of the other p-norms. This change
defines the method `LinearAlgebra.normInf(::AbstractArray{<:Measurement})` to
always force zero uncertainty in the Inf-norm when the value is also zero.
giordano
force-pushed
the
mg/linear-algebra
branch
from
19789b4
to
d2ada3d
Compare
|
Let me just add here that there may be an order of limits issue in the argument. My understanding is that linear uncertainty propagation is consistent in the limit that the uncertainty is small compared to the scale over which the function you propagate through changes slope. In the argument, we've taken this limit before taking the limit p -> Inf. I haven't thought about the consequence of reordering these limits, I suspect you'd end up picking out the zero with the largest uncertainty, which I guess is a pretty logical way to define the largest absolute value of two uncertain zeros. Then again, the next logical step would be to apply the same reasoning to function composition, which would mean that In other words, as long as this package is happy with |
In Julia v1.9 we currently have
This is due to the fact that the Inf-norm has now zero value with non-zero
uncertainty, but some checks in the computation of the p-norms assume that if a
number is non-zero then dividing by it wouldn't result in an overflow (or NaN).
However this is not true for numbers of the type
0 ± uwithu != 0, whicharen't the additive identity element but nevertheless would result in
overflow (or NaN) when dividing by them.
While a proper solution would be to have in the language two distinct traits for
"additive identity element" (which is already represented by
iszero) and"non-overflowing denominator" (which we currently miss, but I also don't know
any language implementing this trait), Daniel Wennberg pointed out that the
Inf-norm of an array should always have zero-uncertainty if the value is also
zero, thus resulting in a proper "additive identity element" zero which would
satisfy the assumptions in the computations of the other p-norms. This change
defines the method
LinearAlgebra.normInf(::AbstractArray{<:Measurement})toalways force zero uncertainty in the Inf-norm when the value is also zero.
Thanks a lot @danielwe for the help and the in-depth discussion about how to address the problem.