Show HN: Every Day Is Pi Day(euler.party)
euler.party
Show HN: Every Day Is Pi Day
http://euler.party/
89 comments
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.
Very neat demonstration!
Very neat demonstration!
> 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.
I dispute that, although I guess the general brute-force solution is 'easy' given infinite time.
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.
https://oeis.org/wiki/Disjunctive_numbers#Is_pi_a_disjunctiv...
https://en.wikipedia.org/wiki/Normal_number
https://oeis.org/wiki/Disjunctive_numbers#Is_pi_a_disjunctiv...
https://en.wikipedia.org/wiki/Normal_number
Seen this already? https://github.com/philipl/pifs
>> 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:
https://www.angio.net/pi/whynotpi.html
But it has to be emphasized that, given a finite test sequence and an infinite sequence of Pi's digits as a search space, the probability is 1.0.
> 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:
https://www.angio.net/pi/whynotpi.html
But it has to be emphasized that, given a finite test sequence and an infinite sequence of Pi's digits as a search space, the probability is 1.0.
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 :)
Jaruzel(4)
Actually ISO 8601 states that the datecode format that should be used is
YYYY-MM-DDTHH:MM:SS+<OFFSET>
in this format, Pi day is:
2017-03-14 (The rest of the complete format omitted since it is not strictly relevant)
YYYY-MM-DDTHH:MM:SS+<OFFSET>
in this format, Pi day is:
2017-03-14 (The rest of the complete format omitted since it is not strictly relevant)
Except that's not what people mean when the say 'Pi Day' - they mean the US date format of 3-14.
Also works with YYYY-MM-DD...
Although admittedly I too find the US date system's wrong-endianness pretty annoying.
Although admittedly I too find the US date system's wrong-endianness pretty annoying.
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.
Yeah this thought mainly occurred to me when a big hubbub was made about 3.1415 day (3/14/15, or MM/DD/YYYY).
And, in the ISO format, when omitting the year, it's still 3-14.
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 once found myself confused as to how to date a US patent application, I was happy though to find that it was August 8th at the time.
As one of the comments says:
> jyssys3: The rest of the world celebrates it at 22/7.
I'd expect it's really 22.7., but this is more fun.
> jyssys3: The rest of the world celebrates it at 22/7.
I'd expect it's really 22.7., but this is more fun.
22/7 = 3.14285714285714285714 ;)
The text is very blurry on my browser, I'm not sure if it's intended but it makes it hard to focus on what's written.
That is the "text-shadow: 0px 0px 1px;", indeed it has a blurring effect rather than an fancy shadow effect in this case, I agree.
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.
I thought the same thing, that there was some sort of image being displayed. Whcih had me really interested for a moment.
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.
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.
What's the reason for this? Why wouldn't you just use ClearType all the time?
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.
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...
EDIT: Sibling post suggests it was fixed in 2014. I wonder what was wrong with my home laptop then, haha...
In Firefox it shows it as an invalid rule, but you're not able to switch it off.
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?)
`text-shadow: 0 0 1px #bbb` looks slightly better, but nothing will look as good as letting the browser do its thing.
Hey seszett good point, I removed the blur. For context, I wrote this project a while ago and never got around to cleaning it up.
I wonder if the intended effect was to create an artificial "bolding" of the text?
For the curious, the source code takes a somewhat obvious approach:
http://euler.party/pi.js
Yep, I think that is literally pi to 6 million decimal places then doing an indexof of the 6 digit year and 6 digit time of day.
http://euler.party/pi.js
Yep, I think that is literally pi to 6 million decimal places then doing an indexof of the 6 digit year and 6 digit time of day.
I wonder if the 6 million digits cover all possible 6 digit year and time combinations, I guess it wouldn't be hard to bruteforce check.
Edit:
I just noticed for the time digits, it seemed to be reporting something like -2 a few minutes ago.
'133343' doesn't seem to be part of the digits, which would represent 13:33:43. Unless I'm misunderstanding.
Edit:
I just noticed for the time digits, it seemed to be reporting something like -2 a few minutes ago.
'133343' doesn't seem to be part of the digits, which would represent 13:33:43. Unless I'm misunderstanding.
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).
https://gist.github.com/zulln/110a1d454d07339c496cc8ec6349fe...
This means this does not work about 200 times a day in addition to about hundred whole days (for every hundred years).
https://gist.github.com/zulln/110a1d454d07339c496cc8ec6349fe...
This means this does not work about 200 times a day in addition to about hundred whole days (for every hundred years).
A quick script from me determined you need 10,524,628 decimals of pi for this to work for all dates and times, with the limiting time being 16:25:42.
> 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.
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.
I am not sure what you are trying to say here. He did not care about probability, he tested it.
Nice! That's pretty neat zulln. If you'd like to improve things, I do accept pull requests https://github.com/TheDen/PiDay
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.
[1] https://en.wikipedia.org/wiki/De_Bruijn_sequence [2] http://math.stackexchange.com/questions/174674/if-n-balls-ar... [3] https://en.wikipedia.org/wiki/Stirling_numbers_of_the_second...
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.
[1] https://en.wikipedia.org/wiki/De_Bruijn_sequence [2] http://math.stackexchange.com/questions/174674/if-n-balls-ar... [3] https://en.wikipedia.org/wiki/Stirling_numbers_of_the_second...
> 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.
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.
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.
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.
https://gist.github.com/teotwaki/253422ac235960a0d672f9a1c39...
Edit:
- Pi to its 10 millionth digit: http://pi.karmona.com/ (warning, this will severely slow down or crash your browser)
- Pi to its billionth digit: https://stuff.mit.edu/afs/sipb/contrib/pi/
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.
https://gist.github.com/teotwaki/253422ac235960a0d672f9a1c39...
Edit:
- Pi to its 10 millionth digit: http://pi.karmona.com/ (warning, this will severely slow down or crash your browser)
- Pi to its billionth digit: https://stuff.mit.edu/afs/sipb/contrib/pi/
Great work slau. I do accept pull requests https://github.com/TheDen/PiDay if you do want to add improvements
Hey Denis,
Great to hear. I'll throw something together and send it your way.
Thanks!
Great to hear. I'll throw something together and send it your way.
Thanks!
I wonder if it includes more digits than necessary :)
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?
It certainly does not, see this comment: https://news.ycombinator.com/item?id=13868201
You can remove some digits and get the same result as today (see https://news.ycombinator.com/item?id=13867324), but as it lack so many situations as it does I would not say so.
You can remove some digits and get the same result as today (see https://news.ycombinator.com/item?id=13867324), but as it lack so many situations as it does I would not say so.
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 think a 6MB string is preferable to calculating pi to 6+ million digits in JS on each load.
I certainly wasn't suggesting that! Surely there's a superior data structure than a string, though.
Warning: Viewing the js may cause your mobile viewing experience to crash!
"Euler" is pronounced "Oiler", which makes the domain quite amusing if you share my childish sense of humour.
Oiler party? I must be missing something
No idea what the joke is; do you have to be a native speaker of English to understand it?
I'm a native English speaker and I don't get it either.
Nope, you have to be that guy to understand it.
There's a few slang definitions for "Oiler" on Urban Dictionary, but I've never heard any of them except the hockey team mascot.
There's a few slang definitions for "Oiler" on Urban Dictionary, but I've never heard any of them except the hockey team mascot.
It's a joke about strippers.
I can foresee American obesity going up when every day is π day ...
I loved this:
http://euler.party/pi.js
but it could have been done better by preallocating an array of size [86400] (all seconds in a day)
but it could have been done better by preallocating an array of size [86400] (all seconds in a day)
But it's also used for the date as well
An approximation of Pi I put together just now
var i, a = 1, s = false;
var steps = 10000000000;
for (i = 3; i < steps; i += 2) {
a += s ? 1/i : -1/i;
s = !s;
}
console.log(a * 4);
pi = arctan(1) * 4
3.141592653388201
^-- last correct digitI 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.
[deleted]
Seems rather funny that it doesn't do the MMDD interpretation, too, given the current date.
[deleted]
My birthday is Pi Day. Now I don't feel so special anymore.
http://imgur.com/1r5QpQu