Counter behaviour problem

[Fred]

I have a counter that increments by 10 in a loop in wrap mode. With a minimum of -45 and a maximum of 45. I would expect that the counter would keep on with multiples of 5 in a loop (this was the desired behaviour). However when the counter hits 45 the next number is -36. This kind of makes sense, the first value of the 10 increment is used in going over the maximum and engaging the reset. However, it would make more logical sense if the value that pushes the counter over its limit is preserved or discarded completely (or maybe I am using the wrong tool to count by 5 from -45 to 45 in a loop). 

In my case I would like that the over signal is discarded and after the increment that passes maximum I land back on my minimum. Another logic that makes more sense to me is if the whole value was passed, so instead of using up part of the increment value on passing the maximum threshold, that the increment is preserved and in this case, (increment 10, min value -45, max value 45) the values would proceed from 45 to -35, or 45 to -45, not as they currently do 45, to -36.

I totally understand the logic however, when this is compared with the float counter the behaviour pattern breaks. The float counter uses the whole increment every time, so the sequence goes from 45 to -35. If the behaviour was consistent I would expect the float counter go 45, -35.0000001 (or to whatever the maximum significant figures the float holds)

I guess changing this would break some patches, but the clarity of behaviour would be good to understand and make consistent.

As I want to chain two counters (as if iterating through a 2d array) it seems it would be useful in this case to have a loop out trigger on the counter actor when in loop mode. The way it is now, I cannot find a way to properly reproduce this behaviour for a lesson.

I attached a simple patch as an example of the behaviour.

Counter error.izz

[DusX]

Yes, this is great catch.

I would 100% agree the behaviour of the Float Counter is what would be expected.
Have you entered a formal bug report? I can if you haven't.

[Fred]

@DusX nope no bug report. Actually i thought that over values are all used up and it should just hit the minimum, this behaviour does not exist in either yet though. My logic is that it should be able to function as an iterator. I know that I can do this with javascript, but I am preparing lessons for beginners, with the idea that I can illustrate the principles I am talking about with Isadora and the information has another lesson built in. This is the first lesson about pixels, so javascript is a bit much.

[mark]

@Fred & @DusX 

I think the Counter actor really works as it should. It's all about how on thinks about the wrapping

For example, here's a graphic representation of a Counter with the 'min' input set to -3 and the max to +3, with the 'amount' amount set to 3.

As you can see, if you go up by three, and if you have both -3 and +3 as part of the cycle, then it works exactly as it should. Can you see why this makes sense?

It is true that the float counter works differently, so there is an inconsistency ,this I will admit. That's because the true upper limit is a fraction less than 'max'. For a Float Count with the 'min' input set to -3 and the max to +3, with the 'amount' amount set to 3, you get this pattern:

In fact, you never hit +3 because the actual limit is 2.99999999999.... (Try it and you'll see it's true.) Also not so intuitive.

Fred, if you want the Counter to work the way you want, you can set the 'max' value to the desired max value plus the amount value minus 1. So, for your case, if you set the 'min' input to -45, and the 'max' input to (45 + (5-1)) 49, you'll see that it goes 30, 35, 40, 45, -45, -40, -35, etc.

Now, I am open to changing this – we could have an "inclusive" input which would either include or exclude the maximum value. (The Counter is currently "inclusive" while the Float Counter is currently "exclusive.")

Do you have a different suggestion about how it should work to make it more logical? In the end, you probably want the behavior of the Float Counter in the normal, integer Counter. But then to get the results you desire, you'd have to set a range of -45 to 50. This also is not very intuitive. 

Waiting to hear your thoughts.

Best Wishes,
Mark