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 can'
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 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 multiple of 64-byt
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
On Wed, Jun 5, 2013 at 5:14 PM, Alex Tweedly 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 long to md
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.
134 ns
get empty 227 ns
get alphabet 288 ns
get random(999) 327 ns
get md5Digest(alphabet) 890 ns
get md5Digest(startLongSeconds & al
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 bit
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 ms
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 l
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 random&random version, but as the
line size increase
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
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
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 rand
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. Re
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 wrote:
>
> Yes, that's a good shuffle for small dat
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 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
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 make
On 23 May 2013, at 21:11, Björnke von Gierke 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
> getting
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 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. :)
--
Jacqueli
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
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:
Hmmm.
put randomBytes(8) into sortIV
sort lines of myVar by sha1Digest( each & sortIV )
or
resetUniqueRandom
sort lines of myVar by uniqueRandom( the number of lines of myVar )
-- where resetUniqueRandom and uniqueRandom are custom handlers
Dar
On May 23, 2013, at 2:11 PM, Björnke von Gierk
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 ti
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 getting
a higher probability:
sort theData by random(the number of lin
I don't think anybody is claiming that random() does not work. (Some random
number generators will break with a bad seed, but that is outside the scope of
discussion.) When Chris thought random() was broken, most people suggested he
look at his code around the sort.
The problem is that rand
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 wrote:
> Fuck me that's correct. :(
___
use-livecode mailing list
use-livecode@lists.run
Fuck me that's correct. :(
So we do need the sort to actually be "for each", instead of random. Would you
guys say this is a bug, or that a feature request for making sort use a unique
random value instead of an arbitrary one?
On 23.05.2013, at 06:20, Dar Scott wrote:
> Easy mistake to make,
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 simpl
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'r
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 demonstrates
So much misinformation in this thread :(
The random function works! it uses the same code as many other programs to do
random stuff. Of course it's using a semi random list, but the technicalities
about when random is not random enough does not come into place for sorting
lines.
sort the lines
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 ass
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
repe
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
answ
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 wrote:
> As I understand the sort command the syntax is something like:
> sort this_group _
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
The sort value of each line does not depend on 'each' in this case.
On May 22, 2013, at 7:16 PM, Jacques Hausser wrote:
> Chris, I think Randy has put his finger on something: the * is before any
> number or letter in the ASCII numeration. I do not know what the random
> function uses when ra
I think this is likely, too. Well, now that you got rid of the small argument
to random.
On May 22, 2013, at 6:36 PM, Randy Hengst wrote:
> Well Chris, I'm sure you've already tried this, but when this kind of thing
> happens to me… in other words, when a script is correct, but the results ar
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 l
Chris, I think Randy has put his finger on something: the * is before any
number or letter in the ASCII numeration. I do not know what the random
function uses when randomizing a "set" (I was not even aware of this
possibility) but that could well be the ASCII value(s) of the first char(s).
Ja
Well Chris, I'm sure you've already tried this, but when this kind of thing
happens to me… in other words, when a script is correct, but the results are
wrong… I've messed something up later in the script with another put statement
that overrides it. Maybe the place in the script where you've re
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 mouseUp
On May 22, 2013, at 5:04 PM, Dick Kriesel wrote:
> combinations
oops... permutations
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.r
On May 22, 2013, at 10:59 AM, Chris Sheffield 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 -- note: ignore other p
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 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 test
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 tO
Chris,
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.
If you want a random order of the three lines of possible answers, you co
I have no idea hat your problem might be but here's what I'd try
next to see if I could figure out what's happening :-)
Change from
set the itemDel to tab
put "*" & item 3 of sRecSet into tPossibleAnswers -- correct answer
put cr & item 4 of sRecSet after tPossibleAnswers -- distractor 1
p
The testing is on the desktop, though? It might well be possible to "break"
random with a bad random seed depending on the method, so it might be broken
from earlier experiments. Restarting LiveCode should fix that. I don't think
that is your situation, but it is easy to do.
This is a puzzle
Thanks for the suggestions everyone, but I'm still getting strange results, and
I'm beginning to think there's something I'm doing that's affecting use of the
random() function. Not really sure what it would be though. Here's my code:
set the itemDel to tab
put "*" & item 3 of sRecSet into tPoss
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 proportio
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 Sheffiel
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
f the next line in the list.
Craig Newman
-Original Message-
From: Chris Sheffield
To: How to use LiveCode
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 with,
the first word is the correct a
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 'always
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? The
58 matches
Mail list logo
