Matrices, Vectors, uniform interface

[rleonid]

Part of the goal of Oml is to make it as easy as possible to interact with data.

For some types of data and functionality, such as distributions, native OCaml float array's are perfect and convenient. For other tasks, such as regression, not so much. While I think Lacaml is super powerful, I don't want to have to remember the idiosyncrasies of BLAS/LAPACK, and more-over, I don't want to spend a lot of time thinking of about the orientation of data.

I want it to do the right thing. I'd like a middle (functional) layer that makes it easier to work with dimensional data.

[smondet]

Maybe some inspiration froml there:
https://github.com/hammer/ocaml-getting-over-the-hump/blob/master/libraries.md ?

• https://github.com/dbuenzli/gg
• https://github.com/amnh/ocamion
• https://github.com/cheshire/onumerical
• https://github.com/akabe/slap

[struktured]

I like the changes thus far- should Sampling start using vector and/or matrix where applicable instead of float arrays? All for that, myself. If so, let me know and I'll make the changes.

[rleonid]

Knowing what I'm thinking about, at this point, I would say no.

Writing those vector and matrix functions reminded me of why I find Matlab so convenient, and at least in this area, that's what I'm hoping to have. I don't like having the distinction between the two and would just rather have something like

type dimensional = NativeVector of float array
                 | NativeMatrix of float array array
                 | LacamlVec of Lacaml_float64.vec
                 ....

with combinators that do the right thing. For example

val prod : dimensional -> dimensional -> dimensional

as opposed to all that prod_row_vector and prod_column_vector nonsense.
I don't mind runtime errors of size mismatches, since the convenience of being able to perform these functions in the toploop outweighs the safety.

I looked into https://github.com/akabe/slap, and will want to write some code in it, before I pass judgement. But my initial impressions were just 'meh'. Seems excessive. OCaml doesn't have dependent types, and I'm fine with it for now.

[struktured]

What is the value of permanently representing the data types as anything but a Lacaml_float64.vec (at least underneath the hood, it can be abstract type if necessary)?

Are some of these variants suggested so you that can easily enter data into the top level? Can you give an example when this becomes easier with some representations?

Or maybe it's because we can sometimes can avoid (un)boxing to Lacaml types when possible? Just want to hear more of your thoughts. I now get some of your 'meh'ness about the previous implementation at least.

[rleonid]

What is the value of permanently representing the data types as anything but a Lacaml_float64.vec (at least underneath the hood, it can be abstract type if necessary)?

In my opinion, the value comes in flexibility. Lacaml is useful for some specific operations, but it isn't flexible. There are times when you want to prepend a 1 to a vector, and there isn't necessarily much use in allocating a new one.

Yes, I want to keep things as easy as possible in the top loop. So, ideally the actual code that would interface with a dimensional would be small (ie, probably not Descriptive, [1]). But, you're hitting on the other thing that I want for it to do well, which is to handle all of the Lacaml state without the un-boxing/transformation. For example, the products in Svd would have been better kept in Lacaml land, but I want to write that logic once and forget about the nitty-gritty BLAS/LAPACK details.

1. Who knows though. If a dimensional has a well defined order or way of traversing, which will probably happen, those functions are easy to implement.

[rleonid]

@struktured I've put the basics of what I'm thinking about in this issue in the dimensional branch. Comments welcome there or here.