On Wed, Jun 5, 2013 at 5:14 PM, Alex Tweedly a...@tweedly.net wrote:
Your code has a minor bug :-)
You get MD5Digest(S[1])
instead of using S[i]
Agh!!! ;-)
Interestingly, md5 appears to scale roughly linearly on the length of the
strings. 100x as long string means about 15x as
Right. There is a little bit of overhead for padding for both md5 and sha1
(they use the same padding method), as a string a multiple of 64-bytes is
created. Then each resulting 64-byte block is processed; this is linear. The
methods are very similar, an important difference being the number
I did some reading and it sounds like md5 and sha1 should both be
deprecated in favor of sha256.
On Fri, Jun 7, 2013 at 10:57 AM, Dar Scott d...@swcp.com wrote:
Right. There is a little bit of overhead for padding for both md5 and
sha1 (they use the same padding method), as a string a
For we mere mortals, I suspect that the social and physical aspects of security
dominate and the infinitesimal increase in application speed from using the
faster functions might in some mysterious way do more for our security than a
better hash. But, also, being one of the mere mortals, I
What code were you using Alex? I thought the first step(s) of the MD5
process reduce (or grow) whatever input string is given to 128 bits, and
then everything from there operates on the 128 bit data. Likewise for SHA1,
in 160 bits.
In other words, the size of the individual strings should have a
Your code has a minor bug :-)
You get MD5Digest(S[1])
instead of using S[i]
Here's the code I used (now extended to check different lengths).
constant K=10-- the number of iterations
constant KLength=20 -- this * 36 -- the number of chars per line
on mouseup
put empty into msg
MD5 works on 512-bit blocks. The message is padded so that it is 64 bits short
of being a multiple of 512. It works on all of those blocks iteratively,
generating a 128-bit value each iteration and consuming one. The final 128-bit
value is the hash.
So, it does crank away on all of the
Here are some timings of random functions going in another direction.
Results for an old mac mini:
Works better on OS X.
Time for a 1000 X loop divided by 1000.
nothing134 ns
get empty 227 ns
get alphabet 288 ns
get random(999) 327 ns
get md5Digest(alphabet) 890 ns
get
At the risk of beating the decaying equus -- the previously suggested
random() solutions should be fine for all purposes --I found an alternative
that:
1. Is faster than sorting by random(9) random(9)
2. Is about as fast as sorting by random(9)
3. Is (I think) less likely
I tinkered with the same thing.
I also made a random generator using md5 with the long seconds as the seed. In
that, md5 is applied to previous result, not each, requiring a separate
function, but each can be mixed in.
I assume there is nothing weird in a text sort that will affect this. I
No comments on the collision-or-not-ness, but some concerns about
performance.
The performance of random() random() is conveniently
data-independent, but that for md5digest() is not. With nice short
lines, it is indeed faster than the randomrandom version, but as the
line size increases, so
Nice one, Alex. I spent an hour convincing myself that the sA array could
contain duplicate elements after the loop, until the penny dropped. Remind me
never to play cards if you're shuffling. :-)
Dave
On 24 May 2013, at 00:41, Alex Tweedly a...@tweedly.net wrote:
Yes, that's a good
Seems someone beat us to entering this feature request:
http://quality.runrev.com/show_bug.cgi?id=10919
On 24.05.2013, at 12:04, Dave Cragg wrote:
Nice one, Alex. I spent an hour convincing myself that the sA array could
contain duplicate elements after the loop, until the penny dropped.
Dar -- I hardly think you need my blessing, but I agree with your
definition of p(k). I ran some numbers through Wolfram Alpha, and it looks
like even for 100 item lists the probability of the first item being sorted
to the first spot is about 0.015, or 1.5 times what it should be if sorted
by
I made a typo:
delete line random_line_number of the_lines
should be
delete line random_line_number of some_lines
(see below)
Sorry,
Michael
On May 23, 2013, at 12:07 PM, Michael Mays michael_livec...@nayyan.com wrote:
As I understand the sort command the syntax is something
No it is 3 factorial. Jacques and Craig and I are right.
This is picking without replacement, not picking with replacement. The first
answer position has three choices. Once you pick it the second answer position
has 2 and the final position 1 option left. To get 27 options means you have
Shuffling is more complicated than commonly thought. A properly uniform
shuffle is given as follows:
function scramble x -- scramble lines or items in a row
put the number of lines of x into z
if z = 1 then put the number of items of x into n
else put the number of lines of x into n
Yes, sorting involves picking. But this is assigning a sorting value to each
item or line. Each item or line is assigned a value independently; the history
of assigning previous values does not matter.
Only then is the sorting performed (virtually).
It is possible for some lines to be
to tab
put * item 3 of sRecSet into tPossibleAnswers -- correct answer
put cr item 4 of sRecSet after tPossibleAnswers -- distractor 1
put cr item 5 of sRecSet after tPossibleAnswers -- distractor 2
sort lines of tPossibleAnswers by random(99) -- randomly re-order the
list
This app
There is, indeed much confusion here. I, of course, am correct ;-)
I simplified the problem to a list of two items:
1,2
That way the sort command has exactly two outcomes. It either reverses the
list, or it doesn't. The two outcomes should happen roughly 50% of the
time. This script
Björnke von Gierke wrote:
sort the lines of theList by random(the number of lines in theList)
This too works. there's no need to make an arbitrary large number
_BECAUSE IT MIGHT IN SOME CASES DECREASE RANDOMNESS_. Mostly when
your variable grows bigger then anticipated, so usually you're
I agree, Geoff! Your theory and measurements are consistent with mine for 3.
An important part of Geoff's test is this:
put originalList into newList
Dar
On May 23, 2013, at 1:30 PM, Geoff Canyon wrote:
There is, indeed much confusion here. I, of course, am correct ;-)
I
LOL…. I just spit my coffee all over my screen……
-- Tom McGrath III
http://lazyriver.on-rev.com
mcgra...@mac.com
On May 23, 2013, at 3:52 PM, Björnke von Gierke b...@mac.com wrote:
Fuck me that's correct. :(
___
use-livecode mailing list
(99) -- randomly re-order the
list
This app pulls words from a database and presents three possible answers
to choose from. The asterisk above is used to identify the correct answer
after the sort takes place. It's removed later on. The sort only works
randomly one time. After
item 5 of sRecSet after tPossibleAnswers -- distractor 2
sort lines of tPossibleAnswers by random(99) -- randomly re-order the
list
This app pulls words from a database and presents three possible answers
to choose from. The asterisk above is used to identify the correct answer
after
On May 23, 2013, at 1:52 PM, Björnke von Gierke wrote:
So we do need the sort to actually be for each, instead of random.
That will work if what we are looking at is random as far as we can tell. For
example, by md5Digest( each ) might scramble in a sense, but it would be the
same each
-- distractor 1
put cr item 5 of sRecSet after tPossibleAnswers -- distractor 2
sort lines of tPossibleAnswers by random(99) -- randomly re-order
the list
This app pulls words from a database and presents three possible answers
to choose from. The asterisk above is used to identify the correct
I hit send faster than I can think. This will put like lines next to each
other. Fail! But a LiveCode function that looks at sortIV and sets it with
the current hash should work. (I better hit send fast before I find something
wrong with that.)
On May 23, 2013, at 2:26 PM, Dar Scott wrote:
Indeed you are correct. The maths is simple (even if not very obvious or
intuitive).
Sorting N lines by random(K)
The likelihood of swapping any two lines *should* be 1/2, but (because
the sort is stable, and because they are random *integers*), there is a
1/K chance of the two random values
On 5/23/13 2:30 PM, Geoff Canyon wrote:
Here's one result I got:
Sorting by random(2) kept the same order 7514 out of 1 times.
Sorting by random(9) kept the same order 5014 out of 1 times.
If anyone disagrees, come at me, bro. ;-)
I never argue with a math guy. :)
--
On 5/23/13 3:31 PM, Dar Scott wrote:
(I better hit send fast before I find something wrong with that.)
LOL. I'm so glad you're back on the list, Dar.
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On 23 May 2013, at 21:11, Björnke von Gierke b...@mac.com wrote:
Yes, that is why I myself lean towards a feature request. For example the
following line could tell the engine to make a unique random number for each
of the supplied lines, to not have the problem with lines that come first
I did a math.
The probability of the first element not moving for a k item list named myList
that is sorted by
sort items of myList by random( the number of items of myList )
is p(k) where
p(k) = sum with i from 1 to k of 1/k * ( i/k ) ^ (k-1)
That power increasing with k tends to
I simplified the expression but didn't change the comment. It should include
...i/k is 1 for only i=k.
On May 23, 2013, at 4:31 PM, Dar Scott wrote:
I did a math.
The probability of the first element not moving for a k item list named
myList that is sorted by
sort items of
Yes, that's a good shuffle for small data, but a bit slow for larger
data sets. I dug out an old function I wrote a few years ago (and
converted it to LC); this would be faster for large data sets (time
taken grows linearly rather than by the square of the number of lines).
local sA, sIndex
I have a list of three words that I need to be randomly sorted. To start with,
the first word is the correct answer to a question. I want to re-order the list
so that the correct answer may be the second or third word, and not necessarily
the first. How can I do this successfully every time?
If you want random sorts, don't change the randomseed. It's set for you on
startup, and only should be set if you want non-random things to happen.
If you sort three lines randomly there's a pretty high chance that a given line
remains on the same line for two consecutive times. It's not
line in the list.
Craig Newman
-Original Message-
From: Chris Sheffield cmsheffi...@icloud.com
To: How to use LiveCode use-livecode@lists.runrev.com
Sent: Wed, May 22, 2013 2:01 pm
Subject: randomly order a list
I have a list of three words that I need to be randomly sorted. To start
Chris,
I think your problem is the use of the word lines…
These versions will show the difference:
on mouseUp
local myVar
put one,two,three into myVar
put myVar
wait 30
sort lines of myVar by random(1)
put myVar
end mouseUp
on mouseUp
local myVar
put one,two,three
Try replacing 'the number of lines of myVar' with some huge number you think is
allowed for random(), say 99.
With small numbers you are likely to get the same number for different lines
and perhaps sort does not change order in that case.
Dar
On May 22, 2013, at 11:59 AM, Chris
I think you are going to get the first line of the original list (correct
answer) about half the time. Does that seem right to you from what you have
seen? The correct answer will be in the first two about 80% of the time.
Using the larger argument for random should give you better
into tPossibleAnswers -- correct answer
put cr item 4 of sRecSet after tPossibleAnswers -- distractor 1
put cr item 5 of sRecSet after tPossibleAnswers -- distractor 2
sort lines of tPossibleAnswers by random(99) -- randomly re-order the list
This app pulls words from a database and presents three
tPossibleAnswers -- distractor 1
put cr item 5 of sRecSet after tPossibleAnswers -- distractor 2
sort lines of tPossibleAnswers by random(99) -- randomly re-order the list
This app pulls words from a database and presents three possible answers to
choose from. The asterisk above is used to identify
cr item 5 of sRecSet after tPossibleAnswers -- distractor 2
sort lines of tPossibleAnswers by random(99) -- randomly re-order the list
to keeping a randomly generated value on the line
set the itemDel to tab
put * item 3 of sRecSet TAB random() into tPossibleAnswers -- correct
-- correct answer
put cr item 4 of sRecSet after tPossibleAnswers -- distractor 1
put cr item 5 of sRecSet after tPossibleAnswers -- distractor 2
sort lines of tPossibleAnswers by random(99) -- randomly re-order the list
This app pulls words from a database and presents three possible
Sorry, I'm afraid I put a stupid error in my script:
the second possibility should be:
put into tLastOrder
put into tOrder -- they must of course be the same at the start
repeat until tOrder tLastOrder
put line(random(6)) of sOrderOfLines into tOrder
next repeat
put tOrder into
On May 22, 2013, at 4:35 PM, Jacques Hausser wrote:
I think that you cannot sort by random(99) because the argument of the
sort (the sortkey as it is called in the dictionary) must by something like
item 2 of each and not a number out from a random generator.
I'll have to run tests to
Here is (I think) the situation for random(3).
Lines will be (virtually) assigned numbers randomly; there are 27 possibilities.
There are 9 cases in which the first line is assigned a 1. It is first in the
sort.
There are 4 cases in which the first line is assigned a 2 and the other lines
get
On May 22, 2013, at 10:59 AM, Chris Sheffield cmsheffi...@icloud.com wrote:
sort lines of myVar by random(the number of lines of myVar)
Hi, Chris.
I suggest you try this:
sort lines of myVar by _random( the number of lines in myVar, each )
with this:
private function _random pUpperLimit --
On May 22, 2013, at 5:04 PM, Dick Kriesel dick.krie...@mail.com wrote:
combinations
oops... permutations
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
Dar,
I'm afraid you are wrong…
they would not be 27 possibilities (3^3) but only 6 (3! - factorial), because
each line (first, second and third) can only be present once.
And I tested random (3) and random () corrected to give a number between 1
and 3 with the following scripts:
on
of sRecSet into tPossibleAnswers -- correct answer
put cr item 4 of sRecSet after tPossibleAnswers -- distractor 1
put cr item 5 of sRecSet after tPossibleAnswers -- distractor 2
sort lines of tPossibleAnswers by random(99) -- randomly re-order the list
This app pulls words from a database
by random(99) -- randomly re-order the
list
This app pulls words from a database and presents three possible answers to
choose from. The asterisk above is used to identify the correct answer after
the sort takes place. It's removed later on. The sort only works randomly
one time. After
Easy mistake to make, Jacques, but it is not 3!.
Random() emulates independent random numbers. It cannot avoid numbers returned
before in the sort. Each line will get a randomly assigned number independent
of the other lines.
The number of ways 3 lines can be ordered does not apply.
Each
after tPossibleAnswers -- distractor 2
sort lines of tPossibleAnswers by random(99) -- randomly re-order the
list
This app pulls words from a database and presents three possible answers to
choose from. The asterisk above is used to identify the correct answer after
the sort takes
tPossibleAnswers -- distractor 1
put cr item 5 of sRecSet after tPossibleAnswers -- distractor 2
sort lines of tPossibleAnswers by random(99) -- randomly re-order the
list
This app pulls words from a database and presents three possible answers to
choose from. The asterisk above
As I understand the sort command the syntax is something like:
sort this_group _of_thing by the _text _values_in _this _other_thing
so what it seems like to me is that Randy is saying
sort the_lines_in_this_thing by either_1_or_2_or_3
In other words the lines are being sorted by a
57 matches
Mail list logo
