41–50 of 98 posts
(Edit: oops, incorrect numbers)
Following BLC8's bytewise encoding convention of [1], w218's binary encoding 0100 0101 1010 1000 0110 0110 0000 0001 0101 1011 1011 0000 0011 1001 1101 0 gets padded with 3 arbitrary least significant bits, say 000, and becomes 45A8_6601_5BB0_39C0 in hexadecimal. [1] https://www.ioccc.org/2012/tromp/
Earlier quoted context omitted.
As I've replies several times before, we don't allow arbitrary mappings. We allow computable mappings but consider only obviously non-cheating languages like Turing machines or lambda calculus or Linux's bc or any existing programming language, that are not geared toward outputting insanely large numbers.
I would say that all of those seem both arbitrary and geared toward outputting insanely large numbers (in the sense that the output of any Turing-complete language is). Now if you can make these claims in a mathematical rigorous way (i.e. without relying on a particular mapping like Turing Machines / Lambda Calculus, and without silly "up to a constant factor" cheats) then that would be more interesting.
There is unfortunately no mathematically rigorous way to define what is cheating, so it seems unreasonable to ask me for that.
Please no more comments to the extent of "i can define a much larger number in only 1 bit". What makes my blog post (hopefully) interesting is that I consider tiny programs for computing huge numbers in non-cheating languages, that are not specifically equipped for doing so.
Earlier quoted context omitted.
As I've replies several times before, we don't allow arbitrary mappings. We allow computable mappings but consider only obviously non-cheating languages like Turing machines or lambda calculus or Linux's bc or any existing programming language, that are not geared toward outputting insanely large numbers.
It's not "the largest representable number" because you're not representing numbers in any rigorous sense. If I give you 64 bits, you can't tell me what number those bits represent (first, because the rules of the game are ambiguous - what if I give you 8 bytes that are a valid program in two different languages; and second, because even if you made the rules precise, you don't know which bitstrings correspond to pro…
You have to tell me the (non-cheating) programming language that the 64 bit program is written in as well.
> And you're asking, what is the largest finite output you can get from a program in today's programming languages that is 8 bytes or less.
That's what the post ends up saying, after first discussing conventional representations, and then explicitly widening the representations to programs in (non-cheating) languages.
Please no more comments to the extent of "i can define a much larger number in only 1 bit". What makes my blog post (hopefully) interesting is that I consider tiny programs for computing huge numbers in non-cheating languages, that are not specifically equipped for doing so.
Please no more comments to the extent of "i can define a much larger number in only 1 bit". What makes my blog post (hopefully) interesting is that I consider tiny programs for computing huge numbers in non-cheating languages, that are not specifically equipped for doing so.
So basically you have a very low density of representable numbers (2^64 / w218), I wonder how quickly it grows as you use more and more 1-bits, and is there even a correlation between the bit pattern and the corresponding number value?
Please no more comments to the extent of "i can define a much larger number in only 1 bit". What makes my blog post (hopefully) interesting is that I consider tiny programs for computing huge numbers in non-cheating languages, that are not specifically equipped for doing so.
Surely you've been on HN long enough to know people just read the headline. Not that it would stop all sniping, but that headline doesn't even include "program" (or "compute").
Neither does Scott's article titled "Who Can Name the Bigger Number?" [1]
The title is just a way to invite the reader to find out why the answer isn't simply 2^64-1.
Please no more comments to the extent of "i can define a much larger number in only 1 bit". What makes my blog post (hopefully) interesting is that I consider tiny programs for computing huge numbers in non-cheating languages, that are not specifically equipped for doing so.
Please no more comments to the extent of "i can define a much larger number in only 1 bit". What makes my blog post (hopefully) interesting is that I consider tiny programs for computing huge numbers in non-cheating languages, that are not specifically equipped for doing so.
An interesting follow-up question is, what is the smallest number unable to be encoded in 64 bits of binary lambda calculus?
It all goes over my head, but, what does the distribution of values look like? e.g. for unsigned integers its completely flat, for floating point its far too many zeros, and most of the numbers are centered around 0, what do these systems end up looking like?
4x208506 6x203638 7x93072 8x202741 9x62039 10x189422 11x101450 12x183896 13x96804 14x167842 15x103631 16x131387 17x100319 18x161560 19x148361 20x180227 21x117866 22x82568 23x90577 24x136315 25x158660 26x207930 27x181334 28x33308 29x33331 30x52430 31x80559 32x140753 33x231169 34x3643 35x1356 36x2817 37x1162 38x2067 39x707 40x1820 41x414 42x1316 43x226 44x1026 45x230 46x663 47x142 48x189 49x150 50x189 51x63 52x102 53x169 54x161 55x24 56x71 57x88 58x48 59x6 60x63 61x11 62x19 63x3 64x18 65x11 66x20 67x10 68x13 69x4 70x6 71x11 72x8 73x12 74x10 75x7 76x9 77x5 78x6 79x5 80x4 81x3 82x9 84x6 85x2 86x3 87x3 88x13 89x3 90x6 92x5 94x3 95x2 96x9 101x1 102x3 103x1 106x2 108x2 109x1 111x3 112x1 113x3 115x1 117x1 118x1 120x2 121x1 122x1 124x1 127x3 128x1 130x2 132x1 133x1 134x3 141x1 142x3 143x2 144x1 146x1 148x1 149x2 158x1 159x1 160x3 161x1 162x7 164x3 166x1 179x1 180x1 187x2 199x1 202x2 203x1 217x1 223x1 225x1 227x4 242x1 247x2 267x1 268x1 269x1 280x1 296x1 298x1 331x1 363x1 394x1 432x1 475x1 484x1 544x1 673x1 708x1 820x1 1364x1 1812x1