Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : Advanced Micro Devices - Moderated (AMD) -- Ignore unavailable to you. Want to Upgrade?

To: Joe NYC who wrote (65010)	12/6/2001 2:48:52 AM
From: kapkan4u	Read Replies (1) \| Respond to of 275872

<I believe Kap mentioned hash table, rather than binary tree. I don't know what compiler he is using.> I never mentioned a hash table. I said a jump table. Wanna, who is perpetually confused, called it a hash table. Kap

To: Joe NYC who wrote (65010)	12/6/2001 5:08:32 PM
From: Neil Booth	Read Replies (1) \| Respond to of 275872

I believe binary trees have O of sqrt(n). I believe Kap mentioned hash table, rather than binary tree. I don't know what compiler he is using. No, O(log n). Each time the choices are halved. But for the purpose of this discussion, what is more relevant is how the table or the binary tree gets built up, since that's the bottleneck. ?? The binary tree and tables are built at compile-time - I assumed you were talking about run-time bottlenecks. IMO hash tables are rarely if ever appropriate for switch statements. And I doubt they use any less compile time or run time than the algorithm I described; a jump table for dense choices is as efficient as it comes, and combining it with a binary search for sparse bits covers the other bases. Neil.