It seems this Show HN proves you rather wrong. I understand the point, you use a different format for your dates than the US. But the point of this Show HN is that all number sequences can be found within the digits of pi quite easily.
Yeah, this isn't known to be true. pi has not been proven to be a disjunctive number (a real number whose expansion contains all possible finite strings), let alone a normal number (where all finite strings occur with the probability you'd expect if the digits were random). Both of these, however, are generally conjectured to be true, but it's just a conjecture.
>> all number sequences can be found within the digits of pi quite easily
> I dispute that, although I guess the general brute-force solution is 'easy' given infinite time.
Look at it this way -- if it were not true, then the digits of Pi would not be normally distributed (see https://en.wikipedia.org/wiki/Normal_number), and that would be a rather extraordinary mathematical finding.
If Pi's digits are normally distributed, then one can reliably predict the time required for finding any particular digit sequence using probability theory. And given the presumption of normalcy, that probability is the same for any digit sequence of a given length.
The probability for finding a given test digit sequence in the first 100 million digits of Pi is given here:
You're both giving me too much credit. I was merely making the less sophisticated point that it's not 'easy' to find an arbitrary-length sequence in pi because that might take longer than the lifespan of the universe when the needle gets long enough. Your response was much more interesting, though, thanks :)
It's always fashionable to make fun of the US doing things its own way, when that's just seldom true.
You're mostly right that nobody else uses MMDDYYYY (although many countries use it as a secondary format). But it's not like there's a consistent format that _everyone else_ uses.
There are 2-3 different formats spread around the world, with no real consistency in why some pick a particular format.
Maybe that day can be written 2017-π to preserve both the pun and (if not the letter) the spirit of ISO notation. In that sense, it's Pi day for a given year.
I've always been surprised that Pi Day is primarily evangelized by so many math / science / CS folks, when I would think it would be precisely these folks who hate the MM/DD/YYYY format. ISO format soothes my soul like a warm slice of apple pie with ice cream.
Pi Day is the same in Drunk Endian (US) and Big Endian (ISO Standard) formats (March 14th). It's different in Little Endian (Traditional European) format.
I have been dating all official documents in ISO-8601 format and never had an issue with that in over 15 years. This includes bank forms, checks, contracts, and many other informal docs. Same for when my birthdate is requested of me. Even if the form has specific spaces for MM/DD/YYYY, I just write over it with the pen.
I assume you have the luxury of an unambiguous birthday (eg. 01-13). I imagine if I wrote 11-12 on a form without regard to what the specific spaces say, it would be regularly misinterpreted in the US.
I had the same question and I was perplexed why project maintainers thought it was a good idea to put a 1px blur effect on text. At first, I though they were showing badly compressed .jpg for text, which would be even more peculiar.
From what I remember, that is actually supposed to "smooth" text in some browsers. Text used to look too sharp in Chrome (haven't had this problem in a while) sometimes. I believe that was one of the "fixes!"
Until about 2014, Chrome didn't support ClearType on Windows, which is why text looked so awful compared to other browsers.
Mac's renderer happens to err on the side of drawing more pixels in case of ambiguity (e.g. calculation yields fractions of a pixel); this is why everything on a mac looks like its in bold with the default settings. Windows tends to err on the side of not rendering those pixels but this is configurable with ClearType.
If you choose non-ClearType (what Google did in the early days), you have chosen to have ugly text that will not look good on anything other than a CRT in the 90s.
Now, somewhat ironically, Google's text actually looks somewhat better than Edge's; Microsoft stopped using subpixel rendering (i.e. the best part of ClearType) in Metro/Windows Store Style/Modern/UWP apps years ago, while Chrome is still taking advantage of the feature.
As for why Chrome didn't implement it early on, they likely just hadn't bothered to use the newer APIs/use the APIs properly.
The reason why subpixel rendering is disabled in modern/WinRT/UWP apps, as I understand it, is likely to do with rotation. Modern apps are designed for tablet use, where the display may be oriented in any particular direction. Subpixel rendering depends on knowing the layout of the pixel elements themselves (the position of the R, G, & B elements relative to the greater pixel). When rotated, the layout changes and subpixel rendering makes things look worse.
In an ideal world, subpixel rendering would be turned off only in situations where the display is rotated. It appears that at least the rendering surface for Edge does use subpixel rendering, just not UI elements, which is an improvement over no use at all.
I think that family of ClearType bugs persisted for like 5 years on Chrome for Windows (I only noticed it fixed last fall?) so I'm not surprised people were attempting extreme fixes. The text looked really bad.
EDIT: Sibling post suggests it was fixed in 2014. I wonder what was wrong with my home laptop then, haha...
Fortunately, you can override it by adding, for example, `text-shadow: 0 0 0;` to <body>. I was unable to read the page before fixing this, I would strain my eyes trying to focus. (Perhaps this problem is exacerbated by "retina" screens?)
I wrote a quick script to test it. It does not take leap seconds into consideration and assumes all months to have 31 days (would be easy to modify, but it is sufficient for the task).
> A quick script from me determined you need 10,524,628 decimals of pi for this to work for all dates and times ... (emphasis added)
For a finite, normally distributed digit sequence (as Pi is thought to be), the probability is always less than 1.0 for finding a particular sequence within it. But if you mean a specially engineered sequence designed to include all possible 6-digit sequences, then we've left the question of whether a given finite Pi sequence includes it.
What are the odds that this worked? Or, how many digits should we expect to need? Naively, you'd need at least 1 million to get all 6 digit numbers in it. If Pi happened to be a De Bruijn sequence [1], then that would suffice. However, there are only (10!)^(10^5)/10^6 ~ 2e655970 such sequences, compared to 10^(10^6) total random sequences. I.e. the probability of getting a De Bruijn at random with a million characters is about 2e-344030. I'll round that up to "ain't gunna happen". So we probably need a lot more than the naive lower estimate... but where does it start getting likely?
Edit:
Here's another estimate: with 6 million digits, we can get all 6 digit possibilities by just concatenating them all together. There's then (10^6)! ways to arrange the 6 digit strings before concatenating them. So if we picked a random 6 million digit sequence, there's (10^6)!/10^(6e6) ~ 10^(-10^5.6) chance of getting one of those. So the chance that a random 6 million digit string contains all subsequences is at least that high. But that's not saying very much!
This is related to the question: how many balls do I need to thrown randomly into N buckets so that the each bucket gets at least one ball (with high probability)? I was amused to learn recently that the answer must be more than linear in N. You might think that throwing a billion times N balls would suffice, but for very large N it won't. Even though you're throwing a billion times more balls than there are buckets! The probabalists I was talking to about this didn't know off-hand what the exact asymptotic of "enough balls" to throw was. That answer appears to depend upon the asymptotics of the second Stirling number based off this stack exchange [2]. But to complicate matters, the approximation given by the Wikipedia page [3] is precisely insufficient to answer the question! We'd need to know how it approaches that asymptotic.
> Naively, you'd need at least 1 million [digits] to get all 6 digit numbers in it.
How naive do you do it? :)
When I just concatenate all possible 6-digit numbers (of which there are 1e6 = 1 million), I get 6 million digits total. You could of course overlap them partially to save space, but that does not count as "naive" anymore.
Your 6 million digits isn't a lower bound though: it's just demonstrating that 6 million digits can suffice, but there could be shorter ways to do it. In particular, none of your million 6 digit strings are overlapping. My estimate was the following. If you take a million digit string, then there are 1 million six digit substrings (actually you need 1 million and 5 digits * ). I.e. a 6 digit substring is specified by choosing where it starts, and there are 1 million places to do that. So if each of these were distinct, you'd get it. But any shorter string just doesn't have enough substrings in it to possibly get them all!
But it's not clear that it's possible to overlap all possible substrings in the right way: that's what De Bruijn sequences do but I don't consider them to be naively obvious at all.
* This is where I overlooked in my last post that De Bruijn sequences (which achieve this lower estimate) are actually for cyclic strings, allowing the subtrings to go past the end and back to the start of million digits. That allows 1 million digits to suffice. We'd actually need that 1000005 digits.
> I wonder if the 6 million digits cover all possible 6 digit year and time combinations
Only an infinite sequence of normal digits can be assured (probability: 1.0) of matching a test digit sequence within it, even a trivial one. For all other normal digit sequences, there's a probability less than 1.0 for finding an example sequence within it.
> '133343' doesn't seem to be part of the digits, which would represent 13:33:43. Unless I'm misunderstanding.
Good example. One would think that a relatively short test sequence would be a shoo-in for being located somewhere within 100 million normal digits, but that's by no means assured.
Edit: the sequence '133343' appears 80 times in the first 100 million digits of Pi.
pi to the 10 millionth digit was not enough. I had to use the billionth (didn't try anything between those two). Mind you, the 10 millionth only had 3 times that didn't match.
I've uploaded[1] the reverse system, which is quite a bit more efficient. It's a 600KB JSON array with every second in a day and its corresponding offset in Pi.
That's easy to check even with just ctrl+f: the last six digits are 422990 which occur 8 times throughout that string. Hence, we could remove at least the last digit without losing anything.
It also includes sequences that can never match such as "999". I wonder if overwriting those with a non-digit would allow indexOf to be infinitesimally faster?
Wow, not even an efficient data structure, just an almighty string! On one hand, that's pretty disgusting. On another, it's an impressive demonstration of just how fast everything is nowadays; I wonder if the javascript interpreter in my browser does any kind of optimisation on that string in order to perform such gargantuan indexOfs.
I just performed an experiment with this 100 * 10^6 sequence of Pi and found out that a reasonable approximation of pi (31415926) is located at an arbitrary location within the sequence (apart from the obvious location):
Test sequence found at location 0.
Test sequence found at location 50366472.
2 instances of "31415926" within the first 100 million digits of pi.
I [think I] understand the annoyance with indicating Pi Day based on the US order for month/day (though, I normally use ISO 8601 as my first choice, also), but I think some people may be missing the point. In the United States, with poor STEM performance, anything that increases awareness of math in the United States is beneficial, even if it is in an extremely arbitrary way.
http://imgur.com/1r5QpQu