World: r4wp

That should work, and be more secure

arr/i/value: f

Oh, with path notation, you need to adjust the loop to start counting 
the index from 1

I'm still discovering how Red/System works :)

If your original program keeps erroring out, please enter it in the 
bug tracker

Kaj, your code throws compilation error invalid struct member i in: 
arr/i/value

Ah, it's actually even simpler :-)

i: 1
f: 0.0
arr: as pointer! [float!] allocate 10 * size? float!

while [i <= 10] [
	arr/i: f
	f: f + 0.1
	i: i + 1
]

In Linux, on your original code, I get:

*** Runtime Error 9: float invalid operation
*** at: 08048397h

With your latest version I get *** Runtime Error 11: float stack 
check (on windows).

Better enter both in the bug tracker, then

Rebolek: yes, add them to the bugtracker, I will fix them this weekend.

That's great, thanks!

Just an update, I just tried latest Kaj's code on Ubuntu under VirtualBox 
and I get *** Runtime Error 9: float invalid operation

It looks like we haven't tested floats pointer arithmetic enough.

Is that 64 bit Ubuntu?

32bit Lubuntu

Rebolek: I've pushed a fix for your issue (Intel CPU). I'm looking 
on the other issue you had with ARMv5TE.

Great! But I've got another one... putting it to bugtracker.

For the ARM isse, I'm testing with an emulated ARMv5TEJL, and both 
Fibonacci and Mandelbrot perform correctly. I've added some questions 
to the ticket on the bugtracker.

I will provide the info tomorrow when I have access to the machine.

I've answered to your ticket #220.

Thanks, it's getting late, I better should left testing for tommorrow 
:)

I've located the cause of bug #220, you should have a fix when you'll 
wake up. ;-)

Fix for issue #220 pushed.

Wow, that' was fast! :)

I've added information about my machine to #219 (no gcc info, as 
it doesn't have gcc installed).

Doc, another float! problem found (#221).

Can anybody check this code? https://gist.github.com/3135678

It's not a bug, but I wonder why the obviously more complex sine-osc 
is cca 50% faster than square-osc. These are the results I get on 
my machine:

sine-osc time:  1068
square-osc time:  1790

Are you running on OSX?

Windows

If I remember correctly, the Windows clock function is a bit different 
from the LibC one.

I use Query PerformnceCounter in Windows in my Date-Time lib.

So you think that the 50% speed difference between these two functions 
is due to Windows clock?

Windows clock is bitch :-)

http://www.codeproject.com/Articles/1236/Timers-Tutorial

There's even some mention of the Amiga in the above article comments, 
and even Carl liked it, IIRC :-)

Well the timing is consistently more or less same and square-osc 
is always about 50% slover than sine-osc. I think that it's not caused 
by Windows timing.

Beats me. It looks OK

It's true, though, that process-time is currently a primitive function

Have you tried moving the one execution before the other, to make 
sure it's not some process anomaly?

Yes.

Seems like a fairly sound timing, then

You could try increasing the loops another tenfold

Yes, I also tried putting more loops there (for example sine sine 
square square sine square), but the timing is always consistent.

Loop increased tenfold:

sine-osc time:  10576
square-osc time:  22034

Switched order:

square-osc time:  17441
sine-osc time:  15318

There's a lot of variation in the results for such a long loop, so 
it does point to timer instability

I remember that most platforms account real scheduler timeslices 
in this function, while some basically take wall clock time