On 2009-10-15 22:55:02 +0200, Fawzi Mohamed said:
On 2009-10-15 17:51:56 +0200, "Robert Jacques" said:
On Thu, 15 Oct 2009 04:48:57 -0400, Fawzi Mohamed wrote:
[...]
Note that a ref return for opIndex, could work in most situations.
As Bill correctly pointed out sparse matrix offer the mo
On 2009-10-15 17:51:56 +0200, "Robert Jacques" said:
On Thu, 15 Oct 2009 04:48:57 -0400, Fawzi Mohamed wrote:
[...]
Note that a ref return for opIndex, could work in most situations.
As Bill correctly pointed out sparse matrix offer the most challenging
example, there one wants to have two
On Thu, 15 Oct 2009 04:48:57 -0400, Fawzi Mohamed wrote:
On 2009-10-14 23:09:26 +0200, "Robert Jacques" said:
On Wed, 14 Oct 2009 16:49:28 -0400, Andrei Alexandrescu
wrote:
Jason House wrote:
Bill Baxter Wrote:
On Wed, Oct 14, 2009 at 7:42 AM, Jason House
wrote:
Andrei Alexandresc
On Thu, 15 Oct 2009 02:58:51 -0400, Don wrote:
Andrei Alexandrescu wrote:
Also, the much-discussed identity:
x @= y<-->x = x @ y
is difficult to enforce statically in practice. I think some types
would want to define both to achieve good efficiency. It would be hard
for the compi
On 2009-10-14 23:09:26 +0200, "Robert Jacques" said:
On Wed, 14 Oct 2009 16:49:28 -0400, Andrei Alexandrescu
wrote:
Jason House wrote:
Bill Baxter Wrote:
On Wed, Oct 14, 2009 at 7:42 AM, Jason House
wrote:
Andrei Alexandrescu Wrote:
Right now we're in trouble with operators: opIndex
Andrei Alexandrescu wrote:
Don wrote:
Well timed. I just wrote this operator overloading proposal, part 1.
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP7
I concentrated on getting the use cases established.
I'm not sure multiplication is generally commutative (e.g. in linear
a
On Wed, 14 Oct 2009 16:49:28 -0400, Andrei Alexandrescu
wrote:
Jason House wrote:
Bill Baxter Wrote:
On Wed, Oct 14, 2009 at 7:42 AM, Jason House
wrote:
Andrei Alexandrescu Wrote:
Right now we're in trouble with operators: opIndex and opIndexAssign
don't seem to be up to snuff because
Bill Baxter Wrote:
> On Wed, Oct 14, 2009 at 7:42 AM, Jason House
> wrote:
> > Andrei Alexandrescu Wrote:
> >
> >> Right now we're in trouble with operators: opIndex and opIndexAssign
> >> don't seem to be up to snuff because they don't catch operations like
> >>
> >> a[b] += c;
> >>
> >> with re
Jason House wrote:
Bill Baxter Wrote:
On Wed, Oct 14, 2009 at 7:42 AM, Jason House
wrote:
Andrei Alexandrescu Wrote:
Right now we're in trouble with operators: opIndex and opIndexAssign
don't seem to be up to snuff because they don't catch operations like
a[b] += c;
with reasonable expres
On Wed, Oct 14, 2009 at 9:34 AM, Bill Baxter wrote:
> On Wed, Oct 14, 2009 at 7:42 AM, Jason House
> wrote:
>> Andrei Alexandrescu Wrote:
>>
>>> Right now we're in trouble with operators: opIndex and opIndexAssign
>>> don't seem to be up to snuff because they don't catch operations like
>>>
>>> a
On Wed, Oct 14, 2009 at 7:42 AM, Jason House
wrote:
> Andrei Alexandrescu Wrote:
>
>> Right now we're in trouble with operators: opIndex and opIndexAssign
>> don't seem to be up to snuff because they don't catch operations like
>>
>> a[b] += c;
>>
>> with reasonable expressiveness and efficiency.
Andrei Alexandrescu Wrote:
> Right now we're in trouble with operators: opIndex and opIndexAssign
> don't seem to be up to snuff because they don't catch operations like
>
> a[b] += c;
>
> with reasonable expressiveness and efficiency.
I would hope that *= += /= and friends could all be handle
On Wed, 14 Oct 2009 18:39:27 +0400, Robert Jacques
wrote:
On Wed, 14 Oct 2009 10:31:06 -0400, Andrei Alexandrescu
wrote:
Don wrote:
Well timed. I just wrote this operator overloading proposal, part 1.
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP7
I concentrated on getti
On Wed, 14 Oct 2009 10:31:06 -0400, Andrei Alexandrescu
wrote:
Don wrote:
Well timed. I just wrote this operator overloading proposal, part 1.
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP7
I concentrated on getting the use cases established.
I'm not sure multiplication is
On Wed, 14 Oct 2009 06:11:22 -0400, Kagamin wrote:
Robert Jacques Wrote:
Also needed is an extension of the opDollar to return different values
based on the index:
opDollar(size_t index);
Dollar is just a synonym for length, isn't it?
User types can also override Dollar, though I don't re
Don wrote:
Well timed. I just wrote this operator overloading proposal, part 1.
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP7
I concentrated on getting the use cases established.
I'm not sure multiplication is generally commutative (e.g. in linear
algebra it isn't). So why sho
Lars T. Kyllingstad wrote:
Kagamin wrote:
Robert Jacques Wrote:
Also needed is an extension of the opDollar to return different
values based on the index:
opDollar(size_t index);
Dollar is just a synonym for length, isn't it?
Yes, but if opIndex and opSlice take multiple indices (like i
On Wed, Oct 14, 2009 at 12:48 AM, Lars T. Kyllingstad
wrote:
> Don wrote:
>>
>> Andrei Alexandrescu wrote:
>>>
>>> Right now we're in trouble with operators: opIndex and opIndexAssign
>>> don't seem to be up to snuff because they don't catch operations like
>>>
>>> a[b] += c;
>>>
>>> with reasonab
Lars T. Kyllingstad Wrote:
> Yes, but if opIndex and opSlice take multiple indices (like in a matrix)
> opDollar needs a way to distinguish between the different dimensions.
size_t length(size_t idx);
Kagamin wrote:
Robert Jacques Wrote:
Also needed is an extension of the opDollar to return different values
based on the index:
opDollar(size_t index);
Dollar is just a synonym for length, isn't it?
Yes, but if opIndex and opSlice take multiple indices (like in a matrix)
opDollar needs
Robert Jacques Wrote:
> Also needed is an extension of the opDollar to return different values
> based on the index:
> opDollar(size_t index);
Dollar is just a synonym for length, isn't it?
Don wrote:
Lars T. Kyllingstad wrote:
Don wrote:
Andrei Alexandrescu wrote:
Right now we're in trouble with operators: opIndex and opIndexAssign
don't seem to be up to snuff because they don't catch operations like
a[b] += c;
with reasonable expressiveness and efficiency.
Last night this i
Lars T. Kyllingstad wrote:
Don wrote:
Andrei Alexandrescu wrote:
Right now we're in trouble with operators: opIndex and opIndexAssign
don't seem to be up to snuff because they don't catch operations like
a[b] += c;
with reasonable expressiveness and efficiency.
Last night this idea occurred
Don:
> BTW we need to deal with slices as well as indexes. I think the way to
> do this is to make a slice into a type of index.
Such slice also needs a way to specify the end of the enclosing interval, the $
syntax.
Slice may enjoy a lot a third optional argument (default = 1), that represents
Don wrote:
Andrei Alexandrescu wrote:
Right now we're in trouble with operators: opIndex and opIndexAssign
don't seem to be up to snuff because they don't catch operations like
a[b] += c;
with reasonable expressiveness and efficiency.
Last night this idea occurred to me: we could simply use
On Tue, Oct 13, 2009 at 10:39 AM, Chad J
wrote:
> Forgotten already?
Apparently, yes!
> http://prowiki.org/wiki4d/wiki.cgi?DocComments/Property#Semantic
>
> This is the same problem as property lvalue-ness and it has the same
> solution. When property rewriting is done correctly, the opIndexAss
On Tue, Oct 13, 2009 at 8:56 AM, Don wrote:
> Well timed. I just wrote this operator overloading proposal, part 1.
> http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP7
> I concentrated on getting the use cases established.
>
> The indexing thing was something I didn't have a solution f
Forgotten already?
http://prowiki.org/wiki4d/wiki.cgi?DocComments/Property#Semantic
This is the same problem as property lvalue-ness and it has the same
solution. When property rewriting is done correctly, the opIndexAssign
problem can then be solved almost for free.
Just treat opIndex expressi
On Tue, 13 Oct 2009 13:08:59 -0400, Andrei Alexandrescu
wrote:
Bill Baxter wrote:
Huh? It didn't sound to me like it would get rid of anything, except
for the use of the word "index" in many methods that have to do with
index operations. That just seems confusing to me. I think the
opInde
On Tue, 13 Oct 2009 11:56:36 -0400, Don wrote:
Andrei Alexandrescu wrote:
Right now we're in trouble with operators: opIndex and opIndexAssign
don't seem to be up to snuff because they don't catch operations like
a[b] += c;
with reasonable expressiveness and efficiency.
Last night this id
On Tue, Oct 13, 2009 at 10:22 AM, JC wrote:
> This idea along with a slice overload would save me a lot of pain and
> performance while working with matrices in my production code. Any ideas
> when this could be implemented in D1?
> Jonathan
It won't be implemented in D1. Stability -- it's the
This idea along with a slice overload would save me a lot of pain and
performance while working with matrices in my production code. Any ideas when
this could be implemented in D1?
Jonathan
Andrei Alexandrescu wrote:
Right now we're in trouble with operators: opIndex and opIndexAssign
don't se
On Tue, Oct 13, 2009 at 10:08 AM, Andrei Alexandrescu
wrote:
> Bill Baxter wrote:
>>
>> Huh? It didn't sound to me like it would get rid of anything, except
>> for the use of the word "index" in many methods that have to do with
>> index operations. That just seems confusing to me. I think the
On Tue, Oct 13, 2009 at 10:00 AM, Steven Schveighoffer
wrote:
> On Tue, 13 Oct 2009 12:44:21 -0400, Denis Koroskin <2kor...@gmail.com>
> wrote:
>
>> Another thing I dislike about this proposal is that "a[b] += c;"
>> translates into "opAddAssign" and doesn't mention "index" while "a[b] = c;"
>> do
Bill Baxter wrote:
Huh? It didn't sound to me like it would get rid of anything, except
for the use of the word "index" in many methods that have to do with
index operations. That just seems confusing to me. I think the
opIndexXxxAssign functions may need to be added, but adding them by
overlo
On Tue, 13 Oct 2009 12:44:21 -0400, Denis Koroskin <2kor...@gmail.com>
wrote:
Another thing I dislike about this proposal is that "a[b] += c;"
translates into "opAddAssign" and doesn't mention "index" while "a[b] =
c;" does ("opIndexAssign").
I think the optimization translates to opAssig
On 2009-10-13 11:16:01 -0400, Andrei Alexandrescu
said:
Right now we're in trouble with operators: opIndex and opIndexAssign
don't seem to be up to snuff because they don't catch operations like
a[b] += c;
with reasonable expressiveness and efficiency.
Last night this idea occurred to me:
On Tue, 13 Oct 2009 20:34:06 +0400, Robert Jacques
wrote:
On Tue, 13 Oct 2009 12:28:05 -0400, Denis Koroskin <2kor...@gmail.com>
wrote:
On Tue, 13 Oct 2009 19:16:01 +0400, Andrei Alexandrescu
wrote:
Right now we're in trouble with operators: opIndex and opIndexAssign
don't seem to b
On Tue, 13 Oct 2009 12:21:20 -0400, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
On Tue, 13 Oct 2009 11:16:01 -0400, Andrei Alexandrescu
wrote:
There's no chance of ambiguity because the parameter counts are
different. Moreover, this scales to multiple indexes:
a[b1, b2, ...,
On Tue, Oct 13, 2009 at 9:08 AM, Steven Schveighoffer
wrote:
> On Tue, 13 Oct 2009 11:16:01 -0400, Andrei Alexandrescu
> wrote:
>
>> Right now we're in trouble with operators: opIndex and opIndexAssign don't
>> seem to be up to snuff because they don't catch operations like
>>
>> a[b] += c;
>>
>>
On Tue, 13 Oct 2009 12:28:05 -0400, Denis Koroskin <2kor...@gmail.com>
wrote:
On Tue, 13 Oct 2009 19:16:01 +0400, Andrei Alexandrescu
wrote:
Right now we're in trouble with operators: opIndex and opIndexAssign
don't seem to be up to snuff because they don't catch operations like
a[b] +
On Tue, 13 Oct 2009 19:16:01 +0400, Andrei Alexandrescu
wrote:
Right now we're in trouble with operators: opIndex and opIndexAssign
don't seem to be up to snuff because they don't catch operations like
a[b] += c;
with reasonable expressiveness and efficiency.
Last night this idea occurre
Steven Schveighoffer wrote:
On Tue, 13 Oct 2009 11:16:01 -0400, Andrei Alexandrescu
wrote:
There's no chance of ambiguity because the parameter counts are
different. Moreover, this scales to multiple indexes:
a[b1, b2, ..., bn] = c
gets rewritten as
a.opAddAssign(b1, b2, ..., bn, c)
I'm g
On Tue, 13 Oct 2009 11:16:01 -0400, Andrei Alexandrescu
wrote:
Right now we're in trouble with operators: opIndex and opIndexAssign
don't seem to be up to snuff because they don't catch operations like
a[b] += c;
with reasonable expressiveness and efficiency.
Last night this idea occurre
Andrei Alexandrescu wrote:
Right now we're in trouble with operators: opIndex and opIndexAssign
don't seem to be up to snuff because they don't catch operations like
a[b] += c;
with reasonable expressiveness and efficiency.
Last night this idea occurred to me: we could simply use overloading
Right now we're in trouble with operators: opIndex and opIndexAssign
don't seem to be up to snuff because they don't catch operations like
a[b] += c;
with reasonable expressiveness and efficiency.
Last night this idea occurred to me: we could simply use overloading
with the existing operator
46 matches
Mail list logo
