You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Anton Tagunov <at...@mail.cnt.ru> on 2003/07/03 13:18:29 UTC
Re[2]: [math] abstact nonsense was Re: [math][functor] More Design Concerns
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.
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?
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)?
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
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'.
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! ;-)
And also if all we need are real value computations,
the 'double' interfaces are probably more "usable",
"user-friendly" and less "scaring".
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[math] Generics was: Re: [math] abstact nonsense was ...
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Craig R. McClanahan wrote:
>On Thu, 3 Jul 2003, Al Chou wrote:
>
>
>
>>Date: Thu, 3 Jul 2003 12:05:49 -0700 (PDT)
>>From: Al Chou <ho...@yahoo.com>
>>Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
>>To: Jakarta Commons Developers List <co...@jakarta.apache.org>
>>Subject: Re: [math] abstact nonsense was Re: [math][functor] More Design
>> Concerns
>>
>>--- "Mark R. Diggory" <md...@latte.harvard.edu> wrote:
>>
>>
>>>Anton Tagunov wrote:
>>>
>>>
>>>>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.
>>>
>>>
>>I believe for our purposes it suffices to describe generics as the ability to
>>write something like (I'm too lazy to look up the exact syntax):
>>
>>ArrayList<Double> myArray = new ArrayList()<Double> ;
>>Double d ;
>>int position = 0 ;
>>
>>myArray.add( new Double( 1.0 ) ) ;
>>
>>// Here's the part where generics make life easier. Look, Ma, no cast:
>>d = myArray.get( position ) ;
>>
>>
>>
>
>My understanding is that this is exactly what you'll get from the
>auto-unboxing capability. The compiler will be able to see that the right
>hand side returns a Double, and generate the code to unbox it into a
>double primitive for you.
>
>This is separate from Generics because it also works in other scenarios:
>
> Double d1 = new Double(1.0); // A lowly scalar instance of the wrapper
> double d2 = d1; // But no cast here either!
> d1 = d2 + 0.5; // Or here ... it is bidirectional
>
>
>>From http://java.sun.com/javaone you can download a webcast of the
>Technical General Session on Tuesday morning that covered the 1.5 language
>changes, including both of the topics above. It was the first time I'd
>ever seen cheering sections for the different proposed features :-).
>
>Craig
>
>
>
That auto-boxing capability alone would make me jump for joy!
JavaOne: a very worthwhile subscription I can get my employer to cover ;-)
-Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] abstact nonsense was Re: [math][functor] More Design Concerns
Posted by Al Chou <ho...@yahoo.com>.
--- "Craig R. McClanahan" <cr...@apache.org> wrote:
> My understanding is that this is exactly what you'll get from the
> auto-unboxing capability. The compiler will be able to see that the right
> hand side returns a Double, and generate the code to unbox it into a
> double primitive for you.
>
> This is separate from Generics because it also works in other scenarios:
>
> Double d1 = new Double(1.0); // A lowly scalar instance of the wrapper
> double d2 = d1; // But no cast here either!
> d1 = d2 + 0.5; // Or here ... it is bidirectional
IMO, that's even more useful than generics (or limited C++-style templates, if
you prefer to think of them that way). As a math-using person, I really never
wanted to have to make much of a distinction between a double and a Double
(although I somewhat understand the CS considerations that could make having
the distinction desirable).
Al
=====
Albert Davidson Chou
Get answers to Mac questions at http://www.Mac-Mgrs.org/ .
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] abstact nonsense was Re: [math][functor] More Design
Concerns
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 3 Jul 2003, Al Chou wrote:
> Date: Thu, 3 Jul 2003 12:05:49 -0700 (PDT)
> From: Al Chou <ho...@yahoo.com>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Subject: Re: [math] abstact nonsense was Re: [math][functor] More Design
> Concerns
>
> --- "Mark R. Diggory" <md...@latte.harvard.edu> wrote:
> > Anton Tagunov wrote:
> > > 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.
>
> I believe for our purposes it suffices to describe generics as the ability to
> write something like (I'm too lazy to look up the exact syntax):
>
> ArrayList<Double> myArray = new ArrayList()<Double> ;
> Double d ;
> int position = 0 ;
>
> myArray.add( new Double( 1.0 ) ) ;
>
> // Here's the part where generics make life easier. Look, Ma, no cast:
> d = myArray.get( position ) ;
>
My understanding is that this is exactly what you'll get from the
auto-unboxing capability. The compiler will be able to see that the right
hand side returns a Double, and generate the code to unbox it into a
double primitive for you.
This is separate from Generics because it also works in other scenarios:
Double d1 = new Double(1.0); // A lowly scalar instance of the wrapper
double d2 = d1; // But no cast here either!
d1 = d2 + 0.5; // Or here ... it is bidirectional
> Al
>From http://java.sun.com/javaone you can download a webcast of the
Technical General Session on Tuesday morning that covered the 1.5 language
changes, including both of the topics above. It was the first time I'd
ever seen cheering sections for the different proposed features :-).
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] abstact nonsense was Re: [math][functor] More Design Concerns
Posted by Al Chou <ho...@yahoo.com>.
--- "Mark R. Diggory" <md...@latte.harvard.edu> wrote:
> Anton Tagunov wrote:
> > 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.
I believe for our purposes it suffices to describe generics as the ability to
write something like (I'm too lazy to look up the exact syntax):
ArrayList<Double> myArray = new ArrayList()<Double> ;
Double d ;
int position = 0 ;
myArray.add( new Double( 1.0 ) ) ;
// Here's the part where generics make life easier. Look, Ma, no cast:
d = myArray.get( position ) ;
Al
=====
Albert Davidson Chou
Get answers to Mac questions at http://www.Mac-Mgrs.org/ .
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] abstact nonsense was Re: [math][functor] More Design Concerns
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
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