Page 1 of 1
for - next
Posted: Sat Jun 30, 2007 4:49 pm
by dobro
a hope of several years!!
to be able to make :
Code: Select all
a.f=20.2
b.f=2.5
c.f=2.2
for t.f=c.f to a step b.f
debug t
next t
Posted: Sat Jun 30, 2007 5:12 pm
by Kaeru Gaman
IF this would be implemented some day, I strongly request a new command like ForF, ToF, NextF.
reason:
the actual implementation of For-Next is performance-optimized for use with LONG only.
any change in the nativ command may cost performance on For-Loops done the classic way.
for some, only few circumstances it sure would be nice to use floats,
but not for the cost to lose performance on all other standard-loops.
thus, I think this request would not be granted,
just also because it's really easy to use other loops for it.
Posted: Sat Jun 30, 2007 7:30 pm
by Kale
Kaeru Gaman wrote:IF this would be implemented some day, I strongly request a new command like ForF, ToF, NextF.
Euch! If this was implemented i hope that the type would be read from the loop by the compiler and the relevant ASM used rather than new 'F' commands.
In the meantime, one work around:
Code: Select all
For x = 22 To 202 Step 25
Value.f = x / 10
Debug "Float: " + StrF(Value) + " - Double: " + StrD(Value)
Next x
Posted: Sun Jul 01, 2007 11:35 am
by blueznl
Dobro, why would you need it? In general, while / wend constructions are more maintainable, better readable, and more flexible...
Posted: Sun Jul 01, 2007 11:48 am
by Dare
For the purposes of this purely hypothetical debate:
Not sure I like the idea of ForF, ForQ etc. The compiler can optimise by determining what the iterator is.
Eg:
For myFloat = 1.0 to 99 - float
For myQuad = 1 to 99 - quad
For myUndeclared = 1.0 to 99 - float as the 1.0 is floating point literal (and we just hope it isn't a double heading into overflow and the programmer should be using EnableExplicit anyway!
)
Posted: Sun Jul 01, 2007 4:20 pm
by Kaeru Gaman
Kale wrote:... i hope that the type would be read from the loop by the compiler ...
ok, this would be much better.
and also Dare's idea with the need to predefine could be realizable...
all I wanted to state is: Do not slow down the Long-Optimized For-Next as it is!
Posted: Mon Jul 02, 2007 1:44 am
by Dare
Kaeru Gaman wrote:all I wanted to state is: Do not slow down the Long-Optimized For-Next as it is!
Agreed
Posted: Mon Jul 02, 2007 3:32 am
by Rescator
I'm biased on this, yes it would be cool, but considering how floats tend to round numbers and does not have the same accuracy as integers I can imaging the headache of debugging, and the bunch of additional bug reports the PB team need to work though that aren't really "bugs" but caused by float rounding instead.
The only speed gain of a float For/next would be if all the code inside the loop was float only. (only talking about single float, double would need it's own loop code etc)
Althoug it might be a slight pain I think it's better to "convert" the floats to integer before the loop into something usable.
(multiply by 10 for example)
Code: Select all
EnableExplicit
Define.l a,b,c,t
a=20.2*10.0
b=2.5*10.0
c=2.2*10.0
For t=c To a Step 2
Debug t*0.1 ;say hi to float rounding errors :P
Next t
I can only imagine the issues of comparing the results with another float
as 20.200000000000003 is not equal to 20.2 for example.
Maybe some of the ASM gurus here know for sure if accurate real float loops are possible or not on x86 cpus?
I suspect that it would have the same rounding issue as in the example here, but I'm no expert so...
Posted: Mon Jul 02, 2007 3:48 am
by netmaestro
It was discussed at some length here:
http://www.purebasic.fr/english/viewtopic.php?t=19452
and probably elsewhere as it's a recurring topic. There's a couple of demos in that thread showing errors in looping logic due to rounding. If that could be solved it might be viable, but I've no idea how you could achieve it.