[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Commented: (OFFICE-2385) 5.4.7 Infix Operator"="
[ http://tools.oasis-open.org/issues/browse/OFFICE-2385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17829#action_17829 ] Dennis Hamilton commented on OFFICE-2385: ----------------------------------------- I concur that this is very much different than precision as shown. I also concur with other aspects, with two provisos. 1. I was not suggesting that users could be equated with the folks that Knuth is speaking of. Just the same, users of spreadsheets often need to be cautioned about this just as they need to know that not all Integer values (from a spreadsheet perspective) are Precise Integer values. 2. I do think that one can probably characterize what the effective comparison approximation tolerance happens to be and even specify it. This is a figure of merit, and I think it can be specified. It is useful about what can be expected just as knowing a figure-of-merit such as equivalent decimal digits of approximation is useful. (Before I pursue this I need to see if there is actually a mistake in Knuth's passage on how he determines the comparison approximation tolerance. I will start to see if there is errata about this on Knuth's web pages. If not, he is going to be mildly surprised to hear from me after all this time.) > 5.4.7 Infix Operator "=" > ------------------------ > > Key: OFFICE-2385 > URL: http://tools.oasis-open.org/issues/browse/OFFICE-2385 > Project: OASIS Open Document Format for Office Applications (OpenDocument) TC > Issue Type: Bug > Components: OpenFormula > Reporter: Patrick Durusau > Assignee: Dennis Hamilton > Fix For: ODF 1.2 Part 2 CD 2 > > > General commentary under 5.4.7 Infix Operator "=" deleted. > Created JIRA issue to call attention to it. > "Note that in most implementations, numbers are computed using fixed-length representations in base 2 or 16, using a matissa and an exponent. This means that values such as 0.1 cannot be exactly represented (just as 1/3 cannot be exactly represented in base 10 using decimal notation). As a result, (0.1*10) will not have the same bit representation as 1. Since many spreadsheet users do not understand how computers typically represent numbers, applications may attempt to hide these differences by allowing "nearly" equal numbers to be considered equal, but applications are not required to do so. > Note that in some user interfaces this is displayed or accepted as "=="." -- 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