Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: new types for independent measurements and dependent measurements #7

Open
giordano opened this issue Oct 25, 2016 · 3 comments

Comments

@giordano
Copy link
Member

giordano commented Oct 25, 2016

We could make Measurement type abstract, and define two concrete types, IndependentMeasurement and DependentMeasurement (the latter may be an abuse of language but gives the idea):

abstract Measurement{T<:AbstractFloat} <: AbstractFloat

immutable IndependentMeasurement{T<:AbstractFloat} <: Measurement{T}
    val::T
    err::T
    tag::Float64
end

immutable DependentMeasurement{T<:AbstractFloat} <: Measurement{T}
    val::T
    err::T
    der::Derivatives{Tuple{T, T, Float64}, T}
end

measurement function would create IndependentMeasurement objects, while result function in src/math.jl would create DependentMeasurement objects. This function could have a specialized method for IndependentMeasurement only arguments, which could be fairly efficient.

Ideally, there would not be user-visible changes, apart from performance improvements.

I'm not sure this proposal will actually improve performance, I'm leaving this as a memo for me open for discussion.

giordano added a commit that referenced this issue Oct 30, 2016
Addresses issue #7.  This is mostly a proof of concept, does not work
very well.

Complex numbers may not currently work (at a first glance, it looks
impossible to have Complex{IndependentMeasurement}, see for example
log(::Complex{T}) which internally has log(convert(T,2))::T which cannot
be true).  As a work around, complex numbers may be forced to
Complex{DependentMeasurement}, which however defeats the purpose of this
change.

Still TODO: implement specific methods for `result` function with
`IndependentMeasurement`-only arguments, which will greatly improve
performance.
giordano added a commit that referenced this issue Oct 31, 2016
Addresses issue #7.  This is mostly a proof of concept, does not work
very well.

Complex numbers may not currently work (at a first glance, it looks
impossible to have Complex{IndependentMeasurement}, see for example
log(::Complex{T}) which internally has log(convert(T,2))::T which cannot
be true).  As a work around, complex numbers may be forced to
Complex{DependentMeasurement}, which however defeats the purpose of this
change.

Still TODO: implement specific methods for `result` function with
`IndependentMeasurement`-only arguments, which will greatly improve
performance.
@giordano
Copy link
Member Author

giordano commented Dec 25, 2016

Different approach in dispatch-on-constant branch: no new type, the only change is the dispatch of result for 1-arg functions is based on constants (Val{...}), but this isn't very fast. The branch is left there only as a proof-of-concept.

@alusiani
Copy link

alusiani commented Jun 1, 2021

We could make Measurement type abstract, and define two concrete types, IndependentMeasurement and DependentMeasurement (the latter may be an abuse of language but gives the idea):

I support this evolution. As far as I understand, the Python uncertainties packages works in this way. I have written code to do elaborations of uncertain and correlated quantities in R and resorted to the same concepts. It seems to me the most straightforward way to easily track down correlations when doing elaborations using quantities that themselves depend on overlapping sets of uncertain variables.

@giordano
Copy link
Member Author

giordano commented Jun 1, 2021

The reason why that I never went on with this idea is that it creates lots of type-instabilities, or it makes it more likely to have inhomogeneous containers which include both IndependentMeasurements and DependentMeasurements, which is really not a good idea performance-wise.

If one wants to distinguish an "independent" measure from a derived quantity, I believe traits would be a better approach.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants