I guess I need to find an excuse to pass through singapore for business!
Best, -tony
On 10/19/12, David Hodge davidbhodge@gmail.com wrote:
Its a good idea - with a bit of refactoring I think changing the numerical layer should not be to hard.
something to think about.
Steve and I are meeting tomorrow, this is definitely on the list of things to discuss, apart from beer and saying
:)
On 19/10/2012, at 3:58 PM, "A.J. Rossini" blindglobe@gmail.com wrote:
Sounds good!
Am happy to help, my end goal is to play with a lispy statistically clear DSL, not write numerics :-).
As long as we get solid numerics, I'm happy to use macros to play around with the interfaces I want to see on the dsl, unless every happens to like what I like.
Clone and pull/push requests seem to be best, making branches which reflect author names and topics or both name-and-topic.
Shared access works as well, but not reason not to keep separate.
Best,-tony
On 10/19/12, Mirko Vukovic mirko.vukovic@gmail.com wrote:
Based on a recent discussionhttps://groups.google.com/d/topic/lisp-stat/sYBndICy_HA/discussionon the Common Lisp Statistics group, I decided to start a github project numerical-lisp https://github.com/mirkov/numerical-lisp.
The purpose of the project is to serve as an ordered (as much as possible) collection of thoughts on what would make a useful and powerful system for numerical programming, analysis and visualization based on common-lisp. I suspect the discussion will be taking place on the common lisp statistics group, antik, and maybe others. I don't think that we should form yet another discussion forum. Coding would start in the next few months.
The project would depend a great deal on Antik, gsll, cl-num-utils, and other numerical libraries. The goal is not to start yet another incompatible numerical library. Instead, the goal is to provide a flexible
framework into which one can plug in existing libraries with relatively little modification.
When it comes to coding, there will be relatively little intense numerical or graphics coding. Instead, we should use as many of already existing resources and libraries already available, and allow enough flexibility so as not to be locked to a particular library. We should also look at other systems (R, numpy, Matlab, mathematica, Macsyma), and incorporate their best features, albeit in a lispy way. The project may boil down to software engineering, and good language design (maybe we should study Fortress for hints)
Right now the project is quite empty, and I will add to it over the coming weeks. Once I figure out how github operates for collaborative work, I would welcome contributions from others as well.
I hope this to be a community effort.
Mirko
-- You received this message because you are subscribed to the Google Groups "Common Lisp Statistics" group. To post to this group, send email to lisp-stat@googlegroups.com. To unsubscribe from this group, send email to lisp-stat+unsubscribe@googlegroups.com. Visit this group at http://groups.google.com/group/lisp-stat?hl=en.
-- best, -tony
blindglobe@gmail.com Muttenz, Switzerland. "Commit early,commit often, and commit in a repository from which we can easily roll-back your mistakes" (AJR, 4Jan05).
Drink Coffee: Do stupid things faster with more energy!
-- You received this message because you are subscribed to the Google Groups "Common Lisp Statistics" group. To post to this group, send email to lisp-stat@googlegroups.com. To unsubscribe from this group, send email to lisp-stat+unsubscribe@googlegroups.com. Visit this group at http://groups.google.com/group/lisp-stat?hl=en.
-- You received this message because you are subscribed to the Google Groups "Common Lisp Statistics" group. To post to this group, send email to lisp-stat@googlegroups.com. To unsubscribe from this group, send email to lisp-stat+unsubscribe@googlegroups.com. Visit this group at http://groups.google.com/group/lisp-stat?hl=en.