News for hackers. Stuff that matters.
Re:When your data doesn’t fit in memory: the basic techniques by mytailorisrich on Monday November 11, 2019 @04:18PM (#21509011)
> A semi-common beginning programmer's exercise is to write a program that numbers the lines in a text file.

In term of RAM this can be done an arbitrarily small buffer in the sense that this can be done by reading the file byte by byte. I.e. O(1).

Edit: For all practical purposes the line counter is also constant space.

Re:When your data doesn’t fit in memory: the basic techniques by rongenre on Monday November 11, 2019 @04:28PM (#21509101)
Yeah log(n) would be the space to hold the digits of the counter. Presumably (unless things got super-silly), this would be dominated by the buffer size for the line being read.
Re:When your data doesn’t fit in memory: the basic techniques by dfox on Monday November 11, 2019 @07:42PM (#21510449)
The point there is that you don’t need a buffer for whole line, you only have to find the line terminators. Something like:

    printf(“0: “);
    ln = 1;
    while ((ch = getch()) != EOF) {
      putch(ch);
      if (ch == EOL) {
        printf(“%d: “, ln);
        ln++;
      }
    }
And I believe that original unix implementation of nl is mostly this, although with the stdio functions replaced with raw read/write.
Re:When your data doesn’t fit in memory: the basic techniques by johnc1231 on Monday November 11, 2019 @04:29PM (#21509116)
Yeah, I think the above poster said O(logn) space because that's the size of the line count in bits
Re:When your data doesn’t fit in memory: the basic techniques by jeremysalwen on Monday November 11, 2019 @05:34PM (#21509642)
The usual computation model includes "log n sized words", so it really is O (1). You usually are implicitly using that model, otherwise any algorithm that used pointers would have an extra log n tacked on, e.g. linked lists append would be log n not constant.