June 08, 2010
Andrei Alexandrescu wrote:
> On 06/07/2010 04:35 PM, "Jérôme M. Berger" wrote:
>> Andrei Alexandrescu wrote:
>>> On 06/07/2010 12:57 PM, "Jérôme M. Berger" wrote:
>>>>> Do this in any dynamic language ->   FAIL because looping is so
>>>>> slow that you might
>>>>> die of old age before it executes.  Besides, who wants to do
>>>>> computationally
>>>>> intensive, multithreaded work in a dynamic language?
>>>>
>>>>      In python: max (map (max, args)) should have reasonable
>>>> performances and is *much* more elegant...
>>>
>>> I very much doubt that.
>>>
>>     What do you doubt? That it has reasonable performance or that it is
>> more elegant?
> 
> That it has reasonable performance. Then, there are a number of things that can't be compared such as figuring out the tightest static types, something that Python doesn't worry about (at the expense of precision and performance).
> 
	Please define "reasonable performance"...

> I see such examples as simple illustrations "look, if you give up X, you gain Y!" - just coming without mentioning X.
> 
	Precisely my point :) If you look at the OP message, what it boils
down to is: "look if you do this the D way in a dynamic language
it'll be dead slow" - just coming without mentioning that the D way
isn't the right way in those languages...

		Jerome
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr



June 08, 2010
Jérôme M. Berger wrote:
> Andrei Alexandrescu wrote:
>> On 06/07/2010 04:35 PM, "Jérôme M. Berger" wrote:
>>> Andrei Alexandrescu wrote:
>>>> On 06/07/2010 12:57 PM, "Jérôme M. Berger" wrote:
>>>>>> Do this in any dynamic language ->   FAIL because looping is so
>>>>>> slow that you might
>>>>>> die of old age before it executes.  Besides, who wants to do
>>>>>> computationally
>>>>>> intensive, multithreaded work in a dynamic language?
>>>>>      In python: max (map (max, args)) should have reasonable
>>>>> performances and is *much* more elegant...
>>>> I very much doubt that.
>>>>
>>>     What do you doubt? That it has reasonable performance or that it is
>>> more elegant?
>> That it has reasonable performance. Then, there are a number of things that can't be compared such as figuring out the tightest static types, something that Python doesn't worry about (at the expense of precision and performance).
>>
> 	Please define "reasonable performance"...
> 
>> I see such examples as simple illustrations "look, if you give up X, you gain Y!" - just coming without mentioning X.
>>
> 	Precisely my point :) If you look at the OP message, what it boils
> down to is: "look if you do this the D way in a dynamic language
> it'll be dead slow" - just coming without mentioning that the D way
> isn't the right way in those languages...
> 
PS: I should perhaps mention that I like D. I just think that
spreading FUD about other languages is not the right way to promote D...

		Jerome
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr



June 08, 2010
On 06/08/2010 01:27 PM, "Jérôme M. Berger" wrote:
> Andrei Alexandrescu wrote:
>> On 06/07/2010 04:35 PM, "Jérôme M. Berger" wrote:
>>> Andrei Alexandrescu wrote:
>>>> On 06/07/2010 12:57 PM, "Jérôme M. Berger" wrote:
>>>>>> Do this in any dynamic language ->    FAIL because looping is so
>>>>>> slow that you might
>>>>>> die of old age before it executes.  Besides, who wants to do
>>>>>> computationally
>>>>>> intensive, multithreaded work in a dynamic language?
>>>>>
>>>>>       In python: max (map (max, args)) should have reasonable
>>>>> performances and is *much* more elegant...
>>>>
>>>> I very much doubt that.
>>>>
>>>      What do you doubt? That it has reasonable performance or that it is
>>> more elegant?
>>
>> That it has reasonable performance. Then, there are a number of things
>> that can't be compared such as figuring out the tightest static types,
>> something that Python doesn't worry about (at the expense of precision
>> and performance).
>>
> 	Please define "reasonable performance"...

Within 15% of hand-optimized code specialized for the types at hand.

Andrei
June 08, 2010
On 06/08/2010 01:29 PM, "Jérôme M. Berger" wrote:
> PS: I should perhaps mention that I like D. I just think that
> spreading FUD about other languages is not the right way to promote D...

Hope I didn't do that.

Andrei
June 08, 2010
On Tue, Jun 8, 2010 at 14:28, Andrei Alexandrescu < SeeWebsiteForEmail@erdani.org> wrote:
>
> This is kind of funny. This works because reduce is defined as follows:
>
> template reduce(alias fun)
> {
>    alias Reduce!(fun).reduce reduce;
> }
>
> I did that to work around some old compiler bugs that have been since fixed. I'd initially intended to define reduce like this:
>
> Unqual!E reduce(alias fun, E, R)(E seed, R r) { ... }
>
> but that wouldn't have allowed Nick's alias, which is quite useful. So it looks like we have a cool idiom.


Currying in general is always handy to have. The possibility to say

alias map!fun funMapper;

would be cool also. If possible, having this in Phobos would be quite nice. Bu then, I'm one of those persons that'd like to have

alias take(3) takeThree; // will then work on any range.

Instead of take(range, 3). If find the former to be much more generic.

I liked it so much I defined a small template to invert and curry these
(R,n) functions.

Philippe


June 08, 2010
On Tue, Jun 8, 2010 at 20:13, Nick Sabalausky <a@a.a> wrote:

>
> Template currying ;) Maybe not as flexible as typical currying, but still.
>

I recenly achieved getting partially there. At least, given

foo(A,B,C)(n args list) {...}

curry!foo will correctly create n 1-arg templated function inside one
another and deliver the result at the end.
But it does not verify the compatibility of arguments while filling the
arguments :(

Given

foo(A,B,C)(A a, Tuple!(B,A) b, C[A] c)

curry!foo will accept any A a, but then should only accept b's of the correct type: Tuple!(B,A), for some B and the already defined A, and the same for c. I'm making sense there?

I more or less see how to get there, but can't get motivated to do this :-)



> Also, what's Unqual?
>

Gets rid of any const/immutable qualifiers.

Philipe


June 08, 2010
Andrei Alexandrescu wrote:
> On 06/08/2010 01:27 PM, "Jérôme M. Berger" wrote:
>>     Please define "reasonable performance"...
> 
> Within 15% of hand-optimized code specialized for the types at hand.

I would have said O(n) or O(log n), as opposed to, say, O(n*n).

General rules for performance improvements:

1. nobody notices a 10% improvement

2. users will start noticing speedups when they exceed 2x

3. a 10x speedup is a game changer
June 08, 2010
On 06/08/2010 04:05 PM, Walter Bright wrote:
> Andrei Alexandrescu wrote:
>> On 06/08/2010 01:27 PM, "Jérôme M. Berger" wrote:
>>> Please define "reasonable performance"...
>>
>> Within 15% of hand-optimized code specialized for the types at hand.
>
> I would have said O(n) or O(log n), as opposed to, say, O(n*n).
>
> General rules for performance improvements:
>
> 1. nobody notices a 10% improvement
>
> 2. users will start noticing speedups when they exceed 2x
>
> 3. a 10x speedup is a game changer

max of n elements is O(n).

Andrei
June 08, 2010
Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote

> max of n elements is O(n).

T max( T )( T[] values ) {
    T result = values[0];
    foreach ( i, e; values[1..$] ) {
        if ( max( values[i+1..$] ) > result ) {
            result = max( values[i+1..$] );
        }
    }
    return result;
}

-- 
Simen
June 08, 2010
Simen kjaeraas <simen.kjaras@gmail.com> wrote:

> Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote
>
>> max of n elements is O(n).
>
> T max( T )( T[] values ) {
>      T result = values[0];
>      foreach ( i, e; values[1..$] ) {
>          if ( max( values[i+1..$] ) > result ) {
>              result = max( values[i+1..$] );
>          }
>      }
>      return result;
> }

Better:


T max( T )( T[] values ) {
    if ( values.length == 1 ) {
        return values[0];
    } else {
        return max( values[0..values.length/2] ) > max( values[values.length/2..$] ) ? max( values[0..values.length/2] ) : max( values[values.length/2..$] );
    }
}

-- 
Simen