Skip to content

Commit

Permalink
Browse files Browse the repository at this point in the history
Spec .min/.max on Bags
  • Loading branch information
@lizmat
lizmat committed Apr 13, 2014
1 parent 9e5a70e commit 9213b13
Showing 1 changed file with 2 additions and 1 deletion.
3 changes: 2 additions & 1 deletion S32-setting-library/Containers.pod
View file
Expand Up @@ -1261,7 +1261,8 @@ A collection of values or objects that work just like sets, except
that they need not be unique. The count of each value or object is
represented by an associative mapping from each key value/object to its
replication number. The C<.total> method returns the sum of all
replication values.
replication values. The C<.min> and C<.max> methods return the minimum and
maximum replication number.

Sets and bags do not flatten into list context, nor do the constructors
interpolate items passed to them, even if they look like sets or bags.
Expand Down

7 comments on commit 9213b13

@colomon
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there an argument that .min should always return 0? It would be very weird if

("a" => 10, "b" => 0).Bag.min

equaled 10....

@quietfanatic
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since that bag is supposed to represent a collection of 10 "a"s, I'd expect .min to return "a".

@Benabik
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, return 10 anyway.

While it may seem odd when you say ("a"=>10,"b"=>0).Bag.min, it might make more sense if you look at ("a"=>$num_a, "b"=>$num_b).Bag.min. If $num_b is zero, there's none of them in the bag and they don't matter for min.

@colomon
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To put it a slightly different way, consider

> my $bh = ("a"=>10, "b"=>1).BagHash
> say $bh.min
1
> $bh<b>--
> say $bh.min
10

@raiph
Copy link
Contributor

@raiph raiph commented on 9213b13 Apr 14, 2014

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All standard QuantHashs (BagHash, etc.) delete keys with value zero (or False etc.). This seems like classic perl think and here to stay. So colomon's example makes sense:

> my $bh = ("a"=>10, "b"=>1).BagHash
> say $bh.min
1
> $bh<b>--
> say $bh.min
10

But then consider:

> {a=>2,b=>1}.min.say
"a"=>2

So .min on a hash (currently in Rakudo) returns the min key, ignoring the value.

And:

> ("a"=>10, "b"=>10).BagHash.min.say 
10

returns the min value, but we've lost knowing there's two such keys.

Seems like there's design work to do.

If only there were a Damian around... ;)

@lizmat
Copy link
Contributor Author

@lizmat lizmat commented on 9213b13 Apr 14, 2014 via email

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@colomon
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also remembering that it's extremely easy to get the min value by just saying

$bag.values.min

(likewise for .keys and .pairs)

Please sign in to comment.