On Tue, Jun 18, 2002 at 02:20:24AM -0400, Seer wrote: > > (Err ... how in the nineteen hells is this "simplification"?) > > well, mk_wcwidth would be algorithmically simpler itself, and > all the interval/width data would be in one table or tree. > (though a tree itself looks pretty bad when written as an initialized > set of C objects)
It's the complexity of the whole that I'm referring to, and setting up a tree is much more complicated. (You actually suggested code generation, which is orders of magnitude more complex.) > > If you really need a speedup for specific cases, it could work, but > > it's actually a tradeoff; speed one up and slow down others. (And > > it's not an even trade: for every one you move up the tree, you move > > two down.) Except for ASCII, that kind of tradeoff isn't very useful > > in general-purpose code. > > not sure i agree with that. I think that a tree lookup would be > significantly fewer compares. admittedly, a difference wouldnt > likely matter unless one was widthing megs worth of data. They're both O(log n) compares. They're doing the same thing, except a binary tree conceptually moves the binary search logic into the data structure. The only way you'd have less compares is if you optimized the tree for certain data sets, and except for ASCII, you can't do that in generalized code. If you think I'm wrong, please be specific. -- Glenn Maynard -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
