4 ms·

I don't know why no one seems to think about symbolic programming which was the original killer feature of lisp, and one of the main reasons for doing macros.

I don't know why no one seems to think about symbolic programming which was the original killer feature of lisp, and one of the main reasons for doing macros. In math oriented programming this should be one of the most powerful features and skills in order to simplify and modify calculations. Sure you can implement that with macros and AST but that is not at the level of S-Expressions. Everything else is not more important as any other competition of DSLs.

chongli 7y ago
Generally it seems people prefer to keep symbolic and numerical computation separate. Perhaps it's due to the cultural schism between pure and applied mathematics, or perhaps it's something else. Having said that, I think people tend to prefer to work out their final equations using symbolic software before transcribing the functions into a numerical system. Maybe it's too hard to reason about what's going on if your machine is both deriving the equations and computing the numerical result in one go?
jahewson 7y ago
I'm going to speculate wildly and suggest that most math-oriented code nowadays is not analytical, but numerical, where the advantage of having a symbolic system is limited.
ddragon 7y ago
That was the strength of Lisp as the original 'AI' language, but the following AI summer were always more numerical oriented (neural networks, bayesian inference, SVM, neural networks part 2), so that particular strength was not very needed. And in the end the most important killer feature of an 'AI' language ended up being approachable and easy to use, and not the "power", which is why Julia goes with the "Looks like Python, feels like Lisp, runs like Fortran". And like you said, even without s-expr you can do it with macros (especially in a homoiconic language like Julia), for example: https://github.com/chakravala/Reduce.jl https://github.com/chakravala/Reduce.jl https://github.com/korsbo/Latexify.jl https://github.com/korsbo/Latexify.jl
- lispm 7y ago
  There seems to be a market for symbolic maths, too. See: http://wolfram.com/ http://wolfram.com/
- nudpiedo 7y ago
  Somehow you moved the discussion to AI comparisons and macros back again, instead of the point of solving/simplifying math problems by using abstract symbols and grammars. Although Julia can be represented in a homoiconic representation, no one sane can believe that Julia is homoiconic. Unless such person is so optimistic that could believe things such as Europe-Asia-Africa is a big giant island.
cossatot 7y ago
In my experience doing lots of computational science, the analytical/symbolic part of the problem solving is typically done separately, as it really needs to be done once, and (mostly) by hand so that you understand the problem and solution better. Then, once you've gotten the problem and solution framed the way you like, you start implementing the numerical solution of your problem. There are a few exceptions, particularly when things do get hairy. For example one of my colleagues has created a radial basis function finite difference solver[1]. In some of the modules, it manipulates the RBFs using SymPy and then compiles that to C which is then executed by Cython as part of the solution process. [1]: https://github.com/treverhines/RBF/ https://github.com/treverhines/RBF/
- nudpiedo 7y ago
  How is that the “easy things” are done by humans, often in paper and the “hairy” problems are done using a computer? Why not let the computer do all simplifications and precalculations and precomputations? I am an external and maybe I see the things a bit different but if I should write a decimal number I would prefer to keep sqrt(2) as in my code rather than writing an approximate, almost equivalent, float. And I see formula simplifications and analysis in the same way... work to feed the compiler.
ChrisRackauckas 7y ago
We can do this in Julia quite well. ModelingToolkit.jl for example takes in numerical Julia functions and symbolically calculates and builds the function for computing the Jacobian. Example: https://github.com/JuliaDiffEq/ModelingToolkit.jl/pull/155 https://github.com/JuliaDiffEq/ModelingToolkit.jl/pull/155 The JuliaDiffEq team will be pushing symbolics for automatic transformations and automated model order reductions over the next few years. It's already working really well.

chongli 7y ago

Generally it seems people prefer to keep symbolic and numerical computation separate. Perhaps it's due to the cultural schism between pure and applied mathematics, or perhaps it's something else. Having said that, I think people tend to prefer to work out their final equations using symbolic software before transcribing the functions into a numerical system. Maybe it's too hard to reason about what's going on if your machine is both deriving the equations and computing the numerical result in one go?

jahewson 7y ago

I'm going to speculate wildly and suggest that most math-oriented code nowadays is not analytical, but numerical, where the advantage of having a symbolic system is limited.

ddragon 7y ago

That was the strength of Lisp as the original 'AI' language, but the following AI summer were always more numerical oriented (neural networks, bayesian inference, SVM, neural networks part 2), so that particular strength was not very needed. And in the end the most important killer feature of an 'AI' language ended up being approachable and easy to use, and not the "power", which is why Julia goes with the "Looks like Python, feels like Lisp, runs like Fortran". And like you said, even without s-expr you can do it with macros (especially in a homoiconic language like Julia), for example: https://github.com/chakravala/Reduce.jl https://github.com/chakravala/Reduce.jl https://github.com/korsbo/Latexify.jl https://github.com/korsbo/Latexify.jl

lispm 7y ago
There seems to be a market for symbolic maths, too. See: http://wolfram.com/ http://wolfram.com/
nudpiedo 7y ago
Somehow you moved the discussion to AI comparisons and macros back again, instead of the point of solving/simplifying math problems by using abstract symbols and grammars. Although Julia can be represented in a homoiconic representation, no one sane can believe that Julia is homoiconic. Unless such person is so optimistic that could believe things such as Europe-Asia-Africa is a big giant island.

cossatot 7y ago

In my experience doing lots of computational science, the analytical/symbolic part of the problem solving is typically done separately, as it really needs to be done once, and (mostly) by hand so that you understand the problem and solution better. Then, once you've gotten the problem and solution framed the way you like, you start implementing the numerical solution of your problem. There are a few exceptions, particularly when things do get hairy. For example one of my colleagues has created a radial basis function finite difference solver[1]. In some of the modules, it manipulates the RBFs using SymPy and then compiles that to C which is then executed by Cython as part of the solution process. [1]: https://github.com/treverhines/RBF/ https://github.com/treverhines/RBF/

nudpiedo 7y ago
How is that the “easy things” are done by humans, often in paper and the “hairy” problems are done using a computer? Why not let the computer do all simplifications and precalculations and precomputations? I am an external and maybe I see the things a bit different but if I should write a decimal number I would prefer to keep sqrt(2) as in my code rather than writing an approximate, almost equivalent, float. And I see formula simplifications and analysis in the same way... work to feed the compiler.

ChrisRackauckas 7y ago

We can do this in Julia quite well. ModelingToolkit.jl for example takes in numerical Julia functions and symbolically calculates and builds the function for computing the Jacobian. Example: https://github.com/JuliaDiffEq/ModelingToolkit.jl/pull/155 https://github.com/JuliaDiffEq/ModelingToolkit.jl/pull/155 The JuliaDiffEq team will be pushing symbolics for automatic transformations and automated model order reductions over the next few years. It's already working really well.