Change internal representation of composition

[juliohm]

I think we can drop the dependency on static arrays and use plain named tuples moving forward. Given that composition objects are never treated as plain vectors, we don't gain much from the default linear algebra behavior of static arrays.

[mralbu]

I'd like to experiment with compositional data kriging, using GeoStats.jl, in the future.
Do you think there could be gains of maintaining the compositions as static arrays for this application?

[juliohm]

Oh that is nice! I had this application in mind as well. It would be great if you could push it forward and see if it already works, or what needs to be changed to make it work.

The idea of working with composition objects and Julia generics is that we don't need to know about the internal representation of the type. I think the transformations ilr, alr, clr should still return static vectors, I agree.

Hopefully we will be able to just have a spatial set of composition objects and feed it into Kriging without issues. But let's see how it goes. :)

[juliohm]

I did some refactoring, and ended up preserving the internal SVector as well. The only thing I don't like about this representation is that the getproperty implementation is not very elegant. The getproprety method allows us to access specific parts of the composition by name:

c = Composition(a=1.0, b=2.0, c=missing)

c.a == 1
c.b == 2

ismissing(c.c)

and currently it loops in the names of the parts until it finds the symbol. Maybe the compiler is optimizing this loop given that everything is static. I didn't have time to check though.