chreekat: python is great for doing science because it runs your code no matter what. No matter what they say about pre-registering experiments, scientists just love to tinker and make up hypotheses after the fact
I must say, I've had some horrible experiments where I run Python code for hours and then finally it prints out:
Traceback (most recent call last):
File "boop.py", line 1, in <module>
print(x)
NameError: name 'x' is not defined
Though that's completely consistent with what you said :P
@ocramz_:matrix.org
and they say Haskell compilation takes a long time...
anton_5: backprop is very handy. I've used it a few times
1 reply
oh, cool; for ML, as in neural nets, backprop should be great; at least, regarding performance on CPU and if your nets have large tensors in them, as opposed to very many smaller ones (it uses blas/lapack under the hood)
Oh, nice, good to know, thanks! I wonder if it can work with the accelerate as well.
Looks like accelerate has bindings to cublas, so, in theory, it should be possible to substitute regular blas in the backprop for cublas.
Or use the arrayfire bindings.
mentions library https://gitlab.com/sacha-sokoloski/goal used in https://elifesciences.org/articles/64615 , probably of interest to some datahaskellers :)
1 reply
Hi! I come from a pure math background with an interest in data. I recently stumbled upon haskell and really found it cool. I feel that a really nice way for me to get familiar and learn more about haskell, work on some cool stuff and contribute to the community. How do I go about all this? Thanks :)
I have experience in coding with c/c++/openmp/mpi/cuda/python and other basic ml libraries
1 reply
Welcome! So, would you like to contribute to a Haskell data-related project? Right now, or after learning Haskell in a conventional way? Haskell does take some adjusting, though the challenging experience is described as beneficial by the survivors.
there was a very recent talk on accelerate https://www.youtube.com/watch?v=FzfofFPOGOs&list=PLOvRW_utVPVnqp24VsF0wiIRa-m9oWrox&index=2
Just a question, if my company says that any work generated by the associate arising out/in connect of my connection with the company counts as confidential stuff, then would I be able to contribute to these kind of projects or would I need to talk about these things with my company first? I'm new to all these things, so please don't mind these basic questions.
re geometry, this is not computational geometry, I think, but a bit related: https://gitlab.com/sacha-sokoloski/goal
re your company, IANAL, but if you are not doing it in company time, they should not have a say, and if you do, they probably should
Some companies do claim to have rights to any and all work regardless of when it's done, but then, those claims may not be enforceable, so you probably want specific legal advice in any case
*may not be enforceable depending on local laws
1 reply
Sure! I’ve been working on a Haskell->Stan (the Bayesian modeling language) interface. Someone else had done a bunch of the runtime stuff (hs-cmdstan) and I’ve been building some stuff around writing the Stan code from Haskell as well as integrated data-handling, etc. kind of a mess right now but does the job. Thinking about integration with Monad-Bayes.
Hi! I'm implementing yet another automatic differentiation library with a bunch of co-conspirators and a major struggle in that is wrapping my head around some data science concepts, e.g., data normalization (Mikolaj/horde-ad#42).
4 replies
@dataopt: I’m intrigued by monad-Bayes as well. I doubt it will be fast enough for my purposes but it also opens up some algorithmic possibilities that might balance that out. Plus I’d rather keep all of it in Haskell as it would simplify the data-pipeline.
Separately, I continue to think that the difficulty of managing flexible row types is a key issue. I’ve opted for Frames mostly, but I often end up with monstrous sets of constraints when writing anything polymorphic in the row content.
Separately, I continue to think that the difficulty of managing flexible row types is a key issue. I’ve opted for Frames mostly, but I often end up with monstrous sets of constraints when writing anything polymorphic in the row content.
1 reply
Not sure about the randomness part, but for the Hamiltonian Monte Carlo bit it’s more that Stan is intensely optimized. So it would, I think, take a lot of work for another implementation to catch up. But there are interesting variations on HMC that might be easier to implement on a fresh Haskell library than on a large scala/c++ codebase.
gitter is old tech now right? where would the new kids want to hang out now?
1 reply
We will never beat the blas bindings of hmatrix in performance, and I think stan bindings are in the same category - will remain useful for a good while.
gitter has been somehow ported or bridged to Matrix and matrix (directly, not via gitter) is where I post from right now: https://matrix.to/#/!JSHTXUPHaIJhjEINXX:matrix.org?via=m.topoi.dev&via=gitter.im&via=matrix.org
Part of my motivation is I wanted to do a bit of a survey, state of play, for data haskell, what's out there right now and what might be on the radar. data haskell might not be the right name for it though. More like practical machine learning.
Man of Letters: you may also want to try to use array fire https://github.com/arrayfire/arrayfire-haskell instead of hmatrix for gpus.
2 replies
Man of Letters: if going via the staging route, I think it’s worth exploring the possibility of emitting MLIR https://mlir.llvm.org/