Representation of measures (or other box weights)

[gaioguy]

Question by @cafaxo: "By the way... this asks the question on how we want to represent measures in GAIO. I am not sure if a tuple (boxlist::BoxList, measure::Vector{Float64}) is the best way. But this is not the right place to discuss that. :)"

It would be useful to be able to attach weights to Boxes when storing a BoxSet.

[cafaxo]

I disagree with having something attached to Boxes in a BoxSet. More correctly, it would then be a BoxDict and not have the usual set methods any more (union, setdiff, etc.) These methods do not make sense for dictionaries.

[gaioguy]

That is right. So what is the problem with your tuple suggestion?

[cafaxo]

It could be interesting to have an object like

struct BoxFunction{P<:BoxPartition,K,X}
    partition::P
    key_to_value::Dict{K,X}
end

which represents functions from a BoxSet to some space X. Such a function is constant on every box in the BoxSet.

For these objects, it would be natural to define f + g and scalar multiplication λ f. This can of course be used to represent measures, but could also be useful for representing characteristic functions etc.

[gaioguy]

Yes, that would be useful, indeed. Do I understand correctly, that if a BoxFunction results from some computation on some BoxSet, then the values in key_to_value associated to the keys in that BoxSet would be assigned a value - and all other values would implicitely be/remain nothing?

[cafaxo]

I am not sure. We could define such a function to be nothing outside the BoxSet... or maybe zero(X)?

[gaioguy]

Since the domain(f) (of definition) of a BoxFunction f would be the BoxSet used for construction, I strongly prefer the function to be undefined (which, I assume, is represented by nothing in Julia) outside of that set.

[cafaxo]

We could also throw a DomainError like sqrt(-1) does. That prevents the type instability we would have due to returning Union{X,Nothing}.

[MaHermann]

Do we really need a type for this? Maybe we can, in all situations where we want to have something like this, work with usual functions f(box)? The invariant measure could then look someting along the lines of this:

function invariantMeasure (boxset::BoxSet, transistion_matrix}
    # compute measure here, e.g. with a dict of values (or a vector, etc.)
    # e.g. called `value_of_measure`
    return function invariantMeasure(box) begin
         if !haskey(value_of_measure, box)
             throw DomainError
         end
         return value_of_measure[box]
    end
end

We could probably work exactly like with BoxFunction in all our code, but allow more flexiblity for user-defined functions. Maybe we should also provide some utility methods for creating such functions.

This would probably require something like box in partition to work nicely though, which is not straightforward (e.g. what if a box has the exact same coordinates as a box in the partition, but is not the same object? What if it is exactly subdivided by some boxes in the partition?).

Also, I'm not sure about potential drawbacks for the type system.

[cafaxo]

The idea is that we could then do things like plot(colormap ∘ measure). Where colormap is a usual function from [0,1] to a set of colors and colormap ∘ measure is again a BoxFunction that represents the composition. With a simple old Julia function we couldn't do that.

Furthermore, since we are already representing sets, it could be useful to represent functions on those sets. Example:

f = x -> norm(x) <= 1 # indicator function representing the unit ball
g = BoxFunction(f, domain) # adaptively constructed BoxFunction approximating `f` using a `TreePartition`
integral(g)

Also, I'm not sure about potential drawbacks for the type system.

What do you mean by this?

[gaioguy]

The idea is that we could then do things like plot(colormap ∘ measure). Where colormap is a usual function from [0,1] to a set of colors and colormap ∘ measure is again a BoxFunction that represents the composition. With a simple old Julia function we couldn't do that.

Awesome.

Furthermore, since we are already representing sets, it could be useful to represent functions on those sets. Example:

f = x -> norm(x) <= 1 # indicator function representing the unit ball
g = BoxFunction(f, domain) # adaptively constructed BoxFunction approximating `f` using a `TreePartition`
integral(g)

Yes, computing with functions is really useful (cf. ApproxFun.jl) and having this ability for step functions on a BoxSet seems like a really nice feature (not at all present in the old GAIO).

[gaioguy]

We could also throw a DomainError like sqrt(-1) does. That prevents the type instability we would have due to returning Union{X,Nothing}.

Ok, if that helps in terms of performance, sure.