[M3devel] About Juno-2 and automating debugging software

[Daniel Alejandro Benavides D.]

Hi all:
I think the speed improvement we might have in Juno-2 (to prove the concept) is to develop an interface for the constraint equational non-linear solving, perhaps done in CUDA see:
http://en.wikipedia.org/wiki/CUDA

like interface or OpenCL if so, and perhaps create a model for it under SOFA, see:
http://en.wikipedia.org/wiki/SOFA_(Simulation_Open_Framework_Architecture)

like model as some solvers already do that:
http://www.sofa-framework.org/docs/sofa-tled-isbms08.pdf

Also a FPU model would be needed of it or added to current modes of operation of Float point types, besides tohers like legacy x87 support, and newer ones.
In this way we could prove the interface and give a proof of the concept.
Indeed is heavy work and might not be reasonable to put first in a TODO list, but be aware this guys of GPGPU are creating so many things like large array of clusters to processing any kind of data, we might try to do that or some of it. And you know time is running for all and every should be keeping the pace.
Perhaps this would require some sophistication in the needed machinery like 2 or three GPGPU or so, but still worth the value I think
Thanks in advance,

PD please if anybody has a CUDA or OpenCL interface design or already in mind or any ideas on this please speak up 

--- El sáb, 29/1/11, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribió:

> De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
> Asunto: [M3devel] About Juno-2 and automating debugging software
> Para: m3devel at elegosoft.com
> Fecha: sábado, 29 de enero, 2011 21:18
> Hi all:
> I was watching a book, sort of wondering what your ideas
> you might have about that.
> The idea behind this book, is sort of the same in some
> point to what it is ESC/Modula-3.
> in
> [1] W. R. Murray, Automatic program debugging for
> intelligent tutoring systems. Pitman, 1988.
> A technical report here, get it:
> ftp://ftp.cs.utexas.edu/pub/AI-Lab/tech-reports/UT-AI-TR-86-27.pdf
> 
> You will see its rationale is that a program must be
> capable of catching more bugs and errors from the program,
> than a syntactical analyzer, which is the idea behind
> ESC/Modula-3, even if not a fully decidable problem as Greg
> Neslon says.
> 
> Well I just put it there so we may see how about such a
> thing an Automatic debugger in Juno-2, as the Automatic
> Program Debugger is a declarative language Lisp subset and a
> subset of Lisp implementation is available, sort of nice
> thing to have already and Boyer-Moore underneath it theorem
> prover also available, see on:
> http://www.cs.utexas.edu/~moore/best-ideas/nqthm/index.html
> (Unreacheable code, etc like program errors, etc).
> 
> Sort of nice having strong competence in the arena (see
> on:
> http://www.cs.cmu.edu/afs/cs/project/jair/pub/volume4/bhansali96a-html/paper.htm
>  ) with sketchup and stuff, and Juno-2 alternative JVM
> already written backend and so (not for animations but sort
> amenable for dynamic code generation?).
> Only missing thing was just Prolog logical compiler but
> also being written one for proof of soundness of modula-3
> type system typechecking 
> Thanks in advance
> 
> 
> 
>