in reply to Re: Heap structure for lookup?
in thread Heap structure for lookup?

They certainly reduce the infrastructure overhead (number of pointers), but the last time I used b-tree was ~20 years ago, and my memory of them is ***AAAAAAAAAAAAARGGGG!***.

We were using a library purchased from a 3rd party company that went to the wall and needed to move from 16 to 32-bit compiles.

We had the source code and thought it would be reasonably easy, till we looked. It was a nightmare. The algorithms are really quite involved.


With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority". I'm with torvalds on this
In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked

Replies are listed 'Best First'.
Re^3: Heap structure for lookup?
by RichardK (Parson) on May 27, 2015 at 10:26 UTC

    As you're only storing single values it shouldn't be too bad, only the balancing code gets a bit involved, when you split the current node you insert into it's parent node which may cause it to split and so on back up to the root node. It's really not that hard, once you get your head round it.

    Anyway you've had 20 more years of experience since then, so you shouldn't have any problems ;)

      Anyway you've had 20 more years of experience since then, so you shouldn't have any problems

      If only it worked that way. If only :)


      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority". I'm with torvalds on this
      In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked