[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Commented: (OFFICE-2246) PROB: check andspecify 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 commented on OFFICE-2246: ----------------------------------------- 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]