It wasn't clear to me that the problem as framed was about asymptotic growth. I was curious if/when the factors might become relevant, so I started sketching this out...

The 63x64 binary canvas is made of integers on the order of 2^4032. (Please forgive my approximation notation.)

    ln(2^4032) ~= 2795
    log_10(2^4032) ~= 1214

So, the difference between natural log (for this canvas size) and log base 10 is only one binary digit (min 11, max 12). The "noise" you need to introduce to the image will definitely keep to the bottom right corner.

So, I'm curious how tall the phone-width image needs to be before the required noise exceeds 64 bits (aka a single row). And the answer is... Too tall to be calculated quickly with my brute force method of "try bigger numbers until you get too impatient to wait for your desktop to calculate the natural log".

I'm sure if I spent enough time drawing the parameters out, I'd eventually agree that there's no representation of this problem where those factors ever become relevant.

BUT.

If the problem we were calculating involved log base 1.0001 instead of the natural log, those factors would become relevant at much smaller canvas sizes. I would love to hear an intuitive explanation of logarithms that would convince me to not bother making calculations like this in the future!

As the post you replied to said, it’s a constant factor. You’ll find:

    ln(2^n)     = n * ln(2)
    log_10(2^n) = n * log_10(2)

Which, substituting x for 2^n, gives

    log_10(x) = ln(x) * (log_10(2) / ln(2))

you can do replace 2 by any positive number here. So, the value of

    log_10(x) / ln(x)

is independent of x. A bit of thinking will show it to be equal to

    ln(10)

And indeed,

    1214 * ln(10) ~= 2795,338

No, I understand the conversion factor is constant.

The subthread started when someone thought it was necessary to point out that the log everyone was talking about was the natural log.

Independent of what the actual problem is, say someone tells you that something is log(n). It is a safe assumption that they mean ln(n), but if you are are speaking out loud, that is still pronounced "log n".

What I'm looking for is better intuitions on F/ln(n) versus F/log_x(n) for some completely arbitrary function F. The intuitions for x > e are very different than the intuitions for x < e. (This is just the nature of exponents. Maybe there is no further intuition for me to develop here, other than to just practice more.)

ln 2⁶⁴ⁿ > 2⁶⁴

64n × ln 2 > 2⁶⁴

n > 2⁵⁸ ∕ (ln 2) ≈ 4.2E+17

Such beautiful superscripts and ≈, but then you used * and / instead of × and ÷…

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+'.

THIN SPACE (U+2009) is also good to use to group digits, and is in fact the standard way to group digits in the SI system instead of "," or ".".

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.

HN supports THIN SPACE just fine. I used it in my comment, and so did you.

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.

OK, this is odd. It looks like something browser dependent is going on.

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:

1​234​567 (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.

Looks good with Firefox on Linux too.

Given chrismorgan's comment about breaking, it seems that NARROW NO-BREAK SPACE would be a better choice for digit grouping, right?

Yeah, NARROW NO-BREAK SPACE is probably better.

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&#x200B;234&#x200B;567 (U+200B, ZERO WIDTH SPACE)<br/>
  1&#x200A;234&#x200A;567 (U+200A, HAIR SPACE)<br/>
  1&#x202F;234&#x202F;567 (U+202F, NARROW NO-BREAK SPACE<br/>
  1&#x2009;234&#x2009;567 (U+2009, THIN SPACE)<br/>
  1&#x2006;234&#x2006;567 (U+2006, SIX-PER-EM SPACE)<br/>
  1&#x2008;234&#x2008;567 (U+2008, PUNCTUATION SPACE)<br/>
  1&#x2005;234&#x2005;567 (U+2005, FOUR-PER-EM SPACE)<br/>
  1&#x2004;234&#x2004;567 (U+2004, THREE-PER-EM SPACE)<br/>
  1&#x0020;234&#x0020;567 (U+0020, SPACE)<br/>
  1&#x2000;234&#x2000;567 (U+2000, EN QUAD)<br/>
  1&#x2002;234&#x2002;567 (U+2002, EN SPACE)<br/>
  1&#x2007;234&#x2007;567 (U+2007, FIGURE SPACE)<br/>
  1&#x2003;234&#x2003;567 (U+2003, EM SPACE)<br/>
  1&#x2001;234&#x2001;567 (U+2001, EM QUAD)  </p>
  </p>
  </body>

It’s common for fonts to not include glyphs for all the fancy spaces, which will leave it to a fallback mechanism where a different font is used.

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.

Changed * to × (U+00D7 MULTIPLICATION SIGN) and / to ∕ (U+2215 DIVISION SLASH).

I don't like ÷, and I can't be bothered about whitespace. Sorry!

Thank you for writing out that extremely clear sequence of inequalities. I love a good Unicode style debate, but regardless you absolutely nailed it with conceptual clarity.

I always forget about DIVISION SLASH and that it’s a thing, distinct from FRACTION SLASH (which I use regularly). I wonder if I should add it to my compose key. Nah, I think ÷ and FRACTION SLASH are enough for me.

In computational complexity, one typically ignores multiplicative constants, but in number theory, one often doesn't.

The prime number theorem is of this stronger form, and it is in fact only the natural logarithm that makes the usual statement true. It is considerably more difficult to prove this asymptotic result (first proven 1896) than to get "within a multiplicative constant" as in big-O notation (first proven 1848--50).