I don't see that we need this custom RNG thing. Storing the generated random number with the star gives us portability and more.
What is non-portable about this simple formula? Depending on a system-provided RNG, on the other hand, may result in different rendering on different platforms or lib versions.
For example, the seed can be controlled independently of tip position, allowing smoother variation of the output function and easier to get back to "that one half a second ago" without needing exceptional mouse stability: can use a "lower-geared" widget (less rapidly changing as a function of mouse position) or keyboard.
This seems to require some extra UI, and I'm not sure it's worth the trouble.
Much less importantly: I'd guess that there can be consistency problems with using tip position to seed the RNG, due to different floating point behaviour on different machines (and even with different compiler or compiler flags).
When computing the unique int, the coordinates are rounded to approx 1/1000 of px, which is likely to protect it from rounding errors of any kind.
On Sun, 2004-08-15 at 12:04, bulia byak wrote:
I don't see that we need this custom RNG thing. Storing the generated random number with the star gives us portability and more.
What is non-portable about this simple formula? Depending on a system-provided RNG, on the other hand, may result in different rendering on different platforms or lib versions.
I agree; including our own RNG (particulary when it's this simple) is best.
For example, the seed can be controlled independently of tip position, allowing smoother variation of the output function and easier to get back to "that one half a second ago" without needing exceptional mouse stability: can use a "lower-geared" widget (less rapidly changing as a function of mouse position) or keyboard.
This seems to require some extra UI, and I'm not sure it's worth the trouble.
I am not sure we need to go that far, but experimenting with it it feels like it would be nice if I could make fine adjustments to e.g. inner/outer star radius without re-randomizing the shape.
I think all that is required UI-wise is a "randomize" button (and maybe a keyboard shortcut, as the star toolbar is getting a little crowded...) which selects a new seed. If the current "randomness" is 0.0, "randomize" should probably also bump it up to a sensible default.
Much less importantly: I'd guess that there can be consistency problems with using tip position to seed the RNG, due to different floating point behaviour on different machines (and even with different compiler or compiler flags).
When computing the unique int, the coordinates are rounded to approx 1/1000 of px, which is likely to protect it from rounding errors of any kind.
Not for floating-point numbers. They only preserve the upper N digits of the number (starting from the highest non-zero digit) and throw away the rest. If the value is big enough for a particular platform's floating-point representation to lose the digits after the decimal point, rounding to fractions of a px won't help.
What gets really fun is that the number of digits preserved can differ depending on whether the value came directly from an FP register or from memory (which in turn depends on compiler optimization setings, etc..).
These kinds of issues were responsible for many of the hard-to-solve bugs in the libnr renderer, and why Lauris' attempt to round to fractions of a pixel didn't fix everything. (livarot works better mainly because fred uses better algorithms, though fred may also have done some tweaking to stay within precision limits)
In practice I think double will have enough precision (minimum 52 bits) that this won't be a problem for generating seeds from realistic coordinates, but you should be aware of the issue.
-mental
On Sun, Aug 15, 2004 at 01:04:00PM -0300, bulia byak wrote:
I don't see that we need this custom RNG thing. Storing the generated random number with the star gives us portability and more.
[...] Depending on a system-provided RNG, on the other hand, may result in different rendering on different platforms or lib versions.
No. Was I not sufficiently clear? We store the number with the star. I.e. in the XML. When we open the file on another platform with its different processor and different library versions, we don't call any random number generator, we just read the number from the file, and use the same number.
pjrm.
On Mon, 16 Aug 2004, Peter Moulder wrote:
On Sun, Aug 15, 2004 at 01:04:00PM -0300, bulia byak wrote:
I don't see that we need this custom RNG thing. Storing the generated random number with the star gives us portability and more.
[...] Depending on a system-provided RNG, on the other hand, may result in different rendering on different platforms or lib versions.
No. Was I not sufficiently clear? We store the number with the star. I.e. in the XML. When we open the file on another platform with its different processor and different library versions, we don't call any random number generator, we just read the number from the file, and use the same number.
There are a lot of numbers involved; we can either store them all, or store a single value to seed a portable PRNG to generate the rest.
I suppose we could theoretically infer things from the standard polygon data, but that gets too complicated to be worthwhile for e.g. rounded stars.
-mental
On Sun, Aug 15, 2004 at 01:04:00PM -0300, bulia byak wrote:
When computing the unique int, the coordinates are rounded to approx 1/1000 of px
In what ways can this be affected by the current px/mm ratio (which is in principle variable) ? One way is if the radius or centre of the star is specified in mm (or pt etc.), though this should be relatively rare.
One possibility is to retain the linear-congruential random number generator implementation (which is just a few lines, and doesn't even use long longs any more), and store a seed per star in the XML.
(I won't advocate one way or the other, just providing information relevant to a decision.)
pjrm.
On Mon, Aug 16 2004, MenTaLguY wrote:
There are a lot of numbers involved; we can either store them all, or store a single value to seed a portable PRNG to generate the rest.
I'd humbly suggest going by the portable PRNG route. IMHO, the less data stored, the better.
Note that GLIB has already a very good and portable implementation of such thing, which is one of the best (in the sense of uniformity of randomness and speed) algorithms used today:
http://developer.gnome.org/doc/API/2.0/glib/glib-Random-Numbers.html
I'd like to greet everyone involved in Inkscape and thank you all for the awesome application!!
BTW I'm looking forward to a Python scripting-plugin architecture! I've got tons of ideas for cool geometry-altering plugins. :-)
Marcelo
On Wed, 2004-08-18 at 11:41, Marcelo de Gomensoro Malheiros wrote:
On Mon, Aug 16 2004, MenTaLguY wrote:
There are a lot of numbers involved; we can either store them all, or store a single value to seed a portable PRNG to generate the rest.
I'd humbly suggest going by the portable PRNG route. IMHO, the less data stored, the better.
Note that GLIB has already a very good and portable implementation of such thing, which is one of the best (in the sense of uniformity of randomness and speed) algorithms used today:
http://developer.gnome.org/doc/API/2.0/glib/glib-Random-Numbers.html
Very interesting. I guess the only question is whether its implementation is guaranteed not to change at this point -- if we have no such guarantee, then we would need to copy it to Inkscape rather than using it directly from glib.
If it had changed in the past, that might be bad too, actually, if versions of Inkscape built with older glibs rendered randomized stars differently. So we'd also need to copy in that case.
Now is definitely the time to decide which algorithm to use, anyway, since we will be forever stuck with whatever we have selected once we release 0.40.
-mental
On Mon, Aug 16 2004, MenTaLguY wrote: Note that GLIB has already a very good and portable implementation of such thing, which is one of the best (in the sense of uniformity of randomness and speed) algorithms used today:
http://developer.gnome.org/doc/API/2.0/glib/glib-Random-Numbers.html
Very interesting. I guess the only question is whether its implementation is guaranteed not to change at this point -- if we have no such guarantee, then we would need to copy it to Inkscape rather than using it directly from glib.
I'm sure the GTK/GLIB is commited to such stability, because as you can read from the documentation, the random number implementation was not that good from start, so they adopted the Mersenne Twister and provided a compatibility flag for the older one.
From my experience, they have been very professional regarding upward
and backward compatibility.
If it had changed in the past, that might be bad too, actually, if versions of Inkscape built with older glibs rendered randomized stars differently. So we'd also need to copy in that case.
Sure, but in any case, Inkscape can always include the proper code itself if the implementation changes in the future (but I think that's improbable).
Regards, Marcelo
On Fri, 2004-08-20 at 11:43, Marcelo de Gomensoro Malheiros wrote:
I'm sure the GTK/GLIB is commited to such stability, because as you can read from the documentation, the random number implementation was not that good from start, so they adopted the Mersenne Twister and provided a compatibility flag for the older one.
From my experience, they have been very professional regarding upward
and backward compatibility.
Oh, excellent.
I think we ought to use it then.
-mental
participants (4)
-
bulia byak -
Marcelo de Gomensoro Malheiros -
MenTaLguY -
Peter Moulder