For the best experience on desktop, install the Chrome extension to track your reading on news.ycombinator.com
Hacker Newsnew | past | comments | ask | show | jobs | submit | history | more ihaveqvestion's commentsregister

Can someone explain why the outcomes differ when the roommates are in a different order? Imagine an apartment with one nice room and one terrible room, total rent $1000, and two roommates, one rich, one poor. The poor roommate will always chose the less expensive room, the rich roommate will always chose the nice room unless the price difference is greater than $500.

If the rich roommate is Roommate A, then it converges to a 50/50 split, each paying $500. If the rich roommate is Roommate B, it converges to a 75/25 split, with the rich roommate paying $750. What's going on there?

[EDIT: Also, I've just discovered with three roommates that the results may be displayed without the first roommate ever choosing at all. ???]


I think the key may be that the rich roommate actually prefers a room, while the poor roommate does not (according to their assigned valuations) have any room preference at all. So if the poor roommate is second, they make the most choices in this calculator and their lack of preference makes the split even, whereas if the rich roommate is second, they make the most choices and their stronger preference causes them to pay more.

Even so, the order still seems to matter somewhat, and I would have expected it not to matter at all.


It doesn't guarantee a perfect allocation, but one that is compatible with everyone's preferences. A is willing to pay up to $750 for the nice room and up to $250 for the bad room. B is willing to pay up to $500 for either room. Any solution where A takes the expensive room for $500-$750 and B takes the cheap room for $250-$500 will leave both content with their choice. B could do better by being strategic and switching his preference to only taking the cheap room for no more than $300, however.


Thanks, I think that's what I was misunderstanding.


I agree. I actually began using Firefox again because I heard this UI change was landing in Nightly, and I've been using Nightly since then. I get Chrome's UI minimalism and Firefox's customizability/flexibility - it's the best of both worlds.


Thanks, that's slightly reassuring. It's still odd for a business to go generally incommunicado, though. I think I'll probably wait to buy a license until Kari's words are substantiated.


One argument I've heard is that it keeps you aware of how much tax you're paying.


Just the opposite is probably more important. Since sales taxes can vary locally (city, county, state) hiding the real price prevents people from noticing they can get cheaper goods by driving across an imaginary line.

Example: There is a walmart in both Cityville and its suburb Township. Cityville has a 9% sales tax but Township has a 7% tax rate. Both stores can advertise that they're selling a tv for $500, even though it costs $545 in Cityville but $535 in Township.

This helps prevent people from driving to the Township store to save money, because the advertised price is the same and most people won't think about the tax rate difference.


I did a similar thing for level 6: http://pastebin.com/aScFtgK8


I installed the latest version of this, and of Node, on my Windows computer, and I had to change "~/node_modules" to "./node_modules" in the final line of Makefile (in the "runlocal" target) - the http-server module was installed in the current directory. Otherwise it's working great; thanks!


Good catch -- I fixed the Makefile to actually go along with how http-server is installed in the README.


Confirmed the same issue on Linux


On a preview page, where is the Buy button?


Good idea. We should add that. :-)


In the submitted article, two callback methods are usually provided (one for success and another for failure). Is that possible when using generators? If so, what does that look like?


In generator code you'd use try/catch to handle failure instead.

    try {
      var user = yield Users.get(1234);
      return user.name;
    } catch(ex) {
      // do whatever
    }
rather than..

    return Users.get(1234).then(
      function (u) { return u.name; },
      function (ex) { /* do whatever */ }
    );


Those are not entirely equivalent. For example, if you make a typo when writing "user" or "u", the first one will catch that typo (cannot get property name of undefined) while the second one will not.

  Users.get(1234)
    .then(u => u.name)
    .catch(ex => 1/* do whatever */);


Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search:

HN For You