On 10/03/2012 05:59 PM, renoX wrote:
> I have some mixed feeling about component programming: add in all the
> examples the requirement to give the context (line number for example)
> where something happened (either a match or an error) and suddendly
> component programming becomes much more "tricky"!!
>

Just zip the range with a range of context information, just as would be done with an explicit loop.

> So for me component programming looks good on paper, but not so much in
> the real world..
>
> renoX
>
>

On Wednesday, 3 October 2012 at 19:11:55 UTC, Martin Friesen wrote:
> On Wednesday, 3 October 2012 at 01:40:05 UTC, ixid wrote:
>> On Tuesday, 2 October 2012 at 21:27:42 UTC, Andrei Alexandrescu wrote:
>>> http://www.reddit.com/r/programming/comments/10u6sk/component_programming_in_d/
>>>
>>> Andrei
>>
>> The article contains a bug due to the pernicious behaviour of seedless reduce.
>>
>> This section:
>>
>> "Just to show how flexible algorithms can be, reduce can also compute multiple values with one pass through the data (which is pretty useful for streaming data and would be expensive to save for a second pass through it). Multiple lambdas produce a tuple result, here the sum and sum of squares is computed:
>>
>>    int[] arr = [1,2,3,4,5];
>>    auto r = arr.reduce!((a,b) => a + b, (a,b) => a + b * b);
>>    writefln("sum = %s, sum of squares = %s", r[0], r[1]);
>>
>> Which prints: sum = 15, sum of squares = 55"
>>
>> That is the correct answer for the squares sum but only because 1*1 is 1, what it's really doing here is 1 + (2 * 2) + (3 * 3) + (4 * 4) + (5 * 5) which happens to work in this case and for "a + b" and "a - b" but is otherwise broken. The first element of a seedless reduce does not have any operation carried out on it.
>>
>> If we change the array to [2,2,2,2,2] we would expect the squares sum to be 20. It's 18 because the seed element at arr[0] has no operation carried out on it other than the addition of the other elements to it.
>
> Pernicious? Bug? I've never used D, but it looks obvious that arr.reduce does what it's compile time parameter promises with 'a' as the "seed". It seems that using [0,1,2,3,4,5] or [0]~[1,2,3,4,5] or ([0]~arr).reduce! would have reflected a more general "sum of squares" idea simply enough.

Alternatively:

    auto r = reduce!((a,b) => a + b, (a,b) => a + b * b) (0, arr);

Regards,
rmr

On Wednesday, 3 October 2012 at 21:40:06 UTC, Timon Gehr wrote:
> On 10/03/2012 05:59 PM, renoX wrote:
>> I have some mixed feeling about component programming: add in all the
>> examples the requirement to give the context (line number for example)
>> where something happened (either a match or an error) and suddendly
>> component programming becomes much more "tricky"!!
>>
>
> Just zip the range with a range of context information, just as would be done with an explicit loop.

Yes, of course it's possible, but when you add filename, line numbers, column numbers (etc) the beautiful pipeline looks much less pretty..
Worse: each time you want to add some context, you have to modify the pipeline in a non-local way: take a -> b -> c -> d: you want to have more information in d from a's context, b and c must be modified to propagate the context..

When you have objects which encapsulate contexts, this becomes less an issue..

renoX

>
>> So for me component programming looks good on paper, but not so much in
>> the real world..
>>
>> renoX