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
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.
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.
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.
failing that there is always Skype
On 19/10/2012, at 6:44 PM, "A.J. Rossini" blindglobe@gmail.com wrote:
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.
-- 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.
Hi Tony & list members,
Steve and I have sat here at the Changi Sailing CLub in Singapore and considered the problem of climate warming, solving world hunger and bringing about global peace. Incredibly, we also managed to spare some cycles for CLS. As a priority, we'd like to suggest that re-building the community should be the first priority. This is simply too big for one person to tackle without it being a full-time job.
So, we'd like to suggest, in a rough priority order
1. Make CLS "quicklispable" - quite important from the viewpoint of promoting adoption in the community and just for general ease of use. I am nearly there with that, I think. But will need some guidance tom Zach to know how to package things up.
2. Documentation. Publish a project webpage, and get some level of documentation published asap. (using the gsll /antik documentation as an example fork instance). Not only a single reference source, but it will contribute to the building of a community.
3. Numeric library. In another email I proposed we start with GSL as the replacement for liblispstat. Unless I hear something to the contrary, I will proceed with integrating that.
4. Unit tests. Changing to gsl above will require that we revise the current tests.
5. Develop an agreed roadmap for the next few months once we have a baseline established. For instance i Know Steve is interested in PMML and leveraging regression models, so that might be the first cab off the rank in terms of function
There are some other software engineering hygiene matter in terms of identifying what implemented and whats not in the source and just getting the workflow between us all settled. There's a fair amount of bit-rot and work that's required to get this up to modern standards. And I (david, that is) promise to push all my changes for review next weekend. Probably won't be able to do it this weekend, due to an urgent project in Malaysia.
We'd also like to suggest attempting to get a few select people on board by invite, for example Luke., Tamas, Mirko
So, one thing that would be useful would be to arrange some sort of Skype conference, or audio conference to nail down any agreements - so wondering when we might be able to do that. Next weekend is a long weekend in Singapore, so possibly we can make something happen then.
Cheers
Steve and David
On 19/10/2012, at 6:44 PM, A.J. Rossini blindglobe@gmail.com wrote:
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.
-- 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.
Gents,
I was giving this a bit of thought and wonder where we should start, from a version perspective. I recall when reviewing what needed to be done with David that we need to remove a lot of libraries and cruft, so would like to pose the question: Would we be better off starting from Luke's original port and then adding what we need? Seems that if we could get that original port up to snuff we'd have a good starting point to add too.
I seem to recall that the process of converting from xlisp objects to CLOS was incomplete. Does anyone know for certain the state of the object system in CLS (original)?
Regards, - Steve Nunez
-
A.J. Rossini -
David Hodge -
Mirko Vukovic -
Steven Núñez