> > > i might get to figure out my bitwise arithmetic mistake :D > > > > there's a question of why did i spread the values instead of only > > copying out the ones whose new hash bits were nonzero > > > > and the reason is to keep the same ordering of the underlying data to > > make debugging and inspection clearer. > > > > [.. i didn't consider it valuable to keep the old ones in place > > because writing zeros would heavily fragment the data -- each record > > is a new fetch right now -- and the original growth ratio was so high > > that little would have been kept in place (and that original code is > > currently the only working code!) > > ooooh if you don't need to use zeros to check for presence or if you > disable presence checks then you can just clone the hashtable to grow > it, that's great, i haven't actually studied this, great trick !
that definitely makes sense as a first growth strategy for FixedDict . then presence checking could be implemented in the derived class. of course the code is still nonfunctional right now ... this adds to my queue on comprehend bitwise things :) i'm trying to figure out if the approach works for the inverted structure i have and why not if not ...
