Apparently my answer doesn't work ;_;

probability is weird

i know you figured out it's wrong already, but just intuitively there's nothing that strange about it. 5, eg, can only be acheived one way, with probability (1/7)^5. 6 is slightly more likely but still rare, and so on. so you know right off it's not uniform from 5-35.

yea it seems obvious in retrospect.

I thought 2 was just running good xD

It's irrelavant but at the same time a degree means a little something. Since its unrelated I would move education down near the bottom. If you are still worried about the degree I would just put the graduation date and school name. Don't mention the major. So for example:
University of Devry 2008

Hey guys, I'd appreciate it if you could take a look at my new thread in the Game Theory section, it's on developing an algorithm for a Yahtzee game in which the user could play against the computer. Specifically on developing an algorithm that allows the computer to play (close to) perfect

http://forumserver.twoplustwo.com/25...heory-1518980/

Also feel free to reply to this thread instead of the one I created, if preferred

I feel like you guys are overthinking the rand5() problem a little bit...

work flow question:

in small teams, <10 people, should everyone know the entire codebase?

more specifically, if person A built "search" and person B built "projects". future tickets on "search" (bugs/new features) should be taken by whom? assuming both devs are available.

from my limited exp, it seems that when B starts messing around in "search", code quality tends to go down, and vice versa is true. maybe that's another problem?

i suppose my opinion is that everyone should focus on their domain within the app, is this bad?

That's sort of a philosophical question. Where I am, with five devs plus a manager, we try and share the knowledge as much as possible and have people contribute all over.

That said pressing issues like p0 bugs or critical, time sensitive features often get placed with the person who most recently worked in that section.

It always comes down to deliverables. Assuming you're just like any other shop that pushes code you'll have a hard convincing anyone in managment of "hey we need to start shipping our deliverables at .8x speed in order to have better coverage".

If rand7 is the bottleneck, you can generate in batches to improve the performance.

Your method requires 7/5=1.4 rand7 calls on average. For instance, calculating in batches of 6 would reduce that to an average of 0.89 rand7 calls per generated rand5.

okay this makes sense, in terms of skill level, are the 5 of you about the same? would you feel differently if there's a junior dev w/ 1 yr exp and senior dev with 10 yr exp? how about if it's hard to communicate in real time between the dev because of timezone/language issues? maybe i'm just making excuses...

i'm not sure if this is directed to me, but i think i want to have "worse" coverage? that is, i would like each dev to know his/her own stuff, but would have to sit down for a long while to get their bearings on someone else's work.

I get the philosophy behind lots of modular libraries but this just seems silly. This is just for the tests and build, no application specific packages.

Its horrible. You end up with bad problems when people go on vacation or leave the company. You also end up re-inventing the wheel in multiple places.

Can you elaborate on this? I'm not sure what you mean.

You're hired

I can't speak to karma but this is just the way gulp is - its a plugin based build system that you pick and choose what you need it to do. Also people in general tend to do a terrible job of pruning their package.json when they decide to stop using something which means a million things get downloaded and never required.

[tongue in cheek]writing highly readable, maintainable code along with excellent documentation facilitates devs coming up to speed in short order on portions of the code that they have little to no exposure with.[/tongue in cheek]

I thought the same thing too at first, though you do have to agree this is inefficient.

Inefficient compared to what? I don't think there is a correct solution that doesn't use this approach.

Another two full days spent trying to figure out why our karma unit tests are failing in our rackspace environment but passing on our local. Sometimes they loop, sometimes they give indecipherable errors. Sometimes the order of the tests matters (so we've got some kind of weird side effects going on apparently). One time I was even able to get a group of 4 tests to fail by removing one of the tests.

Meanwhile other lead devs are starting to just comment out the unit test part of our build flow. And I'm completely swamped with actual development work. We have something like a dozen dev teams with maybe 70 devs and I'm the testing department. In my spare time

The funny thing is no one ever even officially assigned me to have anything to do with testing. I just did it because I wanted to learn and I was going to start looking for another job if I didn't get my promotion.

Well we do have 4 offshore dev testers who know how to write selenium tests but have no idea what they should be doing for our new stack. I'm also the branch manager/build engineer, along with two other guys - since our dev ops team is still just learning git/Jenkins/rackspace.

We've mostly given up on protractor end to end tests as they're impossibly unstable, as are our test users and test data.

Our CI/CD effort is an anatomy of a company talking about something but not really prepared to put any time, money or effort behind it. Bound to fail.

There has to be a huge market for a company which can come in as a consultant with a stable suite of unit and end to end testing tools. This stuff is the wild west for a monster site like ours. I feel like we encounter some new weird edge case every day. And the solution is usually just - let's try 100 things until something works - even though we have no idea why.

One of us is much more senior, he also has probably the least understanding of the codebase. But that's partly because he doesn't want to do mobile work and he does almost everything infrastructure related. Then there are 3 of us that are around the same level but with differing strengths technically (one of us is stronger on Rails, one on iOS, and one on Android). And then our newest person it's too early to really judge, but we start out by giving him smallish tasks in different sections of the code base so he gets a broad exposure to start.

The communication piece is important I think. Aside from the senior guy we all work pretty similar hours and from the office and we're good about having quick discussions about how to structure things before getting started and whenever we run into problems or there isn't one clear approach.

We recognize that this approach of spreading everyone around is generally slower and can lead to code quality issues. We haven't really seen any code quality issues with the current group, but two engineers that were here before my time left a lot of crappy legacy code that hasn't been refactored yet.

It's a tradeoff. What we lose in efficiency we think we make up in developer happiness and team resiliency. If we lose 1 or 2 engineers to go found their own startup or whatever, there isn't a gaping black hole of knowledge. By letting us all work everywhere across the entire stack it helps keep anyone from getting too bored in their silo and provides opportunity for personal growth.

That's pretty interesting and a cool feature (imo). Didn't know this/rarely use floats.

Well, randomly choosing a number 1...5 requires log2(5)=2.3 bits of entropy. Your method uses an average of log2(7)*1.4=3.92 bits, which means it wastes about 41%.

To improve this, you can generate in batches of 6 rand5s, which would waste only around 8%.

Basically:
*) Use 5 rand7 calls to get a random number from 0...7^5-1
*) If the number is bigger 5^6-1, discard and repeat (only ~7% of the time)
*) Now you have a random number 0...5^6-1 that you can convert to 6 random base 5 digits

So to make this efficient, you want to find n,m such that 5^n < 7^m but not by much. Or more to the point you want 7^m / 5^n as close as possible to 1 (its the ratio not the difference that matters).
5^6 = 15625
7^5 = 16807

You generate 5 values from 1 to 7 which gives 16807 possible sequences. 15625 of those sequences can be mapped to a usable result and you've generated a 6 element sequence of 1..5, where each sequence is equally probable. The other 1182 map to "try again". 1182/16807 ~= 7.03% chance of that happening.

So that's more efficient than generating the 1..5's one at a time, but there's still no way to guarantee termination. And there's absolutely no procedure (of using 1..7 to generate 1..5) that guarantees termination, correct?

nice.

and yeah, the problem mentions a number theory result saying you can't guarantee termination. i'd imagine it's simply a result of 5 and 7 both being prime, perhaps even being co-prime is enough to prevent a guaranteed terminating algorithm from existing.