juliaearth / coda.jl Goto Github PK

It may be convenient to preserve the name of the parts in the composition. This could be useful for IO methods for example.

This is a first good issue for new contributors.

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.

This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

As discussed in a recent PR, it seems that we should think more seriously about the corner case when a part of a composition is zero. Various operations with log fail, and one possible solution is to always add a eps(). Alternatively, we could consider adding this eps() at the composition constructor.

cc: @mralbu

Hi!

I am trying to play around with this package in the ultimate goal to make a biplot after my log-ratio transformation. Biplot.jl is listed as a potential candidate to make the plotting part but I am struggling to make the link with the 2 packages. And I would also like to understand the benefit to work with CoDaArray compared to a Table from TableTransforms.jl (both packages are new for me). Is CoDaArray kinda useful only if I want to use operations on them?

Here is what I tried with a simple MWE:

table = (SiO2=[0.728,0.725,], TiO2=[0.005,0.005], Al2O3=[0.143, 0.145], Fe2O3=[0.032, 0.032], MnO=[0.001, 0.001], MgO=[0.010, 0.010], CaO=[0.018, 0.022], Na2O=[0.032, 0.034], K2O=[0.003, 0.027])

ctable = compose(table)

table_clr = ctable.coda |> CLR()
# or ctable_clr = clr.(ctable.coda)?

So at the end I am using TableTransforms.jl syntax. Which mean that I could also do a PCA which should be compatible with Biplot.jl?

table_clr_PCA = table_clr |> PCA()

But looking at the exemple on Biplot.jl, it seems to me that it is doing the transformation under the hood before the plotting. So I am a bit confused to what I should give Biplot.jl.

Don't hesitate to tell me if I should more ask the question on TableTransforms.jl or Biplot.jl!

The UnicodePlots.jl has become a heavy dependency as explained here:

JuliaPlots/UnicodePlots.jl#291

Maybe we should consider copying the code for bar plots to CoDa.jl (with appropriate credits) and drop UnicodePlots.jl from our list of dependencies. I didn't have time to investigate the code yet, but it is good way forward to make this package more slim and self-contained in the future.

These functions aren't tested. It would be nice to add some basic tests.

As discussed in a PR, it would be nice to improve the option to read:

compose(table, codanames=(:a,:b,:c)=>:coda)

The package currently exports functions such as components, which conflict with widely used packages such as Distributions.jl. We need to unexport most of these functions given that users don't need them usually if they are using the package correctly.

Future use would require an explicit prefix as in CoDa.components.