Re: cross operator and empty list
HaloO, Larry Wall wrote: (@a X @b X @c).elems == @a.elems * @b.elems * @c.elems Sorry, I was aiming at defining a neutral element of the X operator. In cartesian products of sets this is achieved by having a set that contains as sole member the empty tuple. So how would that be written? (()) perhaps? Or (;)? This would have (;).elems == 1 but (;),1,2 === (1,2). And it would be considered true in boolean context I guess. A more explicit notation might be () but .elems = 1. For anonymous arrays we already have [()].elems == 1, or not? The above might be a bit subtle, though. OTOH, it could save some surprises. Regards, TSa. -- The Angel of Geometry and the Devil of Algebra fight for the soul of any mathematical being. -- Attributed to Hermann Weyl
Re: cross operator and empty list
On Mon, Apr 7, 2008 at 4:50 AM, TSa [EMAIL PROTECTED] wrote: HaloO, Larry Wall wrote: (@a X @b X @c).elems == @a.elems * @b.elems * @c.elems Sorry, I was aiming at defining a neutral element of the X operator. A neutral element for the cross operator seems weird if that is to be compared with 0 for addition 1 for multiplication because the basic assumption would be an element N such that X op N = X This would require that the operator with a neutral element should be a mapping like: op : D x D - D which is not the case for the X operator X : Seq(D1) x Seq(D2) - Seq( D1 x D2 ) At the other hand, any sequence with one only member would define a result @a x ($any) that would be kind of isomorphically equivalent to @a itself. But, apart from that, I don't get the value of defining such a neutral element for the cross operator. Adriano In cartesian products of sets this is achieved by having a set that contains as sole member the empty tuple. So how would that be written? (()) perhaps? Or (;)? This would have (;).elems == 1 but (;),1,2 === (1,2). And it would be considered true in boolean context I guess. A more explicit notation might be () but .elems = 1. For anonymous arrays we already have [()].elems == 1, or not? The above might be a bit subtle, though. OTOH, it could save some surprises. Regards, TSa. -- The Angel of Geometry and the Devil of Algebra fight for the soul of any mathematical being. -- Attributed to Hermann Weyl
Re: cross operator and empty list
Adriano, I think perhaps what Tsa is trying to get at is the identity value
for the X operator, and I believe I know what it is.
In the relational model of data, both the version of the model where tuples
have unordered named attributes/elements (which I prefer), and the version
where tuples have ordered attributes/elements (which Perl 6 seems to be
using in its X operator), the relational cross product operator is
analogous to numeric multiplication or logical 'and' in its properties
(except that the ordered version isn't commutative).
With respect to relational join being like multiplication, the special
values 0 and 1 are represented by the nilary (zero attribute) relation with
either 0 or 1 tuples respectively, which in common Perl array-of-hash (or
array-of-array) notation for rowsets is
[]
and
[ {} ] or [ [] ]
respectively; I'll call them R0 and R1 for now. Joining any relation R
with R0 gives R0 (or alternately a relation with the same attributes as R
but zero tuples; its zero tuples either way), and joining any relation R
with R1 gives R.
So R1 is the identity value for cross product, meaning the identity value
for X, in Perl 6 would be a one-element array|seq whose element is the
empty array|seq. That is,
[X] ()
equals this:
( () )
Larry et al, on a related note, the list of identity values for reduce in
S03 should be updated to account for this; [X] wasn't on the list last I
looked.
-- Darren Duncan
Re: cross operator and empty list
Technically the Cartesian cross operator doesn't have an identity value. There
is no set X such that
A x X = A. Now any singleton set gives a result that is naturally isomorphic
to the original set, I.e, there is a obvious bijection between the two sets,
but they are not equal sets.
--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
-- Original message --
From: Darren Duncan [EMAIL PROTECTED]
Adriano, I think perhaps what Tsa is trying to get at is the identity value
for the X operator, and I believe I know what it is.
In the relational model of data, both the version of the model where tuples
have unordered named attributes/elements (which I prefer), and the version
where tuples have ordered attributes/elements (which Perl 6 seems to be
using in its X operator), the relational cross product operator is
analogous to numeric multiplication or logical 'and' in its properties
(except that the ordered version isn't commutative).
With respect to relational join being like multiplication, the special
values 0 and 1 are represented by the nilary (zero attribute) relation with
either 0 or 1 tuples respectively, which in common Perl array-of-hash (or
array-of-array) notation for rowsets is
[]
and
[ {} ] or [ [] ]
respectively; I'll call them R0 and R1 for now. Joining any relation R
with R0 gives R0 (or alternately a relation with the same attributes as R
but zero tuples; its zero tuples either way), and joining any relation R
with R1 gives R.
So R1 is the identity value for cross product, meaning the identity value
for X, in Perl 6 would be a one-element array|seq whose element is the
empty array|seq. That is,
[X] ()
equals this:
( () )
Larry et al, on a related note, the list of identity values for reduce in
S03 should be updated to account for this; [X] wasn't on the list last I
looked.
-- Darren Duncan
Re: cross operator and empty list
[EMAIL PROTECTED] wrote: Technically the Cartesian cross operator doesn't have an identity value. There is no set X such that A x X = A. Now any singleton set gives a result that is naturally isomorphic to the original set, I.e, there is a obvious bijection between the two sets, but they are not equal sets. If you were talking about ordinary set operators, then what you say is probably true. However, my solution was specific to the relational model of data, whose operators correspond to a superset of plain set operators. In this context, when I say plain set operators, I mean things like: union (or|add) intersection (and|multiply) difference symmetric difference (xor) and in the relational model, each of those operators requires their input relations to have the same headings, that is their tuples are all of the same degree and have the same attribute names, and so the headings of the results match both of the inputs. Extra operators in the relational model that aren't in the plain set include: natural join (and|multiply) cartesian product is a special case intersection is a special case semijoin is a special case semidifference divide (divide) These extra operators are effectively working in 2 dimensions, where one dimension is the set of tuples, and the other is the elements per tuple. Also, every tuple element can itself be any type, either scalar or tuple or relation. And that feature is orthogonal to the 2 dimensions I mentioned. Given this context, the identity value of relational join or cross product was specifically a 2-dimensional value. This said, the identity value of joining 2 tuples still goes under the same principle, even though that is a 1-dimensional operation. Joining any tuple T with a tuple having zero elements is the first tuple T. Since the normal output of X is 2-dimensional, it stands to reason that ( () ) should be a reasonable identity value for X, I think. -- Darren Duncan
Protected data member access considered harmful
Larry Wall wrote: How private is private? I wonder if what you've called private things are really more like protected in C++ (accessible by the derived class) and that 'my' attributes are really private, as are submethods. It's all confused. Who is allowed to access what? No, private methods are not accessible from derived classes, unless the base class explicitly trusts them -- See L12/the exclamation form may be used only in the actual class, not in derived classes. Cheers, Audrey It is my understanding that even Bjarne thinks protected is a bad idea these days... Larry I believe Mr. Stroustrup's deprecation of 'protected' access applies only to data data members, not function members: Fortunately, you don't have to use protected data in C++; 'private' is the default in classes and is usually the better choice. Note that none of these objections are significant for protected member *functions*. I still consider 'protected' a fine way of specifying operations for use in derived classes. -- Bjarne Stroustrup _The_Design_and_Evolution_of_C++_ Section 13.9 [Protected Members] So I understand Perl 6 will have no protected access for data members (though trusted access can be used to provide a similar back door). But does Perl 6 have protected access for methods? =thom
What I'm Working On
I'm taking a stab at turning the S\d\d documents into a formal standard. Going through S02, each factoid gets filed away in a developing outline. I'm using a single ODT file to make it easy to manipulate the outline (currently mostly stubs). Here is an early effort to flesh out imprecise specification, and identify all the needed details. I'm not worried about disagreement, since it is easier to edit than to compose. But identifying and listing such details that need to be addressed will be my contribution, and serve as a straw-man for others to pick at. Here is a sample: http://www.dlugosz.com/files/1.pdf --John
Re: Protected data member access considered harmful
Thom Boyer thom-at-boyers.org |Perl 6| wrote:
I believe Mr. Stroustrup's deprecation of 'protected' access applies
only to data data members, not function members:
Fortunately, you don't have to use protected data in C++; 'private'
is the default in classes and is usually the better choice. Note
that none of these objections are significant for protected member
*functions*. I still consider 'protected' a fine way of specifying
operations for use in derived classes.
-- Bjarne Stroustrup
_The_Design_and_Evolution_of_C++_
Section 13.9 [Protected Members]
So I understand Perl 6 will have no protected access for data members
(though trusted access can be used to provide a similar back door).
But does Perl 6 have protected access for methods?
=thom
I like the idea of using an interface (Role) to specify which methods
are allowed to be accessed, for which purposes. Add to that a way to
write type comprehensions; i.e. All types T such that... and you can
say This abstract interface, beyond the default public interface, is
available to types which have this type as a base class.
A less general means would be to allow trust to be transitive when
granted as such.
Perhaps:
class C
does R1
does R2
is Base
{
does R3 :trusts(D :transitive);
does R4 :trusts(D|E);
is Base2 :private; # allows virtual overrides but no isa
static type
does R5 :trusts($?CLASS, :transitive); # like C++ protected
method ...
}
I think that syntax would work under the current situation, at least
when used inside the class block.
--John
