Yes, I forgot. I use that feature extensively but I forgot.
I have 10.14.2 (the current macOS) and I presume sort -R comes as part of this build of macOS. If Apple has been updating their shell utilities, I wonder what other shell utilities have been updated.
Along the scripting route, here's AppleScript's:
random number from -100 to 100
or
random number from -100.0 to 100.0
The first variation gives integer results; the second gives floats.
That's a novel solution that I hadn't considered. I didn't know AppleScript could do that. You taught me something, thanks. Of course, I would need to create at least one new action (and variable?) for each of my 300 actions that need this, so it won't work for me, but thanks. Peter said he might add something in a future version that won't require new actions, so I'll wait for that.
Or maybe it would be really good if Keyboard Maestro allowed for an AppleScript program inside a calculation, maybe like this:
That would seem a bit redundant, since you can just do it the other way round:
set N to random number from -100 to 100
tell application "Keyboard Maestro Engine" to setvariable "VarName" to N
...which could probably also be done using AppleScript, if I hazard a guess.
You presented me with two constructive ideas.
Your first statement is true, and I hadn't thought of that. However it still requires a new action and a new variable for each of my hundreds of instances. Whereas an applescript token would not require anything new since it can be inserted into a calculation. Tokens can go into calculations.
I think I understand your second point. I.e., replace all my calculations with applescript actions which assign the results to a variable (and the calculations are done in Applescript instead of KM). Unfortunately that won't work because I'm not assigning my expressions into variables, rather I'm using the expressions in certain KM actions. I guess I didn't mention that in my original post, sorry. But it's an interesting idea that I hadn't considered. Although I wonder about the efficiency of applescript actions compared to inline %calculations%.
This is done for the next version.
RANDOM(X,Y) returns a real (floating point) random number between X (inclusive) and Y (exclusive).
RAND(X,Y) returns an integer random number between X (inclusive) and Y (inclusive).
So RANDOM(10) is the same as RANDOM(0,10) and RAND(10) is the same as RAND(0,9).
I decided for the integer one, it is better to include both ends, so that RAND(1,10) means a random number from 1 to 10, which is what you naturally think of for a range like that.
For RANDOM, it is generally irrelevant whether it includes the end points since they never occur in practice anyway.
Which just goes to show that anything that is thought “easy to implement” always has more depth than you expect once you start looking in to it. All up this took a couple hours to design, implement and test.
I just noticed your reply, Peter. That's wonderful. And of course you are right, there's always a little bit of devil in the details. I think you made the right choices there. I use RAND and RANDOM a lot; so this will be appreciated! If I ever say something should be easy, I'm probably wrong. I'm a "noob", and you are a "boon" to the world. I just made that metaphor up. A boon is defined as "a thing that is helpful or beneficial." That's you.
I acknowledge that some things would be "hard," like incorporating ImageMagick code, or maybe even OCR code, into a set of KM actions. But I can hope and pray that these items are somewhere near the bottom of your list for possible future enhancements.