Roadmap to 1.0

[DilumAluthge]

Are there breaking changes that we'd like to make to the public API of MonteCarloMeasurements.jl before releasing version 1.0?

cc: @baggepinnen
cc: @cscherrer

[cscherrer]

Thanks @DilumAluthge !

I can't think of anything offhand that would be a breaking change, but we should review our use of Particles to make sure it's all as consistent as can be.

There is one thing I'd like to add to MCM that would wrap something like e.g. a Normal(::Particles, ::Particles) and treat the result as a mixture of normals. I'll think some more about this, and should be able to write up the ideas tomorrow. But again, that won't be a breaking change.

[baggepinnen]

There are a few inconsistencies I still haven't figured out what to do with:

• Particles behave like both numbers and distributions, whatever is approprate in a given context. This breaks down for functions that are defined for both, but behave differently. Some of these functions are mean, std, maximum etc., i.e., functions that reduce a collection to a scalar. They are defined for scalars and return the scalar, but for distributions/collections they also return a point. In situations where one of these function are called in scalar code, the current implementation of, e.g., mean, will stop propagating the distributions of Particles after the call to mean, even if this was a noop in the scalar code.
• Particles should probably not be iterable other than as a scalar.
• I would also like to try out the stuff in Utilize Blas more  #83, and related, see how far performance can be pushed by having a dedicated MvParticles type represented by a Matrix that reduces the number of allocations, improves cache locality and can make use of BLAS calls for performance. This would be breaking since it causes some functions to return a different type.

[cscherrer]

* `Particles` behave like both numbers and distributions, whatever is approprate in a given context. This breaks down for functions that are defined for both, but behave differently.

Ouch, yeah this gets complicated very quickly. Seems important to be very careful here about the semantics.

Maybe Particles should always mean a <:Real with uncertainty? Then there could be wrappers to give it semantics of different supertypes, with functions to go between the representations. I think wrapping/unwrapping an immutable struct is a no-op at runtime.

[baggepinnen]

The behavior of Particles on master is now following the simple rule "Particles are always scalars, never distributions". This helps a lot with correctness. Most functions that previously treated Particles as a distributions, e.g., mean, std, cov, maximum etc., now have a new function with a prefix p, e.g., pmean, pstd etc. that maintains the old behavior.

A wrapper type around particles to give them distribution semantics like @cscherrer suggested is coming next, but not yet fully functional.