who would have to first work out that Future doesn't have a builtin random function.
I suggest a careful re-reading of Adam's post, as he covered that very well: Of course Future has a built in random function.
In fact, it has several given the wide range of built in scripting languages. Adam gave a C# example. V8 provides math.random() if you prefer that. Keep in mind that, given V8 is built into absolutely every Future installation, all capabilities of V8 are a built in part of Future as well. Same with all the dot net stuff. That's all a built-in capability of Future. If you don't realize you have a huge buffet of choices, well, that's a different matter. The whole point of Manifold going to the immense effort of building in V8, C#, VBScript, etc., etc, is to provide those many, many capabilities as built in parts of Future for you to use. Please take a careful look at what is already there before saying it is not available.
Likewise, if you do realize you have many choices but for some reason you don't like the various options for random number generation that are already built into Future and you prefer that Manifold adds yet another function, well, heck, that's no problem and easy to do. Manifold is always happy to add new features in whatever priority order the community signals those should be done.
Send it in as a suggestion, for example, if in addition to the many random functions already available you want one as an SQL function, and, to help indicate what priority you attach to that, please give examples how you personally need to use random functions in SQL as opposed to the various ways in which you use random functions in scripts and in other settings.
To guide any new implementation of yet another random function it is important to understand what is deficient in the existing random functions Manifold already provides. We have great respect for the people who have implemented random number functions in V8, etc. Those people are not idiots and in general know what they are doing to a very high and professional level.
If anybody wants to go out on a limb and criticize their work, well, that's OK and fair, but if for some reason somebody doesn't like the way their functions work or how they are utilized, I'd ask please show them some respect and state clearly why their way is not good enough for your specific application.
There are good reasons for using random number functions as both Manifold and Oracle have done (Oracle also implements this as part of a script). None of that prevents providing yet another option as an SQL function, but hey, to make sure we cover all bases it would be useful to know what it is about your specific use of random number functions that requires a new function, and an SQL function at that, so that whatever Manifold does in that direction does not repeat the inadequacies of, say, Google's implementation of math.random() or the C# implementation. These things are not easy to write correctly so should the priority of such a thing as indicated by community response ever rise to the level that it jumps ahead of higher priorities it should be done correctly.
I could be wrong about this but a quick review of the truly massive corpus of SQL that is out there online shows very little use of random number functions within SQL itself. It just doesn't seem to be one of those things people use all that much within SQL. It shows up often enough in scripting/programming but seems to be a very, very niche interest n SQL. So, hearing about real life examples, such as Art's, is very important for any new implementation.
I'd also be curious to hear about such examples because it seems to me that at least some of them are driven by the desire to work around inadequacies in their host systems. For example, the need to create smaller samples within other programs for analytics is often driven by the inability of those programs to work with larger data, so a subset is utilized. A better solution would be to work with all of the data instead of jumping through statistical hoops to get around limitations. So I'd be most interested in application of random functions in SQL that are intrinsic to the use of SQL itself and are not just a workaround to something else that is broken in the host program, but which is not an issue within a Radian engine.
Likewise, not all SQL implementations make it easy to call something that is in a script. If a random function is in SQL because the SQL cannot use a well known, highly standard and well understood random function in something like V8 or C#, that too is a workaround that doesn't really apply in a Radian setting. One of the several good reasons to use standard, well-known functions like math.random() in V8 is precisely because they are well understood and have gone through an evolutionary process of Google repairing inadequacies that have been found.
Adam's code is not *strictly* thread-safe.
By that standard nobody has a random function. While it would be fun for Manifold to introduce the world's first totally parallelized and automatic random function, a real achievement above and beyond what Microsoft, Google, Oracle and others have been able to achieve, well, is that really the highest priority? If anybody says "yes" I ask them, "what is your real life application that you are actually doing right now that requires that?". Pseudo-random and slightly, one in a zillion, not thread safe may not be such a bad choice for how such things tend to be used in real life. That's one reason why suggestions that contain real life examples of how the suggester personally will be using the thing tend to be more useful in terms of specifying what should be implemented.
Pretty much any grown up software tool has a Rnd() function: Postgres, SQL Server, Excel, VB, VBA, VBScript, Python (numpy), MapInfo, Access, and the list goes on. I think it will simply cause more people to ask the question: why doesn't Manifold have a Rnd() function? I spent X hours trying to figure how to do this...
Art, your ability to do logic has just gone missing. Remember the transitive property: if A=B and B=C then A=C. Using the symmetric property we can rewrite that as, if A=B and C=B then A=C and, also, C=A.
You just enumerated a few built-in capabilities of things which in turn are built into Manifold. Let's take VBScript as an example. If random is built into VBscript, and VBscript is built into Manifold, then random is built into Manifold. QED. Same for C#, V8, etc., etc. The more examples you list that are built into Manifold which provide random functions, the more you emphasize that Manifold does indeed also provide those many random functions as built-in capability.
If anybody asks "Why doesn't Manifold have a random function?", the correct answer is to patiently and generously explain that Manifold has several random functions. Explain also the utility of going to the effort to build standard capabilities into Manifold, so that such a rich roster of capabilities is placed at the fingertips of Manifold users.
Pretty much any grown up software tool has a Rnd() function:
Ah, well, the "grown up" words! :-) I suppose by that standard since Manifold has not one but several options built in for random functions then Manifold is especially grown up, way more so than things that have only one option for random functions built in.
Since you enumerated examples that have random functions other than SQL functions, then it is clear you intended to cover implementations such as Oracle and Manifold as "grown up." I appreciate you see the wisdom in Adam's approach. :-)
Without pointing any fingers at items in Art's list, Ialso would respectfully remind contributors to this thread that "random" functions are often not really random. It can happen to the best of us. For example, much to Google's surprise they discovered a couple of years ago that even their own work, math.random() in V8, required rework. That somebody claims to have a random function does not mean they really do.
To repeat the substance of Adam's post: Future does indeed have random number generation built in. In fact, it has more than one option given, say, C#, VBScript and V8 at least. There are very good reasons to use such standard implementations, and doing so in scripting is a good way (as Oracle does).
If there is any reason why users feel that the several choices of random functions that exist today do not fulfill their requirements for tasks they are now doing or in reality intend to do, Manifold is certainly happy to implement yet another random function as people desire. You all know the drill for that: send in a suggestion of what you want so it can bubble its way to the top. Even if you don't send in a suggestion, given Manifold's habit of fully articulating all possible functions within SQL no doubt in the future some random function will be added anyway. It is only a matter of when.
But, given that nobody wants Manifold to prioritize re-inventing the wheel in cases where there are perfectly adequate, and possibly even superior, alternatives already implemented, I think it is fair game to ask anybody who is asking for a higher priority for implementing yet another random function to state specifically what, exactly, is their application that drives that highest priority. That also will help ensure that when Manifold does re-invent the wheel, the design of Manifold's new wheel will fit your needs and your tastes.
How you choose to write your suggestions is up to you, but I strongly recommend you maximize the heft of your suggestion by avoiding advocacy that indicates basic misunderstanding. For example, somebody sending in a suggestion powered by comments such as "V8 has a random function, why doesn't Manifold?" is likely to influence not the engineering process but the documentation process, to ensure people are more obviously taught that V8 is part of Manifold so everything that is in V8 is a built in part of Manifold as well.
That's probably not a bad idea in any event, to ensure new users understand that one reason why Manifold has gone to the trouble of building in things like V8, C#, VBScript and so much more is exactly to ensure that such needed capabilities are built into Manifold itself.
Bottom line: if something is missing you actually use and need, send it in. Provide examples of how you will use it in real life. Ensure it is done exactly to your taste by discussing why the capabilities that already do that are not to your liking.