3 ms·

The problem is not that I don't know the algorithm... the problem is that to implement the algorithm you need to remember what method from what class does the t

The problem is not that I don't know the algorithm... the problem is that to implement the algorithm you need to remember what method from what class does the thing you want to do. And knowing that is very difficult, even for seemingly simple problems. That's why Google is the way to program modern programming languages. (Of course I could do the same task without any libraries, but in that case it would be considered bad by most modern programmers, because it would be a sign that I "don't know how to use the language properly"...)

Longlius 3y ago
This isn't a complex problem - this is something you do with built-in standard libraries in pretty much any programming language. Like I would expect anyone who claims to know even basic file I/O in their given language to be able to produce a mostly working version of this in less than 30 minutes.
- kragen 3y ago
  80% of the time they'll produce a subtly biased shuffle, most people don't intuitively know the fisher-yates method unless they've been taught it like, try this import collections, random def shuffle(xs): # naive intuitive shuffle for i in range(len(xs)): j = random.randrange(len(xs)) xs[i], xs[j] = xs[j], xs[i] def first_of(n): xs = list(range(n)) shuffle(xs) return xs[0] print(collections.Counter([first_of(3) for i in range(100_000)])) note that 1 comes out first 25% more often than 2, but with a fair shuffle all three should have an equal chance of being first even without running it you can figure out logically that it must be biased in some way because there are 3! = 6 possible permutations and 3³ = 9 equally likely sequences of choices for j (each producing one of those permutations), and 9 is not divisible by 6, so some of those permutations have to be more likely than others so i think this algorithm is a good one to get from a library if its randomness is important to you not from chatgpt, which commonly does give you subtly buggy code
  - kragen 3y ago
    i'm an idiot, 3³ = 27. but that's still not divisible by 6. that explains how it's possible to be only 25% more likely
kragen 3y ago
if you don't know the algorithm you could easily get it subtly wrong but the only method involved here is string.strip(), so i don't think this is an example of the problem you describe import random n = 100 ws = [line.strip() for line in open('/usr/share/dict/words')] for i in range(n): j = random.randrange(i, len(ws)) ws[i], ws[j] = ws[j], ws[i] print(ws[i]) (did i fuck that up) and yeah probably calling random.sample would be better. and usually import random is better than writing your own rng. but not always

Longlius 3y ago

This isn't a complex problem - this is something you do with built-in standard libraries in pretty much any programming language. Like I would expect anyone who claims to know even basic file I/O in their given language to be able to produce a mostly working version of this in less than 30 minutes.

kragen 3y ago
80% of the time they'll produce a subtly biased shuffle, most people don't intuitively know the fisher-yates method unless they've been taught it like, try this import collections, random def shuffle(xs): # naive intuitive shuffle for i in range(len(xs)): j = random.randrange(len(xs)) xs[i], xs[j] = xs[j], xs[i] def first_of(n): xs = list(range(n)) shuffle(xs) return xs[0] print(collections.Counter([first_of(3) for i in range(100_000)])) note that 1 comes out first 25% more often than 2, but with a fair shuffle all three should have an equal chance of being first even without running it you can figure out logically that it must be biased in some way because there are 3! = 6 possible permutations and 3³ = 9 equally likely sequences of choices for j (each producing one of those permutations), and 9 is not divisible by 6, so some of those permutations have to be more likely than others so i think this algorithm is a good one to get from a library if its randomness is important to you not from chatgpt, which commonly does give you subtly buggy code
- kragen 3y ago
  i'm an idiot, 3³ = 27. but that's still not divisible by 6. that explains how it's possible to be only 25% more likely

kragen 3y ago

if you don't know the algorithm you could easily get it subtly wrong but the only method involved here is string.strip(), so i don't think this is an example of the problem you describe import random n = 100 ws = [line.strip() for line in open('/usr/share/dict/words')] for i in range(n): j = random.randrange(i, len(ws)) ws[i], ws[j] = ws[j], ws[i] print(ws[i]) (did i fuck that up) and yeah probably calling random.sample would be better. and usually import random is better than writing your own rng. but not always