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
> "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?
Wou
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 sill
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
>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
>I'm not ignorant of the technology. But having a method that directly
>represents my thought process, and does something that I need would be
>a win for me.
Adding to the core infinitely more new functions in an environment
with people screaming to yank stuff out, and still worse, adding
new inh
> "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
>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
>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? Ignori
> "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 arra
>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
>> "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_l
> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
Thanks for the summary. (I wish you would be able or have the time to
exand more often on your positions.)
TC> I think you still have some big hurdles here, however. Lists are
TC> crappy set reps.
I don't want a set representation. I w
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} = ();
>
>
> "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
> "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 =
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 t
>We don't have very long names for function names.
s/function/operator/
>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
> "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?
Sorr
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:
>
>*
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 follow
>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
>> 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
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
> 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 twiddli
> "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 s
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
http://www.mail-
>
> =head1 ABSTRACT
>
> When programming in perl we need really often to calculate
> union, intersection, difference between arrays. It will be
> cool if such functions could be part of the perl6 language.
Arrays/Lists are ordered, sets are not.
For sets, hashes are a better perl representati
The thing is that so far, Perl has survived on extremely simple
variable types:
SCALAR: singular generic values
ARRAY: ordered lists of SCALARs
HASH: unordered association of SCALARs
Sure, you have special-purpose accessors like the "%" operator or
s/// or pop or exists or even v
Eric Roode wrote:
> 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 bi
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 it
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-fre
>But, Do you really think that all these ingenuities, to not use another
>term, are really natural and easy to understand to novice programmers ?
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 "novi
John Porter wrote:
>
> 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
>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 ) : () } keys
>but this is not currently legal perl.
keys %HASH = LIST;
is really
@HASH{ LIST } = ();
--tom
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:
@s
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
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, fo
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 ha
>
> 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 w
Also: have you looked at what's on CPAN for handling sets?
Here's a casual search result:
Math::Expr::MatchSet Set::Scalar
Math::Expr::VarSet Set::Scalar::Base
ObjStore::SetSet::Scalar::Null
ObjStore::SetEmulation Set::Scalar::Real
Set
>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 arrays
> 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
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 manip
> 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
lists
of scalars (1, 'to
>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
> More functions from set theory to manipulate arrays
>
> I'd like to use these functions in this way :
>
> @c = union (@a, @b);
> # wich is different from @c = (@a, @b) because union do not duplicate
> same elements
>
> @c = intersection (@a, @b);
> @c = diff(@a, @b);
>
Elements of this ar
Which kind of "difference"?
49 matches
Mail list logo
