Anton Tagunov wrote:
> Hello Mark!
>
> 1)
>
> MRD> One idea is it have Custom Iterators. A Custom Iterator could walk
> MRD> through the objects in a collection (or the double values in an array)
>
> These iterators would also provide other nice capability,
> receiving the values incrementally, "on the fly"
> (say, from an InputStream or properly obtained
> MySQL result set) w/o having to allocate
> intermediate storage for them.
Yes these are excellent examples of where custom iterators could come in
handy. I like the InputStream idea, I could also imagine something along
the lines of a SAX XMLFilter approach that could take SAX Events and
process them to generate stats.
>
> 2)
>
> MRD> Then its up to the implementor of the Iterator how "efficient" it works
> MRD> with the collection or double[], in the double[] case it can just return the
> MRD> value, in the Collection case it may preform a number of tasks prior to
> MRD> returning a value.
>
> Looks like it still has to be decided upon
> whether the iterator should return double or Object
> does not it?
>
> Are the questions
> a) double or Object
> b) iterator or not iterator
> orthogonal?
With a custom iterator, the questions become related in that the regular
"Iterator" interface returns Objects, I've written a custom
"DoubleIterator" interface that returns doubles as well as Objects,
there's no reason that a "DoubleIterator" can't act as a regular
"Iterator".
A default approach that deals with objects of "Iterator" could be
written, in cases where it can be detected (instanceof) that we're
working with a "DoubleIterator", the Statistic could move to using the
DoubleIterator interface instead.
>
> 3)
>
> BTW, probably does the future introduction of Generics (Java 1.5)
> promise any opportunities to work with primitive values and yet
> have no code duplication (a bit like STL)?
>
I've not spent much time looking at Generics yet. I have allot to learn
in this area.
> 4)
>
> Apologies, if this break-in was totally "the wrong sound",
> I certainly lack the knowledge of the current math code
> and interfaces, speaking more "in theory" :-)
>
> -Anton
No, glad to see more involvement and input from others outside the
group, we always need more input.
>
> P.S.
>
> As for the 'double' vs 'Object' issue, if I ever have to use
> a math library I, as an at most purely applied mathematician,
> (yup, my diploma says I am, but I really doubt that myself :)
> will probably prefer 'double'.
>
I think as well in instances where its important we should always try to
get down to "doubles". Object bridging to double can always be part of a
higher architecture or user implementation.
> But it's not a qualified opinion, plz disregard it :)
>
> I wouldn't write a separate mail on this as there
> already are qualified advocates for both viewpoints!
>
> The Funtor-style approach looks promising but I've got deep
> reservations about performance (and yes, that's what C-background
> guys will probably think, not only Fortran-background! ;-)
>
Yes, this has been that argument to date, but I think that its possible
to organize the code in a modular fashion without impacting performance
heavily. We are definitely taking such issues into heavy consideration
in the direction such projects will take the codebase.
-thanks for the input,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
|