Random forest in Pharo
Locked
123
123
 
|
Hi,
did anyone implement a Random Forest algorithm in Pharo? https://en.wikipedia.org/wiki/Random_forest -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill |
|
|
I don't think so.
I followup your message on SciSmalltalk mailing-list. This is something that might interested us ;-) On Wed, Oct 14, 2015 at 4:54 PM, Damien Cassou <[hidden email]> wrote: > Hi, > > did anyone implement a Random Forest algorithm in Pharo? > > https://en.wikipedia.org/wiki/Random_forest > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." --Winston Churchill > -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/ |
Re: Random forest in Pharo
|
|
Not sure you would get enough performance on Pharo per se. Xe may be better off leveraging a multicore enabled external lib. Like caret and doMC on R. Le 14 oct. 2015 17:49, "Serge Stinckwich" <[hidden email]> a écrit :
I don't think so. |
|
|
We do not want to be bound to install and maintain connection with
fifteen different libs.
Stef Le 14/10/15 18:01,
[hidden email] a écrit :
|
|
|
yeah but if this is a special case there is no problems on doing FFI bindings and using an external library.
Precisely for that is FFI. not that we have to integrate everything into the image :)
but… I would not be so fast in assume pharo performance will not be enough. Unique form to know it is to do it and then see how you can optimise, if needed :) Esteban
|
Re: Random forest in Pharo
|
|
I guess you aren't doing lots of random forests. RFs training is the best way to turn my PC into a heater. Phil Phil Le 15 oct. 2015 14:19, "Esteban Lorenzano" <[hidden email]> a écrit :
|
Re: Random forest in Pharo
|
|
I would see the FFI integration being much more approachable. In R, Python, Tcl, and now Java with JNA things are going nicely. Why is it a pain on our platform and why insist on doing all in Pharo? This is holding us back. Pharo is super strong at some things. We just do not need it to be redoing everything when good business is at hand and industry standard libs available. A reason why we try to use libgit2 I guess. Something external. Phil Le 15 oct. 2015 14:29, "[hidden email]" <[hidden email]> a écrit :
|
|
|
In reply to this post by philippe.back@highoctane.be
I do not do any :) In fact I didn’t know what was about until I read the wiki page ;)
|
|
|
In reply to this post by philippe.back@highoctane.be
I agree.
My point was not a “let do all in pharo”, it was more against assumptions :) Esteban
|
|
|
Yes, we need excellent FFI. I would love to see in Pharo FFI as easy
as Julia [1] or LuaJIT [2]. I am not qualified to do deliver such.
And I do not know how possible, how much effort or likely it is.
Sometimes connecting to an external library is a requirement. It would be nice to be able to easily do so. I had problems with NB and it never happened. But, on the other hand. I am a big believer and advocate of keeping as much as possible in Pharo. Even if there are libraries available via FFI. Now I know being practical and expedient sometimes using the libraries is necessary at least initially. I would love as much as possible in Pharo, in our language. This makes it available for us to improve, fix, and learn. It reduces the barrier for entry for those who only know Pharo. We can't do any of those things if it is in a foreign language in a foreign library. Reinventing the wheel so to speak is not always evil. But we do have to know our resources, time, people, community, skills. And as a Smalltalk or Smalltalk inspired tool. We need to have a long view of the world. We already have a longer history than most languages. We should likewise look forward to an even longer future. Always keep the big picture in front of us to inspire through the tedious minutiae that we may currently have to deal with. And by the way. I would love having Random Forests and other scientific, statistic tools in Pharo. I need to look at the SciSmalltalk stuff. Just a few thoughts. Jimmie [1] http://docs.julialang.org/en/release-0.4/manual/calling-c-and-fortran-code [2] http://luajit.org/ext_ffi_tutorial.html On 10/15/2015 07:51 AM, Esteban
Lorenzano wrote:
I agree. |
|
|
On Thu, Oct 15, 2015 at 3:50 PM, Jimmie Houchin <[hidden email]> wrote:
> Yes, we need excellent FFI. I would love to see in Pharo FFI as easy as > Julia [1] or LuaJIT [2]. I am not qualified to do deliver such. And I do not > know how possible, how much effort or likely it is. > > Sometimes connecting to an external library is a requirement. It would be > nice to be able to easily do so. I had problems with NB and it never > happened. > > But, on the other hand. I am a big believer and advocate of keeping as much > as possible in Pharo. Even if there are libraries available via FFI. Now I > know being practical and expedient sometimes using the libraries is > necessary at least initially. > > I would love as much as possible in Pharo, in our language. This makes it > available for us to improve, fix, and learn. It reduces the barrier for > entry for those who only know Pharo. We can't do any of those things if it > is in a foreign language in a foreign library. Reinventing the wheel so to > speak is not always evil. But we do have to know our resources, time, > people, community, skills. And as a Smalltalk or Smalltalk inspired tool. We > need to have a long view of the world. We already have a longer history than > most languages. We should likewise look forward to an even longer future. > Always keep the big picture in front of us to inspire through the tedious > minutiae that we may currently have to deal with. > > And by the way. I would love having Random Forests and other scientific, > statistic tools in Pharo. I need to look at the SciSmalltalk stuff. You can join on SciSmalltalk mailing-list: https://groups.google.com/forum/#!forum/scismalltalk We have a repository here also: https://github.com/SergeStinckwich/SciSmalltalk Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/ |
|
|
In reply to this post by Jimmie Houchin-5
in pharo a FFI call is as easy as: copy: source to: dest <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode> self nbCall: #( char * strcpy( char *dest, char *source ) ) module: ‘libc’. we can improve performance, but I do not think we will succeed on make it easier than that. of course, someone could do a symbol introspector (and I think someone already did something to interpret header files), to be able to have things like: LibC.strcpyWith: dest with: source but I do not thing is a big win over the first one. Esteban
|
|
|
Thanks for the example.
On 10/15/2015 09:04 AM, Esteban
Lorenzano wrote:
That does not look to difficult. Now my current problem is that we are being told that NativeBoost is going away. Then what does FFI look like and with what? The main problem I had with NativeBoost is that it had problems I couldn't understand or fix. And problems that Igor didn't have time for. I was writing a wrapper around a proprietary library. The small part I had written to test out Pharo and NB worked on Windows and crashed in Linux. Exact same code. This message from April 3, 2013 is my request for help. http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2013-April/076934.html I never got anywhere with that project. Thus goes my tortured history with Pharo and programming. Not a judgment against Igor or Pharo. I know the resources of both are stretched to the max. And I am complicit in the problem as I have to few skills to help myself. So it did and sometimes does, send me on programming journeys to explore other languages and tools to empower me within my abilities. I could have done that project in LuaJIT or Julia when it matures a little more. Julia might be approaching that point. My torture is pursuing the language/environment I enjoy, Pharo. Which sometimes can or sometimes can not easily do what I need within my skill set. Or pursuing learning other languages and tools which are better at integrating other external libraries. Or do to the much larger communities have already ready to use wrappers around most anything you want to do. I am no longer pursuing that project. My requirements have changed and I do not require wrapping a proprietary C library. I am reticent to invest in learning FFI that is changing without an idea of the direction of the change. So at the moment I am studying SQL and then possibly spend some time learning C so that I can better help myself and the community and not be as dependent. That way when the dust settles on the FFI as will be in Pharo5/6. I can hopefully be better to use and contribute. Thanks. Jimmie Jimmie [snip] |
|
|
NB is going away in spur, BUT NOT his syntax… you still will do FFI calls in the old way. This is going to be 95% compatible (so far, I needed to introduce changes on: structures and callbacks… all the rest is same… and the changes are not really complicated to adapt). Now, is a bit frustrating because I have said this millions of times (at least once for each one I say we are removing NB… and I’m the only one saying it :P) Esteban
|
|
|
Thanks for the information.
And thank you for all that you do to move Pharo forward. I know some of this must be tedious. But Pharo is getting more beautiful all the time. Jimmie On 10/15/2015 10:02 AM, Esteban
Lorenzano wrote:
|
|
|
In reply to this post by Jimmie Houchin-5
On 10/15/2015 10:51 AM, Jimmie Houchin wrote: > Thanks for the example. > > On 10/15/2015 09:04 AM, Esteban Lorenzano wrote: >> >>> On 15 Oct 2015, at 15:50, Jimmie Houchin >>> <<mailto:[hidden email]>[hidden email]> wrote: >>> >>> Yes, we need excellent FFI. I would love to see in Pharo FFI as easy >>> as Julia [1] or LuaJIT [2]. I am not qualified to do deliver such. >>> And I do not know how possible, how much effort or likely it is. >> >> in pharo a FFI call is as easy as: >> >> copy: source to: dest >> <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: >> errorCode> >> self nbCall: #( char * strcpy( char *dest, char *source ) ) module: >> ‘libc’. >> >> we can improve performance, but I do not think we will succeed on make >> it easier than that. >> >> of course, someone could do a symbol introspector (and I think someone >> already did something to interpret header files), to be able to have >> things like: >> >> LibC.strcpyWith: dest with: source >> >> but I do not thing is a big win over the first one. >> >> Esteban > > That does not look to difficult. > > Now my current problem is that we are being told that NativeBoost is > going away. Then what does FFI look like and with what? > > The main problem I had with NativeBoost is that it had problems I > couldn't understand or fix. And problems that Igor didn't have time for. > I was writing a wrapper around a proprietary library. The small part I > had written to test out Pharo and NB worked on Windows and crashed in > Linux. Exact same code. > > This message from April 3, 2013 is my request for help. > http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2013-April/076934.html > > I never got anywhere with that project. Thus goes my tortured history > with Pharo and programming. Not a judgment against Igor or Pharo. I know > the resources of both are stretched to the max. And I am complicit in > the problem as I have to few skills to help myself. So it did and > sometimes does, send me on programming journeys to explore other > languages and tools to empower me within my abilities. I could have done > that project in LuaJIT or Julia when it matures a little more. Julia > might be approaching that point. > > My torture is pursuing the language/environment I enjoy, Pharo. Which > sometimes can or sometimes can not easily do what I need within my skill > set. Or pursuing learning other languages and tools which are better at > integrating other external libraries. Or do to the much larger > communities have already ready to use wrappers around most anything you > want to do. > > I am no longer pursuing that project. My requirements have changed and I > do not require wrapping a proprietary C library. > > I am reticent to invest in learning FFI that is changing without an idea > of the direction of the change. So at the moment I am studying SQL and > then possibly spend some time learning C so that I can better help > myself and the community and not be as dependent. That way when the dust > settles on the FFI as will be in Pharo5/6. I can hopefully be better to > use and contribute. Exactly right, I feel the same way. I thank you for expressing yourself thusly and being a mirror in words of my own passion. Best, Robert > > > Thanks. > > Jimmie > Jimmie > > [snip] |
|
|
> On 15 Oct 2015, at 17:35, Robert Withers <[hidden email]> wrote: > > > > On 10/15/2015 10:51 AM, Jimmie Houchin wrote: >> Thanks for the example. >> >> On 10/15/2015 09:04 AM, Esteban Lorenzano wrote: >>> >>>> On 15 Oct 2015, at 15:50, Jimmie Houchin >>>> <<mailto:[hidden email]>[hidden email]> wrote: >>>> >>>> Yes, we need excellent FFI. I would love to see in Pharo FFI as easy >>>> as Julia [1] or LuaJIT [2]. I am not qualified to do deliver such. >>>> And I do not know how possible, how much effort or likely it is. >>> >>> in pharo a FFI call is as easy as: >>> >>> copy: source to: dest >>> <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: >>> errorCode> >>> self nbCall: #( char * strcpy( char *dest, char *source ) ) module: >>> ‘libc’. >>> >>> we can improve performance, but I do not think we will succeed on make >>> it easier than that. >>> >>> of course, someone could do a symbol introspector (and I think someone >>> already did something to interpret header files), to be able to have >>> things like: >>> >>> LibC.strcpyWith: dest with: source >>> >>> but I do not thing is a big win over the first one. >>> >>> Esteban >> >> That does not look to difficult. >> >> Now my current problem is that we are being told that NativeBoost is >> going away. Then what does FFI look like and with what? >> >> The main problem I had with NativeBoost is that it had problems I >> couldn't understand or fix. And problems that Igor didn't have time for. >> I was writing a wrapper around a proprietary library. The small part I >> had written to test out Pharo and NB worked on Windows and crashed in >> Linux. Exact same code. >> >> This message from April 3, 2013 is my request for help. >> http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2013-April/076934.html >> >> I never got anywhere with that project. Thus goes my tortured history >> with Pharo and programming. Not a judgment against Igor or Pharo. I know >> the resources of both are stretched to the max. And I am complicit in >> the problem as I have to few skills to help myself. So it did and >> sometimes does, send me on programming journeys to explore other >> languages and tools to empower me within my abilities. I could have done >> that project in LuaJIT or Julia when it matures a little more. Julia >> might be approaching that point. >> >> My torture is pursuing the language/environment I enjoy, Pharo. Which >> sometimes can or sometimes can not easily do what I need within my skill >> set. Or pursuing learning other languages and tools which are better at >> integrating other external libraries. Or do to the much larger >> communities have already ready to use wrappers around most anything you >> want to do. >> >> I am no longer pursuing that project. My requirements have changed and I >> do not require wrapping a proprietary C library. >> >> I am reticent to invest in learning FFI that is changing without an idea >> of the direction of the change. So at the moment I am studying SQL and >> then possibly spend some time learning C so that I can better help >> myself and the community and not be as dependent. That way when the dust >> settles on the FFI as will be in Pharo5/6. I can hopefully be better to >> use and contribute. > > Exactly right, I feel the same way. I thank you for expressing yourself thusly and being a mirror in words of my own passion. FFI is a complicated issue, and we have made some mistakes. There is no shame on being upset with it… we tried to do something cool and at the end we failed, now we are following a different path (as cool as the other, but different). I hope we will stabilise FFI this version (Pharo 5), but of course, I cannot promise 100% crash-free, specially when what you are doing (call out the vm) escapes to vm control :) but well… in the mean time we learn and do steps. We will have a cool FFI, don’t worry… sooner than later :D Esteban > > Best, > Robert > > >> >> >> Thanks. >> >> Jimmie >> Jimmie >> >> [snip] > |
|
|
On 10/15/2015 11:46 AM, Esteban Lorenzano wrote: > >> On 15 Oct 2015, at 17:35, Robert Withers <[hidden email]> wrote: >> >> >> >> On 10/15/2015 10:51 AM, Jimmie Houchin wrote: >>> Thanks for the example. >>> >>> On 10/15/2015 09:04 AM, Esteban Lorenzano wrote: >>>> >>>>> On 15 Oct 2015, at 15:50, Jimmie Houchin >>>>> <<mailto:[hidden email]>[hidden email]> wrote: >>>>> >>>>> Yes, we need excellent FFI. I would love to see in Pharo FFI as easy >>>>> as Julia [1] or LuaJIT [2]. I am not qualified to do deliver such. >>>>> And I do not know how possible, how much effort or likely it is. >>>> >>>> in pharo a FFI call is as easy as: >>>> >>>> copy: source to: dest >>>> <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: >>>> errorCode> >>>> self nbCall: #( char * strcpy( char *dest, char *source ) ) module: >>>> ‘libc’. >>>> >>>> we can improve performance, but I do not think we will succeed on make >>>> it easier than that. >>>> >>>> of course, someone could do a symbol introspector (and I think someone >>>> already did something to interpret header files), to be able to have >>>> things like: >>>> >>>> LibC.strcpyWith: dest with: source >>>> >>>> but I do not thing is a big win over the first one. >>>> >>>> Esteban >>> >>> That does not look to difficult. >>> >>> Now my current problem is that we are being told that NativeBoost is >>> going away. Then what does FFI look like and with what? >>> >>> The main problem I had with NativeBoost is that it had problems I >>> couldn't understand or fix. And problems that Igor didn't have time for. >>> I was writing a wrapper around a proprietary library. The small part I >>> had written to test out Pharo and NB worked on Windows and crashed in >>> Linux. Exact same code. >>> >>> This message from April 3, 2013 is my request for help. >>> http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2013-April/076934.html >>> >>> I never got anywhere with that project. Thus goes my tortured history >>> with Pharo and programming. Not a judgment against Igor or Pharo. I know >>> the resources of both are stretched to the max. And I am complicit in >>> the problem as I have to few skills to help myself. So it did and >>> sometimes does, send me on programming journeys to explore other >>> languages and tools to empower me within my abilities. I could have done >>> that project in LuaJIT or Julia when it matures a little more. Julia >>> might be approaching that point. >>> >>> My torture is pursuing the language/environment I enjoy, Pharo. Which >>> sometimes can or sometimes can not easily do what I need within my skill >>> set. Or pursuing learning other languages and tools which are better at >>> integrating other external libraries. Or do to the much larger >>> communities have already ready to use wrappers around most anything you >>> want to do. >>> >>> I am no longer pursuing that project. My requirements have changed and I >>> do not require wrapping a proprietary C library. >>> >>> I am reticent to invest in learning FFI that is changing without an idea >>> of the direction of the change. So at the moment I am studying SQL and >>> then possibly spend some time learning C so that I can better help >>> myself and the community and not be as dependent. That way when the dust >>> settles on the FFI as will be in Pharo5/6. I can hopefully be better to >>> use and contribute. >> >> Exactly right, I feel the same way. I thank you for expressing yourself thusly and being a mirror in words of my own passion. > > FFI is a complicated issue, and we have made some mistakes. There is no shame on being upset with it… we tried to do something cool and at the end we failed, now we are following a different path (as cool as the other, but different). > I hope we will stabilise FFI this version (Pharo 5), but of course, I cannot promise 100% crash-free, specially when what you are doing (call out the vm) escapes to vm control :) Oh, you're good, but enough blame-shifting, let's fix the real problem. :) > > but well… in the mean time we learn and do steps. We will have a cool FFI, don’t worry… sooner than later :D I was thinking about ASMJIT and it's audience. You may attract a broader audience with JVMJIT, including JNI. That would be something, then support cross-calling between Pharo, Newspeak, Groovy, Scala and Java plus dynamic jar loading. You'd need an army to pull that off though. Robert > > Esteban > > >> >> Best, >> Robert >> >> >>> >>> >>> Thanks. >>> >>> Jimmie >>> Jimmie >>> >>> [snip] >> > > |
Mult-language browsers - MLB (was: Re: Random forest in Pharo)
|
|
On 10/15/2015 11:57 AM, Robert Withers wrote: > > > On 10/15/2015 11:46 AM, Esteban Lorenzano wrote: >> >> but well… in the mean time we learn and do steps. We will have a cool >> FFI, don’t worry… sooner than later :D > > I was thinking about ASMJIT and it's audience. You may attract a broader > audience with JVMJIT, including JNI. That would be something, then > support cross-calling between Pharo, Newspeak, Groovy, Scala and Java > plus dynamic jar loading. You'd need an army to pull that off though. Please excuse the reply to the reply, but I was thinking about a JVMJIT and cross-calling. The key to me, experientially, is to have the same browser for all languages. We need a multi-language browser, a MLB. Depending on the CompiledMethod selected, pick the right set of parsers: compiler, pretty printer, code completion, type inferencer and the MLB's method pane would be an editor for the language specified in the compiled method. Furthermore, to support cross-calling, when you are working is a specific language, you can set that as the interaction language and the browser will present interfaces from other languages in the language you have selected, such that a cross-call is really just a native call to an auto-generated wrapper around the other language. Think of Cincom's Distributed Smalltalk talking Corba with their I3 (Implicit Invocation Interface): http://www.cincomsmalltalk.com/main/documentation/VisualWorks/DSTAppDevGuide.pdf I found this thread on Corba and Squeak: http://squeak-dev.squeakfoundation.narkive.com/AbWTL8Kh/smalltalk-and-corba. Bringing I3 support, into the browser would offer the foundations for the MLB. Any feedback is really appreciated! Regards, Robert |
Re: Mult-language browsers - MLB (was: Re: Random forest in Pharo)
|
|
Hi Robert,
did you see http://scg.unibe.ch/research/helvetia? Bye T. > Gesendet: Donnerstag, 15. Oktober 2015 um 18:33 Uhr > Von: "Robert Withers" <[hidden email]> > An: [hidden email] > Betreff: [Pharo-dev] Mult-language browsers - MLB (was: Re: Random forest in Pharo) > > > > On 10/15/2015 11:57 AM, Robert Withers wrote: > > > > > > On 10/15/2015 11:46 AM, Esteban Lorenzano wrote: > >> > >> but well… in the mean time we learn and do steps. We will have a cool > >> FFI, don’t worry… sooner than later :D > > > > I was thinking about ASMJIT and it's audience. You may attract a broader > > audience with JVMJIT, including JNI. That would be something, then > > support cross-calling between Pharo, Newspeak, Groovy, Scala and Java > > plus dynamic jar loading. You'd need an army to pull that off though. > > Please excuse the reply to the reply, but I was thinking about a JVMJIT > and cross-calling. The key to me, experientially, is to have the same > browser for all languages. We need a multi-language browser, a MLB. > > Depending on the CompiledMethod selected, pick the right set of parsers: > compiler, pretty printer, code completion, type inferencer and the MLB's > method pane would be an editor for the language specified in the > compiled method. > > Furthermore, to support cross-calling, when you are working is a > specific language, you can set that as the interaction language and the > browser will present interfaces from other languages in the language you > have selected, such that a cross-call is really just a native call to an > auto-generated wrapper around the other language. > > Think of Cincom's Distributed Smalltalk talking Corba with their I3 > (Implicit Invocation Interface): > http://www.cincomsmalltalk.com/main/documentation/VisualWorks/DSTAppDevGuide.pdf > > I found this thread on Corba and Squeak: > http://squeak-dev.squeakfoundation.narkive.com/AbWTL8Kh/smalltalk-and-corba. > Bringing I3 support, into the browser would offer the foundations for > the MLB. > > Any feedback is really appreciated! > > Regards, > Robert > > |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |