pg has asked for the wisdom of the Perl Monks concerning the following question:

I started to wondering about this a while ago. There was once a post, which reported his/her discovery that Perl 5.8 has a bug on supporting subs running on its own thread, and returning array or hash. The problem is that the hash or array would be evaluated as if in a scalar context. (Well, there is a workaround, just to return ref to hash or array. In your mind, this workaround is actually even better, as by returning ref, you gain performance quite significantly.)

Now back to my question. When you evaluate array in a scalar context, for example: 
@a = (1,2,4,6,8);
$a = @a;
print $a;

[download]
It gives you a FIVE, which is quite easy to understand, as it matches $#a.

However, if you do, 
%a = (a=>1,b=>2,c=>4,d=>6,e=>8);
$a = %a;
print $a;

[download]
It gives you 5/8. Now I don't understand, what does this number or fraction or whatever mean?

Replies are listed 'Best First'.
Re: what does that value mean, when you evaluate hash in a scalar context?
by runrig (Abbot) on Dec 14, 2002 at 17:03 UTC
    See perldata. Specifically "evaluate a hash in scalar context".
[reply]
      Thanks for the link, now I got my answer. However, now a more serious question is raised.

      According to perldata, the denominator of that fraction is the number of units of momery, perl has allocated for your hash, and more interestingly, the denominator is always a number of 2's power.

      This algorithm of allocating memory really worries me, because it indicates, that it intends to waste more memory, when your hash gets bigger, because whenever you used up the memory been already allocated, perl would just double it.

      I can understand the thought behind this algorithm, one is thinking, okay, I already gave you a big piece of memory, but it is still not big enough for you, instead of wasting time to give you all those small pieces, let's just double the memory I gave you.

      I can understand this is a space vs. time thing, and I have no problem with that, but I still feel this algorithm is way too rough. there must be other more delicate/fine solutions.

[reply]
        Hashes are known to be innefiicient uses of memory. Thats the tradeoff you get for speed.

        One thing I did recently discover is that a nearly full hash will tend to have its elements in some kind of well defined order.
        For example if you do letter frequency analysis of a large document because you think this might be fun for cryptography you end up with a hash %frequencies which contains most of the ASCII character set from 32 to 127 and they are also in nearly alphabetical order that is keys %frequencies produces a list ... 'A', 'B', 'C', 'D' ...

        Dingus

        Enter any 47-digit prime number to continue.
[reply]

        You are right, given the appropriate frame of reference ;-)))

        Old OSs actually gave you the memory you requested.

        In modern, sane operating systems, allocating memory is not the same as occupying it. If you do char* m=malloc(10*1204*1024), you are telling the OS (OK, the C library, which could do some magic, but the result is the same) that you want a megabyte added to your address space. So the OS (for example) adds a couple of lines to your process' page table, and you have your address space. When then you do c[200]=0, the OS tries to access the memory, gets a page fault, remembers that it has to actually give you that memory, and creates a page (a single page, mind, usually in the order of 4KB) to store your data in, attaching it to the appropriate entry in the page table. Now you are occupying memory. 4KB of it ;-)

        So the space occupied is less than the space allocated. Given that most of the time is spent in the allocation phase (you have to keep track of the memory at the OS, library and probably application levels), always doubling the memory allocated to a growing container insures an "amortized linear time" complexity (meaning that it's linear in the mean, but sometimes it is slower (alloc), sometimes faster (write)).

        -- 
        dakkar - Mobilis in mobile
[reply]
[d/l]
[select]
Re: what does that value mean, when you evaluate hash in a scalar context?
by Revelation (Deacon) on Dec 14, 2002 at 18:53 UTC
    You may want to read this. It's an interesting article on how hashes behave. It'll give you some cursory information on how to use them.

    Answer/Nitpicking; 
    @a = (1,2,4,6,8);
$a = @a;
print $a;

It gives you a FIVE, which is quite easy to understand, as it matches 
+$#a.

    [download]
    $#a is the highest index. $a is the scalar value, or how many numbers are in the array. $array gives you how many numbers are in the array, and $a for a hash gives you the ammount of values used over the ammount of values allocated before the hash needs to get bigger. (Somebody has already explained to you why in the previous post.) Also, check out Shift, Pop, Unshift and Push with Impunity! for some more information on perl's algorithms, in general for datatypes.
    Gyan Kapur
    gyan.kapur@rhhllp.com
[reply]
[d/l]
Re: what does that value mean, when you evaluate hash in a scalar context?
by demerphq (Chancellor) on Dec 15, 2002 at 01:14 UTC
    Some additional nitpicking: 
    It gives you a FIVE, which is quite easy to understand, as it matches 
+$#a.

    [download]
     is wrong. :-) There are 5 elements in the array, the value of scalar @a. The value of $#a in a sane situation should be FOUR, that is to say, one less than @a.

    :-)

    --- demerphq
    my friends call me, usually because I'm late....

[reply]
[d/l]
Re: what does that value mean, when you evaluate hash in a scalar context?
by Anonymous Monk on Jun 22, 2005 at 01:24 UTC
[reply]

Back to Seekers of Perl Wisdom