On Mon, 25 Sep 2000 14:44:16 +0100, Simon Cozens wrote:
>Incidentally, so what if a hash is slow? You pay for what you get. It's still
>quicker than doing it by hand.
This is for the cases where epeople forget that they are "asking" for
it. I don't want comp.lang.perl.misc or any other support c
On Mon, Sep 25, 2000 at 03:30:47PM +0200, Bart Lateur wrote:
> If you can garantee that it's also not using a hash internally to keep
> count, but instead a table parallel to the table that's being used to
> hold the conversion values, you've won me over.
Naturally, it's hard to guarantee anythin
On 25 Sep 2000 06:07:01 -0700, Randal L. Schwartz wrote:
>Bart> Plus, in Perl 5, NO core function returns a hash.
>Bart> None at all.
>
>It's not returning a hash. I like the proposal that has it return a
>paired list, similar to the semi-paired list we get with a capturing
>split, or a list-con
On Mon, Sep 25, 2000 at 06:07:01AM -0700, Randal L. Schwartz wrote:
> Bart> character it finds. Plus, in Perl 5, NO core function returns a hash.
> Bart> None at all.
>
> It's not returning a hash.
Precisely. There ain't no such thing as "hash context". It simply returns a
list with an even num
> "Bart" == Bart Lateur <[EMAIL PROTECTED]> writes:
Bart> On Mon, 25 Sep 2000 13:00:58 +0200, Henrik Tougaard wrote:
>> Are the counts stuffed in the array in the order they appear in the
>> tr-string? or in ascii-order? or whatever?
Bart> In the same order as they are in the tr/// string, o
On Mon, 25 Sep 2000 13:00:58 +0200, Henrik Tougaard wrote:
>Are the counts stuffed in the array in the order they appear in the
>tr-string? or in ascii-order? or whatever?
In the same order as they are in the tr/// string, of course.
@freq{'a' .. 'z', '0' .. '9'} = tr/a-z0-9//;
That j
