Do you perhaps want fast lookups of the prices?

Yes, exactly. This actually a rewrite of another script. The orginal programmer used a long series of if/elsif statements. This is how I cleaned it up.

This way, there's no need to store two versions of the key.

The real problem comes like this:

use CGI qw(:standard);
my $input_item = param('item') || 0;
my $subtotal;
my $item_name;
if(exists $ITEMS{$input_item}) {
   $subtotal = $input_item;
   $item_name = $ITEMS{$input_item};
}
[download]

----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer

Note: All code is untested, unless otherwise stated

Hmmm, I think robartes is on to something, the main problem is that you are using a price as a key. It only happens to work because all the prices are different, which is hardly a logical necessity. If at all possible, change the web page so that you use some artificial key, from which you can look up the name and the price.

You could try canonicising (sp? Heck, is that even a word?) the prices before storing them, e.g. like so:

my $key = sprintf("%0.4f", $price);
$items{$key}=$item;
[download]

You basically force the numbers in a certain format (rounded to 4 decimals and zero padded in this case). That way, you are guaranteed that 45.20 and 45.2 will end up as 45.2000 and thus in the same hash entry.

Now remind me again why you want to put the prices in the keys? What happens if you have two items with equal prices?

CU
Robartes-