5 ms·

I would also add parametric types to that list. I've always found it really annoying not to be able to define a type like "array" with element-type, dimensions

by enupten 12y ago

I would also add parametric types to that list. I've always found it really annoying not to be able to define a type like "array" with element-type, dimensions and things (other than the global variable hack). Did you mean Scientific computing ? FEMLISP is refreshingly well written (and fast), and the new version Matlisp I'm writing should also be as good (if less elegant and MOP-py). See: https://github.com/enupten/matlisp/wiki https://github.com/enupten/matlisp/wiki . The "einstein-sum" macro at the end actually generates code which on SBCL is about 20-40% slower than equivalent C code (but this is all naive cache-friendly loops).

orbifold 12y ago
I think a lot of the features Julia julialang.org has, could be implemented just as easily in Common Lisp. Macros in general are much simpler to use to generate domain specific code than templates in C++ are, yet there are tons of very high effort numerical algorithms implemented in C++ and virtually none in Common Lisp.
- enupten 12y ago
  Did you see the wiki ?
  - orbifold 12y ago
    Yes, maybe it wasn't clear, my comment was meant as a reinforcement of your statement. The einstein-sum example is in line with what some C++ libraries can do, but I expect the common lisp implementation to be much simpler. Even more complex libraries like deal.II for pde-solving would probably benefit immensily from a domain specific language instead of a C++ interface.
    - enupten 12y ago
      Can you elaborate on what you mean by "simpler" ? Drop me a mail if you like.
- scottlocklin 12y ago
  A CL with useful math facilities and a decent parallel model would be, like, a zillion times better than anything happening in Julia land. It's not like there isn't a market for something like this: the existence of Incanter and the past existence of XLispStat ought to have demonstrated this. Incanter, of course, will never have adequate numerics performance because the JVM is garbage for numerics, and probably always will be. As I said: Fateman demonstrated that this is possible using CMU-CL or Allegro or whatever it was ... decades ago. Sadly, it never happened.
scottlocklin 12y ago
FEMLISP is pretty cool. Sadly, when I need to do finite element analysis, I end up doing it in Matlab, because vastly more work has been done there. I guess the next time I have to make my own FTDT solver, I will think about doing something like this. Thanks for working on Matlisp; it's a great idea. Have a close look at Torch7 and how they managed to bake pthreads and CUDA into their "THTensor" class (aka, the descendant of the Lush -idx- array type). I don't know if it's the best that can be done, but I trust what has been done there more than what is happening in other areas, as this ends up being used on serious problems.

by enupten 12y ago

orbifold 12y ago

I think a lot of the features Julia julialang.org has, could be implemented just as easily in Common Lisp. Macros in general are much simpler to use to generate domain specific code than templates in C++ are, yet there are tons of very high effort numerical algorithms implemented in C++ and virtually none in Common Lisp.

enupten 12y ago
Did you see the wiki ?
- orbifold 12y ago
  Yes, maybe it wasn't clear, my comment was meant as a reinforcement of your statement. The einstein-sum example is in line with what some C++ libraries can do, but I expect the common lisp implementation to be much simpler. Even more complex libraries like deal.II for pde-solving would probably benefit immensily from a domain specific language instead of a C++ interface.
  - enupten 12y ago
    Can you elaborate on what you mean by "simpler" ? Drop me a mail if you like.
scottlocklin 12y ago
A CL with useful math facilities and a decent parallel model would be, like, a zillion times better than anything happening in Julia land. It's not like there isn't a market for something like this: the existence of Incanter and the past existence of XLispStat ought to have demonstrated this. Incanter, of course, will never have adequate numerics performance because the JVM is garbage for numerics, and probably always will be. As I said: Fateman demonstrated that this is possible using CMU-CL or Allegro or whatever it was ... decades ago. Sadly, it never happened.

scottlocklin 12y ago

FEMLISP is pretty cool. Sadly, when I need to do finite element analysis, I end up doing it in Matlab, because vastly more work has been done there. I guess the next time I have to make my own FTDT solver, I will think about doing something like this. Thanks for working on Matlisp; it's a great idea. Have a close look at Torch7 and how they managed to bake pthreads and CUDA into their "THTensor" class (aka, the descendant of the Lush -idx- array type). I don't know if it's the best that can be done, but I trust what has been done there more than what is happening in other areas, as this ends up being used on serious problems.