Just Another Javascript based BIG [urn]
Julien Bayle
5月 27 2024 | 8:04 午後
Hi there,
I just wanted to post something I just retrieved in my old patchers.
It is a BIG [urn], based on javascript.
[urn] is still limited to 4096.
We all dealt with that but sometimes, when I need to extend the concept, I use this one.
You can get them there. There is a test in the leftmost part of the patch. Test it. It works even with 1000000 numbers in the list and theoretically even bigger numbers !
Hope you'll enjoy this.
midinerd
5月 28 2024 | 7:56 午前
Hey Julien -
Cool implementation, thanks for sharing.
Question about javascript stuff - when you use javascript does it matter if you have it in a timing-dependent chain? Or another way of asking: Does anything rely directly on the promptness of the output of this huge urn? I love writing in javascript and am paranoid about timing, though I am also stubborn and still use it.
Does the question make sense? :) Do you query this js object and cache the result in parallel with other things going on, or is it fast enough you 'just' use it exactly like [urn] in a chain of process?
cheers
Julien Bayle
5月 28 2024 | 8:04 午前
it really depends on my needs. I already did project where I cached a bunch of things in kind of lookup tables.
In this case, it is very fast. It uses Fisher-Yates algorithm one time only, then you use the cache.
I cannot answer globally, it really depends on projects.
I'm more annoyed by objects that doesn't notify about 'job finished' than slowness of js.
It forces us to create mechanism of counting, delaying etc.
midinerd
5月 28 2024 | 10:24 午前
Yep, that's a good answer. Thanks for the insight
Emmanuel Jourdan
5月 28 2024 | 10:32 午前
I made one in Java years ago for that purpose :-) The algorithm is even simpler for the clear message, because you don't really need to reset the lookup table (it already contains all the number), so it only takes time to initialize the lookup, but after that it has a constant cost, and no CPU pic when you clear the table.
Iain Duncan
5月 30 2024 | 2:44 午後
If you are worried about timing, you could also try implementing this in Scheme using Scheme for Max, which allows running in the scheduler thread. The issue with JS is not so much that it is slow, but rather that it is running in the UI thread so the time of your code being run is dependent on what else you have going on in your patcher and can be very inconsistent.
An urn would be very easy to implement in Scheme!