ln 2⁶⁴ⁿ > 2⁶⁴
64n × ln 2 > 2⁶⁴
n > 2⁵⁸ ∕ (ln 2) ≈ 4.2E+17
64n × ln 2 > 2⁶⁴
n > 2⁵⁸ ∕ (ln 2) ≈ 4.2E+17
I like to also put plenty of THIN SPACE ( ) in to give it space to breathe, e.g. 2 ⁶⁴ ⁿ and 64 n instead of 2⁶⁴ⁿ and 64n. I make my thin spaces with Compose+Space+'.
I don't like ÷, and I can't be bothered about whitespace. Sorry!
That looks nice and gets rid of the confusion over number like "1,234" and "1.234". In the US, the former is the integer 1234 and the later is the rational number 1234/1000. In Germany or France, these would be the other way around. In SI, "1.234" and "1,234" would both be 1234/1000, and the integer 1234 would be "1 234" with the space there being a thin space.
Unfortunately, HN does not support THIN SPACE as far as I can tell.
Reddit is a little better. You can enter it in a comment and it will be correctly saved with the comment and it will display correctly in the browser. As long as you don't need to make any edits to your comment afterwards, it is fine.
If you edit the comment thin spaces are converted to regular spaces when it loads the editing widget, so unless you go through and put all the thin spaces back you will lose them when you save.
I’m not at all fond of the thin space digit grouping practice; to my Australian eyes it tends to look fairly terrible in most places, like bad kerning.
Your comment also shows another catastrophic weakness of using a regular thin space for digit grouping without additional magic: you need a non-breaking thin space, but there isn’t one. On my comments page, your comment shows the 1 on one line, and the 234 on the next.
I love my YYYY-MM-DD dates (I use it everywhere where the date format isn’t prescribed, and thus get the occasional odd look on forms and such from people aren’t used to that form of date—so you can see I’m not afraid of deviating from local conventions to prefer superior or sometimes merely international ones), but I hate and consequently don’t use thin space digit grouping in general.
You earlier comment shows up with thin spaces on Chrome for me, but not on Safari or Firefox.
I know Firefox handles thin spaces, because it handles this Reddit comment just fine: https://www.reddit.com/r/Physics/comments/67g28i/because_gra...
I'm going to paste the examples from there here and see what happens:
1234567 (U+200B, ZERO WIDTH SPACE)
1 234 567 (U+200A, HAIR SPACE)
1 234 567 (U+202F, NARROW NO-BREAK SPACE)
1 234 567 (U+2009, THIN SPACE)
1 234 567 (U+2006, SIX-PER-EM SPACE)
1 234 567 (U+2008, PUNCTUATION SPACE)
1 234 567 (U+2005, FOUR-PER-EM SPACE)
1 234 567 (U+2004, THREE-PER-EM SPACE)
1 234 567 (U+0020, SPACE)
1 234 567 (U+2000, EN QUAD)
1 234 567 (U+2002, EN SPACE)
1 234 567 (U+2007, FIGURE SPACE)
1 234 567 (U+2003, EM SPACE)
1 234 567 (U+2001, EM QUAD)
Edit: they displayed with the various different space sizes in Chrome, and with fixed space sizes in Firefox (1 regular space for all except 200B and 202F which showed up with no space).
Unlike Reddit, editing does not lose information.
Also displays right in Edge, and in Firefox on Windows. So it looks like it is just Firefox Mac and Safari that are not handling the various space sizes for me.
Given chrismorgan's comment about breaking, it seems that NARROW NO-BREAK SPACE would be a better choice for digit grouping, right?
As far as the display problem on Firefox and Safari on Mac goes, I've done some experimenting. It looks like it is a font thing. HN has "font-family:Verdana, Geneva, sans-serif;" as part of the style sheet.
I made a minimal test page with just the different space examples, and an internal style sheet that just set the font-family for the body, and it shows the problem. Changing it to "Arial, sans-serif" makes it work.
I've never looked seriously into fonts for browsers, so have no idea what is going on at this point. If there is a problem with the Mac versions of Verdana and/or Geneva, then why is it only affecting Firefox and Safari, and not Chrome, on my Mac?
If anyone else wants to try to figure this out, here is the test page I've been using:
<!DOCTYPE html>
<head>
<meta charset="utf-8"/>
<title>space test</title>
<style>
body { font-family:Verdana, Geneva, sans-serif; }
xbody { font-family:sans-serif;}
xbody { font-family:Arial, sans-serif;}
</style>
</head>
<body>
<p>
1​234​567 (U+200B, ZERO WIDTH SPACE)<br/>
1 234 567 (U+200A, HAIR SPACE)<br/>
1 234 567 (U+202F, NARROW NO-BREAK SPACE<br/>
1 234 567 (U+2009, THIN SPACE)<br/>
1 234 567 (U+2006, SIX-PER-EM SPACE)<br/>
1 234 567 (U+2008, PUNCTUATION SPACE)<br/>
1 234 567 (U+2005, FOUR-PER-EM SPACE)<br/>
1 234 567 (U+2004, THREE-PER-EM SPACE)<br/>
1 234 567 (U+0020, SPACE)<br/>
1 234 567 (U+2000, EN QUAD)<br/>
1 234 567 (U+2002, EN SPACE)<br/>
1 234 567 (U+2007, FIGURE SPACE)<br/>
1 234 567 (U+2003, EM SPACE)<br/>
1 234 567 (U+2001, EM QUAD) </p>
</p>
</body>It’s also common for web fonts especially to possess glyphs for some of the fancier spaces, but as duplicates of SPACE, i.e. the wrong size.
Face it: fonts (to a degree the technology, but mostly the actual fonts) are generally pretty bad.