C programming

>>212509
#!/usr/bin/env python
import random
print sample("ABCDEF".split(''),4)

>>212509
In C, you need to write that yourself, which for a short string means picking a random number, and re-rolling it if it's on a list of numbers you've already picked.

>>212561
Sounds super inefficent, as the programm might get stuck on a number for long times.

Another way you can do it, would be to randomly pick a letter and then store the other 5 letters in a new array to work with, then just repeat this. Can't pick a letter 2 times if it's not for selection the second time.

>>212564
and how would i do this?

>>212564
>Sounds super inefficent, as the programm might get stuck on a number for long times.
Doesn't matter, because it's only four bytes. If it's a core loop you're executing billions of times, you'd be doing it in assembler with the vector hardware (or on a GPU in CUDA) and unpacking the entropy directly into the output strings.

As it's not, it makes no difference whatsoever whether it takes 0.00001 seconds or 0.00002 seconds.

Your "more efficient" solution does have a deterministic runtime, but that runtime guarantees 5+4+3+2 copies to avoid an second deviation of 1+1+3+5 random rolls.

Plus it's more complicated, so you're wasting a human's time to save a computer's.

File: 1477158275575.jpg (48KB, 600x500px)

48KB, 600x500px

As an alternative you could randomly swap 2 characters randomly a specific number of times (e.g. 200) and then picking the 4 first characters of the resulting string.
As for the random swap you can pick a first position randomly which will be the first character for the swap and then picking the other character with:
>second_character_index = (first_character_index + (random()%(array_length-1))+1) % array_length;
As an example, for length 6, if you get the first character in the position 1 (the second character), you would add up a random amount between 1 and 5 (by doing %(array_length-1) you get a value between 0 and 4, then you add 1). So all the possible results would be 2,3,4,5 and 0. So it's always a different number.
So basically:
>take your array
>use srand(unsigned int seed) to seed the random (as an example, you can use time() to get the seed)
>use rand() to get random values
>with rand()%array_length get the position of the first character (let's call it "first")
>with the instruction I wrote above pick the second character ("second")
>use a third character "aux"
>assign the content of "first" to "aux", then the content of "second" to "first" and finally the content of "aux" to "second" to make the swap
>repeat a fixed number of iterations (or a random number within some knwon interval)

PS: Don't forget to include the libraries for srand(), rand() and time() if you use it.

File: 1477158152898.jpg (20KB, 450x450px) Image search: [Google]

20KB, 450x450px

>>212609
Also, 2 additional notes:
When you declare a string literal ("ABCDEF"), the compiler automatically adds the character '\0' (string end) to the string, so your example string should be length 7.
As a consequence, have in count that the '\0' character will be a swappable character during the process. So be wary that if you do
>printf("%s\n", array);
with a '\0' as the second character, for example, the output will be only the first character. You have 2 options to deal with this:
>Don't pick the las character for the shuffle using length -1 as your length for the shuffling and add '\0' to the resulting string so it's 4 characters followed by '\0'
>Use the '\0' anyway and print the string character by character, preferrably in hexadecimal with printf("%x", array[index]) so you can see the valu 0 for the '\0'.

Here's some commented code printing in hex if you want to take a look:
http://pastebin.com/BPtUmRUn

>>212609
>>212614
Thanks a lot anon

>>212614
Why not just bubble-sort the zero to [5] then print the string as normal?

C gives no fucks about bounds in either direction.

>>212621
Just ignoring it (since it strats in the last position always) is simpler since it just requires to use a different value for length instead of implementing the sorting. Also, ignoring the last character has a complexity that doesn't scale with length while sorting does. Thus, a huge starting array would make the sorting option way slower thant ignoring the '\0'.

>>212628
>ignoring the last character has a complexity that doesn't scale with length while sorting does
Doesn't matter, because randomly swapping characters does scale with length, thus dominates.

>>212641
But you're talking about just sorting in order to move the zero, which would be an overhead on top of the swapping so even if the complexity for both parts were the same (probably On), using both would result in larger computation times with the difference between them scaling with On.

>>212645
O(n)+O(n) is O(n), anon.

>>212651
Yes, because the computation time would increment in the same way but the sorting approach would take always more time to compute in (almost) every scenario. 1000n and 2n both are O(n) but one gets better computation times than the other.

>>212656
If you're diddling with constants, I don't think you understand the point of big-O.

>>212663
Constants can be significant if the growth is the same or in cases where the values of n are within a known, finite interval. In the case stated before, both functions will grow the same since they are O(n) and as a direct consequence the latter will always, for any non-zero value of n, be faster than the former.
If the complexities were 1000n and 2(n^2), then the first function would be faster than the second with a n big enough so we would pick the first one knowing that in general it would perform better, but if we knew that n would take only values between 1 and 10, then we would know that a complexity 2(n^2) would never have a cost bigger than 1000n.

>>212671
If we knew that n would take only values between 1 and 10, we wouldn't bother calculating the asymptotic runtime in the first place.

>>212674
That was just an example interval. The point is that constants do matter in some scenarios and this is one of them.

>>212682
That wasn't "just an example": if n is bounded such that constants do matter, then big-O is by definition the wrong tool for the job.

>>212687
> then big-O is by definition the wrong tool for the job
But in this case, constants are significant because the big-O results obtained are the same. The fact that the constants aren't relevant for the asymptotic analysis doesn't mean that they aren't relevant for the analysis of the computational cost. Since both grow the same way one will always be more efficient than the other and that will depend on the constants.
In order to get to the conclusion that the growth is the same and that the constants matter you have to go through the asymptotic analysis.