Comments (11)
I also like this line:
There are no infinitely massive body weights (despite recent trends in western dietary health).
😆
from intervalarithmetic.jl.
CC @baggepinnen for MonteCarloMeasurements.jl
.
I don't think it's particularly easy to define a common generic interface. For example I feel quite strongly about making Measurements.Measurement <: AbstractFloat
, which I don't think would make sense for IntervalArithmetic.
@timholy Measurements.jl
implements linear error propagation, which is a simple and commonly used method in Physics, but it relies on the first derivative of the function being the "dominant" one, hypothesis which can locally fail for simple functions like sin
/cos
(think of their stationary points). One could extend the propagation to second-order derivatives to work around this limitation, another approach is Monte Carlo sampling, which should be equivalent to linear error propagation when its condition is satisfied (albeit much slower), and provide more "meaningful" results otherwise.
from intervalarithmetic.jl.
I think a package implementing a base uncertain number type, with common interface, would be very useful. I would have used it when making ProbabilityBoundsAnalysis.jl and MomentArithmetic.jl.
Note: if you're looking for an easy-ish way to reduce puffiness in interval arithmetic, centred from interval arithmetic is still rigorous but uses the first derivative (we can use ForwardDiff.jl) to reduce puffiness. I think when you use higher orders, it generalises to Taylor Models.
Unfortunately gaussian random variables aren't closed under arithmetic operations (except linear transformations), so the distribution's shape will change for anything non-linear. Essentially why first-order error propagation is only accurate for linear-enough functions.
You can however perform computations with moments, or at least bound them in non-linear transformations. So unless you additionally track the shapes, the transformed moments become intervals. Afterwards however, probabilities can be bounded from the moment, using e.g. the Chebyshev inequality.
If useful, we did publish open access article on the topic, and a sort of repository/package. Inside the paper you can find some tables containing the arithmetic rules we worked out (similar to the algebra of random variables)
Reducing puffiness is all about correlations:
julia> using MomentArithmetic, IntervalArithmetic
julia> a = Moments(0, 1, -1 .. 1) # mean 0, var 1, range [-1, 1]
julia> b = Moments(0, 1, -1 .. 1)
julia> a - b # Default is unknown correlation
moment: ~ ( mean = 0, var = [0.0,4.0] , range = [-2.0,2.0] )
julia> subIndep(a, b) # Independence gives precise variance
moment: ~ ( mean = 0, var = 2 , range = [-2.0,2.0] )
At the end of the paper there is some discussion on using covariances to reduce puffiness in arithmetic like in the above.
from intervalarithmetic.jl.
Thanks, this looks useful. In case you're not aware, I tried building MomentArithmetic on 1.10 and got this:
julia> using MomentArithmetic
Precompiling MomentArithmetic
Info Given MomentArithmetic was explicitly requested, output will be shown live
WARNING: could not import ProbabilityBoundsAnalysis.plot into MomentArithmetic
WARNING: Method definition (::Type{MomentArithmetic.Moments})() in module MomentArithmetic at /home/tim/.julia/packages/MomentArithmetic/x2Mva/src/Moments.jl:43 overwritten at /home/tim/.julia/packages/MomentArithmetic/x2Mva/src/Moments.jl:52.
ERROR: LoadError: Method overwriting is not permitted during Module precompile.
Stacktrace:
[1] top-level scope
@ ~/.julia/packages/MomentArithmetic/x2Mva/src/Moments.jl:52
...
1.10 is pickier about turning things that may have been warnings on previous releases into errors, because it was found that in some cases unfixed warnings were the source of serious, very difficult-to-track-down bugs. (In other cases they are fairly harmless, and this may be such a case.)
from intervalarithmetic.jl.
Thanks for the opening this issue!
It would be nice indeed to have a common interface. But I am not sure on the design either; to do this we would need to write down what are the expected features of "thick numbers" and hopefully see if we can reach a consensus.
To add context: interval arithmetic has stringent specifications which play poorly with generic code intended for real numbers (in the mathematical sense). To illustrate, let me copy-paste @Kolaru's recent example
f(x, y) = (x == y) ? 1 : exp(x - y)
which fails for the reasons mentioned already in @timholy's comment.
So to prevent silent failures, we have to fight quite a bit against Julia's flexibility (that's the reason for the recent changes on master
) and this is why having Interval <: Real
is not great. On master
, we still have Interval <: Real
but we removed all comparisons ==, <, etc.
and conversion/promotion with Number
; in PR #572 we are also discussing if intersect, union, etc.
should follow the Base
definition or just error to disambiguates with their interval arithmetic meaning.
It may also be worth mentioning here that recently we opened #584 as a way to recover interoperability with the ecosystem by exploiting the decoration system. This came up when thinking about conversion, see recently #580. One scenario could be to define
struct Interval{T} <: Real
interval :: BareInterval{T}
decoration :: Decoration
end
struct BareInterval{T}
lo :: T
hi :: T
end
Then, Interval
can be made more permissive since a decoration could flag "unsafe operations" (converting a Number
to an Interval
for instance). On the other hand, BareInterval
will be very conservative.
from intervalarithmetic.jl.
To compare with other similar packages having the same problem (Unitful.jl
, Measurements.jl
and ForwardDiff.jl
for what I know), I think it may be useful to explicit what we want or not from the Real
supertype. That way we may get a clearer view of what we have in common.
What we want:
- Arithmetic.
- Mathematical functions.
- Interoperability with the ecosystem ^^'.
What we do not want:
- Automatic promotion to or from float or other
Real
types. Correctness can simply not be guaranteed in general. - Number as 1 element 0-size arrays (broadcastable, valid for things like iteration, and set operation like
intersect
). We don't want that because it is ambiguous since intervals are sets by their own rights, which conflict withBase
definition of e.g.intersect
for aReal
. Being broadcastable alone would be fine, maybe.
What we can kind of live with:
- Ordering (
<
and such) and comparison (==
). We can in principle use ternary logic for that, that would be guaranteed, but it is still slightly ambiguous (especially for==
). - Mixing different
Real
types.Float64 * Interval
has unclear interpretation, because we don't know if theFloat64
is an exact trustable number. As @OlivierHnt mentioned we could tackle that by extending the concept ofDecoratedInterval
, and tag computation that may have lost validity that way.
I am pretty sure that I am missing some elements, but that's what come to mind right now.
Does it leaves enough in common with other packages ? I am not sure.
from intervalarithmetic.jl.
Update (sorry for the delay, I've been immersed in other things): I've realized that Measurements.jl doesn't implement the arithmetic rules I want:
julia> using Measurements
julia> (0 ± 1) * (0 ± 1)
0.0 ± 0.0
Instead I want something consistent with the algebra of random variables (what I think of as "soft intervals"). AFAICT there isn't really a package doing what I want, so I may start one (locally for now), and as I develop it I'll look for common interests. I may have a more informed view on this in a couple of weeks.
from intervalarithmetic.jl.
There's an initial implementation at https://github.com/timholy/ThickNumbers.jl. Durng this preliminary phase, I'll host it in my personal GitHub account, but if we decide to adopt it I'll transfer it to JuliaMath.
It's preliminary in the sense that I've not actually tried it in practical usage, and I don't plan to register it until I've created or rebased at least two packages on it, so we know if the generalizations "work" in real-world practice.
However, it's got a lot going for it already:
- extensive documentation (still waiting for it to be deployed at the time of writing, so I haven't checked availability)
- default implementations for a subset of IEEE Std 1788-2015 (more presumably to come)
- a subdir package, ThickNumbersInterfaceTests, which can be used to determine whether a concrete subtype satisfies the interface.
- support for ForwardDiff across all ThickNumber subtypes, even though they are
<: Number
rather than<: Real
.
Note that it mirrors the "new" direction for IntervalArithmetic, but with a couple changes in terms of unicode operators. I decided to aim for "dot" consistency, riffing off of ⪽
. So most of the operators I chose have a "dot" in them. I'm happy to discuss and modify these choices.
from intervalarithmetic.jl.
There were some initial issues with doc depoloyment, but those have been fixed and additional improvements made.
from intervalarithmetic.jl.
Toy package serving as a proof-of-principle: https://github.com/HolyLab/GaussianRandomVariables.jl
from intervalarithmetic.jl.
CC To @AnderGray, who has experience and may add something to the discussion.
from intervalarithmetic.jl.
Related Issues (20)
- Remove IntervalBox in favor of AbstractVector{Interval} HOT 11
- Non-allocating version of set operations HOT 2
- Should the 1.0-dev branch be the master branch? HOT 9
- Derivative of abs(::Interval) HOT 7
- `<` and `>` breaks interval? HOT 2
- Warn or error on every operation mixing Interval and number HOT 1
- Matrix multiplication with mixed Interval SMatrix and SMatrix broken HOT 3
- Lack of `convert(::Interval{T}, a::Real)` HOT 3
- IntervalArithmetic.Interval(::Float64, ::Float64) appears no longer supported in v0.21.0; replace with IntervalArithmetic.interval() HOT 2
- Make DecoratedInterval the default HOT 1
- Failure of `Interval{T}(x::AbstractIrrational)` HOT 7
- incorrect comparison for ieee standard HOT 1
- Make sure that the documentation is correct HOT 1
- Replacing CRlibm with CORE-MATH HOT 7
- Revive `@interval`
- constants in `@constraint` not working HOT 6
- "one" on complex intervals returns wrong value HOT 1
- Plotting intervals after removal of `IntervalBox` HOT 4
- Don't write inside of the package dir
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from intervalarithmetic.jl.