Re: The error says the value is uninitialized, but it works anyway

As a general rule, you should avoid changing an array you are iterating over. That's bound to cause all kinds of headaches. Also, it is favourable to name variables by what they mean, not by what they contain. Here, $num is a bad name. $index is better, so are $i, $j, $k, etc.

Here's my stab at the problem.

use strict;
use warnings;

my @colors = qw(red green blue yellow pink purple brown);
my @drop = qw(pink brown);


foreach my $drop_color (@drop)
{  
    my $index = 0;
    foreach my $color (@colors)
    {
        if ( $color eq $drop_color )
        {        
            splice (@colors, $index, 1);
            last;
        }
        $index++;
    }
}
print "@colors \n";
[download]

Besides being clearer, this also works with n elements in whatever array, whereas your solution hardcodes two elements in the @drop.

holli

You can lead your users to water, but alas, you cannot drown them.

Comment on Re: The error says the value is uninitialized, but it works anyway Select or Download Code

Replies are listed 'Best First'.
Re^2: The error says the value is uninitialized, but it works anyway by jcb (Parson) on Aug 19, 2019 at 00:42 UTC
It is probably worth noting here that `$i`, `$j`, `$k`, `$l`, and so on are only good loop iteration variables because of the sheer weight of the long-standing convention of using them that way. As far as I know, this convention originated with the C programming language, although the fact that `I`, `J`, `K` and some others default as integers in FORTRAN suggests that it is older than C. These variables are probably best used when your iteration variables will have integer values, as that is also a (weaker) long-standing convention. In the example that started this discussion, the iteration was over the positions in an array, which are integers in Perl. If you are iterating over the values of an array, as in the solution presented by holli above, you should use a descriptive iterator variable as holli did. The solution holli presented also illustrates another problem: algorithmic complexity. Nested loops are usually the slowest practical way to solve a problem, and when you see such a construction, you should consider if there is a better way, and explicitly checking two elements of `@drop` is really just an unrolled nested loop. (See also: Loop unrolling) On modern hardware, the issue will be unnoticeable until you are trying to process large amounts of data, and then your program will suddenly be horrendously slow. For more enlightenment on this, analyze the expected running time of the various solutions here and then run actual benchmarks with both the small data set given in the original assignment and some (much) larger generated data sets, with hundreds, thousands, tens of thousands, hundreds of thousands, and millions of items.	[reply] [d/l] [select]
Re^3: The error says the value is uninitialized, but it works anyway by AnomalousMonk (Archbishop) on Aug 19, 2019 at 17:27 UTC
... algorithmic complexity. See Analysis of algorithms. Give a man a fish: `<%-{-{-{-<`	[reply] [d/l]
Re^3: The error says the value is uninitialized, but it works anyway by soonix (Canon) on Aug 19, 2019 at 08:36 UTC
I think usage of i, j, k for indexes is older, `FOR`mula`TRAN`slator is oriented towards mathematical notation. However, in homework tasks for beginners, loop unrolling is less likely in the curriculum, and my guess is that it's all about ~~that bass~~ nested loops. All the other solutions given so far won't work if `@drop` has more or less that two elements…	[reply] [d/l] [select]


Come for the quick hacks, stay for the epiphanies.
	PerlMonks