5 ms·

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 th

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!

jwilk 9y ago
ln 2⁶⁴ⁿ > 2⁶⁴ 64n × ln 2 > 2⁶⁴ n > 2⁵⁸ ∕ (ln 2) ≈ 4.2E+17
- chrismorgan 9y ago
  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+'.
  - jwilk 9y ago
    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!
    - chrismorgan 9y ago
      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.
    - dvanduzer 9y ago
      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.
  - tzs 9y ago
    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.
    - chrismorgan 9y ago
      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.
      - tzs 9y ago
        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_gravity_slows_down_time_the_earths_core/dgr7eei/ 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.
Someone 9y ago
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
- dvanduzer 9y ago
  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.)

jwilk 9y ago

ln 2⁶⁴ⁿ > 2⁶⁴ 64n × ln 2 > 2⁶⁴ n > 2⁵⁸ ∕ (ln 2) ≈ 4.2E+17

chrismorgan 9y ago
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+'.
- jwilk 9y ago
  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!
  - chrismorgan 9y ago
    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.
  - dvanduzer 9y ago
    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.
- tzs 9y ago
  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.
  - chrismorgan 9y ago
    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.
    - tzs 9y ago
      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_gravity_slows_down_time_the_earths_core/dgr7eei/ 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.

Someone 9y ago

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

dvanduzer 9y ago
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.)