Hello.

I have made a very simple patch, by which when a bang is triggered, it is meant to trigger a unique number between 0-2, in other words, no numbers are repeated.

In the way that I set it up, it is meant to work in theory. Even my programming mentor said that it should work, in theory, and he's generally a very smart man. He's informally known as being the boffin of the academy.

A few more details:

1. This happens in both purr data and pure data, with the exact same setup.
2. There are no external libraries are used. Just plain Vanilla objects.

Code: Golf.pd

Much appretiated,
- James

@ketchupee1 like this.......... golf.pd
It is all in the message order...... http://puredata.info/docs/manuals/pd/x2.htm
David.

@ketchupee1 I can't tell why it shouldn't work in theory. I got annoyed with the unpredictability of [sel]'s behavior and did an entirely different patching:

golf_alt.pd

Then I got annoyed with myself and figured there must be a way I can use a stepped float to ensure that [sel] gets the right float on the right inlet at the right time, and sure it worked

golf1.pd

Edit- did'nt see whale's reply before I posted. the golf1.pd solution is more simple though

@dwan Oh my GOD you're right. This was driving. Me. Insane. I went over the same patch about 50 times. I haven't been this angry for a good while. Thank you so much for providing a simple, one-step solution. Fuck yes mate, fuck yes, you're a bloody legend. You deserve all the T-shirts in the world.

@whale-av said:

@ketchupee1 like this.......... golf.pd
It is all in the message order...... http://puredata.info/docs/manuals/pd/x2.htm

Your patch does not give an output on each bang

But your reference to the manual gives the solution that i used, and even a [del 0] would work !

it is legal to make a loop if there is a "delay" object somewhere in it. When the "delay" receives a message it schedules a messsage for the future (even if the time delay is 0) and is then "finished;" Pd's internal scheduler will wake the delay back up later.

@bocanegra You are correct. It seems the message order does get screwed up, with the forced repeat float arriving at the trigger before the previous float (I think..... it twists my head off looking at the printout).
So, yes, in certain circumstances my solution fails as well.
A [pipe 0] after random solves it, as does the delay mentioned previously.
Makes no sense (yet)........ it looks like the order of operations is indeed not preserved, and so far I cannot see any error that would indicate that is a patching fault..
David.

Would [urn] simplify?

The problem is in the feedback path / right inlet of [sel] which is either solved by inserting a delay or like I suggested earlier: a float object making sure the 'previous' value is passed to the [sel] objects right inlet at the right time:

I'm not sure which is more efficient CPU wise. And I'm not sure it's a 'bug' per se. Feedback in the message domain can produce a lot of weird behavior.

It's not a bug for me as long as the "right" way to do such a feedback path is mentioned in the documentation. [urn] has the same "issue" because the morphology of the patch (the feedback path) is the same as with [sel].

@ketchupee1 Ok... found...... you put me on the path @bocanegra although maybe only because you had understood it already.
Wood for trees and all that.
Not a bug.
Always feel silly when the logic jumps off the page.

The patching fault is at [trigger]
The float is not sent to the right inlet of the [sel] because the chain reaches around and back to the trigger when there is a match...... in a loop until there is a change of float value...... and then the float that triggered the loop is sent to the right inlet of [sel] after that operation has completed (too late now).
A [pipe] after [random] breaks that chain, as does a [delay] before [random].
[pipe] insists that floats pass through in order that they arrive, holding up the loop until the first float has completed all of its operations, and [delay] holds up the chain for long enough for the second operation of [trigger] to complete first.

The loop itself is not a problem. It is that it interupts the operation of the trigger.

[golf1] works because there is no [trigger] ordering before [sel], and that was the clue....
The first float is not compared.
The following floats are.
But if a bang is sent from the left outlet of [sel] the resulting float from [random] is compared with the first of the matching floats which is now the argument of [sel] from the last float banged into its right inlet when there was no match and the [sel] operation had completed. A subsequent identical pass will of course be the same as the first and so it works fine.

Needed some time bored on a train.

Of course [delay] in this case is a bug, but we are happy to call it a feature. We perceive time as something that cannot be stopped because something that should have happened has not.
"Time waits for no man".
But the left outlet of trigger really should not fire until the right outlet has run it's course.
[delay] cheats..... saying "Yeah, OK, but........ I'll do it later.... honest", and throws the completion into the next schedule.
Just as well.
David.

@whale-av Hahaha I'm not sure I ever understood what the f*** was going on, but my intuition told me to crosswire a float object to ensure predictability and I got lucky. (I tried a heap of combos before I got it right). Deep respect for your analytical level!

Minimal:
The [sel -1] allows an initial zero.

@ingox Tested it. It doesnt work. I get series of same numbers going just a few bangs in. Unless you connect the right sel out to the right f in and use the initial bang for the left f in. The sel argument is moot. It only matters for the first instance, in which you dont need a comparison anyway. Im not sure whether the [t b b] i used for the initial bang is necesary, I think not, but all in all, unless you delay the float that is "previous value" with one tick (initial bang) you get trouble.

@bocanegra seems to work here

@seb-harmonik.ar Might be a late night mistake on my behalf. Can't replicate it today so I guess I'm wrong. Still baffled by the whole issue tho... I reckon the [f] in @ingox version works similar to the suggested pipe and delay. That was not what I thought I was doing with golf1, but anyway, no reason to beat a dead horse...

@bocanegra My version should work in general. Rule of thumb is, whenever you think you would need to use [del 0], there is probably something wrong with your logic.

Anyhow, it is possible that my patch can produce a stack overflow, if the wrong number is chosen over and over by [random]. Thus it would need [del 0] to protect against it.

Here is a version that solves the issue guaranteed in one step. Not beautiful, but should work:

golf.pd

Here is another approach:
golf2.pd

@ingox said:

@bocanegra My version should work in general. Rule of thumb is, whenever you think you would need to use [del 0], there is probably something wrong with your logic.

Anyhow, it is possible that my patch can produce a stack overflow, if the wrong number is chosen over and over by [random]. Thus it would need [del 0] to protect against it.

Not being useful here, just laughing (and a bit crying - you got to love pd).

@ingox where would [del 0] protect against stack overflow? seems like it would just do it whenever the [del 0] finished

@seb-harmonik.ar Whenever the code would create an infinite loop, you can use [del 0] to break the loop:

The example on the left side creates an infinite loop and thus you get a stack overflow. The example on the right has no infinite loop, as [del 0] breaks the loop and starts a new calculation each time. The [1 (-message can be used to end the calculation. But of course it is better to avoid this and write code where the conditions are well defined so no infinite loops occur in the first place.

@ingox Neither should produce an infinite loop.
So the chain is built for this tick, and in your example on the left side [random] is only run once, with all the bangs to its inlet arriving at the same logical time.
So it just pushes out the same value many times, which swamps the stack.
It is not expected behaviour for a sub-routine in a loop, but maybe it is the only way that Pd can be a constantly running "a live" program that is fast enough for our needs?
Or it's a bug.
The [delay] forces it to run again in the next tick.
David.

@whale-av Pd has a strict order of operations. It tries to compute each tree until the end. If it recognizes a loop, it starts an internal counter. If that counter hits a certain threshold, Pd stops the computation and displays "Stack overflow" in the console.

[delay] schedules an operation for the next cycle of operations. So the first set of operations will be finished, then the delayed operations start. The stack overflow counter will be reset for this new cycle of operations.

This is the reason why the left example above will stop with a stack overflow message and the right one will go on forever without any error.