Random function?

Johan_8

I would like to use a randomized function with featurescript but i can't find a RAND command or similar. Any ideas?

ilya_baran

FS does not support true randomness because the feature would regenerate differently every time (see https://cad.onshape.com/FsDoc/intro.html#language-fundamentals).  You can use a pseudo-random number generator (e.g. https://forum.onshape.com/discussion/comment/18945 for a relatively weak one) and you can use the feature id as a seed for more randomness.

ilya_baran

FS does not support true randomness because the feature would regenerate differently every time (see https://cad.onshape.com/FsDoc/intro.html#language-fundamentals).  You can use a pseudo-random number generator (e.g. https://forum.onshape.com/discussion/comment/18945 for a relatively weak one) and you can use the feature id as a seed for more randomness.

john_mcclary

ilya_baran said:

FS does not support true randomness because the feature would regenerate differently every time

LOL

Johan_8

Thank you! That randomness is true enough for me 

kenn_sebesta167

ilya_baran said:

FS does not support true randomness because the feature would regenerate differently every time (see https://cad.onshape.com/FsDoc/intro.html#language-fundamentals).  You can use a pseudo-random number generator (e.g. https://forum.onshape.com/discussion/comment/18945 for a relatively weak one) and you can use the feature id as a seed for more randomness.

Can I be honest? That's a poor argument against including pRNG in the default library. RNGs are useful and it would be easy to add the pseudo-RNG from the other thread into a basic FeatureScript function. The fact that there are strong limitations is not a rationale not to have a pseudo-RNG, it's simply a reason to document the limitations and make sure the user understands same.

john_mcclary

What are some examples of useful applications for RNG in a mechanical CAD application?

Ilya is right, things would regenerate every time. In manufacturing and engineering that is insanely bad if every item you refresh your browser or more than one person logs into the same document your model just goes crazy. It wouldn't be wise to invent "The Onshape uncertainty principle", where measuring the model changes the result. 

Onshape is not a general software for simulating random events. It is a CAD package that should hold absolute positions of all points and faces. It is hard enough to debug a model that had a small unexpected change, could you imagine the stress of the support staff, or yourself when trying to debug someone's broken model, just to find out some armature designer misused an RNG feature script?

Randomness should be calculated externally then the results then imported through a CSV or by pasting  the result into a variable. That would be the proper way to handle randomness in a system like Onshape.

EvanReese

@kenn_sebesta167
I can see why it's niche enough to not add the the core FeatureScript function library, but FeatureScript is flexible enough that you can make your own library of functions and include it anywhere you like. I used the pseudo-random generator for my Attractor Pattern feature to randomly distribute points on surfaces, if you wanna take a look. I agree that I wouldn't want any true randomness because whatever I do needs to be deterministic and repeatable.
https://cad.onshape.com/documents/ca03eaf542826bb98f6cc90e/w/dda165f92e2ad786bd53d97a/e/417d0cf21d506b74a988ad79.

_anton

Pseudo-RNG is also great for getting deterministic Swiss cheese. I would not want my Swiss cheese to be nondeterministic.

kenn_sebesta167

john_mcclary said:

What are some examples of useful applications for RNG in a mechanical CAD application?

A (almost) true RNG? A tRNG is not a domain where I have any expertise so it's not something I can intelligently speak to, but a pseudo-RNG is excellent for anywhere where someone wants to create seemingly random distributions. There's the Attractor Pattern example above. And personally, I wrote a feature-script which intentionally adds tiny voids to a model in order to provoke slicers to use more material in regions of interest. (Arguably this is the slicer's job, but the reality of professional 3D printers is that we're stuck with the slicer they give us.)

john_mcclary said:

Randomness should be calculated externally then the results then imported through a CSV or by pasting  the result into a variable. That would be the proper way to handle randomness in a system like Onshape.

If we allow that randomness is useful, then why not support it? And if it's not useful, then how can there be a proper way to handle it?

Wouldn't it be much better to have a pRNG with an easily defined seed so that the user has full control? This seems to me to give the identical results but be much more user friendly than asking users to generate a CSV and import it.

Evan_Reese said:

you can make your own library of functions and include it anywhere you like.

@Evan_Reese, the problem with the "roll your own solution" is that it guarantees fragmentation over time. Generally we don't want everyone doing their own thing, because the outcome is never as good as having one robust tool which is known to be safe and reliable. I simply copy-pasta'ed @ilya_baran's code into my model and I'm perfectly satisfied with the solution, but what if he discovers a bug and fixes it? There's no route by which I will inherit that goodness.

EvanReese

@kenn_sebesta167
I agree with the issues you're describing with everyone "rolling their own solution". It definitely can get messy, and lead to people duplicating effort. It could be slightly mitigated by just importing the code from a publicly available library of FeatureScript utilities instead of copy/pasting it, that way the community can contribute to bug-fixes that will still reach everyone, but it's still not as airtight or convenient at native implementation. I don't however think that "does anyone find it useful?" is a workable heuristic for deciding what should be included natively in the program. The the error at that end of the spectrum is software bloat and a steeper learning curve. The question the devs have to constantly wrestle with is "do enough people find this useful that it's worth more complexity?" which is a much more difficult and subjective question to answer. I'm glad I don't have the pressure of making that call on behalf of all Onshape users. If I had to make the call in this one instance, I'd slightly favor not adding it, but that's just me and I think a solid case could also be made that it ought to be added, and you might be just the person to make it.

kenn_sebesta167

@Evan_Reese I agree. For me, the deciding factor is what the average programmer expects. Some form of RNG is available as a first-class function in just about every modern programming language. So it seems strange and awkward for FeatureScript to be a standout, especially considering that so much of FeatureScript is dedicated to encapsulating and simplifying the complex mathematics of 3D modeling. Naively, I expect that first class mathematics support comes with first class pRNG.

A second-class lib would be good, especially if it had official support. For instance, Particle does this where their community manager, rickkas7, is an absolute genius of a programmer. He maintains libraries which aren't (yet) appropriate for universal distribution, but they are extremely helpful for anyone who is straying up to the product's boundaries.

john_mcclary

But feature script is not a progamming language like c++ or python. It's a script that is interpereted at each viewing/refresh of the document.

We are building parts and tooling that needs to be accurate to the Nth decimal place and is absolutely the same no matter whet you open it. 

If Onshape were to add a 'regen' button next to the save button which triggers the rng would that be a compromise we can find common ground on? 

EvanReese

@john_mcclary I think @kenn_sebesta167 means (correct me if I'm wrong) a pseudo RNG and not that the feature should be different every time the page refreshes. I have no other meaningful coding background other than FeatureScript, but if it's something pretty standard in other languages, I'm not opposed. I've already demonstrated that I'd personally use it and have nothing other than vague intuition to say that few others would use it. I'm very open to being wrong here.

kenn_sebesta167

@john_mcclary, @Evan_Reese's understanding is correct. The pseudo-RNG makes a repeatable string of numbers. For an identical seed, there is an identical pattern of numbers, which is shared across all computers and devices. By way of an example, we could consider the fibonacci sequence as an example of a pseudo-RNG (although it's got very poor entropy so isn't a very good RNG). 

The idea is that you get something which looks random to the untrained eye, which for our purposes is all that we need. But that random thing is actually not truly random, so it's trivial to recreate.

I definitely buy the argument that anyone looking for a pseudo-RNG should really have their head on straight concerning randomness in a system which strives hard to be utterly deterministic.

ilya_baran

Allow me to weigh in
I didn't include the PRNG from the forum post in std because it's a very poor quality PRNG.  When I (or someone on my team or the modeling team or an intern) catch a break from higher-priority stuff, we'll expose a mt19937 implementation to FeatureScript.  True randomness (not deterministic) is of course out of the question.

kenn_sebesta167

ilya_baran said:

Allow me to weigh in
I didn't include the PRNG from the forum post in std because it's a very poor quality PRNG.  When I (or someone on my team or the modeling team or an intern) catch a break from higher-priority stuff, we'll expose a mt19937 implementation to FeatureScript.  True randomness (not deterministic) is of course out of the question.

On a lark, I decided it'd be fun to try to do this. I found a very clear implementation, https://github.com/anneouyang/MT19937/blob/master/code/implement_mt19937.py, but quickly ran into trouble implementing it in FeatureScript because either it doesn't support hexadecimal notation, or it isn't documented in some way which I can find it. That's not a mortal issue, since the hex can be represented by decimal. However, I don't know what to do for bitwise operators, so this might be something best left for an intern who can program this on the backend in whatever native language you guys use.