I think back to this in discussions about teaching. Abstract concepts are best understood when the student has a legitimate need for them. You can explain something all day and have their eyes glaze over wondering why something is important, but if it solves a problem they have it will click in seconds or minutes.

I wasn't a computer scientist so I read the file in the dumbest way possible, but kept getting errors about memory usage and running out of space since I was looping within loops within loops. I went through it and added `$variable = null` at every opportunity. Lo and behold it worked.

Usually, you cannot achieve this by engaging in academic code with recursion and loops; you have to do the opposite: trade readability and compact code for speed.

Sometimes, code for 6510/68000 is so optimized - usually unrolled - that you get code patterns that resemble data applied at different frames, much like your code.

There is nothing wrong from my point of view. ;)

(Some words of wisdom: May the debug gods be with you on this journey, though.)

  func isOdd(n int) bool {
    switch {
    case n == 0:
      return false
    case n > 0:
      return !isOdd(n-1)
    default:
      return !isOdd(n+1)
    }
  }

    playground::isOdd:
     testq %rdi, %rdi
     setg %al
     andb %dil, %al
     retq

Unfortunately the go playground doesn't seem to support emitting assembly?

    func isEven(n int64) bool {
        return !isOdd(n)
    }

[1] https://www.npmjs.com/~jonschlinkert

  /*!
   * is-even <https://github.com/jonschlinkert/is-even>
   *
   * Copyright (c) 2015, 2017, Jon Schlinkert.
   * Released under the MIT License.
   */

  'use strict';
  
  var isOdd = require('is-odd');
  
  module.exports = function isEven(i) {
    return !isOdd(i);
  };

Now looking at the source, that package may make sense if figuring out whether something is a number type in JS is really that cumbersome. (Though I'd expect that there is a more generic package that covers the other built-in types as well.)

Also since isNumber treats strings that can be converted to a number, a number, it can yield weird results since adding two strings will naturally just concatenate them. So e.g.:

    const a = '1'; 
    isNumber(a); // returns true
    const b = a + a; // Now you have a string in b: '11'

[1]: https://github.com/mickael-kerjean/nulll

[2]: https://news.ycombinator.com/item?id=17072675

[3]: https://github.com/mickael-kerjean/nulll/blob/master/test.js

It was submitted in HN too - https://news.ycombinator.com/item?id=16194932

    'use strict';
    
    const isNumber = require('is-number');
    
    module.exports = function isOdd(value) {
      const n = Math.abs(value);
      if (!isNumber(n)) {
        throw new TypeError('expected a number');
      }
      if (!Number.isInteger(n)) {
        throw new Error('expected an integer');
      }
      if (!Number.isSafeInteger(n)) {
        throw new Error('value exceeds maximum safe integer');
      }
      return (n % 2) === 1;
    };

(Alternatively, perhaps odd numbers are actually much rarer, leading to them having a higher market value, and thus more interest in discovering them.)

    'use strict';
    
    var isOdd = require('is-odd');
    
    module.exports = function isEven(i) {
      return !isOdd(i);
    };

I may be misremembering his meaning, but I remember thinking it was an interesting idea. It wasn’t obviously a terrible idea. I thought it would be like the Clojure standard library on steroids, especially if it was coordinated and vetted by a decent team.

But alas, NPM has proven it otherwise.

    CREATE TABLE even_or_odd (
      is_odd NUMBER(1);
      is_even NUMBER(1);
      is_zero NUMBER(1);
      is_one NUMBER(1);
      is_two NUMBER(1);
      is_three NUMBER(1);
      -- ...
    );
    INSERT INTO even_or_odd (is_odd,is_one) VALUES (1,1);
    INSERT INTO even_or_odd (is_even,is_two) VALUES (1,1);

Not only it helps with portability of the data, it also keeps it in a human-friendly format should the need to inspect it by hand arise.

    /* Copyright 2023. All unauthorized distribution of this source code 
       will be persecuted to the fullest extent of the law*/

It's been ages since I've done anything low-level, but I don't think 4 billion if-statements are compiled to a "lookup table" when optimizations are turned off. Each and every if statement would be evaluated in order to determine if it matches the input. This seems to be supported by OP's program outputting in much less time for small numbers than for large numbers--since the small numbers appear earlier in the code.

A 4 billion case switch statement on the other hand, I would expect to compile to some kind of lookup table. Though when the data type is an unsigned int even then I'm not sure what the compiled code would look like without optimization.

So a rerun of the program should only need to load ~8GB if the filesystem caching is somewhat loop/scan resistant.

My first thought was "probably the math is wrong", but looks like it adds up to something reasonable - especially as all numbers are rather vague / rounded (e.g. let it be 12s) and the number was just high, not absolute maximum.

Truly curious. I guess the linear access pattern helps but 800 MiB/s?