bbigelow

Using the URN object, is there a way to continue it's non-repeating nature when the patch has closed and the computer restarts?

The patch will be used in an installation and I'm having the computer turn on/off each day. So over the course of the installation (and indefinitely thereafter), I would like the numbers to never repeat. (Or not repeat for as long as possible, which with my number range is a very long time).

Using the URN object, is there a way to continue it's non-repeating nature when the patch has closed and the computer restarts?  

The patch will be used in an installation and I'm having the computer turn on/off each day.  So over the course of the installation (and indefinitely thereafter), I would like the numbers to never repeat. (Or not repeat for as long as possible, which with my number range is a very long time).

can-urn-object-not-repeat-despite-computer-restart

If you gave the [urn] a seed and kept track of the number of bangs sent to it during the day or days then at the beginning of the new day use a barrage of [uzi] bangs to catch up to the next seeded [urn] value.

I don't think this would guarantee you don't repeat an element...

Can't you use a coll object and store all the numbers, and compare each new number with its content ? And every night, save the patch before turning the computer off.

I also thought about this and set a match algorithm behind the urn object that would retrig immediatly the urn in case a value has already been output.

Thanks! I will look into the coll object.

Any ideas on a way for max to autosave the patch periodically?

Also my current setup is the patch is saved as an application, but I'm guessing that can't be resaved?

Coll's contents can be saved. Better still might be to randomly grab elements from coll and then remove them and write it out. (Depends on how many random numbers you need, but if it's a large amount, the method I mentioned will be way more efficient.

Coll's contents can be saved.  Better still might be to randomly grab elements from coll and then remove them and write it out.  (Depends on how many random numbers you need, but if it's a large amount, the method I mentioned will be way more efficient.


or make up a new rule which says that when the computer has to be restarted, the exhibition has to be closed.

Rick's patch is just perfect i guess. I never understood the 'seed' concept until now. Well, i still don't but at least i get what it does.

Thanks everyone for the replies! Great to know about these objects and their functions. However, I posted on a math forum asking the probability of the values repeating (even if the data isn't saved between shutdowns), and it's a 10 to the negative 16th power probability it will repeat in about 300 years. So i think im good. :)

ps if you ever need math help, these folks were super helpful: 

Thanks everyone for the replies!  Great to know about these objects and their functions.  However, I posted on a math forum asking the probability of the values repeating (even if the data isn't saved between shutdowns), and it's a 10 to the negative 16th power probability it will repeat in about 300 years.  So i think im good.  :)

ps if you ever need math help, these folks were super helpful: http://mymathforum.com/


indeed, if it matters or not is mainly a question of the range of numbers. if you do random(0,1) the chance that you get a repeating number is 50%, if you use the full 32 bit range it should be ok to restart the patch and its urn object after a crash (except when your patch is performing somehting for a math experiment.)

Can URN object not repeat despite computer restart?