commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <gil...@harfang.homelinux.org>
Subject Re: [Math] Two "Complex" classes? (OT)
Date Sun, 11 Sep 2011 22:54:12 GMT
On Sun, Sep 11, 2011 at 02:50:56PM -0700, Ted Dunning wrote:
> On Sun, Sep 11, 2011 at 2:37 PM, Gilles Sadowski <
> gilles@harfang.homelinux.org> wrote:
> 
> > Discussions on this list are sufficiently tense that we probably don't need
> > to have a flame war on OO. :-}
> >
> 
> And I would hate to start that given that I think the discussions go too
> long in any case.
> 
> 
> > As for not being focused on the end user, I don't think that it is true.
> >
> 
> Well, the recent discussion of exceptions for Cholesky decomposition was a
> great example.  The suggestion was to throw an exception that basically said
> "one number that you have no idea of is less than another idea that is an
> obscure combination of stuff you input".  The argument was that this was
> "more precise".  The user centered exception is "you input was not positive
> definite".

My bad; I tried to be (too) nice to the end-user as per the numerous times
repeated argument that they should not have to turn to the source code in
order to figure out why their input was wrong (by input, I mean the
"threshold"). If the threshold is not the end-user's business, then why
allow to set it?  If allowing to set it, why not report that changing it
might change the behaviour?
Is there is a way to deduce _the_ correct value of the threshold given the
input matrix?

> 
> Another example comes from the random distributions.  The current design
> separates generating values from evaluating CDF's even though users think of
> those as operations on the same object.

I remember that one round of this discussion happened when I started to
contribute to CM. And I had been in favour of providing an interface to
generated data inside the distribution objects. This led to a "sample"
method being available in all those objects. Is it still not satisfactory?

> Moreover, there is an intricate
> lattice of (unique) implementations and interfaces that the user has to
> figure out when all they want is a distribution.  This isn't user centered
> design.   And it doesn't facilitate improvement or back compatibility.

We all agree that when a single implementation of an interface exists, it
should replace it.
I bet that your patch to fix this will be readily applied. ;-)

> 
> Sometimes, it's so focused towards user applications that any other
> > consideration is overriden.
> >
> 
> I can't remember such a case.

You don't have to remember one; the discussion happening right now about
preset tables for "FastMath" is a perfect example of rushing to please a
user.

> 
> >  One of the dangers of only focusing on end-users is adding features
> > without
> > rhyme or reason; that will ultimately leads to unnecessarily complex and
> > consequently unmaintainable code, resulting in the death of the project,
> > with the consequence that the beloved user will be left with nothing.
> >
> 
> That isn't user centered.  User centered means implementing what the user
> actually needs and will use.  Need and use of a function means that it has
> at least some reason.  Rhyme comes from the design elements which cannot be
> forgotten.

IMO, this is backwards: I don't think that a general-purpose library can be
based purely on practical requirements; there needs to be an overall design,
which the end-user might not care about, but which will guarantee long-term
viability.
If the design is sound, then forgotten elements can be added easily; if they
can't, that means that it's time to refactor, as I said in the previous
message.

> Adding frills and filips is the opposite of user centered design.

What I meant is: trying to twist the design to accomodate what does not fit.
[For example, compare the root solvers in CM 2.2 and in trunk.]


Regards,
Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message