www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Array operation for computing the dot product?

reply Trass3r <un known.com> writes:
I wonder if an array operation could be reasonably included.
It's a quite common case and there are direct SSE instructions for it  
since SSE 4.1.
Feb 03 2010
next sibling parent reply Don <nospam nospam.com> writes:
Trass3r wrote:
 I wonder if an array operation could be reasonably included.
 It's a quite common case and there are direct SSE instructions for it 
 since SSE 4.1.

Indeed. The difficult question is, what would the syntax be?
Feb 03 2010
next sibling parent BCS <none anon.com> writes:
Hello Don,

 Trass3r wrote:
 
 I wonder if an array operation could be reasonably included.
 It's a quite common case and there are direct SSE instructions for it
 since SSE 4.1.


Make it an intrinsic? -- <IXOYE><
Feb 03 2010
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Don:
 Indeed. The difficult question is, what would the syntax be?

What about the simper: x.dot(y) Bye, bearophile
Feb 03 2010
next sibling parent reply Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
bearophile wrote:

 Indeed. The difficult question is, what would the syntax be?

What about the simper: x.dot(y)

I don't like symmetric operations with an asymmetric syntax. Better: dot(x, y) Even better: dot_product(x, y) Funner: sum(x .* y) -- Michiel Helvensteijn
Feb 03 2010
next sibling parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 02/03/2010 03:09 PM, Simen kjaeraas wrote:
 On Wed, 03 Feb 2010 21:19:57 +0100, Michiel Helvensteijn
 <m.helvensteijn.remove gmail.com> wrote:

 bearophile wrote:

 Indeed. The difficult question is, what would the syntax be?

What about the simper: x.dot(y)

I don't like symmetric operations with an asymmetric syntax. Better: dot(x, y) Even better: dot_product(x, y) Funner: sum(x .* y)

Weirder: x · y

I vote obscure unicode character \u2743: heavy chevron snowflake x ❆ y
Feb 03 2010
next sibling parent reply BCS <none anon.com> writes:
Hello Ellery,

 On 02/03/2010 03:09 PM, Simen kjaeraas wrote:
 
 On Wed, 03 Feb 2010 21:19:57 +0100, Michiel Helvensteijn
 <m.helvensteijn.remove gmail.com> wrote:
 
 bearophile wrote:
 
 Indeed. The difficult question is, what would the syntax be?
 

x.dot(y)

Better: dot(x, y) Even better: dot_product(x, y) Funner: sum(x .* y)

x · y

x ❆ y

or why not: x ♣ y; no wait that would delete y and assign x to it. -- <IXOYE><
Feb 03 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
BCS wrote:
 Hello Ellery,
 
 On 02/03/2010 03:09 PM, Simen kjaeraas wrote:

 On Wed, 03 Feb 2010 21:19:57 +0100, Michiel Helvensteijn
 <m.helvensteijn.remove gmail.com> wrote:

 bearophile wrote:

 Indeed. The difficult question is, what would the syntax be?

x.dot(y)

Better: dot(x, y) Even better: dot_product(x, y) Funner: sum(x .* y)

x · y

x ❆ y

or why not: x ♣ y; no wait that would delete y and assign x to it.

Before we solve the difficult problem of naming the thing could we first go through the trivial part of optimizing it under its current name. http://www.digitalmars.com/d/2.0/phobos/std_numeric.html#dotProduct Andrei
Feb 03 2010
parent bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:
 Before we solve the difficult problem of naming the thing could we first 
 go through the trivial part of optimizing it under its current name.

In this case finding a good syntax before D2 is out of alpha stage is more important than implementing that efficiently. The user interface is often very important for the usage and success of a machine. And the interface of a computer language is its syntax. Bye, bearophile
Feb 03 2010
prev sibling next sibling parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Ellery Newcomer wrote:
 On 02/03/2010 03:09 PM, Simen kjaeraas wrote:
 On Wed, 03 Feb 2010 21:19:57 +0100, Michiel Helvensteijn
 <m.helvensteijn.remove gmail.com> wrote:

 bearophile wrote:

 Indeed. The difficult question is, what would the syntax be?

What about the simper: x.dot(y)

I don't like symmetric operations with an asymmetric syntax. Better: dot(x, y) Even better: dot_product(x, y) Funner: sum(x .* y)

Weirder: x · y

I vote obscure unicode character \u2743: heavy chevron snowflake x ❆ y

Considering TeX was invented (in part) to handle typesetting of mathematical formulae, one might imagine it would be a good idea to use its syntax... x \mdot y Yeah, maybe not...
Feb 03 2010
prev sibling parent Trass3r <un known.com> writes:
 Before we solve the difficult problem of naming the thing could we first  
 go through the trivial part of optimizing it under its current name.

 http://www.digitalmars.com/d/2.0/phobos/std_numeric.html#dotProduct

it's not like it couldn't be done in parallel :)
Feb 04 2010
prev sibling parent Chad J <chadjoan __spam.is.bad__gmail.com> writes:
Michiel Helvensteijn wrote:
 bearophile wrote:
 
 Indeed. The difficult question is, what would the syntax be?

x.dot(y)

I don't like symmetric operations with an asymmetric syntax. Better: dot(x, y) Even better: dot_product(x, y) Funner: sum(x .* y)

Fine stuff. This reminds me of a discussion we had a year or more ago about offering abstract operators purely for the purpose of overloading. We can use things like (+), (*), (-), (&), and so on. It'd probably be fine to use one for dot product. Probably a dream though. It looks like it's very hard to get new tokens/syntax into the language at this point. I suppose annotations and exponentiation managed it, but with no shortage of blood, sweat, and tears.
Feb 03 2010
prev sibling next sibling parent BCS <none anon.com> writes:
Hello bearophile,

 Don:
 
 Indeed. The difficult question is, what would the syntax be?
 

x.dot(y)

How about: x.y; It reads correctly. OK, bad idea. :) -- <IXOYE><
Feb 03 2010
prev sibling parent reply Don <nospam nospam.com> writes:
bearophile wrote:
 Don:
 Indeed. The difficult question is, what would the syntax be?

What about the simper: x.dot(y) Bye, bearophile

x.dot(y) and dot(x,y) are already implementable without language change.
Feb 03 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Don wrote:
 bearophile wrote:
 Don:
 Indeed. The difficult question is, what would the syntax be?

What about the simper: x.dot(y) Bye, bearophile

x.dot(y) and dot(x,y) are already implementable without language change.

As is std.numeric.dotProduct(x, y) without language _or_ library change :o). Andrei
Feb 03 2010
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Unicode operators are good for Fortress, but not for D.
x.dot(y) is good because it's short and easy to read&understand.

Another silly possibility:
x ^^^ y

:-)
Bye,
bearophile
Feb 03 2010
prev sibling next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
On Wed, 03 Feb 2010 21:19:57 +0100, Michiel Helvensteijn  =

<m.helvensteijn.remove gmail.com> wrote:

 bearophile wrote:

 Indeed. The difficult question is, what would the syntax be?

What about the simper: x.dot(y)

I don't like symmetric operations with an asymmetric syntax. Better: dot(x, y) Even better: dot_product(x, y) Funner: sum(x .* y)

Weirder: x =C2=B7 y -- = Simen
Feb 03 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Wed, 03 Feb 2010 20:55:46 +0100, Don wrote:

 Trass3r wrote:
 I wonder if an array operation could be reasonably included. It's a
 quite common case and there are direct SSE instructions for it since
 SSE 4.1.

Indeed. The difficult question is, what would the syntax be?

a · b
Feb 04 2010
prev sibling next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Trass3r wrote:
 I wonder if an array operation could be reasonably included.
 It's a quite common case and there are direct SSE instructions for it 
 since SSE 4.1.

This would be achieved by adding array aggregate properties, an idea that has cropped up a few times, though I can't seem to find anything other than http://www.digitalmars.com/webnews/newsgroups.php?art_group=D&article_id=21671 at the moment. And then add using these properties as something you can do with array operations besides slice assignment. It's much more general than inventing a new operator just for dot product. But there are more important things to do than adding yet more features to the language.... Stewart.
Feb 04 2010
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
retard wrote:
 I can easily come up with 100 other such features.

Please do so, and submit them to bugzilla.
 Some time ago I really 
 wanted to write a wikibook about D. I also wanted to write a new 
 compiler. It's just that D is a shitty language to work with because even 
 the stable version is a moving target and/or many features are 
 unspecified.

How is D1 a moving target?
Feb 05 2010
parent reply grauzone <none example.net> writes:
Walter Bright wrote:
 retard wrote:
 I can easily come up with 100 other such features.

Please do so, and submit them to bugzilla.

You know, the problem with Bugzilla is, that most entries simply remain unreplied. Especially when they inquire about strange language features or dark corner cases.
 
 Some time ago I really wanted to write a wikibook about D. I also 
 wanted to write a new compiler. It's just that D is a shitty language 
 to work with because even the stable version is a moving target and/or 
 many features are unspecified.

How is D1 a moving target?

Nobody knows how D actually works. Due to the incomplete specification, it's like a blackbox. All you can do is to give dmd some code using under-specified features, and when dmd accepts it, people have to assume the program is correct. Also, I have regressions in almost any dmd release. (I always have to change my code, or wait for later bug fixes. Sometimes the outcome is that a specific thing just wasn't supposed to work.) Even more so, D1 seems like a dead horse, and D2 just again is a really fast moving target. Give us a stable language, Walter! And by stable, I don't just mean an arbitrary frozen "snapshot" of the language. It has to be stable, but alive. Other languages are also doing it without breaking backward compatibility to all existing programs. I'm already hysterically laughing from the thought of an incompatible D3 in some years.
Feb 05 2010
parent Walter Bright <newshound1 digitalmars.com> writes:
grauzone wrote:
 Walter Bright wrote:
 retard wrote:
 I can easily come up with 100 other such features.

Please do so, and submit them to bugzilla.

You know, the problem with Bugzilla is, that most entries simply remain unreplied. Especially when they inquire about strange language features or dark corner cases.

Being in Bugzilla means they will not be forgotten, and will eventually get addressed. All spec problems are answerable by anyone willing to make the effort, and supply a documentation patch.
 How is D1 a moving target?

Nobody knows how D actually works. Due to the incomplete specification, it's like a blackbox. All you can do is to give dmd some code using under-specified features, and when dmd accepts it, people have to assume the program is correct.

There's more that can be done than that - file the issue in bugzilla. If you want to go further, include a patch to the specification.
 Also, I have regressions in almost any dmd release. (I always have to 
 change my code, or wait for later bug fixes. Sometimes the outcome is 
 that a specific thing just wasn't supposed to work.)

It's true that sometimes bug fixes will cause other bugs, this isn't just a spec problem. It's a problem that the test suite isn't thorough enough.
 Even more so, D1 seems like a dead horse, and D2 just again is a really 
 fast moving target. Give us a stable language, Walter! And by stable, I 
 don't just mean an arbitrary frozen "snapshot" of the language. It has 
 to be stable, but alive. Other languages are also doing it without 
 breaking backward compatibility to all existing programs.

It's not possible to have a stable language that gets regular new features. Even innocuous new features risk breaking things in unexpected ways. Even just a new keyword. Other languages do it by taking many years to fold in even very minor changes.
Feb 05 2010
prev sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
retard wrote:
 The funny thing about D is that if you start writing a book about it,
 there's a high desire to change the core features and add more of 

 the community.

I have started writing a D book in June and have not desired to change much about the language. I did find the half-reference behavior of slices weird and voiced my opinion about it. If you meant Andrei's book; he is not changing the language just because he is writing a book about it. The design of the language and the book happen together. My book targets the Turkish speaking novice programmer, and I am sure is tainted by my C++ experience. D is an excellent language to teach programming with. There is very little cruft in the language when doing the simple things. There is very little to make novice mistakes with.
 It's just that D is a shitty language to work with because even
 the stable version is a moving target and/or many features are
 unspecified.

I did need to change my text only a few times, e.g. when constant-sized arrays became value types. Shitty is in the eye of the beholder. Someone else may call C++ shitty just for the opposite reason: it is too stable. Years go by without any addition to the language. Even more years go by for the compiler vendors to catch up. That's not productive. D is great because it is being designed openly by great programmers: the person with the longest C++ compiler writing experience, the person who has pushed C++ templates beyond their limits and introduced needs for stronger templates, many others who contribute to the language at various levels. Heck, even my naive voice has an effect on the language. D2 obviously must stabilize before being useful; but it is great that it moves fast before that happens. Ali
Feb 05 2010
next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-02-05 14:35:20 -0500, Ali ehreli <acehreli yahoo.com> said:

 D2 obviously must stabilize before being useful; but it is great that 
 it moves fast before that happens.

D2 is already useful for small scale projects. I wrote the system to manage license codes for my Mac shareware (Magic Launch) with D2. It's in production since January running as a CGI on my website, and is working great. My only wish in relation to that is that SafeD be more usable. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Feb 05 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Michel Fortin wrote:
 My only wish in relation to that is that SafeD be more 
 usable.

I know safe D isn't fully implemented, but can you say which missing part of it you need?
Feb 05 2010
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-02-05 15:22:44 -0500, Walter Bright <newshound1 digitalmars.com> said:

 Michel Fortin wrote:
 My only wish in relation to that is that SafeD be more usable.

I know safe D isn't fully implemented, but can you say which missing part of it you need?

First, I'd like to say that language itself isn't too bad. I think SafeD as currently implemented has the right design, except when it comes to passing delegates and functions as arguments to templates or functions. But I abandoned using this so it's not a pressing need for me currently. Still, I think that's an important issue to solve otherwise it'll be difficult to make std.algorithm safe and at the same time usable from unsafe code (as it relies heavily on predicates). So basically in the implementation there's just one big annoyance for me right now (but the workaround is easy): http://d.puremagic.com/issues/show_bug.cgi?id=3636 Most of the problems come from Phobos not being safe. I'm using a couple of things scattered in std.range, std.string, std.file, std.stdio, std.path, and to!X in std.conv. So what's the plan? Should everything theoretically safe in Phobos be trusted to avoid complains about unnecessary checks in programs that don't bother about safety? Or should we make things safe and promote them to trusted (for performance) only after a careful review? I'm a proponent of not making anything trusted in Phobos until it has been reviewed and approved by someone else than the author. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Feb 05 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Michel Fortin wrote:
 So what's the plan? Should everything theoretically safe in Phobos be 
  trusted to avoid complains about unnecessary checks in programs that 
 don't bother about safety? Or should we make things  safe and promote 
 them to  trusted (for performance) only after a careful review? I'm a 
 proponent of not making anything  trusted in Phobos until it has been 
 reviewed and approved by someone else than the author.

Every function in Phobos needs to be reviewed and tagged as safe, trusted or system as appropriate.
Feb 05 2010
next sibling parent reply strtr <strtr spam.com> writes:
Walter Bright Wrote:
 Every function in Phobos needs to be reviewed and tagged as safe, 
 trusted or system as appropriate.

I am sorry if this is totally stupid, but shouldn't it be possible for the compiler to do this? addition to -profile maybe It might also be interesting if the compiler were to generate the most restrictive protection attributes for everything, which would still compile or course ;)
Feb 05 2010
parent dsimcha <dsimcha yahoo.com> writes:
== Quote from strtr (strtr spam.com)'s article
 Walter Bright Wrote:
 Every function in Phobos needs to be reviewed and tagged as safe,
 trusted or system as appropriate.


 It might also be interesting if the compiler were to generate the most

course ;) Actually, more generally a generate-attributes flag for the compiler might be a pretty useful thing. I have no idea how feasible this would be at an implementation level, but it would definitely work at a theoretical level (except for trusted, which needs to be checked manually). It would spit out the same source files, but with any attribute that would compile added. For example, all functions that would compile as pure would be marked pure. All functions that would compile as nothrow would be marked nothrow. All unannotated member functions that would compile as const would be marked inout (once inout is implemented for member functions). All function parameters that could be const without breaking anything would be marked as such. This assumes that noone overloaded const and non-const versions of some member function to do semantically different things, but if they did they deserve what they get.
Feb 05 2010
prev sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2010-02-05 18:59:00 -0500, Walter Bright <newshound1 digitalmars.com> said:

 Michel Fortin wrote:
 So what's the plan? Should everything theoretically safe in Phobos be 
  trusted to avoid complains about unnecessary checks in programs that 
 don't bother about safety? Or should we make things  safe and promote 
 them to  trusted (for performance) only after a careful review? I'm a 
 proponent of not making anything  trusted in Phobos until it has been 
 reviewed and approved by someone else than the author.

Every function in Phobos needs to be reviewed and tagged as safe, trusted or system as appropriate.

But is it okay to label most of Phobos safe knowing that it'll reduce performance? I was under the impression that we would want to make most of Phobos trusted for performance. Also, I'm now realizing that safe might be difficult to add to many templates. For instance, this template function from std.range doesn't know if the functions it calls on the range (length, empty, popFront) are safe or not. Labeling it safe will make it not work with unsafe ranges while not labeling it safe will make it uncallable from safe functions (and making it trusted will make it blindly trust the range), neither of which is very compelling. size_t walkLength(Range)(Range range, size_t upTo = size_t.max) if (isInputRange!(Range)) { static if (hasLength!(Range)) { return range.length; } else { size_t result; for (; result < upTo && !range.empty; range.popFront) ++result; return result; } } I'm starting to think that templates should inherit the safe attribute from the context they're instantiated in, not from where they're defined. This would solve the above problem nicely as well as the problem of string predicates in std.algorithm: sort!"a < b"(array); // whether "a < b" needs to be safe depends on the context -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Feb 06 2010
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
retard wrote:
   {protection-attr} == perhaps one of these {public|protected|package|
 private} - I have no effing clue what this does

It actually does the same thing as it does in C++ (with the addition of package).
Feb 05 2010
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
retard wrote:
 Fri, 05 Feb 2010 13:24:44 -0800, Walter Bright wrote:
 
 retard wrote:
   {protection-attr} == perhaps one of these {public|protected|package|
 private} - I have no effing clue what this does

package).

I see. I only noticed now that dmd actually does enforce this rule in some cases. Unfortunately the rule is checked only statically when it can be checked. If you access the object via base class or interface type reference, a runtime check is not made unlike in c++.

There must be some misunderstanding here. There are no runtime access checks in C++, it is all done statically at compile time.
Feb 05 2010
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
retard wrote:
 Fri, 05 Feb 2010 16:03:22 -0800, Walter Bright wrote:
 
 retard wrote:
 Fri, 05 Feb 2010 13:24:44 -0800, Walter Bright wrote:

 retard wrote:
   {protection-attr} == perhaps one of these
   {public|protected|package|
 private} - I have no effing clue what this does

of package).

some cases. Unfortunately the rule is checked only statically when it can be checked. If you access the object via base class or interface type reference, a runtime check is not made unlike in c++.

checks in C++, it is all done statically at compile time.

Thanks. It seems I have been testing this with a buggy c++ compiler or can't remember what was the problem previously. I now tried with gcc 4.4.3 and this is how D and C++ differ: --- class Foo { public: void bar() {} }; class Bar : private Foo { }; int main() { Foo *a = new Bar(); a->bar(); } test.cpp: In function ‘int main()’: test.cpp:10: error: ‘Foo’ is an inaccessible base of ‘Bar’ --- module m1; class Foo { public void bar() {} } class Bar : private foo { } module m2; import m1; void main() { Foo a = new Bar(); a.bar(); } // compiles and runs just fine

That's a bug in dmd. It should behave like the C++ does.
 // Changing the 'Foo a = ...' into 'Bar a = ...' makes this an error

Feb 05 2010
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
Walter Bright wrote:
 retard wrote:
 module m1;

 class Foo {
   public void bar() {}
 }

 class Bar : private foo {
 }

 module m2;
 import m1;

 void main() {
   Foo a = new Bar();
   a.bar();
 }

 // compiles and runs just fine

That's a bug in dmd. It should behave like the C++ does.

It would be different from C++ if everything were in the same module, right? If I understand it correctly, private is not honored for the code in the same module. Is that for all uses of private? Ali
Feb 05 2010
parent Walter Bright <newshound1 digitalmars.com> writes:
Ali Çehreli wrote:
 It would be different from C++ if everything were in the same module, 
 right?

Right.
 If I understand it correctly, private is not honored for the code in the 
 same module. Is that for all uses of private?

Yes.
Feb 05 2010
prev sibling next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
retard wrote:
 // compiles and runs just fine

http://d.puremagic.com/issues/show_bug.cgi?id=3774
Feb 05 2010
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2/6/10 01:25, retard wrote:
 Fri, 05 Feb 2010 16:03:22 -0800, Walter Bright wrote:

 retard wrote:
 Fri, 05 Feb 2010 13:24:44 -0800, Walter Bright wrote:

 retard wrote:
    {protection-attr} == perhaps one of these
    {public|protected|package|
 private} - I have no effing clue what this does

of package).

I see. I only noticed now that dmd actually does enforce this rule in some cases. Unfortunately the rule is checked only statically when it can be checked. If you access the object via base class or interface type reference, a runtime check is not made unlike in c++.

There must be some misunderstanding here. There are no runtime access checks in C++, it is all done statically at compile time.

Thanks. It seems I have been testing this with a buggy c++ compiler or can't remember what was the problem previously. I now tried with gcc 4.4.3 and this is how D and C++ differ: --- class Foo { public: void bar() {} }; class Bar : private Foo { }; int main() { Foo *a = new Bar(); a->bar(); } test.cpp: In function ‘int main()’: test.cpp:10: error: ‘Foo’ is an inaccessible base of ‘Bar’ --- module m1; class Foo { public void bar() {} } class Bar : private foo { } module m2; import m1; void main() { Foo a = new Bar(); a.bar(); } // compiles and runs just fine // Changing the 'Foo a = ...' into 'Bar a = ...' makes this an error

Is there any use to make the base class non public in D? I mean you will also make the Object part inaccessible. Another thing to remove in D2?
Feb 06 2010
parent Walter Bright <newshound1 digitalmars.com> writes:
Jacob Carlborg wrote:
 Is there any use to make the base class non public in D? I mean you will 
 also make the Object part inaccessible. Another thing to remove in D2?

It's possible it's a useless feature. Apparently, nobody has found a use for it yet in D.
Feb 06 2010
prev sibling parent strtr <strtr spam.com> writes:
Walter Bright Wrote:

 retard wrote:
   {protection-attr} == perhaps one of these {public|protected|package|
 private} - I have no effing clue what this does

It actually does the same thing as it does in C++ (with the addition of package).

I didn't know I could protect a superclass like that, where can I read about this?
Feb 05 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Fri, 05 Feb 2010 02:42:53 +0000, Stewart Gordon wrote:

 Trass3r wrote:
 I wonder if an array operation could be reasonably included. It's a
 quite common case and there are direct SSE instructions for it since
 SSE 4.1.

This would be achieved by adding array aggregate properties, an idea that has cropped up a few times, though I can't seem to find anything other than http://www.digitalmars.com/webnews/newsgroups.php?

 at the moment.
 
 And then add using these properties as something you can do with array
 operations besides slice assignment.
 
 It's much more general than inventing a new operator just for dot
 product.
 
 But there are more important things to do than adding yet more features
 to the language....

The funny thing about D is that if you start writing a book about it, there's a high desire to change the core features and add more of them in the community. You can't even list all the D1 features at the moment, because we don't know what they are. Example: class bar {} class foo : private bar {} Another one: pragma(msg, mystruct.tupleof.stringof); I can easily come up with 100 other such features. Some time ago I really wanted to write a wikibook about D. I also wanted to write a new compiler. It's just that D is a shitty language to work with because even the stable version is a moving target and/or many features are unspecified.
Feb 05 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Fri, 05 Feb 2010 03:20:35 -0800, Walter Bright wrote:

 retard wrote:
 I can easily come up with 100 other such features.

Please do so, and submit them to bugzilla.

OK
 
 
 Some time ago I really
 wanted to write a wikibook about D. I also wanted to write a new
 compiler. It's just that D is a shitty language to work with because
 even the stable version is a moving target and/or many features are
 unspecified.

How is D1 a moving target?

Bugfixes in specification make those programs break that had to rely on broken semantics.
Feb 05 2010
prev sibling next sibling parent Trass3r <un known.com> writes:
 What about the simper:
 x.dot(y)

change.

As is std.numeric.dotProduct(x, y) without language _or_ library change :o).

That's why I wondered if it could be reasonably included (without introducing a ton of new stuff to the language). so it should be usable like x.dotProduct(y), right? sounds fine for me. Unfortunately I can't even try to implement it cause my Core 2 is slightly too old ;) Was introduced with Penryn architecture.
Feb 05 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Fri, 05 Feb 2010 11:35:20 -0800, Ali Çehreli wrote:

 I did need to change my text only a few times, e.g. when constant-sized
 arrays became value types.

You can easily check from the changelogs what happened between dmd 1.00 and 1.056. Quite a lot changed. You could even write a 200 page book about the changes.
 D is great because it is being designed openly by great programmers: the
 person with the longest C++ compiler writing experience, the person who
 has pushed C++ templates beyond their limits and introduced needs for
 stronger templates, many others who contribute to the language at
 various levels. Heck, even my naive voice has an effect on the language.

Heh, whatever. But the problem is, when I write a book about C, C++, Java, or some other language, I do know how it behaves. I can write informal programming books for novices or exact academic text with full description of the grammar rules, type system, and e.g. denotational or operational semantics. A D book is like a c++0x, Java7 or Haskell 2010 book - you constantly need to update it to reflect the changes in the next spec update. Now with D this isn't the case. I have to participate in the spec writing process no matter what I do. I do know how lazily Walter responds to queries and I do know that even though many have complained about semantics of the protection attributes in class inheritance several times during the past 10 years, nothing has changed. I don't want to write books that say 1. Classes ---------- 1.1. Inheritance ---------------- Classes in D can inherit from a base class. [snip] The syntax below shows how to do this: class {classname} : {protection-attr} {baseclassname} { } {classname} == name of the new class, represents the type name {baseclassname} == name of the base class {protection-attr} == perhaps one of these {public|protected|package| private} - I have no effing clue what this does and neither does anyone else but isn't this a cool feature that somehow proves that D is very practical language and also implementing your own compiler is so damn easy
Feb 05 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Fri, 05 Feb 2010 13:24:44 -0800, Walter Bright wrote:

 retard wrote:
   {protection-attr} == perhaps one of these {public|protected|package|
 private} - I have no effing clue what this does

It actually does the same thing as it does in C++ (with the addition of package).

I see. I only noticed now that dmd actually does enforce this rule in some cases. Unfortunately the rule is checked only statically when it can be checked. If you access the object via base class or interface type reference, a runtime check is not made unlike in c++.
Feb 05 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Fri, 05 Feb 2010 16:03:22 -0800, Walter Bright wrote:

 retard wrote:
 Fri, 05 Feb 2010 13:24:44 -0800, Walter Bright wrote:
 
 retard wrote:
   {protection-attr} == perhaps one of these
   {public|protected|package|
 private} - I have no effing clue what this does

of package).

I see. I only noticed now that dmd actually does enforce this rule in some cases. Unfortunately the rule is checked only statically when it can be checked. If you access the object via base class or interface type reference, a runtime check is not made unlike in c++.

There must be some misunderstanding here. There are no runtime access checks in C++, it is all done statically at compile time.

Thanks. It seems I have been testing this with a buggy c++ compiler or can't remember what was the problem previously. I now tried with gcc 4.4.3 and this is how D and C++ differ: --- class Foo { public: void bar() {} }; class Bar : private Foo { }; int main() { Foo *a = new Bar(); a->bar(); } test.cpp: In function ‘int main()’: test.cpp:10: error: ‘Foo’ is an inaccessible base of ‘Bar’ --- module m1; class Foo { public void bar() {} } class Bar : private foo { } module m2; import m1; void main() { Foo a = new Bar(); a.bar(); } // compiles and runs just fine // Changing the 'Foo a = ...' into 'Bar a = ...' makes this an error
Feb 05 2010
prev sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
On Sat, 06 Feb 2010 01:43:27 +0100, strtr <strtr spam.com> wrote:

 Walter Bright Wrote:
 Every function in Phobos needs to be reviewed and tagged as safe,
 trusted or system as appropriate.

I am sorry if this is totally stupid, but shouldn't it be possible for the compiler to do this? addition to -profile maybe It might also be interesting if the compiler were to generate the most restrictive protection attributes for everything, which would still compile or course ;)

Theoretically possible, yes. However, that would require whole-program analysis, which is not always possible. -- Simen
Feb 05 2010