The non-logical "for" loop
-
To me, the second example is pretty odd. I feel like the first one is working correctly. Counting 0, the first one is printing 10 times. This would be equivalent to
for (int i = 0; i < 10; i++)If someone wanted to get get the number 10 returned, they would need to use
i <= 10I feel the your second example would return 10 9 8 7 6 5 4 3 2 1.
either way, if Fuze will need to fix the first one. I'd report that to bugs
-
@Nisse5 maybe something for a bug section :) ? I think these should behave in a consistent way, i.e either the "to" element is included or excluded, but at all cases.
-
If I recall in languages like BASIC, a FOR loop was inclusive to the beginning and ending values, so something like FOR i = 0 to 10 would include all numbers between 0 and 10, as well as including both 0 and 10. That behavior is consistent with the second example given by @Nisse5. With FUZE, the first example is doing something like what @_JKDOS mentioned, where it excludes the ending value because it's doing a "<", which is consistent with languages like C, but not BASIC.
I think when the step is negative, it's swaps the "<" to a ">=" rather than just ">".
-
it is odd, the more I use fuze the more I notice these things, it's the same with arrays, 2d arrays making[10] 11 variables were in 3d it makes 10, whenever I'm using a loop or timer or array together it's really just trial and error to what it's going to do. If they change the behaviour now to make this stuff more consistent it's going to break all the demo projects and our projects,
I was using .net when it first came out and they were heavily changing the language in the updates, it had the ability to "port" your project to the newer version but it mostly just broke everything. Be interesting to see how fuze goes about it.
-
@sys64738 This one is very confusing - I'm trying to replicate what you're talking about here and failing. If I declare:
array myArray[10]And print the len() of this array, I get 10.
With:
array myArray[10][10]When I print the len() of
myArray[0]I get 10With
array myArray[10][10][10]When I print the len() of
myArray[0][0]I get 10.If I try to index these elements with a 10 at any point, I get an out of bounds error because the array contains 10 elements, 0-9.
If you're experiencing something different please let me know how I might replicate!
-
Are arrays dynamic
Array blip[10] blip[13] = 6 Print(len(blip))Prints 13.
It should be doing an out of bounds error shouldn't it. Doing the same with 2d array will go out of bounds
Array blip[1][16] blip[1][16] =6 //Print(len(blip))Errors. Attempted to index non-array type
Array blip[1][16] blip[0][16] =6 Print(len(blip))Prints 17?
Array blip[1][16][76] blip[1][16][76] =6 //Print(len(blip))Errors
Array blip[1][16][76] blip[0][16][76] =6 //Print(len(blip))Errors
Array blip[1][16][76] blip[0][15][76] =6 Print(len(blip))Prints 16?
Honestly I have no idea what len a multi dimensional array is meant to say. But it seems to be odd. After looking how java does it blip[24][67] len(blip) should return 24
Then there's the whole arrays saying they are the wrong type if a timers running. But fine if timers not running
-
@sys64738 Edited your post to add code tags for you as it was very hard to read (impossible in the email notification)
You can do so by using three of these before and after the code: `
-
-
I've had a good look at this @sys64738 and this has uncovered an interesting bug. However, I think I should be able to smooth a couple of things over here:
In Fuze, arrays are dynamic, but you can only dynamically expand one dimension at a time.
In the first example,
Array blip[10] blip[13] = 6 Print(len(blip))This actually gives me 14, not 13. As expected, it has extended the array dimension successfully.
In example two,
Array blip[1][16] blip[1][16] =6 //Print(len(blip))You are trying to expand two dimensions at ones. You'd have to do:
array blip[1][16] blip[1] = [] blip[1][16] = 6 print( len( blip ) )The result should be a 2 if this is done. However, testing this has revealed a little bug where actually this gives us 17, the
len()ofblip[0].Same thing applies to more dimensions.
Array blip[1][16][76] blip[0][16] = [] blip[0][16][76] = 6 //Print(len(blip))This result should give 2, but as mentioned before this results in 17.
When you
len()a multi dimensional array without specifying the dimension, you should get thelen()of the first dimension.I've brought the bug to attention, thanks so much for the post.
-
@Nisse5 We could really use, at least, a forEach()
-
I was ran into somthing similar.
I am a programmer, have some c/java backgrounds. I found "for loop" in fuze is very counter-intuitive until I accepted that fuze is a different programming language
// 10 is excluded for i = 0 to 10 loop // 0 is included for i = 10 to 0 loop // the loop body will be skipped for i = 0 to 0 loop
think about the code below
for i = 10 to 0 loop for j = i - 1 to 0 loop print("Hello") repeat repeat
if j evals to 0, the print statement will be skipped which causes some counter-intuitive results -
I'm kind of curious if the design of the for-loop in FUZE is influenced by some language I didn't use. BBC BASIC maybe? I found it counter-intuitive as well, but it's easy enough to adapt to. It seems the only utility of it is to be able to avoid saying "-1" a lot when iterating over arrays. I'm hoping eventually we get some kind of forEach() function/keyword, so we don't have to worry about array indexes at all (e.g. ...)
forEach i in someArray loop doStuffWith( i ) repeat -
@Discostew just felt into that trap. For FUZE I feel like "for 1 to 10", should show 1 to 10 and "for 10 to 0" should show 10 to 0. Its like "spoken language".
-
@spikey If it were meant to be like BASIC, then I'd agree. But the FUZE team have different ideas. In this case, they made it more like C and other such languages. Even the HELP section points out how the loop is not supposed to execute with the ending index value. I prefer it this way because of the major use of everything being base-0, so I can start at base 0 element of things like arrays, and end the loop as if it were the number of times to iterate.
-
@Discostew This was the reason. Anyway I think that we are committed now without breaking everyone's programs
