Comments (8)
the filter function returns tuples, but setter functions do not accept tuples. would it make sense to abandon curried get i j in favor of get (i,j) ? one would lose partial application but it seems otherwise maybe more consistent?
Maybe provide get_tuple
or similar instead or ditching get i j
entirely?
from owl.
a: there are two functions in ndarray module: flatten and reshape, both are cheap and fast and will not make a copy of the data. or you can use iter function which will iterate the elements one by one anyway, also fast.
ah, ok. i misunderstood reshape to make a copy. now i see that Dense.Real.reshape is actually the one that makes a copy. then i would suggest maybe renaming one of them to avoid confusion? Is there a way for (2d) matrices to get reshaped without a copy?
i did not find an easy way to make 2d Ndarray slices into matrices.
a: this is actually very easy. Ndarray can operate on Bigarray.Genarray.t directly, whereas Dense.Complex and Dense.Real operate on Bigarray.Array2.t directly. You only need to call Bigarray.array2_of_genarray x to transform an ndarray into Array2.t, then you can pass it to Matrix module.
ah, ok. i didn't catch that the types are actually equal to the Bigarray types. is that in the docs?
I have provided interfaces like to_ndarray, of_ndarray in both Dense.Real and Dense.Complex as below. This is essentially just one line of code :)
Dense.Real.to_ndarray Dense.Real.of_ndarray Dense.Complex.to_ndarray Dense.Complex.of_ndarray ideally there would be a seamless interoperability between 1d, 2d, nd arrays, so that 1d slices are in fact of the same type as 1d arrays etc.
a: i think you can do that in ndarray, why not? it is just Genarray.t, you can certainly create one dimensional ndarray, e.g., Dense.Ndarray.zeros Float64 [|5|];;
ok, good to know.
another point is: why have separate ndarray and matrix modules at all? i guess it's because linear algebra generally only makes sense on (2d) matrices. that's fair enough, and maybe this does justify the design.
alternatively one could have all the linear algebra functions operate always on the last 2 dimensions of an ndarray by default, and broadcast over the others. an optional argument would allow to specify different dimensions to consider as the matrix to operate on. one would then run into runtime errors when trying that on a 1d ndarray which cannot interpreted as a matrix in a meaningful way. so the simplicity comes at the cost of less static safety.
generally, i'm still not sure what the best matrix or array type system for ocaml would be. one idea that i found intriguing is a matrix type that actually has structural information attached to it. either a parametrized type, like ('a,'b) matrix
where 'a
might be `Symmetric
or `Upper_triangular
etc, and 'b Real
or Complex
. or maybe a record with a field indicating the extra info.
linear algebra functions should be able to dispatch to the most efficient BLAS/LAPACK routine, and the type system would have to know that adding diagonal matrices gives a diagonal matrix, etc, preserving as much structural information as possible. apparently sciruby does something like that. the default for creation functions would then give a general matrix, on which all functions would work with the most general, potentially slower, algorithm, and with minimal user overhead. a user could optionally inform the type system that a matrix is e.g. hermitian, and this information will propagate as far as possible through the type system. in addition to function dispatch, also more efficient storage for structured matrices could be used on the backend, with no user input.
anyway, not sure if such a design is a good idea or if it's feasible but i just though i'd vent my ideas...
from owl.
hi, @nilsbecker thank you very much for trying owl, also a big thank for your comments, they are really useful. I will spend some time in digesting them then come back to you with possible answers @hcarty also thanks for the possible solution, I will think about it :)
Yes, I do acknowledge that many interfaces need to be fine tuned to make owl even easier to use. The overall structure of owl may undertake a lot of changes next year based on the feedback received. At the moment, I am still optimistic about making owl an extensible and high-performance numerical library :)
from owl.
@nilsbecker for these comments:
- reshape in Ndarray copies - most of the time i would use it to do a flat iteration. is this handled by the N.iter function instead?
a: there are two functions in ndarray module: flatten and reshape, both are cheap and fast and will not make a copy of the data. or you can use iter function which will iterate the elements one by one anyway, also fast.
- i did not find an easy way to make 2d Ndarray slices into matrices.
a: this is actually very easy. Ndarray can operate on Bigarray.Genarray.t directly, whereas Dense.Complex and Dense.Real operate on Bigarray.Array2.t directly. You only need to call Bigarray.array2_of_genarray x to transform an ndarray into Array2.t, then you can pass it to Matrix module.
I have provided interfaces like to_ndarray, of_ndarray in both Dense.Real and Dense.Complex as below. This is essentially just one line of code :)
Dense.Real.to_ndarray
Dense.Real.of_ndarray
Dense.Complex.to_ndarray
Dense.Complex.of_ndarray
- can one get a Bigarray back from a Ndarray.t?
a: yes, Ndarray.t is equivalent to Bigarray.Genarray.t
- ideally there would be a seamless interoperability between 1d, 2d, nd arrays, so that 1d slices are in fact of the same type as 1d arrays etc.
a: i think you can do that in ndarray, why not? it is just Genarray.t, you can certainly create one dimensional ndarray, e.g., Dense.Ndarray.zeros Float64 [|5|];;
from owl.
another comment: i think what would be really useful for shaping the api is (one or a few) small but real use case which really exercises a variety of matrix and array manipulations, including getting data into an appropriate shape and the nitty-gritty that is often required. a numpy and maybe a matlab, julia or fortran implementation should also be available. then one could get a feeling for how well the api works (in the repl and in a program), compared to the state of the art. unfortunately i can't think of something like that right now.
from owl.
These are really good points, thank you. There is a trade-off between verbosity and efficiency. Certainly the more type information we can get, the better choice we can make in choosing the best blas/lapack functions to call. At the moment, I am leaning to the ease of use if the performance is not bad (actually pretty good in many tests I have done).
However, due to the new Ndarray module which works similar to Bigarray, wherein you need to pass in the type and precision info using Float32, Float64, and etc., Owl's matrix apis don't look very consistent any more. Currently, I am reworking on the Dense.Complex and Dense.Real to unify them in a Dense.Matrix module so that you can also pass in type and precision information to create different types of matrices.
I will update the documents and tutorial accordingly after this work is finished.
from owl.
another comment: i think what would be really useful for shaping the api is (one or a few) small but real use case which really exercises a variety of matrix and array manipulations, including getting data into an appropriate shape and the nitty-gritty that is often required. a numpy and maybe a matlab, julia or fortran implementation should also be available. then one could get a feeling for how well the api works (in the repl and in a program), compared to the state of the art. unfortunately i can't think of something like that right now.
This is a good idea! Usually, there are a lot of inconsistency and discontinuity in the beginning. Some API will be changed and some will be ditched (which I think is totally fine :). The API should start stabilising later next year when more feedback arrive :)
from owl.
from owl.
Related Issues (20)
- Documentation is not in sync with current way plots are working
- OCaml cannot fins owl package HOT 1
- ssqr_diff' modifies inputs in place HOT 2
- Failure to load datasets for neural nets HOT 1
- Broken link to Algodiff module. HOT 2
- Exponential regression -- incorrect case HOT 1
- Test fails with GCC 13
- `Dataframe.to_cols` returns columns of incorrect size HOT 1
- Move project to ocaml-community HOT 7
- OCaml 5.2 support HOT 4
- Reintroduce owl-plplot HOT 6
- Dead link to TODO list HOT 1
- Random.float bounds are inclusive, be careful with logarithms
- Dataframe issues
- gamma_isf nan HOT 3
- Slack issues
- Map a fancy/basic index list into a list of array coordinates? HOT 1
- `set_fancy` does not work for some arrays with certain `Bigarray.kind` types. HOT 4
- load_mnist_test_data can't download data HOT 1
- Serious bug with `not_equal_scalar` function always returning the wrong result.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from owl.