[elm-discuss] Re: ELM = JAVASCRIPT REINVENTED (PART 1)

[Richard Feldman]

Yeah it's a bit inaccurate to say Elm is JS reinvented because Elm never used 
JS as a starting point. 

I think there's a more plausible case to be made that Elm is "Standard ML 
Reinvented" - since JS is only Elm's (current) compilation target.

Any ways in which Elm's design resembles JS are almost certainly coincidental!

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: The NumPy for Elm

[Francisco Ramos]

That's great. Thanks for the links. I read about PyData. Sounds
promising... I'm algo checking out ML packages in Haskell. I'd like to see
other more functional approaches.

Fran

On Thu, Nov 2, 2017, 19:31 Matthieu Pizenberg 
wrote:

> Hi Francisco, that's awesome what you aim for. I'm also looking forward
> for more scientific programming stuff in elm.
> Inspiration from numpy is a great choice considering almost all learning
> frameworks are usable in python. As a sidenote though you might want to
> have a look at the xtensor project 
> (also inspired by numpy). I've not used it yet but I've seen their 
> introduction
> video at PyData  and the approach looks
> great! I think it could give you some ideas if you want to create a generic
> package for machine learning in elm.
>
> Cheers,
> Matthieu
>
>
> On Tuesday, October 31, 2017 at 5:32:06 AM UTC-7, Francisco Ramos wrote:
>>
>> Today I'm releasing NumElm, another small contribution to the Open
>> Source, Frontend and Elm community. NumElm is inspired by NumPy, the
>> fundamental package for scientific computing with Python. NumElm is the
>> first step in this ambitious idea of mine of building a Machine Learning
>> package for Elm. Still a long way to go, but I'm full of enthusiasm. I'm
>> convinced about the potential of both worlds together, Elm language and
>> Machine Learning.
>>
>> https://github.com/jscriptcoder/numelm
>>
>> Please, any feedback would be highly appreciated.
>>
>> Fran
>>
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: The NumPy for Elm

[Francisco Ramos]

Hey Rupert,

Let me have a look when I have a little bit of time and I'll get back to
you.

Fran

On Thu, Nov 2, 2017, 15:41 'Rupert Smith' via Elm Discuss <
elm-discuss@googlegroups.com> wrote:

> On Wednesday, November 1, 2017 at 8:38:48 PM UTC, Rupert Smith wrote:
>>
>> How would I write a curve fitting alrogithm with this? So I have a 3rd
>> order polynomial:
>>
>> y = a + b.x + c.x^2 + d.x^3
>>
>> and some linear algebra on 100 data points will yield values for a, b, c
>> and d. I'll post up the python code tomorrow, it seems to use an in-built
>> fit_curve() function.
>>
>
> Here is the NumPy code that I would like to convert to NumElm:
>
> import time
> import numpy as nm
>
> def get_curve(measurements, timestamps):
>   y = measurements
>   x = timestamps
>   z = nm.polyfit(x, y, 3)
>   f = nm.poly1d(z)
>
>
>   return f
>
>
> but polyfit and poly1d have not been ported to NumElm. I will take a look
> into how to port them.
>
> Rupert
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: The NumPy for Elm

['Rupert Smith' via Elm Discuss]

On Wednesday, November 1, 2017 at 8:38:48 PM UTC, Rupert Smith wrote:
>
> How would I write a curve fitting alrogithm with this? So I have a 3rd 
> order polynomial:
>
> y = a + b.x + c.x^2 + d.x^3
>
> and some linear algebra on 100 data points will yield values for a, b, c 
> and d. I'll post up the python code tomorrow, it seems to use an in-built 
> fit_curve() function.
>

Here is the NumPy code that I would like to convert to NumElm: 

import time
import numpy as nm

def get_curve(measurements, timestamps):
  y = measurements
  x = timestamps
  z = nm.polyfit(x, y, 3)
  f = nm.poly1d(z)


  return f


but polyfit and poly1d have not been ported to NumElm. I will take a look 
into how to port them.

Rupert

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Multiple "Middleware" pattern instead of single *.program

[Martin Janiczek]

On Thursday, November 2, 2017 at 12:56:52 PM UTC+1, Martin Janiczek wrote:
 

> I have added a Navigation middleware example, see the updated demo: 
> https://janiczek.github.io/middleware/index.html
> (Because *elm-lang/navigation* doesn't expose the *Location -> msg -> Sub 
> msg*, I've had to copy it to the user-space code to be able to connect 
> the subscription to the middleware.)
>

(Of course I meant *(Location -> msg) -> Sub msg*.)

It seems to me that the Navigation example doesn't gain much from being 
written in middleware pattern. It's *better than the *.program approach* in 
that it can compose, but it's *worse than Sub approach* in that user 
doesn't see where the Location msg came from. (In my opinion, it's better 
to be explicit.)
The time-travel middleware does, I think, still have its value in being in 
the middleware pattern: it's more "invasive" change, *view* and all, and 
wouldn't be suited by simple Cmd/Sub.

I assume the reason Navigation has opted for the *.program approach, is the 
custom *init* function. This (init) is one thing I haven't yet thought 
about much for the middleware, and is probably subject to change. There 
probably exists some nice middleware example that would make the API more 
clear. Food for thought :)

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Multiple "Middleware" pattern instead of single *.program

[Martin Janiczek]

On Thursday, November 2, 2017 at 10:30:10 AM UTC+1, Rupert Smith wrote: 
>
> One problem I had was with TimeTravel.program which I was wrapping a 
> RouteUrl.navigationApp with. All the messages were then nested at the 
> time-travel level, and its UI did not support nested filtering, so I could 
> not easily filter out animation messages. It occurs to me that if each 
> middleware knows about the next layer, and has wrap/unwrap functions for 
> it, that it would be possible to have set up the time-travel layer to 
> unwrap the nested messages, if I had such a system as yours.
>

Right now that seems problematic: the composing functions can't inspect the 
types in runtime (to decide how much to unwrap), and the amount of wrapping 
the time-travel middleware will see depends on where you'll put it in the 
chain. It would make sense to put it right next to the user program - no 
middle layers to unwrap then.
 

> Would love to see what a navigation example looks like.
>

I have added a Navigation middleware example, see the updated demo: 
https://janiczek.github.io/middleware/index.html
(Because *elm-lang/navigation* doesn't expose the *Location -> msg -> Sub 
msg*, I've had to copy it to the user-space code to be able to connect the 
subscription to the middleware.)

This brought a minor change to the API: middleware's *subscriptions* now 
take the *programMsgs* record and return *(Sub msg, Sub programMsg)*.

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Multiple "Middleware" pattern instead of single *.program

['Rupert Smith' via Elm Discuss]

On Thursday, November 2, 2017 at 12:09:55 AM UTC, Martin Janiczek wrote:
>
>
>1. Is this a good idea at all?
>
> Having stacked a few programs together by hand, this strikes me as an 
excellent idea and one that is worth exploring.

One problem I had was with TimeTravel.program which I was wrapping a 
RouteUrl.navigationApp with. All the messages were then nested at the 
time-travel level, and its UI did not support nested filtering, so I could 
not easily filter out animation messages. It occurs to me that if each 
middleware knows about the next layer, and has wrap/unwrap functions for 
it, that it would be possible to have set up the time-travel layer to 
unwrap the nested messages, if I had such a system as yours.

Would love to see what a navigation example looks like.

Rupert

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.