161–169 of 169 posts
Earlier quoted context omitted.
The interesting nature of the problem is that you can't just 'eliminate swathes', your question must evenly divide the entire population.
I don't think that that's a requirement at all, unless you think that his second example question of a list of countries perfectly divides the population with not even a rounding error
Earlier quoted context omitted.
The interesting nature of the problem is that you can't just 'eliminate swathes', your question must evenly divide the entire population.
For the purposes of this problem (and most other purposes) if you have a question that divides answers in 47%:A 51%:B 2%:'stupid_question_doesn't_fit_me_I'll_answer_randomly', then it's still perfectly okay.
Very interesting thought experiment. A few random thoughts: Reminds me of Panoptic by the EFF: https://panopticlick.eff.org/ Everyone's ID would change as time passed (if they move, if they age, if they get a sex change, etc). The best questions for this are inherently "irrelevant", since "relevant" questions tend to be statistically linked. So, questions like "Was the second letter of your first girlfriend's middle…
26% of global people are pre-teens; and approx half of the remainder aren't dating women.
Not even going into the fact that the social concept of 'girlfriend' isn't universal, there are multimillion cultures where the relationship stages of going from strangers to family are split differently, and none of those stages can be equated with western 'boyfriend/girlfriend' relationship; e.g. you may like someone but not be dating (so no girlfriend) and then move directly to engagement or marriage; or many other possibilities.
Very interesting thought experiment. A few random thoughts: Reminds me of Panoptic by the EFF: https://panopticlick.eff.org/ Everyone's ID would change as time passed (if they move, if they age, if they get a sex change, etc). The best questions for this are inherently "irrelevant", since "relevant" questions tend to be statistically linked. So, questions like "Was the second letter of your first girlfriend's middle…
Earlier quoted context omitted.
but doesn't 1:1666 mean the success rate is more than 99%? Asking about the posession of an XX chromosome should separate the people almost 50:50, the rest is something else. On the other hand, maybe there are just <1% people who don't identify them self with being male or female, so the questions would make no difference...
| On the other hand, maybe there are just Huzzah for logic. But note that the question was, "Do you have 1 apple" and not, "Choose a statement: 'I have 1 apple', 'I have 2 apples'"
This project assumes we can know things that are not really knowable for everyone. It starts with gender and birthplace, both tricky questions in some situations. So maybe we get to assume we have some oracle that helps us simplify the hard questions. At that stage, it's easy. Begin with, "Assume we build a list of people sorted by time of birth (with some arbitrary tiebreakers, like proximity of birthplace to Barbad…
I had come up with something similar: Question 1: Are you north of an east-west line that perfectly divides the population in half? (proceed to continue to divide each section in half.) Of course, determining the position of those lines is damn near impossible. And as soon as someone hops on a plane, the whole thing comes crashing down.
I guess it gets tricky when people are born.
Wait a minute, just realized this whole question breaks down if we don't recycle numbers from the dead back to the newly born... and there's no guarantee that all of the dead will sufficiently resemble all of the newborns. I want my money back. :)
Earlier quoted context omitted.
I dislike some of the examples of the "falsehoods programmers believe about time" because they typically aren't falsehoods, and will always hold true within the constraints of your system. Yes, time is a fickle thing that is marred by history, but in building a system, I choose a representation for the data I am storing in it. If I choose to store dates using a Gregorian calendar (because I'm following ISO-8601), the…
If you store time in UTC, then you haven't solved all possible time storage problems - for example, you still need to take into account that some days have 25 hours; so any structures for exchange/storage of periodic data (hourly planning schedules; by-minute temperature readings) need to contain a variable number of data instead of fixed set of 24 hours. If your HR system is doing employee scheduling for 24/7 shifts…
I'm curious to know in what circumstance you think a UTC day has 25 hours.
> it has tricky consequences for UI layout and printing if those night hours matter.
This is very true. I don't believe Google Calendar (or any calendar app that I've seen, really) handles displaying DST weirdness well. It would be very tricky to render. I'd love to see something attempt to tackle this.
Earlier quoted context omitted.
I dislike some of the examples of the "falsehoods programmers believe about time" because they typically aren't falsehoods, and will always hold true within the constraints of your system. Yes, time is a fickle thing that is marred by history, but in building a system, I choose a representation for the data I am storing in it. If I choose to store dates using a Gregorian calendar (because I'm following ISO-8601), the…
2am doesn't even repeat in the local timezone, it's just that the timezone changes. So here for example, 1:59:59 am CDT increments to 1:00:00 CST, which does not conflict with the earlier 1:00:00 CDT. I think it would be better not to go through all this hassle though, myself.
Earlier quoted context omitted.
If you store time in UTC, then you haven't solved all possible time storage problems - for example, you still need to take into account that some days have 25 hours; so any structures for exchange/storage of periodic data (hourly planning schedules; by-minute temperature readings) need to contain a variable number of data instead of fixed set of 24 hours. If your HR system is doing employee scheduling for 24/7 shifts…
> some days have 25 hours I'm curious to know in what circumstance you think a UTC day has 25 hours. > it has tricky consequences for UI layout and printing if those night hours matter. This is very true. I don't believe Google Calendar (or any calendar app that I've seen, really) handles displaying DST weirdness well. It would be very tricky to render. I'd love to see something attempt to tackle this.
If your days are meaningful for your app in any way, then you have to have clear boundaries between days/weeks/months - if your website has a report 'downloads per day', then it doesn't mean UTC days (which for many locations would mean splitting in the middle of business hours. And it has days where the difference between 'start-of-day' and 'end-of-day' is not 24 hours, but 25 hours.
Also, no matter how you handle time storage, if you're doing any analytics, and your process is minute-dependent instead of day-dependent (say, power consumption, not purchases), then your daily totals will have ~5% jumps twice a year that you might need to adjust.