why is urn's maximum only 4096 by setting up with a message ?
it sounds like a rhetorical question, but it is a true one, actually:
why is urn's maximum only 4096 by setting up with a message ?
indeed, if we initialize it using argument, we can use greater number but not while using a message...
It may be history.
It's been a while since I looked at this in detail, but the original urn allocated one 32-bit (4-byte) integer per "value" and the getbytes() method used to be limited to an allocation of just under 32 kB per call. 4096 was the largest "round binary" number that could be allocated.
It was, in part, because of this limitation (and the fairly inefficient use of memory -- urn really only needed to use one bit per "value") that I wrote lp.ernie as a replacement.
OTOH, with an urn larger than 4096, the difference between the urn-without-replacement model in [urn] and the urn-with-replacement model of [random] is not noticeable in all except the most exotic of circumstances. So, why do you "need" that big [urn]? (My real question is "Why do you think you need that big an [urn]?")
Hi Peter,
"Why do you think you need that big an [urn]?"
is it rhetorical ? ;)
actually and of course, we can work around it.
just wanted to figure out especially if it was me that didn't understand something or the object itself that would be like I described.
actually, we can live with it, no problem.
Actually, you can 'create' a urn with a larger argument, not getting an error message, however the random numbers you get are still all within the 4096 range. You are just not warned about this!
indeed. I noticed that.
but making things dynamically here isn't really possible.
for reference only:
actually, Emmanuel (Jourdan) 's java based objects ej.urn can go further than that annoying limit:
http://www.e--j.com/?page_id=76
I used it for pixels.28s project, btw: