Live data from Hacker News

HLearn: A Machine Learning Library for Haskell (2013) [pdf]

izbicki.me

11–20 of 23 posts

Re: HLearn: A Machine Learning Library for Haskell (2013) [pdf]

#11

Hi everyone, author of HLearn here :) This is a bit awkward for me as I've paused the development of HLearn and emphatically do not recommend anyone use it. The main problem is that Haskell (which I otherwise love) has poor support for numerical computing. I've tried developing an alternative standard library to improve the situation ( https://github.com/mikeizbicki/subhask ), but Haskell's type system isn't yet powe…

What are you using instead?

Everything (octave, python, julia, c++, various probabalistic programming langugaes) depending on the task and my mood.

Re: HLearn: A Machine Learning Library for Haskell (2013) [pdf]

#12

Hi everyone, author of HLearn here :) This is a bit awkward for me as I've paused the development of HLearn and emphatically do not recommend anyone use it. The main problem is that Haskell (which I otherwise love) has poor support for numerical computing. I've tried developing an alternative standard library to improve the situation ( https://github.com/mikeizbicki/subhask ), but Haskell's type system isn't yet powe…

> Haskell's type system isn't yet powerful enough to do what I want.

What still needs to be done? Does Idris have enough of the power that you need?

Re: HLearn: A Machine Learning Library for Haskell (2013) [pdf]

#13
post #7
post #3

What are the advantages of Haskell at deep learning, given that 1. Graph structures are notoriously difficult to model in functional languages. 2. The software-engineering side of deep learning is not all that difficult (e.g. using Keras is quite simple).

Also, correct me if I'm wrong, but the state of the art seems to be happening in Tensorflow/Keras; so committing to a different platform could mean you are systematically lagging behind in this new field.

Then don't use Haskell! I'm having a hard time understanding if your question is actually genuine or if you're just dropping by the Haskell thread to explain why you're not into using Haskell.

Re: HLearn: A Machine Learning Library for Haskell (2013) [pdf]

#14

Hi everyone, author of HLearn here :) This is a bit awkward for me as I've paused the development of HLearn and emphatically do not recommend anyone use it. The main problem is that Haskell (which I otherwise love) has poor support for numerical computing. I've tried developing an alternative standard library to improve the situation ( https://github.com/mikeizbicki/subhask ), but Haskell's type system isn't yet powe…

I remember repa being a pretty awkward experience when I tried it out

Re: HLearn: A Machine Learning Library for Haskell (2013) [pdf]

#15

Earlier quoted context omitted.

What are you using instead?

Everything (octave, python, julia, c++, various probabalistic programming langugaes) depending on the task and my mood.

Thanks and go UCR: http://positron.ucr.edu/ I bet doing ML in this context would be fun...

Re: HLearn: A Machine Learning Library for Haskell (2013) [pdf]

#16

Hi everyone, author of HLearn here :) This is a bit awkward for me as I've paused the development of HLearn and emphatically do not recommend anyone use it. The main problem is that Haskell (which I otherwise love) has poor support for numerical computing. I've tried developing an alternative standard library to improve the situation ( https://github.com/mikeizbicki/subhask ), but Haskell's type system isn't yet powe…

I am learning Haskell. Can you explain why you think Haskell has poor support for numerical computing?

Re: HLearn: A Machine Learning Library for Haskell (2013) [pdf]

#17

Hi everyone, author of HLearn here :) This is a bit awkward for me as I've paused the development of HLearn and emphatically do not recommend anyone use it. The main problem is that Haskell (which I otherwise love) has poor support for numerical computing. I've tried developing an alternative standard library to improve the situation ( https://github.com/mikeizbicki/subhask ), but Haskell's type system isn't yet powe…

I think it's pretty interesting considering the level of optimization that Hlearn has that the author mentions the poor support for numerical computing. I have two questions. 1. Which are the things that Haskell is missing for numerical computing. Is it something related to the language standard or to the compiler? 2. I have read the info for SubHask but I haven't got enough context to really understand why the alternative Prelude might help with numerical computing. Could you explain it a bit more, please?

Re: HLearn: A Machine Learning Library for Haskell (2013) [pdf]

#18

Hi everyone, author of HLearn here :) This is a bit awkward for me as I've paused the development of HLearn and emphatically do not recommend anyone use it. The main problem is that Haskell (which I otherwise love) has poor support for numerical computing. I've tried developing an alternative standard library to improve the situation ( https://github.com/mikeizbicki/subhask ), but Haskell's type system isn't yet powe…

Let me put Mike's comment into what I think is its proper context. "Poor support for numerical computing" really means "relative to Mike's dream, which is not actually realisable by any programming language today" :-)

Most readers seem to be misinterpreting Mike as anchoring off other popular programming languages of today, whereas he's looking for language features for which there's (a) no consensus that they'll actually be good when they exist, and (b) don't yet exist. (I'm highly skeptical of dependently typed programming.)

I think that there's a case to be made that numeric programming in Haskell, relative to the state of the art of today rather than the year 2100, really isn't so great – but my concerns are very different than Mike's, and revolve around libraries rather than type system features.

Source: have done a bit of Haskell in my day.

Re: HLearn: A Machine Learning Library for Haskell (2013) [pdf]

#19
post #18

Hi everyone, author of HLearn here :) This is a bit awkward for me as I've paused the development of HLearn and emphatically do not recommend anyone use it. The main problem is that Haskell (which I otherwise love) has poor support for numerical computing. I've tried developing an alternative standard library to improve the situation ( https://github.com/mikeizbicki/subhask ), but Haskell's type system isn't yet powe…

Let me put Mike's comment into what I think is its proper context. "Poor support for numerical computing" really means "relative to Mike's dream, which is not actually realisable by any programming language today" :-) Most readers seem to be misinterpreting Mike as anchoring off other popular programming languages of today, whereas he's looking for language features for which there's (a) no consensus that they'll act…

You're 95% correct about my view.

I do think that matlab/python are a bit better numerical programming languages than Haskell as-is, but only marginally. This is not just due to the library ecosystem, but also because I think that dynamic languages really are better than the best Haskell2010/GHC8.2 library theoretically possible. There are just some things that the existing type system makes a bit more awkward.

Re: HLearn: A Machine Learning Library for Haskell (2013) [pdf]

#20

Hi everyone, author of HLearn here :) This is a bit awkward for me as I've paused the development of HLearn and emphatically do not recommend anyone use it. The main problem is that Haskell (which I otherwise love) has poor support for numerical computing. I've tried developing an alternative standard library to improve the situation ( https://github.com/mikeizbicki/subhask ), but Haskell's type system isn't yet powe…

I think it's pretty interesting considering the level of optimization that Hlearn has that the author mentions the poor support for numerical computing. I have two questions. 1. Which are the things that Haskell is missing for numerical computing. Is it something related to the language standard or to the compiler? 2. I have read the info for SubHask but I haven't got enough context to really understand why the alter…

It's common in machine learning to define a parameter space $\Theta$ that is a subset of Euclidean space with a number of constraints. For a simple example, $Theta$ could be an elipse embedded in $R^2$. In existing Haskell, it is easy to make $R^2$ correspond to a a type, and then do automatic differentiation (i.e. backpropagation) over the space to learn the model. If, however, I want to learn over $\Theta$ instead, then I need to completely rewrite all my code. In my ideal language, it would be easy to define complex types like $\Theta$ that are subtypes of $\R^2$, and have all my existing code automatically work on this constrained parameter space.
Post reply on HN