The buddhabrot (challenging ?)

[RobbeK]

Hi folks,

been very busy for a while ( beyond enjoyable to be exact ).

Someone interested to try coding this ?

http://www.vb-helper.com/howto_buddhabrot.html   (for VB)
http://erleuchtet.org/2010/07/ridiculously-large-buddhabrot.html  (for Common Lisp)

(i'll try to build something from scratch )

In the mean time all my Common Lisps can allocate contineous memory and address it , the (pitch) pointers adjusted to all the CL types -- a big plus for buffered graphics.  (all this after some sweat, blood and tears -- I really should have learned C when young ).

Also interesting :   
http://dev.ronware.org/p/reva/home
https://aaron-tech.com/8th.html

best, Rob

[Aurel]

Hi Rob
do you can explain how i can download this thing called 8th
on 8th home page there is no link for download?
is this stuff free or comercial ..
thanks!

[Mike Lobanovsky]

Hi Rob,

Long time no see.

The VB script is suitable for use in FBSL literally with just one correction which is to replace the CInt() function with a % (i.e. to-integer) cast.

[RobbeK]

Hi Mike,

8th : https://aaron-tech.com/contact.html?lang=en   --  for becoming a tester -- (I only had a quick look at Reva, which seems interesting )

and also quickly read Wikipedia about the Buddhabrot -- I think, (I hope) that in this case the image generation can be memoized, -- unlike the Mandelbrot , this stuff is based on random situations, there is no exact Buddhabrot (i think) it depends on the level of iterations (it is based not on the attractors, but on the non-attractors) , so even when the memoizing is wrong (as I did with the Mandelbrot ) the generated images will be any exact as any others 
By memoizing, it may speed up things 100x - 1000x   (we'll see)

best, Rob

[Mike Lobanovsky]

Rob,

Can you please edit your previous message in such a way that the other poster could understand that the 8th: line with the link refers to his question rather than mine? Thank you.

[Mike Lobanovsky]

On the subject matter, I think we won't be able to have an efficient Buddhabrot painting algo either way, VB or Common LISP, memoizing or no memoizing.

Below please find a snapshot of Buddhabrot drawn by running nVidia's CUDA program for some fifteen seconds on my PC. Note the mere 16.5 FPS rate with 20K drawing threads running in parallel directly on the GPU!

Attached are also the program's binaries. Please note however that you'll be able to run the program only if you have a modern CUDA-capable nVidia graphics card and latest video drivers to match.

.

[RobbeK]

Hi Mike,

Wpw, that's an enviable piece of hardware --  I'm miles away from such things  (mm lightyears could be exacter) .. but I'm trying something for the moment , memoizing is possible, be it with a serious math error (which in the case of the buddha may be interesting )  - kind of working with half half-floats qua precision.  (because the resolution is cut on the size of a pixel in a grid).

(in Scheme compiled with the "brutal" STALIN compiler it works extremely fast , sadly I could not connect this Scheme with C style memory allocation and pointers -- the graphics are not buffered and I lose around 90% of processing time on plotting single pixels (for a low level of iterations below 1000).

As an illustration, one of the problems of allocating memory within the Lisp image  (it's weird) :

things work both in interpreted and compiled mode , however the moment you make a standalone application (for an alien computer) Lisp saves its complete image and then if running the program and if the memory allocation is pointed by a variable that is declared global   (like    (defvar x (mem-alloc ... ))  CL or (define x (mem-alloc ...)) Scheme ) the system answers :      "system halted - attempt to assign data from a previous session "   
however with the local declarations   (let or the nested (let*     CL/Scheme and the recursive (letrec    (Scheme) everything is OK and the standalone runs perfectly.

I'll send an Email to 8th, and if I get an answer , I will repost it.

best, Rob
     


 

[Mike Lobanovsky]

Rob,


1. Thanks for the update on what you're planning to do. I'm eager to see the results.



2.

Hi Mike,
8th : https://aaron-tech.com/contact.html?lang=en

I'll send an Email to 8th, and if I get an answer , I will repost it.

Please do not address this information to me any more. I am not interested in it nor am I affiliated in any way with that other entity that asked for it -- please see the attached snapshot and act accordingly.

Thanks in advance!

.

[JRS]

Lets hope the North Koreans don't get their hands on Aurel. Can you imagine what it would be like if he was being paid to act like this?

[RobbeK]

My deepest excuses , Mike ...     must have been a case of severe ...   (c attached)


Дислексия   




.

[Aurel]

so now is forbidden to ask 
maybe is something wrong with my OPERA browser ..

[Aurel]

NO is NOT...


.

[JRS]

Seriously, you need to seek professional mental health assistance. Do you have any friends?

I'm FREE of Aurel. (on this forum at least) I have added Aurel to my Ignore List. This is done from your profile settings. (last menu option - Buddy/Ignore List) Be careful you don't add him to your Buddy list. That's a nightmare just thinking about it. 

.

[RobbeK]

Not the Buddha, but the Thorn -- benchmarking some CL's

From 240 sec. in CLisp (bytecode) to around a sec in Steel Bank Common Lisp together with the CFF interface (for graphics)
(I also tried the on board sb-alien package but this is very much slower )

the ranking is slow->fast  CLisp ,     big gap ,        GCL (aka Austin Kyoto CL) (C) , Clozure CL (native) , Steel Bank CL .. (native)

best Rob
(the SBCL win port is experimental as one can read    -- c attachemt)
(Mike's JavaKiller included when using the batch file)
... much more calc. than doing a Mandelbrot (and on top goniometric formulae)   





.

[JRS]

Slow seems to be the keyword in your message. Using a socket connection between your code and GUI is got to hurt.

@Rob - You need to wean yourself off the JAPI / Java direction. IMHO