Tom Christiansen [EMAIL PROTECTED] writes:
keys %HASH = LIST;
is really
@HASH{ LIST } = ();
Hmm, is it?
I'd expect the first form to set the keys, meaning that the hash will
have _only_ the indicated keys.
The second form will only add the keys, making sure they exist, and
not
Tom Christiansen [EMAIL PROTECTED] writes:
I don't want a set representation. I want set operations. And somehow
for this having to add a use statment and who knows what overhead for
what seems to be a simple operation is a pain.
The overhead is not that it should be a module, but rather,
"TC" == Tom Christiansen [EMAIL PROTECTED] writes:
Basically a hash with
only the keys, no other baggage.
TC If you don't want but the keys, don't use but the keys.
Does that mean, that none of the other bookeeping for the values will
be done?
Is this "@hash{@keys};" valid?
Would it be
Tom Christiansen wrote:
I don't want a set representation. I want set operations. And somehow
for this having to add a use statment and who knows what overhead for
what seems to be a simple operation is a pain.
The overhead is not that it should be a module, but rather,
the
Gael Pegliasco wrote:
So what if the man wants
@foo = @bar union @baz;
@foo = @bar intersetcion @baz;
This is a lot more of a direct map than the twiddling with hashes.
How are you drawing the line. Where does giving the user more power
than a turing machine stop.
At what point do you feel a new operator is not justified? Why do
we need grep/map, just use for? Why have =, cmp, just use ?:
So what if the man wants
@foo = @bar union @baz;
@foo = @bar intersetcion @baz;
This is a lot more of a direct map than the twiddling with
The underlying problem is that arrays don't make SENSE as an
implementation for sets.
And even in those rare places where they do, to use them as such
is gratuitously counter-efficient.
--tom
Eric Roode [EMAIL PROTECTED] writes:
[...]
The underlying problem is that arrays don't make SENSE as an
implementation for sets. What is the value of:
(1, 2, 3, 1, 2, 3) union (2, 3, 4, 5) ?
is it (1, 2, 3, 4, 5)? is it (1, 2, 3, 1, 2, 3, 4, 5)?
But all of the following DO
Ariel Scolnicov wrote:
Eric Roode [EMAIL PROTECTED] writes:
[...]
The underlying problem is that arrays don't make SENSE as an
implementation for sets. What is the value of:
But all of the following DO make sense as implementations for sets,
depending on your application:
* Sorted lists
"TC" == Tom Christiansen [EMAIL PROTECTED] writes:
TC General cases should be preferred over special ones.
TC We've never had named aggregate functions in Perl before that work
TC like infix operators. What is the general proposal out of which this
TC would intuitively decend?
Sorry, I'm not
At what point do you feel a new operator is not justified? Why do
we need grep/map, just use for? Why have =, cmp, just use ?:
So what if the man wants
@foo = @bar union @baz;
@foo = @bar intersetcion @baz;
This is a lot more of a direct map than the twiddling with
"TC" == Tom Christiansen [EMAIL PROTECTED] writes:
The underlying problem is that arrays don't make SENSE as an
implementation for sets.
TC And even in those rare places where they do, to use them as such
TC is gratuitously counter-efficient.
Why? How is
@main_list = ;
"AS" == Ariel Scolnicov [EMAIL PROTECTED] writes:
AS They're going to be useful to a tiny minority of users: math folks
AS whose application matches the use of a hash-based implementation.
AS (Actually, all uses I've seen of set datatypes were strictly outside
AS mathematics, but that doesn't
Chaim Frenkel wrote:
TC And even in those rare places where they do, to use them as such
TC is gratuitously counter-efficient.
Why? How is
@main_list = ;
@more_stuf = ;
@just_to_do_a_job{@main_list} = ();
@just_to_do_a_job{@more_stuff} = ();
"TC" == Tom Christiansen [EMAIL PROTECTED] writes:
The underlying problem is that arrays don't make SENSE as an
implementation for sets.
TC And even in those rare places where they do, to use them as such
TC is gratuitously counter-efficient.
Why? How is
@main_list = ;
I don't want a set representation. I want set operations. And somehow
for this having to add a use statment and who knows what overhead for
what seems to be a simple operation is a pain.
The overhead is not that it should be a module, but rather,
the sillily/evilly inefficient thing that *you*
I'm not understaning your position.
We don't have very long names for function names. Our functions
scan left to right, although our postfix modifiers alter that
picture. And something like "union" or "intersection", long and
alphabetic, certainly looks like a function name.
My position is
We don't have very long names for function names.
s/function/operator/
Tom Christiansen wrote:
General cases should be preferred over special ones.
Perl is diagonal. No preferences should be prejudicially deemed
exclusive.
We've never had named aggregate functions in Perl before that work
like infix operators. What is the general proposal out of which this
I need it as a sorted array 90% of the time. Some of
the time I need/want to add a unique element. So, what do I do, keep
it as an array and sort every time I access it? Keep two copies one as
the hash the other as an array?
Yep. This is *not* a glaringly common data structure. I can think
of
But a Hash isn't the correct data structure either. It just has some,
of the correct properties.
Whatever.
Perhaps we should add a Set to the toolkit. Basically a hash with
only the keys, no other baggage.
Define "toolkit".
But you still would argue against the operators/functions? Ignoring
Basically a hash with
only the keys, no other baggage.
If you don't want but the keys, don't use but the keys.
--tom
"TC" == Tom Christiansen [EMAIL PROTECTED] writes:
TC The overhead is not that it should be a module, but rather,
TC the sillily/evilly inefficient thing that *you* are doing.
TC Or trying to do.
Why, For example, I need it as a sorted array 90% of the time. Some of
the time I need/want to
"TC" == Tom Christiansen [EMAIL PROTECTED] writes:
Both have to go through the same amount of work ("work is conserved")
but one is more efficient in terms of the user's brainpower.
TC Only if you made the mistake of using the wrong data structure all
TC along -- that is, an array.
But a
"TC" == Tom Christiansen [EMAIL PROTECTED] writes:
But, Do you really think that all these ingenuities, to not use another
term, are really natural and easy to understand to novice programmers ?
TC Until you start thinking of terms of hashes, you aren't thinking
TC in Perl. It serves no
David L. Nicol wrote:
For sets, hashes are a better perl representation.
I think you must have missed some of this discussion.
Rather than reiterate my contributions, I'll point you into the archive:
http://www.mail-archive.com/perl6-language%40perl.org/msg03425.html
Eric Roode wrote:
Adjust your thinking a bit, not the language. Try:
%my_fruit_set = (orange = 1, lemon = 1);
or
@my_fruit_set{qw/orange lemon/} = ();
Yes, probably, this could be easiest... :)
But, maybe because I'm a mulish person, I still thinking that if we
actually use such
Tom Christiansen wrote:
Until you start thinking of terms of hashes, you aren't thinking
in Perl. It serves no good to delay this epiphany. Also, remember
that being a "novice" is a temporary and curable condition. Perl
is designed to for long-term ease of use, not short-term learn-free
Buddha Buck wrote:
In a hash implementation, your hash keys -are- your set elements!
my %set;
# add elements to %set
$set{'elem1','elem2'} = 1;
# Compute union
$union{keys %set1, keys %set2} = 1;
Oh, yeah, using native hashes for sets -- what could be simpler?
(Hint:
If it were possible to assign to the keys of a hash, we'd be
a lot closer to our ideal:
keys(%intersection) = map { exists $set1{$_} ? ( $_ = 1 ) : () } keysSNIP
but this is not currently legal perl.
keys %HASH = LIST;
is really
@HASH{ LIST } = ();
--tom
I wonder if it might not be a good idea to implement a function to
compute the intersection of two sets-as-hashes.
Intersection is the only basic set function that's not trivially
implementable with perl hashes. Sure, it's not hard to do, with
a loop and a small bit of programming, but maybe
Gael Pegliasco wrote:
First is the choice of arrays verses hashes as the choice for set
storage.
Arrays are obviously easier to construct, but hashes are both faster
implementations, and easier to determine membership.
Well in fact I'm interested by such functions in order to manipulate
Arrays are ordered.
Hashes are not.
Neither are sets.
Arrays can have repetitions.
Hashes can not.
Neither can sets.
etc.
--tom
Yes, this is true, but the natural syntax, for me, to manipulate sets,
is the one of arrays.
It is not natural to write :
Gael Pegliasco wrote:
Yes, this is true, but the natural syntax, for me, to manipulate sets,
is the one of arrays.
It is not natural to write :
%my_fruit_set = ( 1 = 'orange', 2 = 'lemon' );
but it is natural to write :
@my_fruit_set = ( 'orange', 'lemon' );
I don't want to have to deal
At 03:40 PM 9/1/00 +0200, Gael Pegliasco wrote:
Arrays are ordered.
Hashes are not.
Neither are sets.
Arrays can have repetitions.
Hashes can not.
Neither can sets.
etc.
--tom
Yes, this is true, but the natural syntax, for me, to manipulate sets,
The point is that a hash of booleans (not a list of hashes) is a more direct
way to implement a set. A set is unordered, and does not have duplicates.
This is also true of hash keys. Furthermore, the nature of a hash makes it
faster and easier to check for the existance of a key, which is
I don't care about keys when I'm working with sets, and I don't want to
have to deal with them.
Then, if when implementing these new functions in perl6 you choose to
use an invisible hash table, ok, I don't care, but when writing my perl
script I don't want to deal with hash tables for
Which kind of "difference"?
Next, what subset of the set-theory should be implemented. Obviously you
refer to the basic and / or / xor, but in real practice, the other operators
can be very useful. Chaining operators (especially with array-based-sets)
can be a performance nightmare.
Unless you use bitwise operators on
39 matches
Mail list logo
