4 ms·
Actually it’s not good enough there because JavaScript numbers are f64 rather than u32. Even if you only support the safe integer range (beyond which the answer
by chrismorgan 3y ago
Actually it’s not good enough there because JavaScript numbers are f64 rather than u32. Even if you only support the safe integer range (beyond which the answers become somewhat meaningless), that’s 2⁵⁴, more than four million times as large as 2³². Not sure how big the machine code would be, but I’m guessing it’ll just add 4 bytes (40%) to each case, so you’re up to something like 224 exibytes. And that’s when you’re being lazy and skipping the last ten bits’ worth. If you want to do it properly, multiply by another thousand. Or maybe a little less, I haven’t thought too deeply about NaN patterns. Or maybe just infinite if it supports bigints.
- deepsun 3y agoBut we can probably compress the data very well (e.g. "double delta" is always zero), and then decompress only needed parts.
- vineyardmike 3y agoThis still requires reading through it all in memory at run time. Maybe we can optimize it with a JIT -what if the package called the ChatGPT api to get the the python code that generates the machine code just for the number queried?
- Someone 3y agoBut you can create a self-modifying function that, ‘for speed’, adds each case when it is called. The initial function should start with checking for special cases NaN, infinities, 0 and -0, then do (may not be valid JavaScript) if((x++ === x) && (x—- === x)) printf("even\n"); to handle cases over 2^54 or below -2^54, then do isOdd = true neg = x pos = x while(true) { if(neg++ === 0) break; if(pos-- === 0) break; isOdd = !isOdd } to determine whether x is odd or even in isOdd. Doing the self-modification is left as an exercise. This is good defensive programming. It avoids doing a tricky division by 2.0 that might be buggy (I don’t think https://en.wikipedia.org/wiki/Pentium_FDIV_bug https://en.wikipedia.org/wiki/Pentium_FDIV_bug was affected, but who knows what other FPUs do?)