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
Craig R. McClanahan wrote:
According to the JSR:
== begin quote ==
It is explicitly not required that the system
...
b) Support the use of primitive types as type arguments: While
allowing the use of primitive types (e.g., int, boolean) as type
arguments would be nice, it should not be a goal of
--- Mark R. Diggory [EMAIL PROTECTED] 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
--- Craig R. McClanahan [EMAIL PROTECTED] 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
Brent Worden wrote:
-Original Message-
From: Phil Steitz [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 01, 2003 11:08 PM
To: Jakarta Commons Developers List
Subject: [math] abstact nonsense was Re: [math][functor] More Design
Concerns
The changed subject line is a pun that I hope none
Phil Steitz wrote:
Brent Worden wrote:
Unfortunately, Java has created a huge distinction between objects and
primitives. They're incompatible types. Objects have to be treated
in a
distinctly different manner than primitive values. I prefer objects
over
primitives because the other commons
Brent Worden wrote:
And with HotSpot, frequently executed pieces of code will actually start to
increase in performance as a application runs longer, and in many occasions
eclipse C or C++ performance.
That's what the Java lobby wants you to believe since the introduction
of the first JITC. You
Brent Worden wrote:
The only issues I have are with the UnivariateRealSolverFactory class. I
feel there should be a separation of the factory method and the solve
methods. I don't think the solve method belong on a factory. They are more
appropriately placed (do I dare say) in a SolverUtils
I've been playing around with the Functor library a little and I reworked
the bisection routine to be functorfied. With the addition of functors, the
algorithm has become totally agnostic to its input allowing it to be used in
an endless number of settings. The code goes as follows:
Brent Worden wrote:
This example also helps illustrate what I would like the design of the
library to proceed:
1) There are a collection of utility objects to perform standard operations
on standard input. StatUtils is a good example of this.
2) Factories to create operation objects that perform
My point in (b.) is to discuss what amount to Facades approached in
classes/interfaces like (Store)Univariate and RealMatrix, and the idea
that there are decisions being made concerning how the Facades are
backed by various implementation strategies, not to suggest that the
Facades
On Tue, 01 Jul 2003 14:40:16 -0400, Mark R. Diggory wrote:
Brent Worden wrote:
This example also helps illustrate what I would like the design of
the
library to proceed:
1) There are a collection of utility objects to perform standard
operations
on standard input. StatUtils is a good
[EMAIL PROTECTED] wrote:
I would steer away for primative as much as possible.
Keep in mind that excessive object creation can and usually is
a significant performance drain, both because it is slow in itself
despite all kinds of optimization as well as causing more GC.
J.Pietschmann
--- J.Pietschmann [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
I would steer away for primative as much as possible.
Keep in mind that excessive object creation can and usually is
a significant performance drain, both because it is slow in itself
despite all kinds of optimization as
On Tue, 1 Jul 2003, Mark R. Diggory wrote:
Part of this issue is technical the other political, [...]
[Functor] isn't going to be available as a
maven/build dependency until it graduates.
For the record, whether appropriate or not, other commons-sandbox
components are available via maven,
Rodney Waldhoff wrote:
On Tue, 1 Jul 2003, Mark R. Diggory wrote:
Part of this issue is technical the other political, [...]
[Functor] isn't going to be available as a
maven/build dependency until it graduates.
For the record, whether appropriate or not, other commons-sandbox
components
The changed subject line is a pun that I hope none will find insulting -
sort of a little math joke. Abstract nonsense is the term that some
mathematicians (including some who love the stuff) use to refer to
category theory, the birthplace of the functor concept. To conserve
bandwidth, I am
-Original Message-
From: J.Pietschmann [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 01, 2003 2:43 PM
To: Jakarta Commons Developers List
Subject: Re: [math][functor] More Design Concerns
[EMAIL PROTECTED] wrote:
I would steer away for primative as much as possible.
Keep
Phil Steitz wrote:
I agree. My preference would be to eliminate the original
RootFinding.java and refactor the distribution inversion methods to use
the new framework. Before taking that step, however, I would like to
hear Brent's opinion on what might be improved in the new framework.
I've
Sorry for my non-response on any part of this thread. I've been away on
vacation.
-Original Message-
From: Phil Steitz [mailto:[EMAIL PROTECTED]
Sent: Friday, June 27, 2003 7:20 PM
To: Jakarta Commons Developers List
Subject: Re: [math][functor] More Design Concerns
J.Pietschmann
Phil Steitz wrote:
3 Both MathException and ConvergenceException don't compile on Java 1.3
and nobody noticed. This is ugly:
Ranks inserted (IMHO, of course)
Agreed with rankings. However, I think in the long term either
the recursive exception should be factored out of [lang] into
a separate
Al Chou wrote:
--- Phil Steitz [EMAIL PROTECTED] wrote:
Does staticness preclude extensibility? I assume final-ity would, but we
didn't declare any methods final, AFAIK.
Strictly speaking, no; but static methods do not support polymorphism
and inheritance in the way that instance methods do.
--- J.Pietschmann [EMAIL PROTECTED] wrote:
Al Chou wrote:
Does staticness preclude extensibility?
...
I clearly have never studied for a Java certification. g Thanks for the
clarification, Phil.
No difference to C++ or any other language with class methods
I ever met.
I'm not much of
J.Pietschmann wrote:
5 Static functions for calculating higher moments for arrays are unwise,
because the array is repeatedly scanned if several moments are to be
computed. This should be encapsulated in an object which can hold
already
computed results across invocations of different
J.Pietschmann wrote:
Mark R. Diggory wrote:
Further comments:
1 Now there are two root finding frameworks in place. I think this should
be unified.
I agree. My preference would be to eliminate the original
RootFinding.java and refactor the distribution inversion methods to use
the new
--- Phil Steitz [EMAIL PROTECTED] wrote:
(2) Considerations
a.) Is consistent library design important?Can all these models
interace effectively? Are all these different design models required? Is
there a single design model that can span the entire library?
IMHO, the most important
Rodney Waldhoff wrote:
On Tue, 24 Jun 2003, Mark R. Diggory wrote:
Either way, I hope some of us will take a quick over the the package and
comment according about their opinion. I hope Rodney Waldhoff will feel
comfortable about stepping back in and discussing some more about his
approach
(2) Considerations
a.) Is consistent library design important?Can all these models
interace effectively? Are all these different design models required? Is
there a single design model that can span the entire library?
IMHO, the most important considerations are 1) how easy the library will
be
c.) What is the platform of interest for [math]? Server Side or
Application.
Remember that Jakarta's mission is create *server-side* libraries:
http://jakarta.apache.org/site/mission.html
That doesn't mean that a library couldn't be used in client-side apps but
it does mean that your
(1) Overview of the library design to date
[analysis]:
Uses Objectified Functions, or Functors these objects resemble the
same approach used in the Commons sandbox Functor package.
[stats]:
Univariate use what amount to Data Beans with get/set style methods,
StatUtils provide easy static access
30 matches
Mail list logo
