Re: Vectorizing operators for Hashes
--- Larry Wall <[EMAIL PROTECTED]> wrote: > On Thu, 31 Oct 2002, Markus Laire wrote: > The really great thing about the French quotes is that they visually > keep the user aware of the composition. «+=» is obviously a variety > of > +=, whereas ^+= is not obvious, though shorter. (Square brackets are > even better at that, but have other problems.) I'm still unconvinced that square brackets won't work. But compared to Larry giving up «foo bar baz», «sont petits pommes de terre» __ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/
Re: Vectorizing operators for Hashes
> temp sub infix:^[] is force_hash_to_intersect ; Right. A property used as you suggest is effectively an adverb applied at op definition rather than use. > maybe somebody will wont ( 1,2 ) ^[op] ( 1, 2, 3 ) to return array of > length 3 ; Right. It's quite plausible that one would want to be able to control this at op use, rather than definition. -- ralph
Re: Vectorizing operators for Hashes
Me writes: > > > > > union: > > > > > intersection : > > > > > > > > %a ^is strict_keys; > > > > %b ^is no_strict_keys; > > > > in the resulting hash only ( and all ) keys of %a will be present. > > because %b *admits* unknown keys but %a does not. > > Yes, but the general case is that one wants to be > able to control nuances of (hyper)operations, and > Larry introduced adverbs for precisely that reason. > > Just because one can get away with controlling this > particular issue via noun adjectives (variable properties) > does not mean one should. (Although, conversely, just > because adverbs seem more more appropriate in this > case doesn't mean one shouldn't for some reason use > properties as you suggest.) > there is one mor epossibility : temp sub infix:^[] is force_hash_to_intersect ; ( I'm compleatly not sure about that sintax ) sinse "vectorization" of any op is orthogonal concept to details of that particular op , maybe we can controll behavior of that vectorization by ( ...? ) properties . we need it not only for hashes ; maybe somebody will wont ( 1,2 ) ^[op] ( 1, 2, 3 ) to return array of length 3 ; arcadi
Re: Vectorizing operators for Hashes
> On Thu, 31 Oct 2002, Me wrote:
> : That's one reason why I suggested control of this sort
> : of thing should be a property of the operation, not of
> : the operands.
>
> I think that by and large, the operator knows whether it wants to
> do union or intersection. When you're doing +, it's obviously
> union that you want, with undef defaulting to 0. And // would
> want intersection.
Ok. So I accidentally got something right! ;> ("control of this sort of
thing should be a property of the operation, not of the operands.")
There are clearly some operations where adverbs make sense.
Presumably one of the classes of op for which adverbs might
make sense is hyperop.
Assuming so, did my suggestion of ^adverb make sense to you
as a way to distinguish op and hyperop adverbs?
--
ralph
Re: Vectorizing operators for Hashes
Larry Wall writes: > On Thu, 31 Oct 2002, Me wrote: > : That's one reason why I suggested control of this sort > : of thing should be a property of the operation, not of > : the operands. > > I think that by and large, the operator knows whether it wants to > do union or intersection. When you're doing «+», it's obviously > union that you want, with undef defaulting to 0. And «//» would > want intersection. > > Larry > > > so is really going to the direction that many "official" operators will be "wysiwig" Unicode staff like «+» , and then for some slice of the comunity there will be ( TeX - like ?? ) ascii shortcuts , because we need them ( what was the length of the tread to figure out how to write and read them ) . So perl take placeholders from Mathematica , vector operations from Matlab , and greek and all other funny characters from TeX : use TeX; @\gamma = @\alpha \hyper[\sum] @\beta ; arcadi .
Re: Vectorizing operators for Hashes
Me writes: > > > union: > > > intersection : > > > > How would this work for hashes with differing properties? > > > > %a ^is strict_keys; > > %b ^is no_strict_keys; > > > > What would happen? > in the resulting hash only ( and all ) keys of %a will be present. because %b *admits* unknown keys but %a does not. although I admit that property names can be much better . > That's one reason why I suggested control of this sort > of thing should be a property of the operation, not of > the operands. > > -- > ralph > > arcadi .
Re: Vectorizing operators for Hashes
Austin Hastings writes: > > but I am not shure ... > > "sure" > thanks . sorry that I write so badly . I'll try to be better . > (Unless you do this on purpose :-) > > Cheers, > > =Austin > > __ > Do you Yahoo!? > HotJobs - Search new jobs daily now > http://hotjobs.yahoo.com/ > >
Re: Vectorizing operators for Hashes
Austin Hastings writes:
>
> --- [EMAIL PROTECTED] wrote:
> > I agree. But I think that we can get away here with just hash
> > properties , just like hash behaviour in is controlled by
> > properties .
> >
> > e.g.
> > union:
> >
> > (%a,%b) ^is no_strict_keys ;
> > (%a %b) ^is default_value ( 0 ) ;
> > %a ^[+] %b
> >
> > intersection :
> >
> > (%a,%b) ^is strict_keys ;
> > %a ^[+] %b
> >
> >
> > this maybe longer but clear : one line - one concept .
>
> Arcadi,
>
> How would this work for hashes with differing properties?
>
> E.g.,
>
> %a = ("apple" => 1, "abacus" => 2);
> %b = ("banana" => 3, "abacus" => 2);
>
> %a ^is strict_keys;
> %b ^is no_strict_keys;
>
> %c = %a ^[+] %b;
>
> What would happen?
in the result hash there will be only keys of %a, because
%b *can admit unknown keys*, but %a - cannot
>
> %a rules?: %c == ("abacus" => 4)
> %b rules?: %c == ("apple" => 1, "abacus" => 4, "banana" => 3)
> strict_keys filters result?: %c == ("apple" => 1, "abacus" => 4)
>
> =Austin
>
arcadi
Re: Vectorizing operators for Hashes
On Thu, 31 Oct 2002, Markus Laire wrote: : I don't think there should be any upper limit for operator-lengths. There will never be any official limits. Perl is not about arbitrary limits. But I will tell you that I only added <=> to Perl 5 because I knew there would never be a <=>= operator. We'll have to relax that a bit for Perl 6, but we're still trying vaguely to avoid the Icon trap. Only compositions of operators will be allowed to get longer than 3 chars. And we try to keep the basic operators at 2 or less. The really great thing about the French quotes is that they visually keep the user aware of the composition. «+=» is obviously a variety of +=, whereas ^+= is not obvious, though shorter. (Square brackets are even better at that, but have other problems.) Larry
Re: Vectorizing operators for Hashes
On Thu, 31 Oct 2002, Me wrote: : That's one reason why I suggested control of this sort : of thing should be a property of the operation, not of : the operands. I think that by and large, the operator knows whether it wants to do union or intersection. When you're doing «+», it's obviously union that you want, with undef defaulting to 0. And «//» would want intersection. Larry
Re: Vectorizing operators for Hashes
> > union: > > intersection : > > How would this work for hashes with differing properties? > > %a ^is strict_keys; > %b ^is no_strict_keys; > > What would happen? That's one reason why I suggested control of this sort of thing should be a property of the operation, not of the operands. -- ralph
Re: Vectorizing operators for Hashes
--- [EMAIL PROTECTED] wrote:
> I agree. But I think that we can get away here with just hash
> properties , just like hash behaviour in is controlled by
> properties .
>
> e.g.
> union:
>
> (%a,%b) ^is no_strict_keys ;
> (%a %b) ^is default_value ( 0 ) ;
> %a ^[+] %b
>
> intersection :
>
> (%a,%b) ^is strict_keys ;
> %a ^[+] %b
>
>
> this maybe longer but clear : one line - one concept .
Arcadi,
How would this work for hashes with differing properties?
E.g.,
%a = ("apple" => 1, "abacus" => 2);
%b = ("banana" => 3, "abacus" => 2);
%a ^is strict_keys;
%b ^is no_strict_keys;
%c = %a ^[+] %b;
What would happen?
%a rules?: %c == ("abacus" => 4)
%b rules?: %c == ("apple" => 1, "abacus" => 4, "banana" => 3)
strict_keys filters result?: %c == ("apple" => 1, "abacus" => 4)
=Austin
__
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/
Re: Vectorizing operators for Hashes
Me writes: > > > %a ^:union[op] %b > > > > > > %a :foo[op]:bar %b > > > > I think that any operators over 10 characters should > > be banished, and replaced with functions. > I agree. But I think that we can get away here with just hash properties , just like hash behaviour in is controlled by properties . e.g. union: (%a,%b) ^is no_strict_keys ; (%a %b) ^is default_value ( 0 ) ; %a ^[+] %b intersection : (%a,%b) ^is strict_keys ; %a ^[+] %b this maybe longer but clear : one line - one concept . but I am not shure ... arcadi .
Re: Vectorizing operators for Hashes
Uri Guttman writes:
>
> %hash1.values [+]= %hash2{%hash1.keys} ;
>
but here is exactly example analogous to
my Dog $x = new Dog .
which was discusse dand turned to
my Dog $x .= new ;
It's (almost) clear what you want when you write
%hash1 [+]= %hash2 ;
so why to screen the meaning with several ( almost ) unnecessary
words .
And besides, If that will be usefull there will be somebody who will
make those shortcuts.
aracdi .
Re: Vectorizing operators for Hashes
On 31 Oct 2002 at 0:40, John Williams wrote: > On Wed, 30 Oct 2002, Me wrote: > > > %a ^:union[op] %b > > > > %a :foo[op]:bar %b > > I think that any operators over 10 characters should be banished, and > replaced with functions. I don't think there should be any upper limit for operator-lengths. e.g. When teaching perl to my little brothers (still at primary school) I might want to use alphabetical userdefined operators: print 1 + 5 - 4 / 2 print one plus five minus four divided_by two (and same in finnish) näytä yksi plus viisi miinus neljä jaettuna kaksi At least it wouldn't harm anyone to allow this. -- Markus Laire 'malaire' <[EMAIL PROTECTED]>
Re: Vectorizing operators for Hashes
> > %a ^:union[op] %b > > > > %a :foo[op]:bar %b > > I think that any operators over 10 characters should > be banished, and replaced with functions. I'd agree with that. In fact probably anything over 4, and even 4 is seriously pushing it. I'll clarify that I am talking here about using adverbs. >From A3 (about the colon): Hence, this operator modifies a preceding operator adverbially. ... It can be used to supply a ``step'' to a range operator, for instance. I would expect the length of these adverbs to fall in a range somewhat the same as properties. So a word like 'union' is reasonable, and even 'intersection' too. Ignoring hyperoperators, one might use an adverb thus: $a / $b : dbz_Inf to have a divide by zero be treated as Infinity. I can see scope for a bunch of adverbs that control how a particular hyperoperation works. Thus, perhaps: @a ^[/] @b : short to stop iteration when the shortest of two arrays is used up. But this assumes that the adverb applies to the ^[] hyperop, not the / op. Perhaps this is resolved thus: @a ^[/ : dbz_Inf] @b : short But I also suspect it would be good to be able to associate distinct adverbs with the lhs and rhs of a binary operation. So I thought perhaps one could go down the path of @a ^ :step(2) [/ : dbz_Inf] :step(3) @b : short Hmm. Perhaps hyperop adverbs are preceded with a ^ and one gets instead: @a ^[/] @b : dbz_Inf, ^short, ^step(2,3) -- ralph
Re: Vectorizing operators for Hashes
On Wed, 30 Oct 2002, Me wrote: > %a ^:union[op] %b > > %a :foo[op]:bar %b I think that any operators over 10 characters should be banished, and replaced with functions. ~ John Williams
Re: Vectorizing operators for Hashes
> "fc" == <[EMAIL PROTECTED]> writes:
fc> So is it usefull to make sence out of these :
fc> hash ^[op] hash
fc> hash ^[op] array
fc> hash ^[op] scalar
fc> array ^[op] array
fc> array ^[op] scalar
well, you can't mung the keys to a hash, just the values. so why not
just use the values method as an [lr]value? this works already in perl5.
%hash.values [+]= 10 ;
%hash1.values [+]= %hash2.values ;
now that may fail as the order of the values would be different so use a
slice:
%hash1.values [+]= %hash2{%hash1.keys} ;
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
- Stem and Perl Development, Systems Architecture, Design and Coding
Search or Offer Perl Jobs http://jobs.perl.org
Re: Vectorizing operators for Hashes
> hash ^[op] hash > ... > array ^[op] scalar ie, generally: term ^[op] term > what to do if @a, @b in @a ^[op] @b have different length > what to do if %a, %b in %a ^[op] %b have not the same set of keys > what to do in %a ^[op] @a > > [what to do] resolved by hash property : I'd expect adverbs rather than adjectives for these sorts of issues, ie ':' modifiers of vectorization rather than use of variable/value properties. > @a ???[op] @b = [ array of @a[x] op @a[y] for all pairs x,y ] > > this path have no end, but where to stop ?? b4p6>J! ;> (http://jsoftware.com/) Seriously, I also think it's worth seeing where this goes. As noted above, I'd expect use of adverbs to allow modification of hyperactivity: %a ^[op] %b : union Of course, this suffers the obtw problem. An alternative might be: %a ^:union[op] %b I can definitely see scope for wanting separate adverbs to influence how vectorization works on the lhs and rhs. Perhaps %a :foo[op]:bar %b where I'm assuming :[op] instead of ^[op] as the base syntax for vectorization. -- ralph
Re: Vectorizing operators for Hashes
So is it usefull to make sence out of these :
hash ^[op] hash
hash ^[op] array
hash ^[op] scalar
array ^[op] array
array ^[op] scalar
Actually ,
I just want to understand , why so much accent is put on vectorizing
atomic operations with arrays . It seems that hashes are at least as
frequent . And automating operations on them may be just as usefull.
( my feeling is that the reason is not the same as in Matlab and such
.. Because it begin to look like Matlab .
)
with arrays we have to resolve the question :
what to do if @a, @b in @a ^[op] @b have different length
with hashes we will have this question
what to do if %a, %b in %a ^[op] %b have not the same set of keys
we can resolve it with properties on hashes.
%a is vector_intersect
%a is vector_unify
Now we have also this question :
what to do in %a ^[op] @a
this again can be resolved by hash property :
%a is vector_maptoindex { return int rand }
I am not shure we need all this ( and in this form ) , but if
vectorizing array operations make operators so heavy , we have to
probably take a ride on it. I dont know. Or probably to go on that
path we should introduce tenzor operators . There was a discussion
about Sets .
how about having
@a ???[op] @b = [ array of @a[x] op @a[y] for all pairs x,y ]
this path have no end, but where to stop ??
arcadi.
Re: Vectorizing operators for Hashes
!! Sorry, in previos post I had a mistake
Proposal : Vector operations for Hashes
(
this is just a joke
%a ^{+} %b
)
the direct generalization would be as follows :
@a ^[op] @b
for @a ; @b ->
$x ; $y {
$x op $y
}
%a ^[op] %b
# find common keys
@k = keys hash{ map { { _=>1 } } *( %a.keys , %b.keys ) };
#return hash
hash {
for @k -> $x {
{ $x => %a{$x} op %b{$x} }
}
}
so in words , find common keys and then vectorize op as if
hash keys are array indexes.
Probably that behaviour may be tuned or conrolled by properties of
hashes just like what happens inside .
maybe this could be made more general , since
Larry noted that junctions ( 1 | 2 | 3 ) are similar to hashes
> %hash = ( 1 | 2 | 3 ) ;
dont have any Idea how.
arcadi.
Re: Vectorizing operators for Hashes
On Wed, 30 Oct 2002 [EMAIL PROTECTED] wrote:
: # find common keys
: @k = keys hash{ map { { _=>1 } } *( %a.keys , %b.keys ) };
It seems a bit odd to privilege the intersection over the union.
Larry
Re: Vectorizing operators for Hashes
Proposal : Vector operations for Hashes
%a ^{+} %b
the direct generalization would be as follows :
@a ^[op] @b
for @a ; @b ->
$x ; $y {
$x op $y
}
%a op %b
# find common keys
@k = keys hash{ map { { _=>1 } } *( %a.keys , %b.keys ) };
#return hash
hash {
for @k -> $x {
{ $x => %a{$x} op %b{$x} }
}
}
so in words , find coomon keys and then vectorize op as if
hash keys are array indexes.
Probably that behaviour may be tuned or conrolled by properties of
hashes just like what happens inside .
maybe this could be made more general , since
Larry noted that junctions ( 1 | 2 | 3 ) are similar to hashes
> %hash = ( 1 | 2 | 3 ) ;
dont have any Idea how.
arcadi.
