When I print out the values outputted from the float it starts at 332 and counts down to 0.
As others have pointed out, your original patch uses recursion for the loop.
Recursion means that you are feeding the result of a calculation -- [+ 1] -- into the HOT inlet of the previous object. "Hot" inlet means that the chain of processing must continue immediately, and it must remember all of the steps. Remembering the steps takes up memory, which is why recursion depth is limited.
So recursion is usually something to avoid, unless you're sure that it's the right way, and you're sure that you're doing something to stop the recursion before hitting the depth limit. (590,000 cycles is way, way beyond the limit -- Pd recursion will never be able to handle that many.)
The solution from Alexandros avoids recursion by putting the [+ 1] result into the float box's COLD inlet -- so, this result has been prepared for the next "bang" from [until].
This does have to do with the "counting down" phenomenon.
The left side is counting recursively. The [t f f f] toward the bottom is there to show the impact of different order of execution. For every recursive iteration,
- First print the "before" value;
- Then calculate the next value and recursively loop back -- so this next value will print "before," and calculate its next value and loop back, printing "before" again and so on.
- Only after the [moses] has stopped the recursion can it then backtrack through all of the recursion levels to print "after" -- but now it's backtracking. So the first "after" to print will be the last value processed, continuing in reverse order.
So, using recursion as you were doing, if you simply add a print box after the fact and connected, the order of execution is the same as my [print after] box.
Doing it the optimal way, with [until], then the recursion disappears and the printed output is more intuitive.
One of the problems here is that (AFAICS) Pd training materials do an absolutely abysmal job of prioritizing the materials. It happens that section 2.3.3 of the manual does illustrate the basis of a correct counter (although it's incomplete), but -- while this concept of feeding a value back to a cold inlet is absolutely critical and the foundation of a large percentage of what you will do with Pd, it's mentioned almost in passing, and the text does nothing to highlight how absolutely critical it is (and it really should present a complete, usable counter, with initialization and a termination condition -- but it doesn't do that either).
I have some decades of experience with text-based programming, but it took me months to understand how to count properly in Pd, and more months to extend that concept to related use cases. I'm sure that's partly because of some degree of pig-headedness, but I don't think that's a complete explanation. The manual is simply not very useful pedagogically