PureBasic Forum

What is the overarching reason for requiring that the target of STEP be a constant?

The only reason would be simplicity. That's the way Fred coded it originally, and he found no compelling reason to change it. Using a variable STEP wold require extra code edits.

I can't imagine it being that burdensome to accommodate variable STEPs. If it's going to be that inflexible, why have FOR ... NEXT ... STEP at all? Can anyone think of another language with this requirement? If I remember my C correctly:

It is kind of like comparing apples to oranges, based on what the language author decides is "best".

In reality, the For loop in C does not have a Step at all! it is merely three consecutive statement groups, the middle "usually" a comparison. I say groups, because this is legal:
for (a=1, b=2, x=0; x<=10; x++, a++, b--) // note the "numerous" statements separated by commas.

Carrying that even further, in C, you can do just about any loop with just a For loop. You can omit any of the statements, and even this is legal:
for(;;) //infinite loop

In other syntax, C does not allow anything but constant integers in Switch (Select, in PB) statements. That is, this is illegal in C:

switch x {
case i : //fails because i is a variable
statements; break;
...but it is perfectly valid in PB. One reason is that most C compilers actually separate out the statements from the CASE tests, and put the statements after all of the CASE's so it is the equivalent of a string of "If Test is True Goto..." statements. To contrast that, PB merely parses it sequentially so there is a jump for each and every test.

And back you your original question: no, it would not be overly burdensome for variable steps to be implemented. However, many newbies would get confused by it so I will be surprised if Fred ever does it. Especially when there are other loops that are suitable for it.

I think it would be more confusing for newbies to find that STEP must use a constant. Whatever.

I agree.

No reason why there should not be two 'For Next' functions though, keep the current one and add an advanced version that accepts integer vars. Not all PB Newbies are new to programming, many already know at least one other language.

For what it's worth, this works.


BP

@chris319: I have two quotes from the developers that throw some light on this topic.



This quote was given Jan 27, 2004 in the thread [url]http://www.purebasic.fr/english/viewtopic.php?f=3&t=928[/url]. If implemented this would have been accomplished in Version 3.90 .




This quote was given May 11, 2009 in the thread [url]http://www.purebasic.fr/english/viewtopic.php?f=3&t=37400[/url].


It would seem from just these two quotes that Fred wanted to implement the idea at one point in time at least. It would also appear that when an expression is used for the step value a more complex condition is created for testing for the end of the loop.

Some discussion on aspects of the complexities can be found in the thread from 2009. It can be summed up by saying that with a variable start, stop, and step it would require a loop that tests for multiple situations in each iteration through the loop. If a constant is used then only one condition is tested for because it makes use of the sign of the step value at compile time.


I have a hope that it may still be implemented at some time in the future. In the meantime it can be accomplished with While/Wend or Repeat/Until loops.

Not that anybody much cares, but there is an ANSI standard for BASIC which specifies that the target of STEP be a variable. The document is ANSI INCITS 113-1987 (R2003).

In Pascal it's worse. The increment is 1, unless you use the keyword DOWNTO instead of TO, in which case it is -1.

That right there sums it up. There are no ANSI basic compilers, and very few come close.

@BasicallyPure:

Unfortunately your code will not work when the variable inc is negative (say -2).
Even replacingbystill fails.

This complication is the main reason why I also think that the For..Next loop should natively support an expression for the Step.

+1.1


This does not work (yet). But how simple.

no not simple, it makes problems like this:


The reason is the inaccuracy of doubles

so, no For:To:Next with float or doubles!

Needs to be rounded first, of course.
Too many people think that floats are working like we learned at school (inlcuding me at the beginning). The forum is full of "is this a bug?" for that.... (please check....)
A way to prevent this ambiguity, is to fix the rounding automatically.
Another language uses PRECISION n for that.
Consider this:
PRECISION 2 should be the default value, as most currencies have 2 digits after the decimal point.
Numbers like 9.00000002 should be replaced with 9.00 and 8.999999997 also to 9.00
That way, farewell to the problems!
But it depends of Fred/Freak....

While that precision rounding could be handy, it significantly increases code complexity on the inside.

What might be another solution would be to have fixed-point numbers, rather than convoluted fixes for those who do not understand floating point. Fixed point are much faster--basically, they are integers, with a decimal point located n position from 0. For instance, fixed point of 2 could have a memory value of 12345, and would print on debug as 123.45.

In all reality, though, because of the naivete' of most newbie coders, integers could be used for almost everything. (Few understand that floats are insufficient for currency!) It would solve a lot of their problems, and make the code a lot more efficient.