!!! Caveat: This post presents some speculative suggestions, not to be
interpreted

as a definitive plan or mandate for work-to-be-done or anything like

that; just as an interesting-looking directly for investigation


TL;DR — particularly for use of OpenCog in bioinformatics and other

scientific-computing applications — but also for other applications like

corpus linguistics where one deals with large datasets and wants to

combine OpenCog with other command-line tools — it might be a good

idea to replace or supplement our current Guile shell with a wrapping-up

of OpenCog in Common Lisp … and in particular in the CLASP Common

Lisp framework that Christian Schafmeister has developed.   This would

also have some other smaller side-benefits like letting us exploit the CL

bindings for Jupiter Notebooks which would be cool for OpenCog

tutorials; and making it easy to generate LISP bindings for ROS, thus

avoiding the need to deal with ros-py for OpenCog robotics applications…


Basic reasons are: CLASP is efficient at handling large datasets and

piping them from one place to another.   It can also automatically

generate bindings for C++ code, which could be used to auto-generate

LISP bindings for ROS….


…


So I met Christian Schafmeister at an AI-nanotech workshop in Palo

Alto late last month, and I became aware of this really cool LISP

environment for scientific computing that he's been developing...


https://github.com/drmeister/clasp


https://github.com/drmeister/cando


https://drmeister.wordpress.com/


He has some strong arguments as to why this is a better way than R or

python to get scientific computing done on large datasets….


One thing he found is that in many of his computational chemistry

analysis scripts, the bulk of compute time was getting taken up

passing around datasets and results between different C++ programs,

in R or python or whatever other glue language was being used…


Via using Common LISP compiled into LLVM, he found this could be

worked around, because one could then script stuff in CL but have

efficient garbage collection done via LLVM …


My speculative line of thinking now is that it might be interesting to


-- supplement or replace Guile with Clasp as a shell for working with OpenCog


-- Integrate C++ bio-analytics tools into Clasp, in a similar way to

what Schafmeister has been doing for chem-analytics tools


— Integrate R bio-analytics tools into Clasp as well, using the following

LLVM compiler for R


https://github.com/duncantl/RLLVMCompile


https://arxiv.org/abs/1409.3144


(although I note this compiler appears to still need a bit of work to be fully

generally usable…)


— Use the Clasp tools for automatically generating and updating LISP bindings

for C++ code, to auto-generating ROS bindings for CL


— Use the Jupyter Notebooks wrapping for CL to make Jupyter tutorials

for OpenCog


(although, as a side note, integrating Guile with Jupyter Notebooks

would also not be impossible ... it would just be a bunch of work,

like any of this…)


…


I note, one can auto-convert Guile to Common Lisp using existing available

scripts, though obviously this will require some hand-checking afterwards...

For OpenCog uses of Guile that are basically just “Guile wrapping Atomese”,

auto-conversion to CL would likely work fine.  For cases where there is

more actual programming done in Guile, more hand-adjustment of conversions

to CL would probably be necessary..


One could also emulate what Schafmeister did for C++, and auto-generate CL

bindings for R packages.  Although much of the time, the R packages are just

wrapping C++ functions; so in those cases, it might sometimes be better just

to bypass R and go straight from the underlying C++ functions to CL …


Another possibility would be to develop R-like syntax in a domain-specific

language within CL … much as we’re now developing ChatScript-like

syntax within Guile for authoring content for the Hanson robots…


…


Anyway it is not yet clear that the above would be a great idea, and obviously

it would be a lot of work to do….  However I think that, insofar as we can find

time to consider new development directions, this is worth thinking about…


— Ben


-- 
Ben Goertzel, PhD
http://goertzel.org

"I am God! I am nothing, I'm play, I am freedom, I am life. I am the
boundary, I am the peak." -- Alexander Scriabin

-- 
You received this message because you are subscribed to the Google Groups 
"opencog" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/opencog.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/opencog/CACYTDBfnHzoBi0C2myfJMXHt4gKXsCmmT669qUQe03wyb2Qn8g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to