Trustworthiness of Monte Carlo methods ( a quick and dirty test in Lisp)

[RobbeK]

Hi all,

Showing the exact model (green) and a Monte Carlo method ( # 1.000.000 ) in the image.

Written in GCL (Kyoto Common Lisp)  -- mixed interpreted and compiled code (it takes only a fraction of a second to compute).

attached : scr copy - source

best Rob
(green and red curve shifted (X-axis) for clarification )

.

[Mike Lobanovsky]

Hi Rob,

Please join me in my effort to push Charles and open a new subforum here for LISP submissions. We already have three practical Oxygen-related branches of this activity:

1. Charles' Lispish;

2. RobbeK's O2-to-LISP interfaces; and

3. OxyLISP and its SB and FBSL siblings.

Hallo Charles, are you there?

[RobbeK]

@ your service,   but I'm nowhere when it comes to low level architecture related subjects.

I think, I do can write pseudo iteration mechanisms (based on tail-recursion)   like (loop ..)  (while ...) (until ... )  to make (newbie) people more familiar with the Lisp-like languages.

I translated the Monte Carlo into Scheme (attached) , increased the calculations to 10.000.000 probes (as a kind of benchmark) .. Bigloo is not slow :  same prog

CLisp 55 sec   (slow comp., u know)
Clozure CL 22 sec
GCL 17 sec   
Bigloo 23 sec

(Clisp is a byte-code compiler)

Attached also the exec.  (hope the Japi lib is completely inside , so you don't need the dll --  will give the usual warning when connecting to the Java Server )  -- StarT needs to be clicked only once , the "Monte Carlo" appears only to have an idea about the execution time.

best Rob   (the compiled Scheme is much smaller than CL  -- Steel Bank CL may produce a + 30 Mb stand-alone 
 

.

[Mike Lobanovsky]

Hehe, nice job!

You're too pessimistic about speed. Actually it takes around 5 seconds on my PC to draw the both charts. 20 million probes is a hell of a lot of calc to do for any language, whether compiled or not.

[Mike Lobanovsky]

Putting aside the GUI stuff, this code seems to be employing "vectors". Are these arrays or math vectors?

I think, I do can write pseudo iteration mechanisms (based on tail-recursion)   like (loop ..)  (while ...) (until ... )  to make (newbie) people more familiar with the Lisp-like languages.

Strictly speaking, this isn't exactly my vision of a BASIC LISP. What you suggest looks more like what Charles is doing with his Lispish -- a BASIC-structured syntax with LISP-style tail-first access to operands and Polish notation in its statements. A cup of 3-in-1 Nescafe, sorta. That's his own conscious and rewarding choice, exciting pastime, and useful training for the mind.

I'm seeing FBSL LISP more as a standard and usable dialect of LISP with a compliant syntax and all the basic LISP functionality in it. FBSL has C and asm JIT functionality in it so the resultant symbiosis may appear very practical, speed-wise, in the long run.

[RobbeK]

Thanks Mike,   

The Monte Carlo part is based on 70.000.000 random numbers 

best,  Rob

[RobbeK]

Hi Mike,

Scheme hasn't the classic Common Lisp arrays which can be of any dimension , it uses one-dimensional "simple-arrays".
They however (as in CL) can contain any type, but must be uniformely of a certain type.
Another reason using them is that Scheme has no (nth .... )   (elt ....) to address elements of a list , but with vectors it has (vector-ref ... ) , (vector-set! ... )  to read and write the elements.

Working with arrays, vectors ... should work faster than lists -- they are of a certain type and the "place" in memory can be calculated very fast --   with lists you have to follow the pointers, which may be slow (certainly when you need an element from the "tail" )  ...  variadic, typeless processing is slower,   the price we have to pay for this abstraction.

best Rob 
(that I do use Lists in the lisp, is because it's only a list of 70 elements - the gain will be almost nothing when working with arrays - in Scheme I have no choise , except to start working in a recursive way on the list , (something i don't like))

[JRS]

Rob,

Not a total loss as this Monte Carlo example gives me some direction how we might add SDL_gfx to SBLisp.

[Mike Lobanovsky]

Hehe Rob,

And you said your services can't find any useful application on this forum. Your creations may become an inexhaustible source of John's own creative inspiration.

[RobbeK]

    thanks John , Mike ...

Forgot to mention , Scheme uses lexical scoping (unlike Common Lisp )  ...  from there I can write  (apply max ....  )  while this should be (apply #'max ...  ) in CL.

Bigloo is not a toy , it is developed by INRIA :  (Institut national de recherche en informatique et en automatique) from France.
(it employs 3800 people. Among them are 1300 researchers, 1000 Ph.D. students and 500 postdoctorates.)

from wikipedia :  (bigloo)
Its orientation is towards providing tools for effective and diverse code generation that can match the performance of hand-written C or C++. The Bigloo system contains a Scheme compiler that can generate C code and JVM or .NET bytecode. As with other Lisp dialects, it contains an interpreter (also known as a read-eval-print loop).

best, Rob

[RobbeK]

Another piece of Scheme (based on previous code -- easy to expand it )
..  now with "moving pictures" -- with a delay loop (may be too fast otherwise).


best Rob

.

[Mike Lobanovsky]

I like your animations, Rob!

Why is the probes curve broken at the top?

[RobbeK]

Hi Mike,

very good question -- I have to think about it 

I extended the prog a little , now giving a 3rd diagram, showing the error between the exact value and the MC method.  Indeed the errors seems larger values on the top - infact it seems a normal Gauss distribution again ...

best Rob

oops, yes .. beware, every curve in the error diagram is scaled to have the same top value   (apply max .... ) as the scaling factor, it doesn't tell about the value of the errors, just the distribution -- for the absolute values I need yet another canvas 


.

[RobbeK]

Well,

Converted the source to Common Lisp (GCL - aka Austin Kyoto Common Lisp) and the curves come out smooth ..
(my first idea was that they went "trough the ceiling" of the 32 bit bigloo integers (CL will deliver upto  +1000s bit int's), but this seems not to be the case ...

needs further invest ...    best Rob

(the GCL executable is a mastodon of near 40 Mb -- it's hyper-compressed with 7zip  )



.

[Mike Lobanovsky]

Hi Rob,

4mike

Thanks for the code and exe. It indeed looks much smoother in GCL.

As for huge exes, I'm inclined to regard this "exe" as a snapshot of the actual PC memory at the moment of "compilation". The "compiler" simply adds a small "exe" launcher to read these 30MB from the disk file and project them back into the user PC memory. Then it sets the instruction pointer to the main function's entry point. (FBSL v1 used to deploy such "executables" long long ago )