You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gilles Sadowski <gi...@harfang.homelinux.org> on 2011/09/10 23:51:27 UTC
[Math] Two "Complex" classes? (Was: Re: [math] Complex division)
Hello.
Coming back to this with a simple idea that may hopefully satisfy everyone.
What do you think of having one class that performs all operations by
directly applying the computational formulae, without worrying about NaN
or infinities. This would be represent the complex field, would be simple
and most efficient for general use (not involving limiting cases), would be
documented as "producing undefined results in limiting cases" or "producing
the results expected from direct application of the formulae". The latter
would probably automatically keep track of all combinations of NaNs and
infinities (as seems to be the case in Octave).
In a subclass of the above one, we would attempt to get a completely
consistent representation of the extended complex numbers (one point at
infinity). It would thus contain all the special handling of the limiting
cases of the current "Complex" class (plus all the missing ones and related
bug fixes).
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Two "Complex" classes? (OT)
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
> Well that is interesting. One of my first involvements with CM was
> suggesting just this. The suggestion was roundly shouted down. The Mikkel
> suggested it. It was declined.
>
> I am glad that you finally succeeded.
But you were there too! I was not discussing this with myself :-). Nor did I
start the discussion, because I did not have any use for sampling; I just
happened to agree that it was natural to get samples from a distribution.
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Two "Complex" classes? (OT)
Posted by Ted Dunning <te...@gmail.com>.
Well that is interesting. One of my first involvements with CM was
suggesting just this. The suggestion was roundly shouted down. The Mikkel
suggested it. It was declined.
I am glad that you finally succeeded.
On Sun, Sep 11, 2011 at 3:54 PM, Gilles Sadowski <
gilles@harfang.homelinux.org> wrote:
> >
> > 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?
>
Re: [Math] Two "Complex" classes? (OT)
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
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
Re: [Math] Two "Complex" classes? (Was: Re: [math] Complex division)
Posted by Ted Dunning <te...@gmail.com>.
No. I have to admit that I haven't looked at these classes for a long time.
I am glad to hear that sampling is in the distributions.
On Sun, Sep 11, 2011 at 3:09 PM, Phil Steitz <ph...@gmail.com> wrote:
> 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. 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.
>
> Have you looked at the code in trunk for the distributions? Does it
> still need to be made easier to use? We added sampling directly to
> the distribution classes. If it still looks too hard to use,
> patches are welcome as we prepare for 3.0.
>
> Phil
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [Math] Two "Complex" classes? (Was: Re: [math] Complex division)
Posted by Phil Steitz <ph...@gmail.com>.
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. 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.
Have you looked at the code in trunk for the distributions? Does it
still need to be made easier to use? We added sampling directly to
the distribution classes. If it still looks too hard to use,
patches are welcome as we prepare for 3.0.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Two "Complex" classes? (Was: Re: [math] Complex division)
Posted by Ted Dunning <te...@gmail.com>.
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".
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. 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.
Sometimes, it's so focused towards user applications that any other
> consideration is overriden.
>
I can't remember such a case.
> 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.
Adding frills and filips is the opposite of user centered design.
Re: [Math] Two "Complex" classes? (Was: Re: [math] Complex division)
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hi Ted.
> Nah... I just meant get some usable code done before the inevitable
> discussion winds down. Discussions about designs in commons math tend to
> follow the pattern of a) proposing an OK design, b) proposing a fine
> improvement, and then c) iterating forever on hair-splitting details. The
> final result is rarely as good as even (a), much less (b).
I can more or less agree on the symptoms described above.
> The final design
> also tends to be very strongly focussed on obscure object-orientated design
> orthodoxy and not at all focussed on the end user of the library.
However, I would not derive the same diagnosis.
[Well, in my view, much of the hair-splitting comes from not enough of OO
design, in the sense that when it is recognized that the design is lacking,
it might be necessary to heavily refactor, which almost by definition
clashes with backward compatibility requirements.]
Discussions on this list are sufficiently tense that we probably don't need
to have a flame war on OO. :-}
As for not being focused on the end user, I don't think that it is true.
Sometimes, it's so focused towards user applications that any other
consideration is overriden.
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.
> [...]
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Two "Complex" classes? (Was: Re: [math] Complex division)
Posted by Ted Dunning <te...@gmail.com>.
Nah... I just meant get some usable code done before the inevitable
discussion winds down. Discussions about designs in commons math tend to
follow the pattern of a) proposing an OK design, b) proposing a fine
improvement, and then c) iterating forever on hair-splitting details. The
final result is rarely as good as even (a), much less (b). The final design
also tends to be very strongly focussed on obscure object-orientated design
orthodoxy and not at all focussed on the end user of the library.
So much suggestion is that we are now at (b) and somebody needs to code
something up quick and not wait for (c) to finish.
On Sun, Sep 11, 2011 at 6:51 AM, Phil Steitz <ph...@gmail.com> wrote:
> On 9/10/11 3:19 PM, Ted Dunning wrote:
> > Sounds great.
> >
> > Especially if the implementation of the sub-class is deferred until the
> > first is completed.
>
> What exactly do you mean by "the first is completed" - reverting
> what is in trunk now to eliminate the checks / recodes that it does?
>
> Phil
> >
> > On Sat, Sep 10, 2011 at 2:51 PM, Gilles Sadowski <
> > gilles@harfang.homelinux.org> wrote:
> >
> >> Hello.
> >>
> >> Coming back to this with a simple idea that may hopefully satisfy
> everyone.
> >>
> >> What do you think of having one class that performs all operations by
> >> directly applying the computational formulae, without worrying about NaN
> >> or infinities. This would be represent the complex field, would be
> simple
> >> and most efficient for general use (not involving limiting cases), would
> be
> >> documented as "producing undefined results in limiting cases" or
> "producing
> >> the results expected from direct application of the formulae". The
> latter
> >> would probably automatically keep track of all combinations of NaNs and
> >> infinities (as seems to be the case in Octave).
> >>
> >> In a subclass of the above one, we would attempt to get a completely
> >> consistent representation of the extended complex numbers (one point at
> >> infinity). It would thus contain all the special handling of the
> limiting
> >> cases of the current "Complex" class (plus all the missing ones and
> related
> >> bug fixes).
> >>
> >>
> >> Regards,
> >> Gilles
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [Math] Two "Complex" classes? (Was: Re: [math] Complex division)
Posted by Phil Steitz <ph...@gmail.com>.
On 9/10/11 3:19 PM, Ted Dunning wrote:
> Sounds great.
>
> Especially if the implementation of the sub-class is deferred until the
> first is completed.
What exactly do you mean by "the first is completed" - reverting
what is in trunk now to eliminate the checks / recodes that it does?
Phil
>
> On Sat, Sep 10, 2011 at 2:51 PM, Gilles Sadowski <
> gilles@harfang.homelinux.org> wrote:
>
>> Hello.
>>
>> Coming back to this with a simple idea that may hopefully satisfy everyone.
>>
>> What do you think of having one class that performs all operations by
>> directly applying the computational formulae, without worrying about NaN
>> or infinities. This would be represent the complex field, would be simple
>> and most efficient for general use (not involving limiting cases), would be
>> documented as "producing undefined results in limiting cases" or "producing
>> the results expected from direct application of the formulae". The latter
>> would probably automatically keep track of all combinations of NaNs and
>> infinities (as seems to be the case in Octave).
>>
>> In a subclass of the above one, we would attempt to get a completely
>> consistent representation of the extended complex numbers (one point at
>> infinity). It would thus contain all the special handling of the limiting
>> cases of the current "Complex" class (plus all the missing ones and related
>> bug fixes).
>>
>>
>> Regards,
>> Gilles
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Two "Complex" classes? (Was: Re: [math] Complex division)
Posted by Ted Dunning <te...@gmail.com>.
Sounds great.
Especially if the implementation of the sub-class is deferred until the
first is completed.
On Sat, Sep 10, 2011 at 2:51 PM, Gilles Sadowski <
gilles@harfang.homelinux.org> wrote:
> Hello.
>
> Coming back to this with a simple idea that may hopefully satisfy everyone.
>
> What do you think of having one class that performs all operations by
> directly applying the computational formulae, without worrying about NaN
> or infinities. This would be represent the complex field, would be simple
> and most efficient for general use (not involving limiting cases), would be
> documented as "producing undefined results in limiting cases" or "producing
> the results expected from direct application of the formulae". The latter
> would probably automatically keep track of all combinations of NaNs and
> infinities (as seems to be the case in Octave).
>
> In a subclass of the above one, we would attempt to get a completely
> consistent representation of the extended complex numbers (one point at
> infinity). It would thus contain all the special handling of the limiting
> cases of the current "Complex" class (plus all the missing ones and related
> bug fixes).
>
>
> Regards,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [Math] Two "Complex" classes?
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hello.
> >>>
> >>> Coming back to this with a simple idea that may hopefully satisfy everyone.
> >>>
> >>> What do you think of having one class that performs all operations by
> >>> directly applying the computational formulae, without worrying about NaN
> >>> or infinities. This would be represent the complex field, would be simple
> >>> and most efficient for general use (not involving limiting cases), would be
> >>> documented as "producing undefined results in limiting cases" or "producing
> >>> the results expected from direct application of the formulae". The latter
> >>> would probably automatically keep track of all combinations of NaNs and
> >>> infinities (as seems to be the case in Octave).
> >>>
> >>> In a subclass of the above one, we would attempt to get a completely
> >>> consistent representation of the extended complex numbers (one point at
> >>> infinity). It would thus contain all the special handling of the limiting
> >>> cases of the current "Complex" class (plus all the missing ones and related
> >>> bug fixes).
> >> I agree that to make everyone happy we are going to have to do
> >> something like this, but I would suggest that either we need a third
> >> implementation or the second one should try to implement C99x [1],
> >> preserving signed infinities. I have never seen a fully consistent
> >> implementation of the Riemannian space and if what we want is
> >> consistency with C-based packages, we are better off biting the
> >> bullet and implementing C99x. That could be done by either someone
> >> using their employer or other resource to get hold of the spec or
> >> reverse engineering a C-based OSS implementation like GCC or R. So
> >> I am +1 to
> >>
> >> 0) strip out the recoding / checks in trunk, reverting to previous
> >> "apply formulas and return the results" approach, documenting as the
> >> trig functions now do. (If we do this, we should remember to reopen
> >> any tickets that led to the checks in trunk and either close them as
> >> WONT_FIX or refer to the proposed second implementation as the
> >> proposed fix)
> >> 1) implement C99x in a subclass
> >>
> >> If we choose to implement something other than C99x in the subclass,
> >> we need to agree on the spec for it. Given the vagueness in at
> >> least the draft version of the spec, even in 1), it may turn out to
> >> be best to choose a reference implementation to emulate. In either
> >> case, full documentation of behavior in the javadoc will be necessary.
> >>
> >> As I have said before, I am also fine - and would prefer- doing
> >> nothing, i.e. staying with the documented contracts that are in the
> >> trunk now, realizing that they are not consistent with either the
> >> full Riemannian view or C99x. I see both of these as having
> >> pitfalls and the value of these changes as not worth users of the
> >> main class having to make changes to their exception management code
> >> to accommodate the change. I can see I am in the minority here, so
> >> I am OK with the split implementation idea above.
> > To avoid (or delay) any burden on satisfied users of the "Complex" class, we
> > could leave it as-is for now and create a new "BasicComplex" that will
> > contain the "apply formulas and return the results" approach.
> >
> > Then, if time and motivation allows, gradually implement an
> > "ExtendedComplex" class and/or a "C99Complex" class.
> >
> > Only when that work is done (after the hair-splitting and all), can it be
> > decided to deprecate "Complex" (telling users that they will be better off
> > using one of the new classes).
>
> Sounds good to me. When all is said and done, we might think about
> extracting the (by then stable) interface and just allowing the
> multiple impls to all exist. Or have the Complex class expose
> factory methods to create instances with the "basic" or "extended"
> behavior. In any case, we don't have to decide that yet.
JIRA issue opened:
https://issues.apache.org/jira/browse/MATH-667
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Two "Complex" classes?
Posted by Phil Steitz <ph...@gmail.com>.
On 9/11/11 2:50 PM, Gilles Sadowski wrote:
> On Sun, Sep 11, 2011 at 07:21:20AM -0700, Phil Steitz wrote:
>> On 9/10/11 2:51 PM, Gilles Sadowski wrote:
>>> Hello.
>>>
>>> Coming back to this with a simple idea that may hopefully satisfy everyone.
>>>
>>> What do you think of having one class that performs all operations by
>>> directly applying the computational formulae, without worrying about NaN
>>> or infinities. This would be represent the complex field, would be simple
>>> and most efficient for general use (not involving limiting cases), would be
>>> documented as "producing undefined results in limiting cases" or "producing
>>> the results expected from direct application of the formulae". The latter
>>> would probably automatically keep track of all combinations of NaNs and
>>> infinities (as seems to be the case in Octave).
>>>
>>> In a subclass of the above one, we would attempt to get a completely
>>> consistent representation of the extended complex numbers (one point at
>>> infinity). It would thus contain all the special handling of the limiting
>>> cases of the current "Complex" class (plus all the missing ones and related
>>> bug fixes).
>> I agree that to make everyone happy we are going to have to do
>> something like this, but I would suggest that either we need a third
>> implementation or the second one should try to implement C99x [1],
>> preserving signed infinities. I have never seen a fully consistent
>> implementation of the Riemannian space and if what we want is
>> consistency with C-based packages, we are better off biting the
>> bullet and implementing C99x. That could be done by either someone
>> using their employer or other resource to get hold of the spec or
>> reverse engineering a C-based OSS implementation like GCC or R. So
>> I am +1 to
>>
>> 0) strip out the recoding / checks in trunk, reverting to previous
>> "apply formulas and return the results" approach, documenting as the
>> trig functions now do. (If we do this, we should remember to reopen
>> any tickets that led to the checks in trunk and either close them as
>> WONT_FIX or refer to the proposed second implementation as the
>> proposed fix)
>> 1) implement C99x in a subclass
>>
>> If we choose to implement something other than C99x in the subclass,
>> we need to agree on the spec for it. Given the vagueness in at
>> least the draft version of the spec, even in 1), it may turn out to
>> be best to choose a reference implementation to emulate. In either
>> case, full documentation of behavior in the javadoc will be necessary.
>>
>> As I have said before, I am also fine - and would prefer- doing
>> nothing, i.e. staying with the documented contracts that are in the
>> trunk now, realizing that they are not consistent with either the
>> full Riemannian view or C99x. I see both of these as having
>> pitfalls and the value of these changes as not worth users of the
>> main class having to make changes to their exception management code
>> to accommodate the change. I can see I am in the minority here, so
>> I am OK with the split implementation idea above.
> To avoid (or delay) any burden on satisfied users of the "Complex" class, we
> could leave it as-is for now and create a new "BasicComplex" that will
> contain the "apply formulas and return the results" approach.
>
> Then, if time and motivation allows, gradually implement an
> "ExtendedComplex" class and/or a "C99Complex" class.
>
> Only when that work is done (after the hair-splitting and all), can it be
> decided to deprecate "Complex" (telling users that they will be better off
> using one of the new classes).
Sounds good to me. When all is said and done, we might think about
extracting the (by then stable) interface and just allowing the
multiple impls to all exist. Or have the Complex class expose
factory methods to create instances with the "basic" or "extended"
behavior. In any case, we don't have to decide that yet.
Phil
>
>
> Gilles
>
>> [1] Quite likely, whatever is approved by now is called something
>> like "Annex X of C00.y" - what I am referring to is whatever
>> "informative" or normative guidance the current C spec provides for
>> complex arithmetic and standard functions.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Two "Complex" classes?
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
On Sun, Sep 11, 2011 at 07:21:20AM -0700, Phil Steitz wrote:
> On 9/10/11 2:51 PM, Gilles Sadowski wrote:
> > Hello.
> >
> > Coming back to this with a simple idea that may hopefully satisfy everyone.
> >
> > What do you think of having one class that performs all operations by
> > directly applying the computational formulae, without worrying about NaN
> > or infinities. This would be represent the complex field, would be simple
> > and most efficient for general use (not involving limiting cases), would be
> > documented as "producing undefined results in limiting cases" or "producing
> > the results expected from direct application of the formulae". The latter
> > would probably automatically keep track of all combinations of NaNs and
> > infinities (as seems to be the case in Octave).
> >
> > In a subclass of the above one, we would attempt to get a completely
> > consistent representation of the extended complex numbers (one point at
> > infinity). It would thus contain all the special handling of the limiting
> > cases of the current "Complex" class (plus all the missing ones and related
> > bug fixes).
>
> I agree that to make everyone happy we are going to have to do
> something like this, but I would suggest that either we need a third
> implementation or the second one should try to implement C99x [1],
> preserving signed infinities. I have never seen a fully consistent
> implementation of the Riemannian space and if what we want is
> consistency with C-based packages, we are better off biting the
> bullet and implementing C99x. That could be done by either someone
> using their employer or other resource to get hold of the spec or
> reverse engineering a C-based OSS implementation like GCC or R. So
> I am +1 to
>
> 0) strip out the recoding / checks in trunk, reverting to previous
> "apply formulas and return the results" approach, documenting as the
> trig functions now do. (If we do this, we should remember to reopen
> any tickets that led to the checks in trunk and either close them as
> WONT_FIX or refer to the proposed second implementation as the
> proposed fix)
> 1) implement C99x in a subclass
>
> If we choose to implement something other than C99x in the subclass,
> we need to agree on the spec for it. Given the vagueness in at
> least the draft version of the spec, even in 1), it may turn out to
> be best to choose a reference implementation to emulate. In either
> case, full documentation of behavior in the javadoc will be necessary.
>
> As I have said before, I am also fine - and would prefer- doing
> nothing, i.e. staying with the documented contracts that are in the
> trunk now, realizing that they are not consistent with either the
> full Riemannian view or C99x. I see both of these as having
> pitfalls and the value of these changes as not worth users of the
> main class having to make changes to their exception management code
> to accommodate the change. I can see I am in the minority here, so
> I am OK with the split implementation idea above.
To avoid (or delay) any burden on satisfied users of the "Complex" class, we
could leave it as-is for now and create a new "BasicComplex" that will
contain the "apply formulas and return the results" approach.
Then, if time and motivation allows, gradually implement an
"ExtendedComplex" class and/or a "C99Complex" class.
Only when that work is done (after the hair-splitting and all), can it be
decided to deprecate "Complex" (telling users that they will be better off
using one of the new classes).
Gilles
>
> [1] Quite likely, whatever is approved by now is called something
> like "Annex X of C00.y" - what I am referring to is whatever
> "informative" or normative guidance the current C spec provides for
> complex arithmetic and standard functions.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Two "Complex" classes? (Was: Re: [math] Complex division)
Posted by Phil Steitz <ph...@gmail.com>.
On 9/10/11 2:51 PM, Gilles Sadowski wrote:
> Hello.
>
> Coming back to this with a simple idea that may hopefully satisfy everyone.
>
> What do you think of having one class that performs all operations by
> directly applying the computational formulae, without worrying about NaN
> or infinities. This would be represent the complex field, would be simple
> and most efficient for general use (not involving limiting cases), would be
> documented as "producing undefined results in limiting cases" or "producing
> the results expected from direct application of the formulae". The latter
> would probably automatically keep track of all combinations of NaNs and
> infinities (as seems to be the case in Octave).
>
> In a subclass of the above one, we would attempt to get a completely
> consistent representation of the extended complex numbers (one point at
> infinity). It would thus contain all the special handling of the limiting
> cases of the current "Complex" class (plus all the missing ones and related
> bug fixes).
I agree that to make everyone happy we are going to have to do
something like this, but I would suggest that either we need a third
implementation or the second one should try to implement C99x [1],
preserving signed infinities. I have never seen a fully consistent
implementation of the Riemannian space and if what we want is
consistency with C-based packages, we are better off biting the
bullet and implementing C99x. That could be done by either someone
using their employer or other resource to get hold of the spec or
reverse engineering a C-based OSS implementation like GCC or R. So
I am +1 to
0) strip out the recoding / checks in trunk, reverting to previous
"apply formulas and return the results" approach, documenting as the
trig functions now do. (If we do this, we should remember to reopen
any tickets that led to the checks in trunk and either close them as
WONT_FIX or refer to the proposed second implementation as the
proposed fix)
1) implement C99x in a subclass
If we choose to implement something other than C99x in the subclass,
we need to agree on the spec for it. Given the vagueness in at
least the draft version of the spec, even in 1), it may turn out to
be best to choose a reference implementation to emulate. In either
case, full documentation of behavior in the javadoc will be necessary.
As I have said before, I am also fine - and would prefer- doing
nothing, i.e. staying with the documented contracts that are in the
trunk now, realizing that they are not consistent with either the
full Riemannian view or C99x. I see both of these as having
pitfalls and the value of these changes as not worth users of the
main class having to make changes to their exception management code
to accommodate the change. I can see I am in the minority here, so
I am OK with the split implementation idea above.
Phil
[1] Quite likely, whatever is approved by now is called something
like "Annex X of C00.y" - what I am referring to is whatever
"informative" or normative guidance the current C spec provides for
complex arithmetic and standard functions.
>
>
> Regards,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org