Got it! 
Yay! See how elegant that is?
Here's a functional implementation of Permutations:
It uses a custom block "%List without %item", which I hope is self explanatory. It was just miles easier to read the code by making this block separate:
dragging the pic to the editor works on my side
snap tries to stuff the data into the comment section(s) in the image
you can think that snap gets your block(pun not intended) and changes the spin/# of neutrons of the atom core so that another snap can get out your data without doing computer vision/ocr or something
Thx, copying worked - though generally I feel that ideas are best shared by (also) ”printing” the relevant code within a forum post.
Back to your DURATION OF: it’s a (useful, I think) enhancement of @dardoro ’s, adding the element of a series of runs, and calculating the average run time.
I presume you won’t mind me sharing your code for others to learn from / use / be inspired by:
If the time is accurate only to the millisecond, it's misleading to label it in nanoseconds (even if the result after averaging isn't an integer).
Yeah,I put the script pic there for sharing the code.You think that there are people who don't know how to drag script pics and post the definition,which conveys the same information.
Hmm?
We can prove that the most probable time(the maximum of the PDF) is the limit of the average.
Did you want to say that we should give the whole PDF?
True. Times should be expressed in microseconds, I suppose.
That is, if based in 1,000 repetitions.
Looks great - my compliments!
I'm not a statistician, but I think it should be milliseconds. If anything, the computed average is less precise than the individual measurements, not more precise (because the roundoff errors in the reported times can accumulate when you add them).
Obviously 
Am I wrong about this? If so, please explain.
OK. For once prepare to receive a lecture 
(To be fair, I’m not a statistician either, but at least, when while in college, I took Metrology 101)
Suppose the run time for 1,000 repetitions of a procedure under test (for lack of a better general term) is x milliseconds. Since both start and stop times are measured in milliseconds (± 0.5 ms, assuming the 
block’s precision matches its output resolution), the maximum (measurement) error of x is ± 1 milliseconds (though in most cases it’s substantially smaller). Then the average run time of the procedure under test is (x ± 1) / 1,000 = x / 1,000 ± 1 / 1,000 milliseconds, or (x ± 1) microseconds (μs).
If you really really want to be on the safe side you should use microseconds from 2,000 repetitions, where the error is reduced to ± 0.5 μs, or less. If you trust in statistical distribution, this lower limit may be set at 1,000 √2, or roughly 1,400).
Oh, I see, you're just making one measurement of the total runtime of 1000 repetitions. I was thinking 1000 measurements averaged. So okay, yes, you can report the average time in microseconds. Thanks.
(But I'm sure I remember reading why three experiments with 1000 samples each is better than one experiment with 3000 samples...)
Like I wrote earlier: your latest code looks great!
Just two refinements:
- In your first block, instead of COMBINE () USING [APPEND () () ], why not use APPEND input list () ?
- In your second block, it may be more efficient to calculate INDEX OF () IN () only once, instead of with every time the predicate is evaluated? like:
And again, for large lists, you may want to use memoization.
Can't you say
instead of using KEEP? (But compute LENGTH OF DATA ahead of time instead of for every item.)
Umm,the procedure has an internal PDF for time,but we can only measure to milliseconds.This gives a lot of space for energy It's like shining a light through a half reflector or a polarizer.The statistical effect is you get the correct amount of photons coming through.
Yes, you can, but then you would need to add testing if exception > 1 and exception < length (because of the peculiar way NUMBER FROM () TO () works: it will count down as well as up).
Like:
or, for better readability:
Alternatively, you could use NUMBERS FROM () TO () ASCENDING, from the List utilities library, which IMO is a superior variety of NUMBERS FROM () TO (), as it will report an empty list if (to) < (from):
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.