Friday Facts 384 explained

[ZenMikey]

Hey all! Hope I have the right forum here. I've been doing summaries of some of the recent Friday Facts leading up to Space Age and, well, was hoping to share with the forums and see if anyone was interested.

https://www.youtube.com/watch?v=_EwtvVfKK-c

Please let me know what you think!

[mmmPI]

It was a pleasing watch it's always interesting to see what i missed when someone sum up a text i've also read, i like the level of details and the effort in the images.

I think the random output can become a widespread clock, if you only have 1 input to negate randomness it will generate pulses at a defined interval without requiring a change in value every tick which i highly suspect makes it more UPS friendly than using self reseting counter for the same purpose.

Will watch the other videos.

[ZenMikey]

It was a pleasing watch it's always interesting to see what i missed when someone sum up a text i've also read, i like the level of details and the effort in the images.

I think the random output can become a widespread clock, if you only have 1 input to negate randomness it will generate pulses at a defined interval without requiring a change in value every tick which i highly suspect makes it more UPS friendly than using self reseting counter for the same purpose.

Will watch the other videos.

Thanks for the feedback! That's an interesting idea for a more UPS friendly clock. I wonder if the randomness happened to pick the same element twice in a row, would that double that clock cycle? Could probably account for that somehow, or maybe it would be worth it for the UPS improvement.

[mmmPI]

Output a random signal from the inputs (with a custom update interval).

The way i understood this from the FFF, given that the GUI doesn't allow to tick red or green there was that it would pick a random signal amongst those present in green and red summed up if a signal is present on both, and output it with the value associated, every "x" ticks as a pulse, x being the interval.

As such, i suggested for a clock to only use say a constant combinator set to ouput C=1 as input, so that everytime the randomness proc (every x ticks) it would choose the same element.

I wonder if the randomness happened to pick the same element twice in a row, would that double that clock cycle? Could probably account for that somehow, or maybe it would be worth it for the UPS improvement.

I think it would not matter for the clock cycle, not sure i explained properly the first time or that i understand what you mean. I meant that one can choose a fix hardcoded interval of say 5 or 60 ticks and then the selector combinator act as timed-pulse generator or a clock that counts up to 5 tick or a second and then send a pulse and reset but doesn't take all the intermediate value of 1 2 3 4 ( 58 59 ... ) and brodcast it into the network requiring successive updates.

At least that's how i thought one could use the "random output" if not to get a random output, abusing the "interval" mechanic rather than the "random".