OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] Issue Comment Edited: (OFFICE-2246) PROB:check and specify details



    [ http://tools.oasis-open.org/issues/browse/OFFICE-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17396#action_17396 ] 

Dennis Hamilton edited comment on OFFICE-2246 at 1/6/10 1:31 AM:
-----------------------------------------------------------------

We have a general problem any time tight bounds are specified.  See also my 2010-01-04 comment on OFFICE-2209.

  1. In this case, we do need to tolerate results of exactly 0 (when there are no discrete possibilities in the interval specified to PROB.  (I notice nothing is said about the assured bounds on the result.)  Also, there needs to be a statement on the bounds with respect to the interval from start to end.  (Because start is included in the default case, I would assume that the end is included in the range when given such that end >= start.  Also, the result could be slightly greater than 1 the same way as the sum might be.

 2. With regard to whether the sum of the probabilities exceeds 1, I wonder whether there should be a tolerance for a slightly higher sum or the user of the function should assertain that the sum is strictly <= 1.  We have the problem when the sum is slightly less than 1 too.  

 3. One could be cute and normalize the result (since the sum can be computed while the scan for discrete possibilities in the interval is happening.  I think that is too cute, since the users could do result normalization on their own. 

 4. For me, that leaves the question of PROB producing a result, when the result is 1+epsilon or the sum of the Probability elements is also 1+epsilon or 1-epsilon.  I wonder what various implementations do with these particular edge cases?

 5. Another way would be to define the function as calculating a density on the interval without regard to what the Probability values are (even if negative) then assert that the result is a probability when the probability condition applies to the Probability array.  I suspect that is a punt too far, although it assures a result and leaves satisfaction of any invariants up to the user.

I'm sure there are other speculations to be made here.  I think it is clear that we have to look at computation error around mathematically-sharp edge cases.



      was (Author: orcmid):
    We have a general problem any time tight bounds are specified.  See also my 2010-01-04 comment on OFFICE-2209.

  1. In this case, we do need to tolerate results of exactly 0 (when there are no discrete possibilities in the interval specified to PROB.  (I notice nothing is said about the assured bounds on the result.)  Also, there needs to be a statement on the bounds with respect to the interval from start to end.  (Because start is included in the default case, I would assume that the end, when given and end >= start, the end is included in the range.  Also, the result could be slightly greater than 1 the same way as the sum might be.


 2. With regard to whether the sum of the probabilities exceeds 1, I wonder whether there should be a tolerance for a slightly higher sum or the user of the function should assertain that the sum is strictly <= 1.  We have the problem when the sum is slightly less than 1 too.  

 3. One could be cute and normalize the result (since the sum can be computed while the scan for discrete possibilities in the interval is happening.  I think that is too cute, since the users could do result normalization on their own. 

 4. For me, that leaves the question of PROB producing a result, when the result is 1+epsilon or the sum of the Probability elements is also 1+epsilon or 1-epsilon.  I wonder what various implementations do with these particular edge cases?

 5. Another way would be to define the function as calculating a density on the interval without regard to what the Probability values are (even if negative) then assert that the result is a probability when the probability condition applies to the Probability array.  I suspect that is a punt too far, although it assures a result and leaves satisfaction of any invariants up to the user.

I'm sure there are other speculations to be made here.  I think it is clear that we have to look at computation error around mathematically-sharp edge cases.


  
> PROB: check and specify details
> -------------------------------
>
>                 Key: OFFICE-2246
>                 URL: http://tools.oasis-open.org/issues/browse/OFFICE-2246
>             Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
>          Issue Type: Sub-task
>          Components: OpenFormula
>    Affects Versions: ODF 1.2
>            Reporter: Eike Rathke
>            Assignee: Andreas Guelzow 
>             Fix For: ODF 1.2
>
>
> Broken out from OFFICE-1170
> PROB
> *This needs to specify if Data must be ordered or not (unordered?).
> *It would also be better to be clear about whether Data must be sequential (is 1, 2, 3, 5 (missing 4) OK?) and/or integer (is 1, 2.5, 3,4 OK?).
> *It would also be better to be clear about whether Start and End need to exist within Data (no?) and also whether they can be higher/lower than the max/min values in Data (yes?)
> * It would also be better to be clear about whether Start can be higher than End. Although they're defined as lower/upper bounds, is 'Start>End' an error, or valid with a probability of 0 returned?
> * This needs to specify how the result is calculated if End is omitted and Start is not present in Data (Calc returns 0).
> * This needs to specify the type of error returned - eg #N/A if Data Probability are different lengths. This is important because #N/A is a specific (testable) type of error.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]