Oxygen Basic

Information => Open Forum => Topic started by: RobbeK on January 25, 2015, 07:46:41 AM

Title: Rob's Lisp Adventures
Post by: RobbeK on January 25, 2015, 07:46:41 AM
having so much fun.  :)

yes certainly , thanks John ...

While tk/tcl may (at this moment) have a kind of aura of obsoleteness (because - i read - very popular in the '90s on UNIX systems) - i find it very usable.  On top you get another scripting language that completely can be mixed with other scripts.  I did try it together with the gigantesque Common Lisp compilers -- but I do not like it this way .  As you mentioned the speed difference between compiled and interpreted lisp is not that huge IMHO , a script with JIT compiling and/or DLL/so 's combined with OpenGL scripts is the optimum ...
As I found the tk canvas related functions are rather slow , i wrote some functions myself  for pixel graphics , based (if wished) on buffered graphics (both choices are possible - buffered and unbuffered ).  these are about 10x faster than tk/tcl (system memory is used , no hardware)

the newLISP code itself runs on Win / Linux / Wine without any change  -- the code detects the OStype..  (only under Linux the *.so file has to be copied -- but probably it must be possible with a script to use it from the location of the executable ?)

All calculations are done in the script -- given the fact that this is about 21.000 complex prime numbers, i don't think it is slow..

;-------------------------------code

(silent

(if (= ostype "Linux") (setq DLL "libscreen.so") (setq DLL "libscreen.dll"))
(if (= ostype "Linux") (setq PATH "/usr/bin/wish") (setq PATH  "c:/Tcl/bin/wish.exe"))

(dolist (i (list  "SETSCREEN" "PIXEL" "ENDSCREEN" "SCRLOCK" "SCRUNLOCK" "SCRCLR"))  (import DLL i))

(define XY (array 400 400 '(0)))

(map set '(myin tcout) (pipe))
(map set '(tcin myout) (pipe))
(process PATH tcin tcout)

(define (tk)
  (write-line myout (append "if { [catch { puts ["
              (apply string (args)) "] }] } { "
              [text] tk_messageBox -message $errorInfo; exit }
    [/text]))

  (let (str "")
    (while (starts-with (setq str (read-line myin)) "newLISP:")
      (eval-string ((length "newLISP: ") -1 str)))
    str))

(global 'tk)

;; this is for compatibility with newlisp-tk
;; for new programs just use 'puts' without the 'Newlisp' wrapper
(tk "proc Newlisp { command } { puts $command }") 

;; exit when main window is closed
(tk "bind . <Destroy> {puts {(exit)}}")


(define (prime? x)
 (= 1 (length (factor x))))

(define (sq x) (* x x))

(define (gaussprime? x y)
    (prime? (+ (sq x) (sq y))))

(define (zeven? x y)
  (even? (+ (sq x) (sq y))))

(define (zodd? x y)
   (not (zeven? x y)))

(define (setup-XY)                                                        ;; preprocessor
 (setq nr 0)
  (dotimes (i 400)
   (dotimes (j 400)
   (let ((p (+ (sq (- i 200)) (sq (- j 200)))))
    (when (prime? p) (setf (XY i j) 1) (++ nr) )))))

(define (zodd-zeven)
  (SCRLOCK)
  (for (i -200 200)
   (for (j -200 200)
     (if (zeven? i j)
       (PIXEL (+ 200 i) (+ 200 j) 0 200 0)
       (PIXEL (+ 200 i) (+ 200 j)  200 0 0) )))
   (SCRUNLOCK))

(define (info s)
  (tk (append ".lb config -text " s )))

(define (main)
 (SCRLOCK)
  (dotimes (i 400)
   (dotimes (j 400)
   (when (> (XY i j) 0) (PIXEL i j 0 222 0))))
(info (append  "#primes=" (string nr)) )
  (SCRUNLOCK) 
  )
 
 (define (stars)
 (let ((pixel (lambda(x y) (PIXEL x y 200 200 0))))
  (for (i 1 398)
   (for (j 1 398)
     (when (zero? (XY i j))
      (when (> (XY (+ i 1) j) 0)
       (when (> (XY (- i 1) j) 0)
        (when (> (XY i (+ j 1)) 0)
         (when (> (XY i (- j 1)) 0)
          (pixel i (+ j 1)) (pixel i (- j 1)) (pixel (+ i 1) j) (pixel (- i 1) j)  )))))))
))

 (define (twins)
 (let ((pixel (lambda(x y) (PIXEL x y 255 0 0))))
 (SCRLOCK)
  (for (i 1 398)
   (for (j 1 398)
     (when (zero? (XY i j))
      (when (> (XY (+ i 1) j) 0)
       (when (> (XY (- i 1) j) 0)
            (pixel (+ i 1) j) (pixel (- i 1) j)) )
        (when (> (XY i (+ j 1)) 0)
         (when (> (XY i (- j 1)) 0)
          (pixel i (+ j 1)) (pixel i (- j 1))))))))
 (SCRUNLOCK) )

(define (dens)
 (SCRLOCK)
 (let ( (acc  (lambda (x y d) (+ (XY (- x d) y) (XY (+ x d) y) (XY x (+ y d)) (XY x (- y d))
                                      (XY (- x d) (+ y d)) (XY (+ x d) (+ y d))
                                      (XY (- x d) (- y d)) (XY (+ x d) (- y d)) ))))
 
    (for (i 2 396)
     (for (j 2 396)
     (PIXEL i j 80 0 (* 120 (acc i j 1)) ))))
(SCRUNLOCK)
  )




(define (run )
 (tk "frame .fr -relief sunken  ")
 (tk "wm title . Gaussprimes")
 (tk "wm geometry . 200x220+30+30")
 (tk "label .lb -text {info} -width 20 -pady 5 -bg {gray80} ")
 (tk "button .b -text {Gaussprimes*} -command {Newlisp {(main)}} -width 15")
 (tk "button .b2 -text {CLR Scr} -command {Newlisp {(SCRCLR)}} -width 15 -bg {gray60} -relief sunken")
 (tk "button .b3 -text {zodd & zeven} -command {Newlisp {(zodd-zeven)}} -width 15")
 (tk "button .b4 -text {StarS} -command {Newlisp {(stars)}} -width 15")
 (tk "button .b5 -text {TwinS} -command {Newlisp {(twins)}} -width 15")
 (tk "button .b6 -text {Density} -command {Newlisp {(dens)}} -width 15")
 (tk "pack .b4 -in .fr -side bottom")
 (tk "pack .b -in .fr -side bottom ")
 (tk "pack .b6 -in .fr -side bottom ")
 (tk "pack .b5 -in .fr -side bottom")
 (tk "pack .b3 -in .fr -side bottom")
 (tk "pack .b2 -in .fr -side bottom")

 (tk "pack .lb -in .fr -side bottom ")
 

 (tk "pack .fr")
  (setup-XY)
  (SETSCREEN 400 400 350 30)
   )

(run)

(while (read-line myin)
    (eval-string (current-line)))


)


 8)   best , Rob    (attached, both the Linux and Win executables)

of course OpenGL , can be used for this .. but for some quick and fast progs this is very easy and usable -- one graphic screen of any size can be set up



.
Title: Re: Rob's Lisp Adventures
Post by: JRS on January 25, 2015, 12:59:40 PM
Hi Rob,

I'm having problems running your 32 bit examples on my 64 bit Ubuntu Linux. I have 32 bit support installed but that isn't saying much. It's the old which nut shell is libc hiding/missing under. I'm getting circular dependencies trying make it work. Can you provide source ?

John
Title: Re: Rob's Lisp Adventures
Post by: RobbeK on January 26, 2015, 06:15:33 AM
Yes, sure John

I added the "obligeous" Mandelbrot (generated by the script - should be there in a sec ).
The *.so is compiled with a 32 bit compiler, but a 64 bit newLISP distribution can be downloaded here :

http://www.newlisp.org/downloads/newlisp_10.6.2-1_amd64.deb  (very fresh, less than a week old)
in the terminal use newlisp-edit to start it up (the editor is JAVA dependent however)

On my Ubuntu, the Software Center said the package was not conform the regulations , but I overruled this and just installed it.

best   Rob

now to do ,   poking directly into the frame's back buffer ..  should be even faster ...  8)

.
Title: Re: Rob's Lisp Adventures
Post by: JRS on January 26, 2015, 12:07:45 PM
Rob,

I split the Gauche Scheme thread as it was going off topic. This new thread seems more appropriate. My interests are in Scheme only and was hoping Gauche was enough to convert you to a Scheme centric programmer. Oh well.  :-[

John
Title: Re: Rob's Lisp Adventures
Post by: RobbeK on January 26, 2015, 04:02:21 PM
..   oops , i was drifting again .. 

Yes, but newLISP is a kind of oldLISP , something from before the schism between Scheme and Common Lisp ,imho at first sight it is closer to Scheme than to Common Lisp , and Gauche borrows a lot from Common Lisp - certainly not Scheme standard.

But there's something more important between the old lisp and the newer CL and Scheme , the difference between dynamic (the old) and lexical binding (the newer) , but newLISP does dynamic binding inside of static isolated namespaces.

copying something from Lutz Müller :
"Personally I find dynamic binding more natural. I believe the current trend towards static binding is more a reflection of today's CS curriculum, than of the realities of programming in the real world of applications outside academia. I see static binding more as a fashion than something which is superior to dynamic binding. Both have their advantages and disadvantages.

For most users the fact of dynamic binding in newLISP is not an issue. But dynamic binding dictates a different programming style, avoiding non-local variables. In an example as yours it is still Ok, if you know how dynamic bindng behaves, because the functions involved are close to each other.

Bigger newLISP programs are typically organized in smaller modules inside contexts/namespaces. The overhead of the namespace mechanism is minimal and there is no speed disadvantage. Namespaces isolates modules from each other and can have state.
"

..

Gauche is next on the list, it has everything what I like - (this newLISP stuff is something I had to do -- some old code needed a new jacket )

best Rob     (poking and peeking the frame backbuffer works perfectly in the mean time) 


Title: Re: Rob's Lisp Adventures
Post by: RobbeK on February 01, 2015, 02:57:01 AM
Facts and Numbers --  Recursion 10.000.000 "deep"   on several Lisps

GCL (GNU Common Lisp) 
-> C -> GCC -> native code
2.6.10 CLtL1    Apr  2 2014 14:19:37
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License:  GPL due to GPL'ed components: (XGCL READLINE UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/

>(defun tst (a max)
   (if (= a max) a
     (tst (1+ a) max)))

TST

>(compile 'tst)

Compiling /tmp/gazonk_7894_0.lsp.
End of Pass 1. 

;; Note: Tail-recursive call of TST was replaced by iteration.
End of Pass 2. 
OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
Finished compiling /tmp/gazonk_7894_0.lsp.
Loading /tmp/gazonk_7894_0.o
start address -T 0x8a3640 Finished loading /tmp/gazonk_7894_0.o
#<compiled-function TST>
NIL
NIL

>(time (tst 0 10000000))

real time       :      0.109 secs
run-gbc time    :      0.090 secs
child run time  :      0.000 secs
gbc time        :      0.000 secs
10000000

>(by)
gerd@gerd-HP-Pavilion-dv4000-EK987EA-UUG:~$ clisp  -- bytecode
  i i i i i i i       ooooo    o        ooooooo   ooooo   ooooo
  I I I I I I I      8     8   8           8     8     o  8    8
  I  \ `+' /  I      8         8           8     8        8    8
   \  `-+-'  /       8         8           8      ooooo   8oooo
    `-__|__-'        8         8           8           8  8
        |            8     o   8           8     o     8  8
  ------+------       ooooo    8oooooo  ooo8ooo   ooooo   8

Welcome to GNU CLISP 2.49 (2010-07-07) <http://clisp.cons.org/>

Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2000
Copyright (c) Sam Steingold, Bruno Haible 2001-2010

Type :h and hit Enter for context help.

;; Loading file /home/gerd/.clisprc.lisp ...
;;  Loading file /home/gerd/quicklisp/setup.lisp ...
;;  Loaded file /home/gerd/quicklisp/setup.lisp
;; Loaded file /home/gerd/.clisprc.lisp
[1]> (defun tst (a max)
      (if (= a max) a
        (tst (1+ a) max)))
TST
[2]> (compile 'tst)
TST ;
NIL ;
NIL
[3]> (time (tst 0 10000000))
Real time: 0.947063 sec.
Run time: 0.904 sec.
Space: 0 Bytes
10000000
[4]> (bye)
Bye.
gerd@gerd-HP-Pavilion-dv4000-EK987EA-UUG:~$ racket  bytecode + JIT
Welcome to Racket v5.3.6.
> (define (tst a max)
    (if (= a max) a
     (tst (add1 a) max)))
> (time (tst 0 10000000))
cpu time: 196 real time: 211 gc time: 0  in mSec
10000000
>
gerd@gerd-HP-Pavilion-dv4000-EK987EA-UUG:~$ gosh
gosh> (define (tst a max)

        (if (= a max) a
          (tst (+ a 1) max)))
tst
gosh> (time (tst 0 10000000))
;(time (tst 0 10000000))
; real   1.003
; user   0.970
; sys    0.000
10000000
gosh> gerd@gerd-HP-Pavilion-dv4000-EK987EA-UUG:~$ sbcl  Steel bank Common Lisp
This is SBCL 1.1.14.debian, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.
* (defun tst (a max)
    (if (= a max) a (tst (1+ a) max)))

TST
* (time (tst 0 10000000))

Evaluation took:
  0.134 seconds of real time
  0.120000 seconds of total run time (0.120000 user, 0.000000 system)
  89.55% CPU
  225,237,609 processor cycles
  0 bytes consed
 
10000000
 
gerd@gerd-HP-Pavilion-dv4000-EK987EA-UUG:~$ ecl
ECL (Embeddable Common-Lisp) 13.5.1 (git:UNKNOWN)
Copyright (C) 1984 Taiichi Yuasa and Masami Hagiya
Copyright (C) 1993 Giuseppe Attardi
Copyright (C) 2000 Juan J. Garcia-Ripoll
ECL is free software, and you are welcome to redistribute it
under certain conditions; see file 'Copyright' for details.
Type :h for Help. 
Top level in: #<process TOP-LEVEL>.
> (defun tst (a max)
    (if (= a max) a
     (tst (1+ a) max)))

TST
> (compile 'tst)

;;; Loading #P"/usr/lib/ecl-13.5.1/cmp.fas"
;;; OPTIMIZE levels: Safety=2, Space=0, Speed=3, Debug=0
;;;
;;; End of Pass 1.
TST
NIL
NIL
> (time (tst 0 10000000))

real time : 0.327 secs
run time  : 0.296 secs
gc count  : 1 times
consed    : 21796736 bytes
10000000
>

Ikarus Scheme version 0.0.4-rc1+ (revision 1870, build 2015-01-30)  ;; highly optimazing Scheme
Copyright (c) 2006-2009 Abdulaziz Ghuloum

> (define (tst a max)
     (if (= a  max) a
      (tst (+ a 1) max)))
> (time (tst 0 10000000))
running stats for (tst 0 10000000):
    no collections
    96 ms elapsed cpu time, including 0 ms collecting
    104 ms elapsed real time, including 0 ms collecting
    0 bytes allocated
10000000
>


best Rob -- Ikarus (0.0.4) comes with gl glut and an FFI (the project seems abandoned and on the homepage 0.0.3 is the most recent version, comes with documentation for the ...4  , except openGL are empty pages ....
Title: Re: Rob's Lisp Adventures
Post by: jack on February 01, 2015, 06:44:17 PM
hello Robbek
my timing of DrRacket on my Mac
from the IDE
Code: [Select]
(define (tst a max)
    (if (= a max) a
     (tst (add1 a) max)))
(time (tst 0 10000000))
time in miliseconds
cpu time: 304 real time: 304 gc time: 0

compiled to exe
cpu time: 32 real time: 31 gc time: 0

from my experiments, sbcl is usually very fast.
Title: Re: Rob's Lisp Adventures
Post by: RobbeK on February 03, 2015, 05:59:31 AM
thanks, Jack


Rob
Title: Re: Rob's Lisp Adventures
Post by: RobbeK on February 26, 2015, 06:42:03 AM
Hi all,

Connected tk/tcl to CLISP and Steel Bank CL under windows too ,,   works fine.
Also gl/glu/glut under windows using cl-glop (an example attached --  huge file (a Steel Bank CL image around 50Mb  :-\  )
use  mouse hold left/right and mousewheel to have a look at the plot.  (code came from a Russian website - there are no manuals for glop I can find, i use this and the source as documentation --  wrote the Gauss prime plot with it (clip) )

best Rob
(if someone needs the bindings for tik/tcl and CL , just ask -- have both for Win and Linux (incl. callbacks from tcl to Lisp ))



.
Title: Re: Rob's Lisp Adventures
Post by: Mike Lobanovsky on February 26, 2015, 07:45:41 AM
Hi Rob,

Also gl/glu/glut under windows using cl-glop

Looks like 100% CPU load, doesn't it? Also, there's doesn't seem to be any 50MB example attached...
Title: Re: Rob's Lisp Adventures
Post by: RobbeK on February 26, 2015, 08:32:49 AM
Hi Mike,

100%, yes -- that's the original Russian product -- i put a sleep into the idle loop (runs around 40% cpu usage)

best Rob

I'll try to attach again  -- nope doesn't work (file is a 7zip around 10Mb)
Title: Re: Rob's Lisp Adventures
Post by: RobbeK on February 26, 2015, 12:28:54 PM
OK , put it in my DropBox :   here's the link

https://www.dropbox.com/s/6xldd4dhdji8ocv/SBCL3Dplot.7z?dl=0


best, Rob
(of course , it should be run in the REPL , you can change the formula interactively (while running) :  in Lisp there is no real distinction between read-time, compile-time, and runtime. You can compile or run code while reading, read or run code while compiling, and read or compile code at runtime.
Title: Re: Rob's Lisp Adventures
Post by: Mike Lobanovsky on February 26, 2015, 02:02:18 PM
OK , put it in my DropBox :   here's the link

Thanks, it worked for me this time. This forum has a limitation on the size of attachments to forum posts, which is about 5MB lower than the 15/20MB claimed in the message editor.

100%, yes -- that's the original Russian product

Hehe yes, Russians are hard to beat when it comes to playing on your nerves.

Quote
i put a sleep into the idle loop (runs around 40% cpu usage)

It's as low as 11% only on my quadcore. You must be referring to some low-end CPU, evidently a single-core make.

Quote
(file is a 7zip around 10Mb)

9MB zipped, 50MB unzipped, and ridiculous 350MB when loaded in memory, to be precise. This "in memory footprint" approach to making "executables" certainly takes its toll.

Quote
in Lisp there is no real distinction between read-time, compile-time, and runtime. You can compile or run code while reading, read or run code while compiling, and read or compile code at runtime.

You can run out of memory easily when doing all this stuff at once on a really large program (see my preceding note).


Thanks again for responding, Rob.
Title: Re: Rob's Lisp Adventures
Post by: RobbeK on February 27, 2015, 01:56:54 PM
Hi Mike,

.....are hard to beat when it comes to playing on your nerves...........    the gl_list is also present in system-memory , because it's static it should be in hardware memory  as glNewList (id, GL_COMPILE)  etc ... (not ?)

yes, still low-end for the moment (but awaiting , the new machine should arrive any day now).

There're some problems with these CL's under Linux in the way that it doesn't accept the lib's I wrote (they give segmentation faults) -- they run fine under Racket Scheme and newLISP under Linux -- I tried cdecl , std , std-call , pascal protocol but nothing is accepted.  This is very problematic (under Win everything works).  I need my own libs , those that come with tk/tcl , Racket Scheme etc..  are too slow at pixel level (tk/tcl even can not draw a pixel  -- execpt when switching into a "photo" object - then it's even slower  :(

If i can't solve that problem with CL under Linux, I definitely switch to Racket Scheme and newLISP , the FFI is easy -- it's "only" bytecode with JIT (with a jump tail inside) , but nevertheless  ...  added a test (gaussprimes, that's easy -- checking a 500² grid of numbers , and plotting them -- more than fast enough (the primes are memoized of course  ;) 

in fact, it's very easy coding :

------------------------------------------

#lang racket
 (require ffi/unsafe   ffi/unsafe/define)
 (require racket/gui/base )
 
 (define-ffi-definer mylib-define (ffi-lib "screen2win.dll"))
 (mylib-define pixel (_fun _int _int _int _int _int  -> _void ))
 (mylib-define endscreen (_fun -> _void))
 (mylib-define setscreen (_fun _int _int _int _int -> _ulong ))
 (mylib-define scrclr (_fun -> _void))
 (mylib-define scrlock (_fun -> _void))
 (mylib-define scrunlock (_fun -> _void))
 (mylib-define scr (_fun _int -> _void))
 (mylib-define scrsleep (_fun -> _void))
 (mylib-define pokebyte (_fun _ulong _ubyte -> _void))
 
 
 

(define *z* 0)
(define lim (* 3 250 250))
(define primes (list->vector (range (+ 3 lim))))

(define (make-primes)
  (do ((i 2 (+ i 1)))
    ((> i (/ lim 2.0)))
    (when (> (vector-ref primes i) 0)
      (do ((j 2 (+ j 1)))
        ((> (* i j) lim))
        (vector-set! primes (* i j) 0)))))

(define (prime? x)
  (not (zero? (vector-ref primes x))))

(define (gaussprime? x y z)
  (prime? (+ (* x x) (* y y) (* z z))))

(define (plot-primes)
  (scrlock) (scrclr)
  (for* ((x (in-range -250 250)) (y (in-range -250 250)))
    (when (gaussprime? x y *z*) (pixel (+ 250 x) (+ 250 y) 222 222 0))) (scrunlock) (message) )

(define (message)
  (send ed1 set-value (string-append "Level# : "(number->string *z*))))
                       
(define frame (new frame% [label ""]
                   (x 20)
                   (y 20)
                   (style (list 'no-caption))
                   (spacing 10)
                   (border 30)
                   (width 200)
                   (height 200)))

(new button% (parent frame)
             (label "Incr level")
             (min-width 100)
             (callback (lambda (button event)
                         (set! *z* (+ 1 *z*))
                         (plot-primes)
                         )))

(new button% (parent frame)
     (label "Decr Level")
     (min-width 100)
     (callback (lambda (button event)
                (set! *z* (- *z* 1))
                         (plot-primes)
        )))

(define exitbutton (new button% (parent frame)
     (label "Close graphics and die")
     (min-width 160)
     (callback (lambda (button event) (scr 0)
                 (when (send frame can-close?) (send frame on-close) (send frame show #f))
))))

(define ed1 (new text-field% (label "Info ") (parent frame) (init-value " ") ))
 

(let ((bck (make-object color% 220 220 180)))
       (send ed1 set-field-background bck)
  )

(make-primes)
(setscreen 500 500 350 50)
(plot-primes)

(send frame show #t)

-----------------------------
imho , rather compact for what it does (?)

best, Rob
(still a huge file -- it shows kind of patterns in prime numbers -- nothing special, but a good test for a programming language)

.
Title: Re: Rob's Lisp Adventures
Post by: Mike Lobanovsky on February 28, 2015, 12:26:44 PM
Quote from: Rob
the gl_list is also present in system-memory , because it's static it should be in hardware memory

Hardly. There's only one way to channel your OpenGL data to the hardware memory on your GPU, which is to utilize VBOs (vertex buffer objects). glNewList(GL_COMPILE) and the like are OpenGL's immediate mode instruments that are very old, have nothing to do with VBOs, and are constantly on the verge of being totally deprecated but somehow are still kept there presumably owing to the tremendous educational value of immediate mode and its existing code base for the newbies.

OpenGL draw list data is compiled into conventional memory. If we assume that those particular "executables" are nothing else but memory footprints, then much of their fat is due to the 5002 * 4 * 3 vertex data bytes precomputed by the compiler before dumping the "executable" onto the hard disk.

Quote
There're some problems with these CL's under Linux ...

Why don't you try and address the CL dev team with some incompatibility samples from your libs? Of course the outcome will depend largely on general friendliness (or bitchyness) of the particular community, but there's still a slim chance that you might get your (or their) issues solved one way or the other.
Title: Re: Rob's Lisp Adventures
Post by: RobbeK on February 28, 2015, 12:43:56 PM
A Sierpinski pyramid (Racket Scheme)

Source compiled under Linux and Windows -- strangely the Windows version gives an empty screen when using glLists ..  so attached a somewhat crippled Windows version where every frame is recalculated all over  :-[   -- the Linux version performs the callList

sigh


the idea is to extend the Sierpinski recursion into 3D , it even may expanded in a way  obj1->...   objX ...  -> obj1 etc.. , i mean , here the pyramid is transformed into a congruent object , but everything is possible

best Rob , 

https://www.dropbox.com/s/aaqfxh9c5zf9kae/pyramidL.7z?dl=0   (for Linux)
https://www.dropbox.com/s/j71yh9n4mcohcl3/pyraWin.7z?dl=0   (for Windows)

addendum :  thanks for your reply Mike , messages crossed each other , -- excellent info !   :)



.
Title: Re: Rob's Lisp Adventures
Post by: Mike Lobanovsky on February 28, 2015, 12:55:02 PM
Hehe, it works though rather slow indeed and with only one iteration (5 pyramids all in all).
Title: Re: Rob's Lisp Adventures
Post by: RobbeK on March 01, 2015, 12:07:32 PM
Hi Mike,

You have to edit the text field , and then hit the update button.  However it is restricted to 6 iterations.
In the mean time , I tried it by combining two scripting language : newLISP together with tBasic.  Generating the pyramids is easier in Lisp (just mapping the 1->5 mutation repeatedly over the same growing lisp ).
However, for the max level 6 , Lisp needs 0.15 sec to build all the coordinates , and further around 0.7sec to convert the list into an array (vector in Scheme) (so it can be indexed and called by thinBasic ) the glList building up in tB takes (a lot of) time (several secs) for this level 6.
I also replaced the single pyramid by a single quad.

(tested under Windows and Wine)

best Rob
(use arrow keys and pgUp pgDown)


.
Title: Re: Rob's Lisp Adventures
Post by: Mike Lobanovsky on March 01, 2015, 12:37:52 PM
Hi Rob,

Quote
You have to edit the text field , and then hit the update button.

Actually, no. That didn't produce any visible effect for me. There would always be only 5 pyramids visible, 4 in the bottom row and 1 more on top of it. In other words, the proggy was unresponsive to the input in the text field.

The same effectively applies to this one as well. Changing the number in the text field has no effect, and the only way to change the display is to press the buttons. At the same time, I can't rotate or navigate the view and the structure is seen at some odd angle only.

And yes, it takes very long to recalc the scene... :(

.
Title: Re: Rob's Lisp Adventures
Post by: RobbeK on March 01, 2015, 01:44:58 PM
Hi Mike,

" Changing the number in the text field has no effect, "  --  oops , my mistake ; should be a label ;  but the navigation by the arrow key works here...

trying it with GFA then,   

however  :-\   , GFA does not accept gl vectors , needed for p.e. materials and lights -- it crashes on setting up arrays of single floats and giving back the array pointer to the GL functions.

thanks again,  Rob 


Title: Re: Rob's Lisp Adventures
Post by: Mike Lobanovsky on March 01, 2015, 02:14:22 PM
... but the navigation by the arrow key works here...

Oops, entirely my fault! :-[

I'm mostly a point-and-click guy, and pressing arrows is usually the last thing on my mind. As an alternative, I could use some WASD keys, which is natural for such a seasoned gamer as I am: :D

(http://www.fbsl.net/phpbb2/download/file.php?id=1463)

I'm sorry for my mistake; the arrow keys are functioning here too as intended.
Title: Re: Rob's Lisp Adventures
Post by: RobbeK on March 02, 2015, 01:33:34 PM
 ::)

on mine the parenthesis are almost gone !!

the problems :

-Racket Scheme can NOT do glLists under windows (tested by glGenLists and the answer is nil )  -- explaining does blank screens
-As you stated, there are other problems too
-newLISP and using glut under windows can show static images , the moment motion comes in, the window goes gaga (somewhat as single-buffer graphics , but worse)
 -can not find to set up gl vectors under GFA ,  single float array - arraypointer  ---  C style mAlloc with address --  etc nothing works.
-JAVA is not that stable under Linux , under Wine it is catastrophic
-embedding newLISP under a Linux programming environment is at least difficult if possible

etc etc ...

A pity about Racket Scheme ---  "Among the Racket com­mu­nity, which is laden with com­puter-sci­ence PhDs & pro­fes­sors ....   etc    "
(& I always start with the idea that it is me who made the mistake)

No problems with Steel Bank CL (for the moment)


Title: Re: Rob's Lisp Adventures
Post by: Mike Lobanovsky on March 02, 2015, 02:36:59 PM
::)
on mine the parenthesis are almost gone !!

Ahahahahahaha!!! You bet! I'm seeing the same about my C-ish braces! (fr. accolades)  ;D

Quote
the problems :
-> -> -> -> -> 
"Among the Racket com­mu­nity, which is laden with com­puter-sci­ence PhDs & pro­fes­sors ....   etc"

That's always the same with the communities overpopulated with fossil fauna. They would simply not know, or have long forgotten, their way around the graphics environment of a modern operating system. Take BP.org for example. The place is fly-bitten by a coupla marasmic characters that are doing their utmost to scare people off the place. I stopped posting there a while ago. Now I see Mr Russel of BBC BASIC has just slammed the door behind him. Who's next, guys?

John, how are you feeling yourself in that monkey house?

Quote
(& I always start with the idea that it is me who made the mistake)

And I'd say that would be the most reasonable behavioral pattern for a sentient being.

Quote
No problems with Steel Bank CL (for the moment)

So things aren't that bad after all, are they? :)
Title: Re: Rob's Lisp Adventures
Post by: RobbeK on March 03, 2015, 03:02:53 AM
Hi Mike,

"So things aren't that bad after all, are they? "  , yes , and nothing is gained by giving up  .  It *is* possible to generate 1 glList at the time when running under windows(Racket).  I tried manipulation by glGenLists , glDeleteLists etc..  but one is the max I get.
Nevertheless in most cases this gives a-look-worthy result (though the idea here was a "fluid" demonstration of the iteration (recursion) levels.
)

so, attached something that works --  the X button does nothing - it's for testing some things not so clear to me.
Done on a ten years old machine running XP, it may work too fast on your computer -- i tuned the timer loop as fast as possible for this museum item (but even then it's not a defective show)

best Rob

.
Title: Re: Rob's Lisp Adventures
Post by: RobbeK on March 03, 2015, 12:12:45 PM
ADDENDUM

out of desperation ... 

switched to the ancestor of Racket -- PLT Scheme :  http://plt-scheme.org/

"maintained for historical reasons only"
yep, and also the calculations run about twice as fast , smaller executables ,  no glList problems ,  no flashing screen under Wine , and while (on another Win7 machine , Racket reclaimed there was no OGL context )  PLT runs happy there.

some gadgets are missing ,  have to look if lazy Scheme and typed Scheme are present (declarations like in CL - the slowness of these Lisps is very related every number may be a big number or a complex number - when turned off , Lisp speeds up a lot (not that something as Steelbank CL is slow -- (once in the top ten ...  ))

best Rob  (prog : you can change the recursion level now)    -- update : no levels under Win7 , works on XP (? at least here)  this is all very strange

.
Title: Re: Rob's Lisp Adventures
Post by: Mike Lobanovsky on March 04, 2015, 02:50:20 AM
Hi Rob,

Sierpinski PLT runs very nice here and very fast too under XP (not yet checked under 7). But! It eats memory as the structure spins round and round. When stopped, memory leakage ceases.

Did you limit the max number of iterations? It looks like my PC could use a few more iterations without slowdown...


[UPD]

It works under Win 7 exactly as it does under XP for me. I can increase and decrease the number of iterations as I please but the memory leak is also seen here.
Title: Re: Rob's Lisp Adventures
Post by: RobbeK on March 04, 2015, 06:39:45 AM
Hi Mike,

I replaced (sleep/yield 0) (DoEvents equivalent ) with a "straight" sleep for 10mSec now , it runs now under Win7 too , but sometimes i have to double/triple click the buttons .

OK an updated version -- 4 you up to level 8 (this info in the label field now). on the 10 yrs old machine level 6 is about the max.
Ah,yes for fun..  a pyramid with a triangular base.
If too fast I'll put up two textfields :  one with the angle increase/frame value -- the other with the timer interval , these can be fed to the code (while running).

the problem with glCallLisp under Racket Scheme ,  may be related with attached image -- it seems the FFI does not convert the Scheme number into a C uint32 (???)  --from running the code in the REPL

best Rob (and now a hexagonal base ??  8)

--  ouput sensors / cpu usage (Linux) attached  -- that's too optimistic 20-25% is more correct --  u can c i almost had a melt-down  ;D

.
Title: Re: Rob's Lisp Adventures
Post by: RobbeK on March 05, 2015, 02:50:45 PM
And some Lsystems in 3D  (maybe this is something new )

Code is ready to accept any L-system / # recursions as input - (need to write the text-fields for it)
(for the moment the section is only calculated as a square , but I think I'll change to hexagonal later)

a lot of recursion is used :

-------------------------------------------------the core of the code -----------------

(define-syntax-rule (gl-begin-end Vertex-Mode statement ...)
  (let () (glBegin Vertex-Mode) statement ... (glEnd)))

 
(define rot 0)

(define world (list 'l))
(define rule (list 'l 45 'l -90 'l 45 'l))

(define needs-recalc #t)
(define level 1)

(define (mutate* L M)
  (if (null? L) M
      (if (eq? (car L) 'l) (mutate* (cdr L) (cons rule M))
          (mutate* (cdr L) (cons (car L) M)))))

(define (mutate x)
  (let ((L world))
    (for ((i (in-range x))) (set! L (flatten (mutate* L '() ))))
    L ))

(define (->rad x) (/ (* x pi) 180))

(define (cartesian* L xo yo ao M)
  (if (null? L) M
    (if (eq? (car L) 'l) (cartesian* (cdr L) (+ xo (cos (->rad ao))) (+ yo (sin (->rad ao))) ao (cons (list xo yo) M))
        (cartesian* (cdr L) xo yo (+ (car L) ao) M))))

(define (cartesian L) (cartesian* L 0.0 0.0 0.0 '() ))

 
(define (scale* f L M)
  (if (null? L) M
      (scale* f (cdr L) (cons (list (- (* f (caar L)) 1) (+ 0.005 (* f (cadar L)))) M))))

---------------------------------------------------the JIT compiler does TCO (all replaced by iteration)

written in PLT Scheme - compiled for Windows (and identical code for Linux too --not attached)

best Rob (quiet interesting imho)

 


.
Title: Re: Rob's Lisp Adventures
Post by: Charles Pegge on March 06, 2015, 02:28:37 AM
I found the Sierpinski Tetrahedron irresistable, though rendering it with OpenGl geometry is quite intensive.

The pyramid is less congested, and may be a useful roof structure, using a combination of girders and pencils :)

.
Title: Re: Rob's Lisp Adventures
Post by: RobbeK on March 06, 2015, 04:44:10 AM
Cool Charles  8)   -- it has the looks of a  tubular construction of extreme strength !!  -- did you build it with string arrays ??

In the mean time the Lsystem is ready for user input :
use a " l " for "line"  -- (lower L) and any angle.
The system is every l in the "world" is replaced by the "rule" (recursively)  -- in the example attached it starts with two lines now.
to avoid convergence and divergence it is best to keep the sum of the angles =0 in the rule (and world).


** for scaling and positioning the code does not scale for negatives coordinates (not yet) -- so if you build a square as "the world" start with 90° (is upwards) -- in this way the values will not go below zero.
I'll make a "Charles style"  wired / tubed version too -- sometimes a lot is hidden inside

best Rob   (compiled and tested under Ubuntu Linux and Win32 XP (attached))



.
Title: Re: Rob's Lisp Adventures
Post by: Mike Lobanovsky on March 06, 2015, 04:46:14 AM
Charles,

Your Sierpinski is absolutely fantastic! Can you upload a compiled 32-bit executable here?



Rob,

I'm having problems with your latest exes here. The controls and windows (including the console) are almost unresponsive, OpenGL fails to update the draw lists according to the level chosen, and I can't exit cleanly because the console [X] button is almost always disabled while Ctrl+C crashes the app. And the applications do leak memory in chunks of approx. 8 to 12 kilobytes per second when in rotation mode.

Quote
I replaced (sleep/yield 0) (DoEvents equivalent ) with a "straight" sleep for 10mSec

You may not do it. MS Windows Sleep() is not a substitute for DoEvents. It simply suspends all activity including window message processing (roughly) for a specified number of milliseconds in the caller thread. In Windows, this would be the application's main thread where message processing is simply hidden from you in the accompanying third-party GUI libraries that utilize native Windows forms and controls.

You cannot write platform-independent code in tight endless loops like your rotation/rendering loop not taking due account of target system specifics. Platform independence in GUI applications is a fairy tale, a conspiracy and a chimera nurtured by Windows haters like Linus Torwalds and his ilk.

You absolutely must find a way to code a Lisp equivalent to the following (FBSL) BASIC code and call this sub in each iteration of a tight loop. Unhindered message processing must have top priority over everything else in your Windows GUI applications and especially in the loops that take more than just a few milliseconds to execute before bailout.

Code: OxygenBasic
  1. Type MSG
  2.     hwnd As Long
  3.     message As Long
  4.     wParam As Long
  5.     lParam As Long
  6.     time As Long
  7.     x As Long
  8.     y As Long
  9. End Type
  10.  
  11. Const PM_REMOVE = 1
  12.  
  13. Sub DoEvents()
  14.     Dim message As MSG
  15.  
  16.     While PeekMessage(@message, hWnd, 0, 0, PM_REMOVE) ' Don't change this to If!
  17.        TranslateMessage(@message)                     ' All pending messages, if any,
  18.        DispatchMessage(@message)                      ' must be processed before the sub exits!
  19.    Wend
  20. End Sub

where hWnd is the handle to the application's main window and the three functions are imported from user32.dll.
Title: Re: Rob's Lisp Adventures
Post by: RobbeK on March 06, 2015, 05:57:42 AM
Hi Mike ,

It's a Scheme (sleep 0)

        (sleep [secs]) → void?

      secs : (>=/c 0) = 0

Causes the current thread to sleep until at least secs seconds have passed after it starts sleeping. A zero value for secs simply acts as a hint to allow other threads to execute. The value of secs can be a non-integer to request a sleep duration to any precision; the precision of the actual sleep time is unspecified.

&

        (sleep/yield secs) → void?

      secs : (and/c real? (not/c negative?))

Blocks for at least the specified number of seconds, handling events meanwhile if the current thread is the current eventspace’s handler thread (otherwise, sleep/yield is equivalent to sleep).

your latest exes ...    yes, I lowered the interval in the timer loop ,otherwise it will not run under windows (well, it does run but it builds no new glLists )  these problems do not (at all) exist under Linux -- here (Win32) I have to set up a flag if the glList has to be replaced with a new one -- this is bad technique , surely ..  somehow  ,  somewhere  "things turn square"

  -- i do know that Mr Müller from newLISP , just removed semaphores , sync and i do think (almost sure) the timer events functions for the Win versions (probably he converted from Linux too)    there *is* certainly something wrong here

sigh -- once again , not a "write once - compile everywhere" piece of code  :(

thanks, for showing these facts -- it's important to me

best, Rob
Title: Re: Rob's Lisp Adventures
Post by: Charles Pegge on March 06, 2015, 06:09:34 AM
Hi Mike,

Submitted with trepidation, since I am using shaders!

It is animated by a simple tumbler. You can take snapshots using ctrl-p

I also include the main source for Rob, where you can see the geometry and glCompiled lists used in construction. As you can see, the recursion could be compacted a little further.


.
Title: Re: Rob's Lisp Adventures
Post by: Mike Lobanovsky on March 06, 2015, 07:05:13 AM
Excellent! :D

Maximized window: CPU usage 10.8%, GPU memory usage 12%, GPU usage 25%. And if my eyesight doesn't fail me, your shaders are anti-aliased?
Title: Re: Rob's Lisp Adventures
Post by: Mike Lobanovsky on March 06, 2015, 07:37:06 AM
Rob,

For what it's worth, all this bla-bla may be applicable under Linux but I don't see how they could in fact implement a sleep/yield in Windows that would block the caller thread in everything except window message processing. MS Windows Sleep() is a kernel function that has fixed functionality you can't change in any way. Sleep(0) will yield immediately the remaining portion of current time slice to other threads even if there are window messages pending in the app message queue. Sleep(n) will block all activity in the thread, again including window message processing, for roughly 16 * Floor(n / 16) milliseconds unless special measures are taken to increase its resolution.

The unresponsiveness that I'm seeing is exactly what it would look like if their sleep/yield were implemented based off of MS Windows' blocking Sleep() that I described above. Again those Linux guys are claiming things that aren't there. Oftentimes it is very irritating to see how they can spit at an operating system that they turn out to know nothing about.

I still insist that you arm your GUI Lisp creations with DoEvents() that I described in my earlier message. Then you will be able to use Lispish define/defined? for conditional compilation of your code similar to how it is done with C preprocessor directives in the C language programs that can rightfully claim a certain degree of multi-platformness:

Code: C
  1. #if defined(WIN32)
  2.     DoEvents();
  3. #else
  4.     sleepyield(0); // or whatever it is for Linux
  5. #endif // WIN32
Title: Re: Rob's Lisp Adventures
Post by: Aurel on March 06, 2015, 11:25:25 AM
Mike
Just one small question..if is not a problem.
You suggest to use While loop for message processing ...
why i ask..i think that i made mess in my crappy interpreter using IF
so do i must use while instead of if

thanks...
Title: Re: Rob's Lisp Adventures
Post by: Mike Lobanovsky on March 06, 2015, 12:11:07 PM
Yes Aurel,

You should use While/Wend because many events in an MS Windows window (pun is unavoidable here) generate a batch of several window messages rather than just one message. So, While/Wend will ensure that all concurrent and interrelated messages are processed together until PeekMessage(PM_REMOVE) returns zero (i.e. logical FALSE) to indicate that there are no more messages left unattended in the message queue.

If you used If here, PeekMessage(PM_REMOVE) would only process just the first one of the messages that might be waiting in the message queue, which would be effectively the same as if no messages were processed at all, because an event is considered complete only after all of its relevant window messages have been processed either in the user-defined callback, or by DefWindowProc(), or both, and the corresponding message return codes have been transmitted back to the system.

MS Windows agrees to wait till it gets a due response from the user to the window message it has sent only for a very short time period, and that period gets visibly shorter and shorter with every new version of Windows. So, what may still work for you in your XP Sp2 might not work at all under the user's Win 7 that would simply kill your application as "not responding".
Title: Re: Rob's Lisp Adventures
Post by: Aurel on March 06, 2015, 01:46:23 PM
Thanks Mike
Great explanation and i will do that way.
Well ..so far it seems that my XP progs work on win7(32bit) without problem..
anyway ..good to know
 :)
Title: Re: Rob's Lisp Adventures -- the ENDLOESUNG
Post by: RobbeK on March 08, 2015, 05:01:29 AM
thanks Charles , Mike

...   the final solution then
when identical code runs fine under Linux and erroneous under Win, then there's something wrong not (?)

the combination thinBasic , Oxygen and newLISP does solve all problems and fulfills my needs.
newLISP get a lot of critique for its dynamic scope - but as I do not use many globals and in case functions can be declared in a statical name space (context) , this should give no problem at all. 
Furthermore , it has superb FFI (which makes it possible to communicate with a tB O² environment via on the fly generated oxygen dll ' s)
Unlike other Lisps it hat (address   ) and can access (read/write) physical memory.

As an example (need to replace the use of the arrow keys for navigation -- what ure the usual keys ??  --  I'm working on a (mainly) French AZERTY keyboard )  , pro demo a short console based prog , calculating a Fibo number,  then the pseudo 3D L-systems.   (use arrow keys and PgUP , PgDn (zooming)

best ,   Rob

 

All the experiments stop here (for Linux , i'll keep using Racket , under Win as above mentioned )

.
Title: Re: Rob's Lisp Adventures -- the ENDLOESUNG
Post by: Mike Lobanovsky on March 08, 2015, 09:33:52 AM
Hi Rob,

... when identical code runs fine under Linux and erroneous under Win, then there's something wrong not (?) ...

For me, it is absolutely clear what's wrong with it: the instruments are/were developed by the Linuxoids and for Linux, and then carelessly/ignorantly "ported" to hateful Windows because absolutely no application can claim, and aspire for, multi-platformness if it is/was not originally targeted for/has gained recognition under Windows as the most widespread and fundamental operating system of today.

Other people may have other standpoints about this phenomenon but mine is, and will continue to be, exactly as I stated above.

Quote
the combination thinBasic , Oxygen and newLISP does solve all problems and fulfills my needs.

I respect your choice. Personally, I think I know only one combination that can potentially be better than this but here I will keep my preferences to myself. :)

Quote
need to replace the use of the arrow keys for navigation -- what ure the usual keys ??  --  I'm working on a (mainly) French AZERTY keyboard

This problem is not uncommon to me either; all my co-developers are Frenchmen. :) The UP, LEFT, DOWN, RIGHT arrow functionality should be duplicated with the QUERTY buttons W, A, S, D, and/or the AZERTY buttons Z, Q, S, D, respectively. Zooming in/out with PgUp, PgDn buttons should be duplicated with mouse wheel rotation.

Toggling between the keyboard layouts should be preferably automated based on the OS locale actually running.

Duplication is desirable because:

Quote
... for Linux , i'll keep using Racket ...

... I presume, only if you actually happen to prefer to stay on that platform at all. :D
Title: Re: Rob's Lisp Adventures
Post by: RobbeK on March 09, 2015, 06:55:08 AM
HI Mike,

"For me, it is absolutely clear what's wrong with it: the instruments are/were developed by the Linuxoids and for Linux, and then carelessly/ignorantly "ported" to hateful Window"   - yes , (more than) probably --  Corman Lisp is the only Lisp "born" on a Windows platform , all the others are Linux.
But someone could have told me / mentioning on the web etc ...  the potential problems :   
 either by an honest warning (SteelBank CL)
  WARNING: the Windows port is fragile, particularly for multithreaded
code.  Unfortunately, the development team currently lacks the time
and resources this platform demands.
*


or removing semaphores , sync and timers (newLISP)  ***

or making no distribution at all  (picoLisp)

(could have saved me some time )

"I think I know only one combination that can potentially be better than this "  i even don't have to guess  ;)
"only if you actually happen to prefer to stay on that platform"  time will tell - the use may fade away depending on people asking to do something with it.

The included fast Fibonacci is just included by reason of propaganda  8)  En France, on dit : "on n'attrape pas les mouches avec du vinaigre "
(you don't catch flies with vinegar  8)  )

best Rob

--  *** be aware , newLISP seems to be in a way the favorite "urinoir" corner (that's also French, but the meaning is obvious) for the Lisp "academici" (honestly I think most of them are pretenders ).

no compiler :  the choral :  " he can't do it , he can't do it ....."
dynamic scope i.o. lexical  :  the choral :  " he can't do it , he can't do it ..... he's too stupid"
semaphores , syncs :   the choral :  " he can't do it , he can't do it ..... he's an idiot"

imo newLISP is closest to the original concept of Lisp (it borrows a lot from Scheme too )  -- maybe it is too simple for some  people ???
Title: Dynamic Classification of Escape Time Sierpinski Curve Julia Sets ;-)
Post by: RobbeK on May 05, 2015, 03:21:37 AM
Hi all,

I'm back to windows ... (and be very careful if you have a dual OS on your machine -- the Linux GRUB is very hard to remove, I needed a boot CD to fix the MBR to start up in Windows again ).

OK, found something interesting that may be of interest (on http://math.bu.edu )

I wrote it first in PLT Scheme and found there is no difference in operation time between an iterative and recursive definition of the fractal.

goes like this :

(define (juliaR x y rg ig it maxit orb)
  (if (or (> orb 4.0) (= it maxit )) it
      (juliaR
       (- (* x x) (* y y) (/ (+ (* 2 ig x y) (* rg x x) (- (* rg y y))) (+ (* 4 x x y y) (sq (- (* x x) (* y y))))))
       (- (* 2 x y) (/ (- (* ig x x) (* ig y y) (* 2 x y rg)) (+ (* 4 x x y y) (sq (- (* x x) (* y y))))))
       rg ig (add1 it) maxit (+ (* x x) (* y y)))))


As this is only f(z)=z²-C/z² and these already need some pen and paper to convert into f(x,y) I switched to complex numbers.
To my surprise and working in Clozure Common Lisp unexpectedly there is almost no loss in processing time between real numbers and complex.   !!!!

the complete formula simplifies into :


(defun juliaC (z c it maxit orb)
   (if (or (> orb 4.0) (= it maxit )) it
     (juliaC (-  (sq z) (/ c (sq z))) c (1+ it) maxit (abs (* (realpart z) (imagpart z))))))

(where sq is definied as   (defun sq (x) (* x x))


you can see I replaced (at the end) the usual |z| for testing the orbit escape limit with an hyperbolic criterium (gives nicer images  ;)   )

As there 're some poles in the formula it's even possible to ignore these by telling the compiler :

(set-fpu-mode :overflow nil :invalid nil )
it's very easy to expand the definition into any power of z -- prototyping can be done in minutes.

best Rob

.
Title: Re: Rob's Lisp Adventures
Post by: JRS on May 05, 2015, 12:26:42 PM
Quote from: Rob
I'm back to windows ...

 :o :'( :-X ::)
Title: Re: Rob's Lisp Adventures
Post by: Mike Lobanovsky on May 06, 2015, 08:00:25 AM
Hi Rob,

Welcome home. Long time no see. :)

This Julia looks cool. The fractal seems symmetrical; would it be reasonable to calc just one quadrant and then flip the image to the other ones, do you think?
Title: Re: Rob's Lisp Adventures
Post by: RobbeK on May 06, 2015, 10:48:03 AM
Hi John, Mike ..

John, it's not a question of better or worse ..

Mike, yes 4 symmetry axis's  -- an "octant" (if this is the correct word already would be enough ).
BTW I could solve that problem with glLists under Windows for PLT Scheme -- it's rather weird, but the list can only be build inside the main gl loop.  In this case a flag does the trick (if true the list is not compiled once again ).
Attached an example -- a start of a 3D presentation of the Newton-Raphson method for finding roots of equations.  It's based on a seed and this guess is iterated till the result is acceptable.  However for numbers (complex) that are at about the same distance of the roots, it starts to generate fractals --  easier to understand when you see it.
It are a heap of calculations, the canvas will be blank for some seconds , but then if you push the rotate button , you can see the glLists work , nothing is recalculated again  :)

This is a representation of the z³-1

ps : the iterations is a'=a - f(a)/f ' (a)
(this is only a quick start to see maths are correct --   (define (newton ...      are only a few lines in lisp (see image)  )

best & thanks   Rob   

.
Title: Re: Rob's Lisp Adventures
Post by: RobbeK on May 07, 2015, 12:04:28 PM
I calculated a general formula that does any Newton-Raphson given by Z^n=1

the iteration step is      Z'= Z-1/n[ Z - Z^(1-n)]     8)

Now , Freebasic and the Math module of Mr Jean Debord (as a DLL) will speed things up a lot.  While not slow, PLT Scheme is "only" a bytecode compiler with GNU Lightning JIT .

There is no complex calculus module for Oxygen ??

attached : a fifth power

.
Title: Re: Rob's Lisp Adventures
Post by: Mike Lobanovsky on May 07, 2015, 03:21:01 PM
Wow! It gives me the creeps as if it were alive...  :o
Title: Re: Rob's Lisp Adventures
Post by: Charles Pegge on May 07, 2015, 10:18:21 PM
Hi Rob,

I'm working on a complex library based on the Freebasic Math lib you posted some time ago:

Code: [Select]
  ' ******************************************************************
  ' Complex number library
  ' ------------------------------------------------------------------
  ' Based on ComplexMath Delphi library by E. F. Glynn
  ' http://www.efg2.com/Lab/Mathematics/Complex/index.html
  ' ******************************************************************

It is tied in with Oxygen's operator-overloading system, which I think needs to be implemented in direct code instead of function calls, to get the best performance for fractals.
Title: Re: Rob's Lisp Adventures
Post by: RobbeK on May 08, 2015, 02:26:29 AM
Hi Charles, Mike ,

The intention is to get something as attached Z³=1  ..  however commercial software is used and a 1600x1000 pix image needs around 2 hrs of calculations (March 2011).

The use of complex numbers may be preferable as the formulae grow rapidly in length (attached same zzz=1 and here on the right it even has to be split in a real and imag part  .. it would be possible (theoretically) to obtain these data from the complex formula and these data turned into code (Lisp/Scheme) can do this -- but this will take some time.

Yep, that's the lib , you got the pdf ??  (attached) ;;
the nice thing is that (unlike in many other systems) the operators are redefined they can take complex numbers directly.

like Z=Z*Z     

+ - * / ^ and = !=    are (forgot about < > etc ..  but these use the magnitude anyway which are real numbers.)

Writing such a ray tracer in oxygen , freebasic would be a real challenge (the maths behind it may not be that difficult)

best Rob

Ah, yes , for fun -- I also make pictures  (photography)  attached a work inspired on fractals  8)

.
Title: Re: Rob's Lisp Adventures -- the Wheel in PLT Scheme
Post by: RobbeK on July 24, 2015, 05:39:34 AM
Hi all,

Found something "useful" considering the Wheel.
About twin primes (both p and p+2 are primes  ... like 11 and 13) ; iirc still not proven there are an infinite number of those twins.

The Wheel is fast - 1000000 number testing on a slow computer :
0.9 sec in newLISP  (script)
0.35 sec in PLT Scheme (bytecode and JIT)
0.015 sec in Steel Bank Common Lisp (native code)

-- & thanks again for SetWindowPos (it is used here)

best , Rob
(ah , yes Miller-Rabbin used for the primality test , but is seems Solovay-Volker-Strassen is faster (?) )




[attachment deleted by admin]