On Tue, 26 Sep 2000, Bennett Todd wrote:
> That sounds positively noble when you put it that way. I can
> actually hear choirs of cherubim providing atmosphere.
I heard them also, but I thought it was the radio.
> > And yes, a list of 250 items to store 5 items is HUGE. There is no way to
> > know how many items I will have.
>
> Yup, but as long as you're working with 8-bit encodings the array
> will never get bigger than 256.
Who says I'm working with 8-bt encodings?!
Perl5 already has rudimentary support for multibyte encodings. So far I
haven't used them, but this is only because I'm dealing with my multibyte
input as binary data, and just passing it allong. Presumably I will want
to make some sanity checks once I learn enough to know what I'm checking
for.
When the Martians come out of hiding, we're going to have to add 13bit
fonts, so maybe we should keep our arbitrary character restrictions in the
core, in just one place, to make it easier to accomodate this inevitable
circumstance. If we make everything else general enough, we will be able
to meet their demands quicker, saving the world and bringing a new age of
prosperity to humankind.
> > O(N*50) is never going to make me happy.
>
> O(1) should make you happy. It's got a small fixed upper bound.
> Unless, of course, split// and ord get interesting in the face of
> UTF-32 or something and the data is no longer bounded, in which case
> (as I said) your only hope is to change the [] to {}, at which point
> it's probably as fast as the hyper-sexy hash-building-tr///.
A "small" fixed upper bound? It is N that is bounded, that doesn't stop it
from using N*50 variables to represent N, or N*150 variables if I'm only
matching vs 2 characters. Perhaps instead of using O() I should have just
said, "it is 0 to 150 times slower." The overal algorithm, that is, I am
assuming that this list is going to be iterated over. Making this monster
list would add inefficiencies to each step in the algorithm. In any case,
that sollution doesn't seem to work, because of it's reliance on an
arbitrary set of conditions that are smaller than the conditions in the
problem domain. What's the upper bound in a 16bit language? Or does that
case just have to break? "Sorry, you're not European. Please be
assimilated before using this tool. Resistance is futile."
> What's all this about eval?
That was in reference to my previous map example, which is the best
general way I've seen proposed to handle the specified counting in p5.
Ugly as it is, there is hopefully a better way, but not one that is
obvious (to me). But given the changes proposed in RFC 283, it would not
only be easier, it would be more efficient, and fully compatible with
whatever character encodings Perl supports, now and into the future.
Paris Sinclair | 4a75737420416e6f74686572
[EMAIL PROTECTED] | 205065726c204861636b6572
www.sinclairinternetwork.com
