little bit more example
dec 33
hex 21
pubkey 021697ffa6fd9de627c077e3d2fe541084ce13300b0bec1146f95ae57f0d0bd6a5
use your program to get 32 keys of above pubkey
you will see 0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798 in your list
one step ahead pubkey is 1.03125 ( 03bb2228d3ea32cb3c1eb160cc824a4ba8115f9a7f415d18ddcaac8193defc2c47 + 0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798 )
and in private key F7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFEC4D965FF79CE5B39E1D3CB9869B48F38
029eda0cebe3c594b59add6dccbff3347f06ad09e83e0b9279dd821cc94284c5d0
hope you will test each zone for your understand
Sorry to rain on this, but this method is useless.
I managed to decode how to split multiple keys using this method (I even made a script that reproduces your example, but it's private at the request of someone else, not that the results would be useful/practical to anyone here), and it turns out you're just using mod(32)-sized ranges.
Now as we all know, when you modinv a small number on secp256k1 you get a
very large number (and modinv a "decimal number" is really just modinv(denominator) * numerator so this still holds for that)
This effectively means that the range becomes humungous, way bigger than 2^120 where we started.
The ranges look something like this (P = public key):
1*modinv(32) 2*modinv(32) 1P
2*modinv(32) 3*modinv(32) 2P
...
32*modinv(32) 33*modinv(32) (32*modinv(32) = 1) 32P
The ranges are much bigger than when you divide-and-split them down by a number.
Now of course you can replace 32 with an extremely huge number to make the ranges manageable/smaller but what's the point? Now you have an unmanageable amount of public keys.
in range 
