Re: amoeba, a chess engine written in D

[extrawurst via Digitalmars-d-announce]

On Friday, 20 May 2016 at 23:16:01 UTC, Richard Delorme wrote:
I am pleased to announce the release of a chess engine written 
in D:

https://github.com/abulmo/amoeba

I am not aware of any other chess engine written with the D 
language.


The source can be compiled with dmd, ldc or gdc, but the best 
performance are obtained with the latter (almost twice faster).


This is my first program using the D language (I am a former C 
programmer), and I enjoyed it a lot.


That is awesome!

Two questions:
1) If it is using UCI protocol I guess there are other engines 
that you can compare amoeba with when it comes to performance and 
other aspects, did you ?


2) It would be awesome if you could write down how it was to use 
D for that project as someone freshly coming from C. What were 
the reasons you chose D, what did you like, what did u hate ? 
That would help you being read on reddit by a hundred blood 
thursty devs (street cred and all) and us for knowing what we can 
improve and also get the PR :)


Cheers,
Stephan

amoeba, a chess engine written in D

[Richard Delorme via Digitalmars-d-announce]

I am pleased to announce the release of a chess engine written in 
D:

https://github.com/abulmo/amoeba

I am not aware of any other chess engine written with the D 
language.


The source can be compiled with dmd, ldc or gdc, but the best 
performance are obtained with the latter (almost twice faster).


This is my first program using the D language (I am a former C 
programmer), and I enjoyed it a lot.

Re: My ACCU 2016 keynote video available online

[Jens Müller via Digitalmars-d-announce]

On Friday, 20 May 2016 at 20:04:35 UTC, Andrei Alexandrescu wrote:

On 5/20/16 2:13 PM, Jens Müller wrote:
No it doesn't work because you need to break in the last case. 
Consider
the case when the last element of a is equal to an element in 
b. Next

iteration you overrun a.


I'm not that Bright :o).


Me neither.

So you'd need one more test, but you still save the other test 
and the test on one of the three branches, so 2 out of 4. --


Yes. Current version reduces it from 4 to 2.
I've read that people use SSE to speed it up. Maybe I consider 
this later.
If we want to improve on similar vectors (which is a great idea) 
we just reorder the cases, I'll guess. Just did it. It improves 
on my test data. But then on near dissimilar input I expect it to 
be worse.
When doing these optimizations it is always dependent on the 
expected input which is a pity when optimizing library functions. 
These must work in all cases and should only be less efficient 
for very good reason.

I'm looking forward to Fastware.

Jens

Re: My ACCU 2016 keynote video available online

[Andrei Alexandrescu via Digitalmars-d-announce]

On 5/20/16 2:13 PM, Jens Müller wrote:

No it doesn't work because you need to break in the last case. Consider
the case when the last element of a is equal to an element in b. Next
iteration you overrun a.


I'm not that Bright :o).

So you'd need one more test, but you still save the other test and the 
test on one of the three branches, so 2 out of 4. -- Andrei

Re: My ACCU 2016 keynote video available online

[Walter Bright via Digitalmars-d-announce]

On 5/20/2016 6:47 AM, H. S. Teoh via Digitalmars-d-announce wrote:

Not to mention inconsistency in what exactly
is being tested for: if you want to check if something is an input
range, do you use is(typeof(R.empty)), etc., or should you use
__traits(compiles, R.init.empty), or is it is(typeof((R r){r.empty;})),
or any of the 15 or so slightly different ways of testing for the
existence and type of some aggregate member, all subtly different from
each other? Subtly different as in, for instance, testing for
is(typeof((){R r; bool x = r.empty;})) is different from is(typeof(R
r){bool x = r.empty;}), because the former doesn't work with R that has
parameters closing over a local scope, whereas the latter does.


That is not a problem with constraints, it's a result of a dozen people adding 
constraints in an uncoordinated manner. I.e. it's a library problem.




Whereas if D had concepts, it would have been a simple
matter of defining the prototypical range with struct-like syntax and
calling it a day.


That really isn't good enough. Constraints can address behavior and 
relationships, concepts do not.

[OT] Re: pl0stuff an optimizing pl0 > c transcompiler

[Johan Engelen via Digitalmars-d-announce]

On Friday, 20 May 2016 at 18:04:55 UTC, Stefan Koch wrote:


Update I have implemented D codegen.
The CodeGenerator as well as the optimizer work at CTFE.
Therefore you can transcompile code at compileTime at call PL/0 
functions as there were naively implemented in D.


This is pretty cool :D

Now I understand why you want to improve CTFE. You actually want 
better C++ interop. And to do that, you are going to CTFE compile 
the C++ code to D code, which is then mixed in, and all is good. 
Excellent idea! ;-)


cheers,
  Johan

Re: My ACCU 2016 keynote video available online

[Jens Müller via Digitalmars-d-announce]

On Friday, 20 May 2016 at 14:14:18 UTC, Andrei Alexandrescu wrote:

On 05/19/2016 06:50 PM, Jens Müller wrote:
What if you stomped over an index in a that has as an equal 
index in b

(it could be anywhere in b).


Hmmm, you're right. So that doesn't work, or at least not 
efficiently (the fixup would entail a binary search in b).


How about this idea: arrange things such that a.back.idx <= 
b.back.idx (i.e. swap them if not so). Then stomp b.back.idx 
with size_t.max. Your kernel is:


if (a[i].idx < b[j].idx) {
  if (i == imax) break; // check needed
  i++;
} else if (a[i].idx > b[j].idx) {
  j++; // no check needed
} else {
  // no check needed
  r += a[i++].val * b[j++].val;
}

The fixup needs only to account for the case a.back.idx == 
b.back.idx. In fact I like this a lot better than others 
because it works real fast for identical vector (taking the 
norm) or similar vectors (often the case). Works?


No it doesn't work because you need to break in the last case. 
Consider the case when the last element of a is equal to an 
element in b. Next iteration you overrun a.

But optimizing for similar vectors is interesting.

Jens

Re: pl0stuff an optimizing pl0 > c transcompiler

[Stefan Koch via Digitalmars-d-announce]

On Friday, 20 May 2016 at 18:04:55 UTC, Stefan Koch wrote:

Therefore you can transcompile code at compileTime at call PL/0 
functions as there were naively implemented in D.




If you do want to call functions from D.
You cannot use the optimizer.
As it does _very_ aggressive inlineing and will fold all used 
functions into main.

Re: pl0stuff an optimizing pl0 > c transcompiler

[Stefan Koch via Digitalmars-d-announce]

On Monday, 28 December 2015 at 16:41:30 UTC, Stefan Koch wrote:

On Monday, 28 December 2015 at 10:45:59 UTC, Nick B wrote:

what languages do you plan to support for input and output ?


I just planned on PL/0 as input and C as output.
It is a simple one-pass (okay 2 pass if you count the 
optimizer) trans-compilation.


Update I have implemented D codegen.
The CodeGenerator as well as the optimizer work at CTFE.
Therefore you can transcompile code at compileTime at call PL/0 
functions as there were naively implemented in D.


While this does not make sense for underpowered languages like 
PL/0.

You can apply the same concept to something more powerful.

I will write up a detailed blogpost about the mechanisem at 
codesoldier.blogspot.de

Re: D's Auto Decoding and You

[Martin Nowak via Digitalmars-d-announce]

On Tuesday, 17 May 2016 at 14:06:37 UTC, Jack Stouffer wrote:

Related discussion 
https://trello.com/c/4XmFdcp6/163-rediscuss-redundant-utf-8-string-validation.

Re: My ACCU 2016 keynote video available online

[Andrei Alexandrescu via Digitalmars-d-announce]

On 05/19/2016 06:50 PM, Jens Müller wrote:

What if you stomped over an index in a that has as an equal index in b
(it could be anywhere in b).


Hmmm, you're right. So that doesn't work, or at least not efficiently 
(the fixup would entail a binary search in b).


How about this idea: arrange things such that a.back.idx <= b.back.idx 
(i.e. swap them if not so). Then stomp b.back.idx with size_t.max. Your 
kernel is:


if (a[i].idx < b[j].idx) {
  if (i == imax) break; // check needed
  i++;
} else if (a[i].idx > b[j].idx) {
  j++; // no check needed
} else {
  // no check needed
  r += a[i++].val * b[j++].val;
}

The fixup needs only to account for the case a.back.idx == b.back.idx. 
In fact I like this a lot better than others because it works real fast 
for identical vector (taking the norm) or similar vectors (often the 
case). Works?



Andrei

Re: My ACCU 2016 keynote video available online

[Manu via Digitalmars-d-announce]

On 19 May 2016 at 22:10, Andrei Alexandrescu via
Digitalmars-d-announce  wrote:
> On 5/18/16 7:42 AM, Manu via Digitalmars-d-announce wrote:
>>
>> On 16 May 2016 at 23:46, Andrei Alexandrescu via
>> Digitalmars-d-announce  wrote:
>>>
>>> Uses D for examples, showcases Design by Introspection, and rediscovers a
>>> fast partition routine. It was quite well received.
>>> https://www.youtube.com/watch?v=AxnotgLql0k
>>>
>>> Andrei
>>
>>
>> This isn't the one you said you were going to "destroy concepts" is it?
>> At dconf, you mentioned a talk for release on some date I can't
>> remember, and I got the impression you were going to show how C++'s
>> concepts proposal was broken, and ideally, propose how we can nail it
>> in D?
>
>
> That's the one - sorry to disappoint :o). -- Andrei

Ah. Okay, well while this is a very interesting talk, I was indeed
hoping you were going to make a D concepts proposal... do you have
such a thing in mind, or are you against concepts in D?