Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.


But 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 was affected, but who knows what other FPUs do?)


But we can probably compress the data very well (e.g. "double delta" is always zero), and then decompress only needed parts.


This 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?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: