Comments on: Building a Generic Statistics Library, Part 4: Map

By: Raymond

Raymond — Thu, 18 Sep 2008 19:37:02 +0000

I agree, the caller has no business in dictating the internal Map implementation. I was just trying to get my head around how returning an IEnumerable to the caller helps with resolving the issue with the sample implementation above constructing the result set.

Ultimately the issue is that delegating creation and management of the result set to the Map() function removes some of the type safety inherent in the approach. The caller is required to perform additional type checks on the result set and the result set is no more than a collection of mutated instances of the original type T (which may not be particularly useful to the caller, or appropriate to the operation being performed).

Anyhoo, this is really just nitpicking and not related to your aim of demonstrating generics. Keep up the good work!

By: Craig Stuntz

Craig Stuntz — Thu, 18 Sep 2008 16:48:59 +0000

I’m not implying anything about implementation; to the contrary, I’m saying that it is none of the caller’s business with the implementation is. However, the caller would see the same result in either case, unless you mutate the list. But if you mutate the list, there is little need for a function like Map.

By: Raymond

Raymond — Thu, 18 Sep 2008 16:41:59 +0000

By ‘Ideally I’d like to return an IEnumerable … rather than constructing an actual list’, are you suggesting that the Map() implementation actually be nothing more than an enumerator that calculates individual results from the given list when the caller sucks on it? This would have the, IMO, undesirable effect of synchronising the processing with the act of retrieving the result (something like a Quantum Mechanics approach ).

Otherwise, I’m not sure how returning an IEnumerable helps as this otherwise needs to be an interface on a concrete container of results which must be constructed somewhere…

By: Craig Stuntz

Craig Stuntz — Thu, 18 Sep 2008 12:50:45 +0000

Ideally I’d like to return an IEnumerable. This could return the list elements directly rather than constructing an actual list. But D2009’s IEnumerable isn’t quite fully supported in the RTL, yet.

By: Raymond

Raymond — Thu, 18 Sep 2008 03:33:14 +0000

Hi Craig,

You know, it’s going to take a while to get used to code that looks like this:

SquaredDeviations := Map(function(AValue: T): T
begin
Result := ASquare(ADeviation(AValue, Avg));
end,
AData);

Regards the map() function itself, it’s not so much returning a new instance, but it is returning a new TList instance, rather than an intance of the TEnumerable derived type. To be truly generic (sic) the map function either needs to be given the list (as yuou suggest), or the type of the required resultant list. The former is parhaps better for lifetime management smoothness (again, as you suggest) and also allows more complex construction semantics for the result list prior to passing to Map().

One minor performance pick Given this code I would add a line:

NewList.Capacity := AData.Count;

after the construction of newlist to remove the potentially many resizes of the list.

On reflection, I remember you saying that TEnumerable does not support Count (and suggested using a Fold() variant to implement a count). This is possibly another reason to provide Map with the result set.