in reply to Re: Arrays: Last-index special variable vs. scalar values
in thread Arrays: Last-index special variable vs. scalar values

(I realize this question has been settled... just thought I'd clarify the above answer so there was no need to go to the docs)

From the Camel Book 2d ed. p47
In a list context, the value of the list literal is all the values of the list in order. In a scalar context, the value of a list literal is the value of the final element, as with the C comma operator, which always throws away the value on the left and returns the value on the right. For Example:
@stuff = ("one","two","three");
assigns the entire list value to array @stuff, but:
$stuff = ("one","two","three"); assigns only the value three to variable $stuff.

----
Lists are different animals than arrays. Lists are not simply collections of literals. You can have a list of arrays. It seems like if you evaluate a hash in scalar context, i.e $x = (%hash); you get some funky fraction that doesn't mean much. If you did $x = (@ary1,@ary2); you'd get the last value of @ary2. I'm sure that's useful.

Replies are listed 'Best First'.
Re: Arrays: Last-index special variable vs. scalar values
by Dominus (Parson) on Nov 16, 2000 at 22:07 UTC
    Say tenatious:

    > If you did $x = (@ary1,@ary2); you'd get the last value of @ary2.
    Sorry, but that is not correct.

    The comma operator propagates the scalar context to @ary1 and @ary2. In scalar context, the array expressions turn into the number of elements in each array. So if @ary1 has 10 elements and @ary2 has 20 elements, the expression above is like $x = (10,20), and $x is assigned the number 20.

[reply]
Re: Re: Arrays: Last-index special variable vs. scalar values
by Dominus (Parson) on Nov 16, 2000 at 22:17 UTC
    Says tenatious:
    >It seems like if you evaluate a hash in scalar context, >i.e $x = (%hash); you get some funky fraction that doesn't mean much.
    It's in the manual what it means. (Check perldata.) Probably the most useful thing about it is that it is false if the hash is empty and true if the hash is not empty, so you can use this:

        if (%hash) {
      # it is not empty
    }

    [download]
    to test for an empty hash.

    But yes, the fraction is information about the internal structure of the hash, and not usually useful. It tells you how many of the hash structure's internal 'buckets' have been used. 11/32 means that there are 32 buckets, and 11 of the buckets have some data in them.

    Low-valued fractions mean that Perl's hashing algorithm is performing badly and the hash will have slower access. What you really want here is for the numerator of the fraction to be exactly equal to the number of keys in the hash. When this happens, every key has its own bucket and looking up keys is fast. When many keys are in the same bucket, Perl has to spend time searching through all the keys in the bucket looking for the one you want.

    I have a program somewhere that exercises the worst-case behavior for Perl's hashes: It constructs a hash that has 10,000 keys, all of which are in the same bucket. Accessing this hash is very slow! The program looks at the funny fraction returned by %h in scalar context to check to make sure it is going the right thing. If the numerator of the fraction ever climbs above 1, the program knows that something has gone wrong!

[reply]
[d/l]

In Section Seekers of Perl Wisdom