You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "O'brien, Tim" <to...@transolutions.net> on 2003/05/21 19:26:28 UTC
Re: [math] Ok Neo, this should really bake your noodle... (or
k-Statistics)
On Wed, 2003-05-21 at 20:25, Mark R. Diggory wrote:
>
> Phil Steitz wrote:
> > One thing that is starting to cause me some pain is this
> > whole issue of what to return (or throw) when a statistic
> > is meaningless. My inclination is to throw something
> > rather than just returning Double.NAN or 0, but I am
> > ambivalent. I just think that we need to settle on some
> > policies and be consistent. I am interested in what others
> > think about this.
> >
>
> My sentimate is to look to the behavior of the Math/StrictMath classes.
> These classes return NaN's when a function is meaningless.
>
one is a practical concern and one is personal taste, and another one is
influenced by the existing JDK.
1. I'm not interested in libraries that demand a try/catch for
operations such as finding the mean of a set of values. I trust the
developer enough to document and adhere to a contract which can return
Double.NaN instead of using the exception mechanism to signal the
absence of an answer.
2. What is the mean of an empty set? I think that question has a clear
answer - the mean of an empty set is not a number. It isn't zero, and
it isn't EmptySetException. We should throw exceptions for exceptional
conditions such as trying to read an element from array index -23, or
attempting to put a square peg into a round hole.
3. the JDK Math and StrictMath all make liberal use of NaN when an
answer is meaningless, indefinite, unanswerable, etc. IEEE 754 contains
+/- INFINITY and NaN for the exact situations we are encountering.
Trying to find the square root of a -4, or trying to find the maximum
number contained in an empty array.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Re: [patch] developer documentation
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Sorry, my bad...I didn't proof read before I sent it.
-Mark
Tim O'Brien wrote:
>Please conform to the commons practice of prefixing all email with the
>particular project name.
>
>Thanks
>
>Tim
>
>
>On Thu, 2003-05-22 at 11:40, Mark R. Diggory wrote:
>
>
>>You got it boss! ;-)
>>
>>-Mark
>>
>>robert burrell donkin wrote:
>>
>>
>>
>>>then submit a patch!
>>>
>>>- robert
>>>
>>>On Thursday, May 22, 2003, at 04:48 PM, Mark R. Diggory wrote:
>>>
>>>
>>>
>>>>I suspect these should be *required reading* for every Commons Math
>>>>developer, nice references Tim!
>>>>
>>>>-Mark
>>>>
>>>>O'brien, Tim wrote:
>>>>
>>>>
>>>>
>>>>>>OK. You guys have convinced me. We just need to carefully
>>>>>>document "Nan semantics" in interface specifications. thx
>>>>>>
>>>>>>
>>>>>>
>>>>>Phil,
>>>>>
>>>>>I was convinced by the sections regarding NaN and IEEE 754 in these two
>>>>>documents.
>>>>>
>>>>>http://www.validlab.com/goldberg/paper.ps
>>>>>
>>>>>http://www.cs.berkeley.edu/~wkahan/ieee754status/ieee754.ps
>>>>>
>>>>>Tim
>>>>>
>>>>>
>>>>>
>>>>>---------------------------------------------------------------------
>>>>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>>>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>>
>>>>
>>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>
>>>
>>>
>>----
>>
>>
>>
>
>
>
>>Index: developers.xml
>>===================================================================
>>RCS file: /home/cvspublic/jakarta-commons-sandbox/math/xdocs/developers.xml,v
>>retrieving revision 1.1
>>diff -u -r1.1 developers.xml
>>--- developers.xml 20 May 2003 10:27:25 -0000 1.1
>>+++ developers.xml 22 May 2003 16:37:48 -0000
>>@@ -18,6 +18,34 @@
>> <section name='Guidelines'>
>> Still under development...!
>> </section>
>>+ <section name='Recommended Readings'>
>>+ <p>Here is a list of recommended reading and worthy sites for link within JavaDoc comments for Math Developers</p>
>>+ <subsection name='Recommended Readings'>
>>+ <dl>
>>+ <dt>Concerning floating point arithmetic.</dt>
>>+ <dd>
>>+ <a href="http://www.validlab.com/goldberg/paper.ps">
>>+ http://www.validlab.com/goldberg/paper.ps
>>+ </a><br/>
>>+ <a href="http://www.cs.berkeley.edu/~wkahan/ieee754status/ieee754.ps">
>>+ http://www.cs.berkeley.edu/~wkahan/ieee754status/ieee754.ps
>>+ </a><br/>
>>+ </dd>
>>+ </dl>
>>+ </subsection>
>>+ <subsection name='Javadoc Comment Resources'>
>>+ <dl>
>>+ <dt>References for mathematical definitions.</dt>
>>+ <dd>
>>+ <a href="http://rd11.web.cern.ch/RD11/rkb/titleA.html">
>>+ http://rd11.web.cern.ch/RD11/rkb/titleA.html
>>+ </a><br/>
>>+ <a href="http://mathworld.wolfram.com">
>>+ http://mathworld.wolfram.com
>>+ </a><br/>
>>+ </dd>
>>+ </dl>
>>+ </subsection>
>>+ </section>
>> </body>
>>-</document>
>>-
>>+</document>
>>\ No newline at end of file
>>
>>----
>>
>>
>>
>
>
>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[math] Re: [patch] developer documentation
Posted by Tim O'Brien <to...@discursive.com>.
Please conform to the commons practice of prefixing all email with the
particular project name.
Thanks
Tim
On Thu, 2003-05-22 at 11:40, Mark R. Diggory wrote:
> You got it boss! ;-)
>
> -Mark
>
> robert burrell donkin wrote:
>
> > then submit a patch!
> >
> > - robert
> >
> > On Thursday, May 22, 2003, at 04:48 PM, Mark R. Diggory wrote:
> >
> >> I suspect these should be *required reading* for every Commons Math
> >> developer, nice references Tim!
> >>
> >> -Mark
> >>
> >> O'brien, Tim wrote:
> >>
> >>>> OK. You guys have convinced me. We just need to carefully
> >>>> document "Nan semantics" in interface specifications. thx
> >>>>
> >>>
> >>> Phil,
> >>>
> >>> I was convinced by the sections regarding NaN and IEEE 754 in these two
> >>> documents.
> >>>
> >>> http://www.validlab.com/goldberg/paper.ps
> >>>
> >>> http://www.cs.berkeley.edu/~wkahan/ieee754status/ieee754.ps
> >>>
> >>> Tim
> >>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> >>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >>>
> >>>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>
> ----
>
> Index: developers.xml
> ===================================================================
> RCS file: /home/cvspublic/jakarta-commons-sandbox/math/xdocs/developers.xml,v
> retrieving revision 1.1
> diff -u -r1.1 developers.xml
> --- developers.xml 20 May 2003 10:27:25 -0000 1.1
> +++ developers.xml 22 May 2003 16:37:48 -0000
> @@ -18,6 +18,34 @@
> <section name='Guidelines'>
> Still under development...!
> </section>
> + <section name='Recommended Readings'>
> + <p>Here is a list of recommended reading and worthy sites for link within JavaDoc comments for Math Developers</p>
> + <subsection name='Recommended Readings'>
> + <dl>
> + <dt>Concerning floating point arithmetic.</dt>
> + <dd>
> + <a href="http://www.validlab.com/goldberg/paper.ps">
> + http://www.validlab.com/goldberg/paper.ps
> + </a><br/>
> + <a href="http://www.cs.berkeley.edu/~wkahan/ieee754status/ieee754.ps">
> + http://www.cs.berkeley.edu/~wkahan/ieee754status/ieee754.ps
> + </a><br/>
> + </dd>
> + </dl>
> + </subsection>
> + <subsection name='Javadoc Comment Resources'>
> + <dl>
> + <dt>References for mathematical definitions.</dt>
> + <dd>
> + <a href="http://rd11.web.cern.ch/RD11/rkb/titleA.html">
> + http://rd11.web.cern.ch/RD11/rkb/titleA.html
> + </a><br/>
> + <a href="http://mathworld.wolfram.com">
> + http://mathworld.wolfram.com
> + </a><br/>
> + </dd>
> + </dl>
> + </subsection>
> + </section>
> </body>
> -</document>
> -
> +</document>
> \ No newline at end of file
>
> ----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[patch] developer documentation
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
You got it boss! ;-)
-Mark
robert burrell donkin wrote:
> then submit a patch!
>
> - robert
>
> On Thursday, May 22, 2003, at 04:48 PM, Mark R. Diggory wrote:
>
>> I suspect these should be *required reading* for every Commons Math
>> developer, nice references Tim!
>>
>> -Mark
>>
>> O'brien, Tim wrote:
>>
>>>> OK. You guys have convinced me. We just need to carefully
>>>> document "Nan semantics" in interface specifications. thx
>>>>
>>>
>>> Phil,
>>>
>>> I was convinced by the sections regarding NaN and IEEE 754 in these two
>>> documents.
>>>
>>> http://www.validlab.com/goldberg/paper.ps
>>>
>>> http://www.cs.berkeley.edu/~wkahan/ieee754status/ieee754.ps
>>>
>>> Tim
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
Re: [math] Ok Neo, this should really bake your noodle... (ork-Statistics)
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
then submit a patch!
- robert
On Thursday, May 22, 2003, at 04:48 PM, Mark R. Diggory wrote:
> I suspect these should be *required reading* for every Commons Math
> developer, nice references Tim!
>
> -Mark
>
> O'brien, Tim wrote:
>
>>> OK. You guys have convinced me. We just need to carefully document
>>> "Nan semantics" in interface specifications. thx
>>>
>>
>> Phil,
>>
>> I was convinced by the sections regarding NaN and IEEE 754 in these two
>> documents.
>>
>> http://www.validlab.com/goldberg/paper.ps
>>
>> http://www.cs.berkeley.edu/~wkahan/ieee754status/ieee754.ps
>>
>> Tim
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Ok Neo, this should really bake your noodle... (ork-Statistics)
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
I suspect these should be *required reading* for every Commons Math
developer, nice references Tim!
-Mark
O'brien, Tim wrote:
>>OK. You guys have convinced me. We just need to carefully document
>>"Nan semantics" in interface specifications. thx
>>
>>
>
>Phil,
>
>I was convinced by the sections regarding NaN and IEEE 754 in these two
>documents.
>
>http://www.validlab.com/goldberg/paper.ps
>
>http://www.cs.berkeley.edu/~wkahan/ieee754status/ieee754.ps
>
>Tim
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Ok Neo, this should really bake your noodle...
(ork-Statistics)
Posted by "O'brien, Tim" <to...@transolutions.net>.
> OK. You guys have convinced me. We just need to carefully document
> "Nan semantics" in interface specifications. thx
Phil,
I was convinced by the sections regarding NaN and IEEE 754 in these two
documents.
http://www.validlab.com/goldberg/paper.ps
http://www.cs.berkeley.edu/~wkahan/ieee754status/ieee754.ps
Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Ok Neo, this should really bake your noodle... (ork-Statistics)
Posted by Phil Steitz <ph...@steitz.com>.
robert burrell donkin wrote:
> On Thursday, May 22, 2003, at 07:34 PM, Phil Steitz wrote:
>
>> --- robert burrell donkin
>> <ro...@blueyonder.co.uk> wrote:
>
>
> <snip>
>
>>> error handling when dealing with boundary conditions in
>>> particular can
>>> raise long term code maintenance issues. it can be
>>> difficult to work out
>>> what boundary condition violations are associated with
>>> the interface and
>>> which with the particular implementation. it's easy to
>>> add boundary
>>> conditions into the interface contract which are really
>>> part of the
>>> particular implementation.
>>
>>
>> Yes. I have experienced this pain. That is why I am
>> perhaps naively wanting to keep the interface contracts as
>> clean, logical and complete as possible, effectively
>> forcing the implementations to support a reasonable and
>> "standard" contract.
>
>
> i'd definitely agree that interface contracts should be as clean,
> logical and complete as possible.
>
>>> an unforeseen class of
>>> implementations might
>>> have very different characteristics when it comes to
>>> which values are
>>> valid. it can be difficult or impossible to accommodate
>>> these
>>> implementations if the interface's boundary conditions
>>> are specified too
>>> tightly.
>>
>>
>> Can you provide a concrete math or stat example of this? I
>> am asking only so that I can understand exactly what we you
>> mean.
>
>
> fast algorithms which are valid for a smaller range of values
> (specifying boundary conditions means that these algorithms would need
> to fall back on a basic algorithm for values outside their range) and
> power series algorithms that behave reasonably over a larger domain of
> values (i'll expand on this below.)
>
>>> IMHO a more robust approach is:
>>>
>>> 1. to give only general strategies in the interface. so
>>> for example, the
>>> interface might specify that a Double.NaN (or a
>>> IllegalArgumentException
>>> or whatever) would be returned (or thrown, whatever) when
>>> the implementing
>>> algorithm's boundary conditions were not forfilled rather
>>> than specifying
>>> the actually boundary conditions.
>>
>>
>> I need education here, since this looks dangerous to me. I
>> don't see why interfaces can't be fully specified. That
>> creates a much nicer world for the user. In all of the
>> mathematical examples that I can think of, things are
>> either defined and meaningful or they are not, or the
>> defintions differ. My opionion is that it is the
>> responsibility of the interface designer to fully specify
>> the mathematical definitions and the boundary conditions.
>> This is probably a naive view, but I need to understand
>> exactly why.
>
>
> IIRC it's not uncommon to be able to use a power series definition to
> calculate certain functions. using power series to calculate these
> functions can give a bigger range of acceptable parameters than
> calculating these functions from the basic definition.
>
> this ordinarily wouldn't cause too many problems - just create an
> implementation that has a method which can be called which will return
> values for the full valid range of the power series and another which
> implements the interface by rejecting those values outside the valid
> range of the basic function. the user then has a nice choice about which
> to call.
>
> the difficulties arise when these interfaces are used as strategies. if
> you have a more complex computation which uses these interfaces as
> pluggable strategies, then this means that you are prevented (by the
> contract) from using an algorithm with an extended domain even if it
> perfectly reasonable to do so.
>
> (similar issues arise when specifying things such as degrees of
> accuracy. it seems like a good idea to give the user a minimum guarantee
> of the accuracy to which the implementations will perform. when you do
> this with a strategy interface, this prevents a user plugging in a
> fast-but-inaccurate algorithm for use - for example - in a graphical
> application.)
>
> i've taken a look at the stuff in math now and i think i agree with you
> that specifying boundary conditions in the interfaces we have does make
> the code easier to use. if we start using these interfaces as pluggable
> strategies then we may want to think about whether we should create
> separate strategy interfaces with weaker specifications and adapters.
Thanks. Now I understand. My (perhaps naive) inclination is to force
at least the initial interfaces to fully determine contracts. Strategy
interfaces can later be abstracted and used as you describe. We will
likely see the need for this first in the Matrix implementations.
>
> - robert
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Ok Neo, this should really bake your noodle... (ork-Statistics)
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Thursday, May 22, 2003, at 07:34 PM, Phil Steitz wrote:
> --- robert burrell donkin
> <ro...@blueyonder.co.uk> wrote:
<snip>
>> error handling when dealing with boundary conditions in
>> particular can
>> raise long term code maintenance issues. it can be
>> difficult to work out
>> what boundary condition violations are associated with
>> the interface and
>> which with the particular implementation. it's easy to
>> add boundary
>> conditions into the interface contract which are really
>> part of the
>> particular implementation.
>
> Yes. I have experienced this pain. That is why I am
> perhaps naively wanting to keep the interface contracts as
> clean, logical and complete as possible, effectively
> forcing the implementations to support a reasonable and
> "standard" contract.
i'd definitely agree that interface contracts should be as clean, logical
and complete as possible.
>> an unforeseen class of
>> implementations might
>> have very different characteristics when it comes to
>> which values are
>> valid. it can be difficult or impossible to accommodate
>> these
>> implementations if the interface's boundary conditions
>> are specified too
>> tightly.
>
> Can you provide a concrete math or stat example of this? I
> am asking only so that I can understand exactly what we you
> mean.
fast algorithms which are valid for a smaller range of values (specifying
boundary conditions means that these algorithms would need to fall back on
a basic algorithm for values outside their range) and power series
algorithms that behave reasonably over a larger domain of values (i'll
expand on this below.)
>> IMHO a more robust approach is:
>>
>> 1. to give only general strategies in the interface. so
>> for example, the
>> interface might specify that a Double.NaN (or a
>> IllegalArgumentException
>> or whatever) would be returned (or thrown, whatever) when
>> the implementing
>> algorithm's boundary conditions were not forfilled rather
>> than specifying
>> the actually boundary conditions.
>
> I need education here, since this looks dangerous to me. I
> don't see why interfaces can't be fully specified. That
> creates a much nicer world for the user. In all of the
> mathematical examples that I can think of, things are
> either defined and meaningful or they are not, or the
> defintions differ. My opionion is that it is the
> responsibility of the interface designer to fully specify
> the mathematical definitions and the boundary conditions.
> This is probably a naive view, but I need to understand
> exactly why.
IIRC it's not uncommon to be able to use a power series definition to
calculate certain functions. using power series to calculate these
functions can give a bigger range of acceptable parameters than
calculating these functions from the basic definition.
this ordinarily wouldn't cause too many problems - just create an
implementation that has a method which can be called which will return
values for the full valid range of the power series and another which
implements the interface by rejecting those values outside the valid range
of the basic function. the user then has a nice choice about which to call.
the difficulties arise when these interfaces are used as strategies. if
you have a more complex computation which uses these interfaces as
pluggable strategies, then this means that you are prevented (by the
contract) from using an algorithm with an extended domain even if it
perfectly reasonable to do so.
(similar issues arise when specifying things such as degrees of accuracy.
it seems like a good idea to give the user a minimum guarantee of the
accuracy to which the implementations will perform. when you do this with
a strategy interface, this prevents a user plugging in a
fast-but-inaccurate algorithm for use - for example - in a graphical
application.)
i've taken a look at the stuff in math now and i think i agree with you
that specifying boundary conditions in the interfaces we have does make
the code easier to use. if we start using these interfaces as pluggable
strategies then we may want to think about whether we should create
separate strategy interfaces with weaker specifications and adapters.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Ok Neo, this should really bake your noodle... (ork-Statistics)
Posted by Phil Steitz <st...@yahoo.com>.
--- robert burrell donkin
<ro...@blueyonder.co.uk> wrote:
>
> On Thursday, May 22, 2003, at 06:01 AM, Phil Steitz
> wrote:
>
> > O'brien, Tim wrote:
> >> On Wed, 2003-05-21 at 20:25, Mark R. Diggory wrote:
> >>> Phil Steitz wrote:
> >>>
> >>>> One thing that is starting to cause me some pain is
> this
> >>>> whole issue of what to return (or throw) when a
> statistic
> >>>> is meaningless. My inclination is to throw
> something
> >>>> rather than just returning Double.NAN or 0, but I am
> >>>> ambivalent. I just think that we need to settle on
> some
> >>>> policies and be consistent. I am interested in what
> others
> >>>> think about this.
> >>>
> >>> My sentimate is to look to the behavior of the
> Math/StrictMath classes.
> >>> These classes return NaN's when a function is
> meaningless.
> >>>
> >> one is a practical concern and one is personal taste,
> and another one is
> >> influenced by the existing JDK.
> >> 1. I'm not interested in libraries that demand a
> try/catch for
> >> operations such as finding the mean of a set of
> values. I trust the
> >> developer enough to document and adhere to a contract
> which can return
> >> Double.NaN instead of using the exception mechanism to
> signal the
> >> absence of an answer. 2. What is the mean of an empty
> set? I think that
> >> question has a clear
> >> answer - the mean of an empty set is not a number. It
> isn't zero, and
> >> it isn't EmptySetException. We should throw
> exceptions for exceptional
> >> conditions such as trying to read an element from
> array index -23, or
> >> attempting to put a square peg into a round hole.
> >> 3. the JDK Math and StrictMath all make liberal use of
> NaN when an
> >> answer is meaningless, indefinite, unanswerable, etc.
> IEEE 754 contains
> >> +/- INFINITY and NaN for the exact situations we are
> encountering.
> >> Trying to find the square root of a -4, or trying to
> find the maximum
> >> number contained in an empty array.
> > OK. You guys have convinced me. We just need to
> carefully document "Nan
> > semantics" in interface specifications. thx
>
> i do agree with tim on this - but i'd like to add a
> general observation.
>
> error handling when dealing with boundary conditions in
> particular can
> raise long term code maintenance issues. it can be
> difficult to work out
> what boundary condition violations are associated with
> the interface and
> which with the particular implementation. it's easy to
> add boundary
> conditions into the interface contract which are really
> part of the
> particular implementation.
Yes. I have experienced this pain. That is why I am
perhaps naively wanting to keep the interface contracts as
clean, logical and complete as possible, effectively
forcing the implementations to support a reasonable and
"standard" contract.
> an unforeseen class of
> implementations might
> have very different characteristics when it comes to
> which values are
> valid. it can be difficult or impossible to accommodate
> these
> implementations if the interface's boundary conditions
> are specified too
> tightly.
Can you provide a concrete math or stat example of this? I
am asking only so that I can understand exactly what we you
mean.
>
> IMHO a more robust approach is:
>
> 1. to give only general strategies in the interface. so
> for example, the
> interface might specify that a Double.NaN (or a
> IllegalArgumentException
> or whatever) would be returned (or thrown, whatever) when
> the implementing
> algorithm's boundary conditions were not forfilled rather
> than specifying
> the actually boundary conditions.
I need education here, since this looks dangerous to me. I
don't see why interfaces can't be fully specified. That
creates a much nicer world for the user. In all of the
mathematical examples that I can think of, things are
either defined and meaningful or they are not, or the
defintions differ. My opionion is that it is the
responsibility of the interface designer to fully specify
the mathematical definitions and the boundary conditions.
This is probably a naive view, but I need to understand
exactly why.
> 2. if exceptions are thrown, prefer a small number of
> general exceptions
> with general statements of policy. implementations should
> usually throw
> more specific subclasses and specify the subclasses they
> actually throw
> and the exact circumstances in which they throw them.
> this will allow
> unforeseen classes of implementation to be accommodated
> without having to
> break the original exception handling contracts.
>
This I understand and agree with. I also agree with Tim's
point about it being a pain to surround trivial
computations with try-catch blocks.
Thanks for raising these issues and thanks in advance for
helping me understand them better.
Phil
> - robert
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.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] Ok Neo, this should really bake your noodle... (ork-Statistics)
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Thursday, May 22, 2003, at 06:01 AM, Phil Steitz wrote:
> O'brien, Tim wrote:
>> On Wed, 2003-05-21 at 20:25, Mark R. Diggory wrote:
>>> Phil Steitz wrote:
>>>
>>>> One thing that is starting to cause me some pain is this
>>>> whole issue of what to return (or throw) when a statistic
>>>> is meaningless. My inclination is to throw something
>>>> rather than just returning Double.NAN or 0, but I am
>>>> ambivalent. I just think that we need to settle on some
>>>> policies and be consistent. I am interested in what others
>>>> think about this.
>>>
>>> My sentimate is to look to the behavior of the Math/StrictMath classes.
>>> These classes return NaN's when a function is meaningless.
>>>
>> one is a practical concern and one is personal taste, and another one is
>> influenced by the existing JDK.
>> 1. I'm not interested in libraries that demand a try/catch for
>> operations such as finding the mean of a set of values. I trust the
>> developer enough to document and adhere to a contract which can return
>> Double.NaN instead of using the exception mechanism to signal the
>> absence of an answer. 2. What is the mean of an empty set? I think that
>> question has a clear
>> answer - the mean of an empty set is not a number. It isn't zero, and
>> it isn't EmptySetException. We should throw exceptions for exceptional
>> conditions such as trying to read an element from array index -23, or
>> attempting to put a square peg into a round hole.
>> 3. the JDK Math and StrictMath all make liberal use of NaN when an
>> answer is meaningless, indefinite, unanswerable, etc. IEEE 754 contains
>> +/- INFINITY and NaN for the exact situations we are encountering.
>> Trying to find the square root of a -4, or trying to find the maximum
>> number contained in an empty array.
> OK. You guys have convinced me. We just need to carefully document "Nan
> semantics" in interface specifications. thx
i do agree with tim on this - but i'd like to add a general observation.
error handling when dealing with boundary conditions in particular can
raise long term code maintenance issues. it can be difficult to work out
what boundary condition violations are associated with the interface and
which with the particular implementation. it's easy to add boundary
conditions into the interface contract which are really part of the
particular implementation. an unforeseen class of implementations might
have very different characteristics when it comes to which values are
valid. it can be difficult or impossible to accommodate these
implementations if the interface's boundary conditions are specified too
tightly.
IMHO a more robust approach is:
1. to give only general strategies in the interface. so for example, the
interface might specify that a Double.NaN (or a IllegalArgumentException
or whatever) would be returned (or thrown, whatever) when the implementing
algorithm's boundary conditions were not forfilled rather than specifying
the actually boundary conditions.
2. if exceptions are thrown, prefer a small number of general exceptions
with general statements of policy. implementations should usually throw
more specific subclasses and specify the subclasses they actually throw
and the exact circumstances in which they throw them. this will allow
unforeseen classes of implementation to be accommodated without having to
break the original exception handling contracts.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Ok Neo, this should really bake your noodle... (ork-Statistics)
Posted by Phil Steitz <ph...@steitz.com>.
O'brien, Tim wrote:
> On Wed, 2003-05-21 at 20:25, Mark R. Diggory wrote:
>
>>Phil Steitz wrote:
>>
>>>One thing that is starting to cause me some pain is this
>>>whole issue of what to return (or throw) when a statistic
>>>is meaningless. My inclination is to throw something
>>>rather than just returning Double.NAN or 0, but I am
>>>ambivalent. I just think that we need to settle on some
>>>policies and be consistent. I am interested in what others
>>>think about this.
>>>
>>
>>My sentimate is to look to the behavior of the Math/StrictMath classes.
>>These classes return NaN's when a function is meaningless.
>>
>
>
> one is a practical concern and one is personal taste, and another one is
> influenced by the existing JDK.
>
> 1. I'm not interested in libraries that demand a try/catch for
> operations such as finding the mean of a set of values. I trust the
> developer enough to document and adhere to a contract which can return
> Double.NaN instead of using the exception mechanism to signal the
> absence of an answer.
>
> 2. What is the mean of an empty set? I think that question has a clear
> answer - the mean of an empty set is not a number. It isn't zero, and
> it isn't EmptySetException. We should throw exceptions for exceptional
> conditions such as trying to read an element from array index -23, or
> attempting to put a square peg into a round hole.
>
> 3. the JDK Math and StrictMath all make liberal use of NaN when an
> answer is meaningless, indefinite, unanswerable, etc. IEEE 754 contains
> +/- INFINITY and NaN for the exact situations we are encountering.
> Trying to find the square root of a -4, or trying to find the maximum
> number contained in an empty array.
>
>
>
OK. You guys have convinced me. We just need to carefully document
"Nan semantics" in interface specifications. thx
Phil
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org