SE-0202 Amendment Proposal: Rename Random to DefaultRandomNumberGenerator

[Jens]

I could probably agree with most of the above. But I don't think the topic of this thread (the name change) is that important, and I agree with @xwu's post. And more generally, I still stand by …

… most of what I said …

@Jens

Note that range conversions like these could be factored out as a set of numeric range conversion methods/initializers that would be useful on their own. In this particular case it’s range conversion from the full range of UInt64 to the unit range of a floating point type, but it can also be for converting between the full range of any two fixed width integer types (which can be useful for eg doing bit depth conversion).

@Jens

And more generally, I still think that there hasn’t been nearly enough (hardly any?) actual practical usage/testing/experimentation using the proposed API in order to know how, or even whether or not, it can be successfully extended with custom (seedable) PRNGs, and eg Gaussian distributions etc, and IMHO it sounds like a lot of people here are OK with just assuming that this API is a good starting point and that everything will just work out even if we haven’t actually tried to do anything real with it (ie try to use it for some little game with procedurally generated graphics and levels, or a little raytracer (which could use 2d gaussian values for multii-sampling) or something).

I haven’t looked into the playground of @nnnnnnnn which seems to be the only effort that has been made in this direction. But for example, it’s impossible to measure efficiency in a playground settings.

My guess/feeling is that I will have to continue using my own little Random library (that I have been using, testing and modifying for a couple of years) even If this proposal is accepted. My requirements are PRNG, and the generators and the stuff based on them (conversions into various floating point ranges, other distributions, etc) have to be as fast as is possible, and I’ve sometimes needed different generators for different scenarious, sometimes trading speed for quality, perhaps a generator with a state that is of suitable size for a particular task, etc. I have never needed a non-seedable cryptographically secure RNG, but I understand that there might be others that have, and I understand the rationale of having it be the default. My use cases have been graphics/audio/signal processing (which would include games with procedurally generated graphics, levels and stuff like that).

I don’t have the time to dig deeper in this (trying out and/or providing example code etc) but maybe these negative ramblings of mine can provide some sort of non-negative value anyway.

@Jens

It’s more complicated than this in practice (when you take into account optimizability etc). And these are things that has to be tested rather than assumed/speculated. The currently discussed Random API could be designed in ways that make these extensions straight forward and successful/fast or practically impossible, forcing users to make eg their gaussian 2d distr random number code on the side, unrelated to the Random API.

But perhaps this thread has seen enough of my negativity now : ) Maybe I will find the time to channel my concerns via requests for improvements instead, once this Random API has been approved and is available in dev snapshots.

@Jens

Again, some concrete example use cases / projects in which the Random API could be put to actual use would quickly reveal these and many other issues/questions, as well as serving as an actual foundation for the design decisions, currently there is no such foundation except vague speculations.

It looks like a practical foundation for and evaluation of the design of the API will have to wait until after a(n essentially untested) proposed API gets approved and implemented, which seems a little backwards to me.

@Jens

If the idea is to separate the PRNG-part into an additional proposal, I think it would be better to discuss it now and include it in this proposal, in order to ensure that the RNG-part (having otherwise been designed in isolation) doesn’t end up negatively impacting the design of the PRNG-part.

… in the proposal review.

---

And more importantly …

… I think it would have been better to simultaneously discuss, design, use, test and benchmark this Random API as a stand alone implementation (not a framework, just a couple of source files to be used module internally (for simplicity and optimizability-reasons) within a set of non-trivial sample-projects that would put it to actual and heavy use), before adding it to do standard library.

This would have given its design/implementation some valuable time without having to be incrementally evolved, making it possible to evaluate instead of just speculate about the pros and cons of various designs and implementations.

Big changes to the Random API might be hard to get through, once it has landed in the standard library, which I think is unfortunate.

I'd for example like to see if would be possible to increase both composability AND (I'm quite sure) performance by factoring out some of the range conversion aspects of the current Random API to a separate Range Conversion API (I'm not sure if range conversion is the proper term here), ie I have this UInt64 value (could be random, doesn't matter), and I want to convert it from the full range of its type (UInt64) to the full range of some other fixed width uint type, or to the full range of a certain number of bits, or to a unit range Float, Double or Float80, or to any range (eg -1 ..< 23), etc.

A Random API is (or will at least eventually be) a big thing, and it's important to get it right, especially if its API is to be spread across many other types of the standard library (via eg static .random(in: using:).

---

I will, if I may, probably continue to ask questions about and point out possible opportunities of improvements in the Random API on these forums (though not here, but in Using Swift or Dev / Std Lib), rather than in code review on GitHub.

… any reply to this post, should probably go in a new separate thread. : )