for - next

[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

WITH FOR-next not another thing!!

[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.

[Kale]

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

[blueznl]

Dobro, why would you need it? In general, while / wend constructions are more maintainable, better readable, and more flexible...

[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! )

[Kaeru Gaman]

... 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!

[Dare]

all I wanted to state is: Do not slow down the Long-Optimized For-Next as it is!

Agreed

[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...

[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.