Alla som är intresserade av att delta och göra ett program som beräknar ett mandlebrot kan utgå från denna psuedokod:

(Saxad från http://www.pjde.demon.co.uk/answers/mandel.htm där även ett exempel skrivet i C finns)

<code>
x = y = 0 ( z ( 0 ) = 0)
for p = -2. 25 to 0.75 step (real increment)
for q = -l.5 to 1.5 step (imaginary increment)
for n = 1 to (iteration maximum) step 1
x' = x * x - y*y + p
y' = 2*x*y + q
m = x' * x' + y' * y' (the square magnitude of z)
if m greater than cut-off value
colour point with colour
reset n and escape n-loop
x = x'
y = y'
next n
next q
next p
</code>

Lite värden behöver dock definieras för att programmen ska vara rättvisa:
cut-off value = 100
(real increment) = 3 / 640
(imaginary increment) = 3 / 480
(iteration maximum) = 256

Din fraktal ska alltså bli 640x480 pixler stor och bestå av 256 färger.

Reglerna för de som vill delta i en inofficiell tävling är följande:
Språket är valfritt.
Koden får implementeras på valfritt sätt, dock så skall alla bilder som produceras skall vara exakt likadana, detta på grund av att variation kan påverka tidsåtgången för programmet att köras enormt mycket.
Programmet skall ange exakt hur lång tid det tog på sig att generera bilden (som givetvis måste visas på skärmen) räknat i millisekunder.
Bilden skall gå att spara som en bitmap med 24 bitars färgdjup (bmp-format eller gif-format är ok då jag vill kunna jämföra bilderna på ett enkelt sätt).
Färgskalan skall vara grå, en grå färgskala är enkel att generera, sätt bara r,g och b till samma värde som n-1.
Alla bidrag mailas till <mailto:pontus.wang@home.se>.

Vinnaren får behörighet att kora sitt språk till det snabbaste språket i ren prestanda och ingen får säga emot honom under loppet av en vecka, alla andra får bita i det sura äpplet och hålla med.

Prestandatestet jag kör (5ggr per program, snitttiden är den som gäller) blir på en Celeron 600, P3 800@897 samt en P3 500, samtliga kör Windows XP, kommer det in program för andra plattformar så är det inte helt olösbart.

All källkod skall följa med, den komer att packeteras i en zip-fil och publiceras på filarean.

Prestandatestet körs Lördagen den 24 maj eller när minst fem olika språk är representerade efter det.

Denna post dubbelpostas även i skrivklådeforumet...

En korrigering i reglerna:
att spara bilden till hårddisken skall inte ingå i tidsåtgången, enbart presentationen och beräkningen av bilden!

"Vinnaren får behörighet att kora sitt språk till det snabbaste språket i ren prestanda och ingen får säga emot honom under loppet av en vecka, alla andra får bita i det sura äpplet och hålla med."

haha kan inte låta bli att skratta :p

Öh?
Du har inte läst om Mandelbrot/Juliafraktalerna, va?
>cut-off value = 100
Det ska vara sqrt(x^2+y^2)>=2 eller (mycket mer beräkningseffektivt) x^2+y^2<=4.

Det är liksom inget man drar till med, det är en bestämd konstant. Om radien är över två så kommer punkten aldrig röra sig mot Mandelbrotmänden, utan växa mot den komplexa oändligheten.

Jodå jag har läst om dom, jag har mycket medvetet valt just denna algoritm för att inte bara språket ska spela in, programmerarens kunskaper ska spela in för det finns så många ställen att plocka prestanda på.

Vidare ska även kunskapen i att leta och läsa om algoritmer spela in, annars är tävlingen i sig inte helt rättvis. Rätt implementerad så kommer även ett rejält slött språk (QuickBasic t.ex.) kunna producera konkurrenskraftiga tider.

Och ännu effektivare (x*x) + (y*y) <=4

>Jodå jag har läst om dom,
Men varför har du då skrivit 100 istället för 4?

>jag har mycket medvetet valt just denna algoritm för att inte bara språket ska spela in
Jag kan inte låta bli att tycka att det inte riktigt funkar. Algoritmen är ju fullständigt beskriven. Man kan inte påverka ett smack.

Då kommer det snarare in snygghetskrav, tycker jag. I C++ kan man skriva den förbannat snyggt eller förbannat snabbt, beroende på den mycket speciella utformningen av den fraktala ekvationen.

Den enda optimeringen man faktiskt kan göra (som jag ser det) är på assemblernivå, något som numera nästan är att betrakta som förlegat. Såna optimering ska ske EN gång, och det är vid utveckling av ett bibliotek.

> Men varför har du då skrivit 100 istället för 4?

Som sagt, för att folk inte ska förlita sig på den algoritm jag presenterat, därför tog jag den i exakt det skick den fanns på sidan den var beskriven.

> Då kommer det snarare in snygghetskrav

Nope, prestanda i språket var det främsta argumentet för att utlysa denna tävling överhuvudtaget.

> Den enda optimeringen man faktiskt kan göra (som jag ser det) är på assemblernivå

Med hänsyn till regelverket kan man påverka prestandan på många punkter, iofs kan man inte påverka algoritmen i någon större utsträckning men man kan påverka många element i den så till den milda grad att det märks tydligt i utresultatet.

> Såna optimering ska ske EN gång, och det är vid utveckling av ett bibliotek.

Javisst, men du kommer alltid att hamna i situationer där du får göra avsteg från det bibliotek du använder dels på grund av prestanda och dels på grund av speciella krav från slutkund.

Ta det för vad det är, en möjlighet att bevisa dina kunskaper i optimering. Min övertygelse om vilket sprråk som skulle vinna en sån här tävling är det språket som har den bästa kompilatorn och snabbaste biblioteket om alla använder exakt samma algoritm det är därför jag formulerat tävlingen som så att utresultaten är de som räknas. Det ger alla samma möjlighet att delta och vinna även om olika kompilatorer genererar olika resultat.

> Och ännu effektivare (x*x) + (y*y) <=4

och ytterligare lite effektivare (det är inte mindre än, utan större än!) om man använder booleska operatorer...

(((x*x) + (y*y)) Or 4)

Men det stämmer inte heller kom jag på, felet får ni klura ut själva...