I was hoping for something akin to a xkcd or SMBC comic, this isn't really much better than what my asm prof said when he explained it for MIPS programming. Maybe it's because I don't get what he means by offset and window, but this wasn't really that helpful.
The window limits the value the offset can represent -- minimum and maximum bounds. The window doubles each time you increment it since it's binary / power-of-two (0, 1, 2, 4, 8, …).
Within any given window there are 2^23 possible values. If you imagine those values as an array, the offset is the array index.
So in the example of 3.14, the window is [2, 4] since that's the power-of-two pair that contains the value. The offset is (value - minimum) / (maximum - minimum) = 0.57, which you multiply by 2^23 to get the array index.
Because the window doubles each time it's incremented, as the window gets bigger you lose precision -- in his example, [0, 1] gives 15 decimal places but [2048, 4096] only gives 4 decimal places.
The window is an index into a consecutive block of numbers (like a 4K page), and the offset is the offset into that block. [edit: the other poster highlighted the important distinction--that the window doubles in size each time so your fixed offsets into that window become further apart. If you had 1024 offsets into a 1024 window, you get index 0 for 0. index 1 for 1. 2 for 2. etc. But when you double that window, you're now one index for two steps. #1 for 2, #2 for 4, #3 for 6. and then you add that onto the top of the previous window's starting point, which in my example was 0-1023. So add 1023 for the second block. But a diagram would be really helpful at this point.]
Now, I don't see the huge benefit of introducing a whole extra topic (pointer arithmetic) to explaining floating point. But if it works for someone, more power to them!
[edit: Also, since pointers don't normally swell/scale/double like floating point, then even if you explain using the pointer analogy... you then have to NOTE the difference. So I still think it's a really bad analogy to use. Even worse when tons of modern day programmers know almost nothing about system programming and addressing modes.]
Anyway, best of wishes. The guy certainly put a lot of work into writing an article he thought would be helpful.
Personally, I'm grateful that it isn't a comic. Between some stick figures plus a diagram and just the plain diagram, I'll take the latter. Comics might help writers order their thoughts because due to the constrained and sequential nature of speech bubbles, but generally they don't add much to the explanation itself.
