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?
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
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
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
[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
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
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
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
