Copyright © 2008, 2016, XBRL International Inc., All Rights Reserved.
This document was originally published in 2008 by the former Software Interoperability Working Group. Since publication, the XBRL 2.1 Specification has been subject to a number of significant errata corrections relating to the handling of precision and decimals attributes. The Base Specification Working Group is in the process of reviewing the validity of this document in the light of these changes, and does not currently endorse its contents. It is maintained here for the convenience of third parties that reference parts of it.
It should be noted that this document has always been an informational guidance document, and not a specification. In the event of any contradiction between this document and an XBRL International Recommendation, the latter will always take precedence.
Circulation of this Document is unrestricted. Other documents may supersede this document. Recipients are invited to submit comments to pdu-feedback@xbrl.org, and to submit notification of any relevant patent rights of which they are aware and provide supporting documentation.
The
@precision
and
@decimals
attributes in XBRL indicate the range in which the
actual value of the fact that gave rise to its expressed
value in the XBRL instance lies. They are sometimes
misunderstood as having a relationship to scaling or
presentation. Non conformant implementations and the use
of units of measure such as
"thousands"
compound software interoperability problems. The effects
of these attributes on calculations can cause
difficulties in interpretation and misunderstandings are
common. This document provides supplemental information
to that provided in normative XBRL International
publications, describes existing implementation
conventions, attempts to clarify commonly misunderstood
concepts, and requests additional commentary regarding
empirical implementation experience.
1 Goal
2 Relationship to other work
3 Language independence
4 Document conventions
4.1 Typographic conventions
4.1.1 Definition notation
4.1.2 Footnote notation
4.1.3 Element and attribute notation
4.2 Formatting conventions
5 Terminology
6
The Intent of the
@decimals
and
@precision
attributes
6.1 Computer Science Problem
6.2 Accounting Problem
6.3
Sources of data for Instance Document Creation -
inference of precision from decimals
6.4 Other points to note
7 Issues Arising in Practice
7.1
Different levels of precision for a single fact
7.2 Units of measure with implicit multipliers
7.3 Rounding and Calculation Inconsistency
7.4 Representing Exact Monetary Amounts
7.5 Representing Exact Fractions
7.6 Inconsistent Levels of Accuracy
7.7 Exact Zero
7.8
Non-standard uses of the decimals and precision attributes
8 Effect on calculations in XBRL
9 Lexical Consistency
A Interval Arithmetic
A.1 Notation
A.2 Basic operations in interval arithmetic
A.2.1 Operations on closed intervals
A.2.2 Operations on half-closed intervals
A.2.3 Operations on open intervals
B References
C Intellectual property status (non-normative)
D Acknowledgements (non-normative)
E Document history (non-normative)
F Errata corrections in this document
1 Rounding
2 Regulator specified accuracy
3 Variations on Zero
4 Simple Sales Report (exact values)
5
Simple Sales Report (rounded to thousands)
6
Simple Sales Report (rounded to thousands and
adjusted)
1 Scientific Notation
2 Interval Notation
Interval Notation
length of an interval
Lexical Consistency
Scientific Notation
The goal of this document is to augment [XBRL 2.1] material related to decimals, precision, and units, particularly that in Section 4.6 and to provide more examples, design rationale, and examples of conventions used in practice.
The
@precision
and
@decimals
attributes indicate the range in which the actual value
of the fact that gave rise to its expressed value in the
XBRL instance lies. The root cause of the
conceptualisation problem is that there is a tendency to
misunderstand this point. These attributes are often
thought of as telling the document's consumer "what you
should do to the number you find in the instance"
whereas they are actually answering the question "what
was the original possible range of values that could
have given rise to what I find in the instance?".
Making this harder to understand is that it can give rise to counter intuitive situations such as the precision 1 row in example 11 of [XBRL 2.1]. Here "99" appears in the instance but it has only precision 1 - this means that the second "9" is meaningless (i.e. appearing "randomly") and so the original value must actually have fallen in the range 85 to 95 (the counter-intuitiveness arising from the fact that 99 is outside this range).
[XBRL 2.1] attempts to clarify this in the (non-normative) note in section 4.6.4
"NOTE: The definitions in this specification mean that precision and by inference, decimals indicate the range in which the actual value of the fact that gave rise to its expressed value in the XBRL instance lies."
Further clarifying explanation was introduced into the text, in erratum corrections 013 and 059 such as
"The same procedure MAY be followed for any value of n, and we then say that a particular lexical representation of the value of a number is correct to n significant figures. It is possible that this technique has been used to create the lexical representation of a fact in an XBRL instance with a precision attribute of n."
in 4.6.7.1 and
"Rounding, as described earlier, might have been used to make a number correct to exactly n decimal places for inclusion in an XBRL instance with a decimals attribute of n."
This example is particularly relevant since the erratum corrections changed it from saying
"...can be used to make...".
The official language of XBRL International's own work products is English and the preferred spelling convention is UK English.
Comments which are informative, but not essential to the understanding of the point at hand, are provided in footnotes. All footnotes are non-normative.
When referring to a specific element, it will be identified by
its namespace prefix and local name. For example, the root element
of a versioning report would be referred to as <ver:report> .
Attributes are also identified by their local name and, where
appropriate, their namespace prefix. Attributes are
distinguished from elements by prefixing them by an
@
symbol. Thus,
@id
refers to the attribute with the name id.
When referring to any attribute, so long as it has a specific
namespace, the local name is replaced by an asterisk (
*).
Thus, the notation @xml:* specifies any attribute
in the namespace
http://www.w3.org/XML/1998/namespace.
The following highlighting is used for normative technical material in this document:
Text of the normative example.
The following highlighting is used for non-normative examples in this document:
Text of the non-normative example.
The following highlighting is used for non-normative examples of poor, discouraged or disallowed usage.
Text of the discouraged example.
This section provides the definitions of terms used elsewhere in the document.
Where this document refers to Scientific Notation, it is referring to notation in which a number is represented as a decimal mantissa, followed by a non-numeric character such as "E" or "e", followed by a decimal exponent.
-9.8e3 = -98e2 = -9800.
Where this document refers to Interval Notation, it is referring to notation in which a set of real numbers between a and b, including a and b, is denoted [a,b]. The square bracket is replaced by a parenthesis for end points omitted from the range.
[-1.6,4.3] represents the set of real numbers between -1.6 and 4.3 including both -1.6 and 4.3
[-1.6,4.3) represents the set of real numbers between -1.6 and 4.3 including -1.6 but omitting 4.3.
For further details about arithmetic involving Interval Notation see Appendix A.
@decimals
and
@precision
attributes
This section describes the intent of the
@decimals
and
@precision
attributes on numeric items. It is adapted from material
prepared by
Hugh Wallis
during the requirements gathering process for
[XBRL 2.1].
Preparers and consumers of XBRL instance documents
may need information about the accuracy of numeric
facts that are expressed in an instance document.
From a computer science and processing point of view
it may be necessary to know the number of significant
figures of accuracy in the representation of a
numeric fact. This is so as to be able to make
statements about the accuracy of numeric facts that
are derived from that input numeric fact as a result
of calculations that involve the input numeric fact.
If there is a need to ensure a certain level of
accuracy in calculated results, different
calculation algorithms and number representations may
be necessary in the computer processor that is
performing the calculation. This requirement was
satisfied in XBRL specification version 2.0 (by
means of the
@precision
attribute on numeric contexts). The term "precision"
is commonly used in computer science to express the
number of significant figures in the representation
of a number.
On the other hand, preparers of printed statements
often approximate the numeric facts that are
presented by either truncation or rounding (usually
rounding) of the actual values of those numeric
facts so that the resulting presentation is correct
to a certain number of places to the left or right
of the decimal marker. A large segment of the XBRL
user community is accustomed to this mechanism and
expects to be able to represent numeric facts in
this fashion in instance documents. The
@precision
mechanism in XBRL makes a statement about the
accuracy of data so provided. In XBRL 2.0 it
required the creation of multiple numeric contexts.
Moreover, the details of each such numeric context
were dependent on the length of the sequence of
characters 0-9 and decimal marker (the lexical
representation) used for the numeric facts in
question and so had to be generated "on the fly" as
the instance document was created once the numeric
representations of the facts had been calculated.
Additionally, preparers of instance documents may be provided with input data that has already been expressed to a certain number of decimal places. This is the best that they have to work with in producing their instance documents. Because they know that some of the numbers are likely to be inaccurately represented, they need to be able to state that knowledge in the resultant instance document. Such data will have widely varying precision because of the rounding that has already taken place on it (with attendant loss of precision) and yet still may need to be represented and transmitted in XBRL. In such a situation it may be undesirable for the XBRL document to make any statement about the precision of the data for future calculations. All that may be known is the number of decimal places.
If all that is stated is the number of decimal places, then a 'worst case scenario' value for precision can be inferred. For example, if an XBRL document is to represent 1000 (in millions) and it is KNOWN that it is correct to two decimal places (EXACTLY one million dollars, as in, for example, a cash prize) then it may legitimately be represented as "1000000.00 correct to x significant figures, correct to 2 decimal places" where x can be any integer greater than or equal to 9. However, if all that is known is that the number 1000 (in thousands) appears on the face of a report that is to be rendered in XBRL, then the best that can be done is to represent it as "1000000 correct to 4 significant figures, correct to –3 decimal places".
Thus, omitting the statement about the number of significant figures is not a problem because a minimum value of 4 can be inferred from the combination of the lexical representation of the number itself and the fact that it is known to be correct to –3 decimal places. This also raises the possibility that it may be desirable to express the fact that the lexical representation of the numeric value of a fact is the exact value of that fact (as in the cash prize example above). In effect this is the same as saying that the number is correct to an infinite number of decimal places.
Another related issue is the desire to express the
exact value of certain ratios that cannot be exactly
represented in a decimal representation. This
requirement arises from the Tax domain space.
Specific examples from the UK Inland Revenue (now
HMRC) are marginal relief rates (varying between
9/400 and 1/40 in the late 1990s) and a special tax
rate of 22.5/77.5. This implies the need for the
fractionItemType
in XBRL (where the numerator and denominator are
always exact).
It should be noted that, while there is often a desire to present numbers accurately to a certain number of decimal places in a printed report or a display on a computer screen, that does not preclude the keeping of more accurate representations of that number in the computer processor’s storage. An example that is probably familiar to most readers of this document is the difference between the storage and the display of numbers in Microsoft Excel, where it is possible to reduce the display accuracy while still retaining the more accurate representation in memory.
Furthermore, it is important to remember that
@decimals
and
@precision
are an indication of the accuracy of the
source
of the data. Therefore:
@decimals
and
@precision
attributes do not imply any kind of scaling of
the values of numeric elements.
decimals="3",
for example, does not mean that the value is
to be multiplied (or divided) by 1000.
@decimals
and
@precision
attributes do not indicate that the digits must
be presented to a user in any particular way by
software.
@decimals
and
@precision
attributes
do
impact the way that digits are parsed to produce
a numeric value; the string
123456.7
with
decimals="3"
represents a different range of possible values
than the same digits with
decimals="-3".
A number may appear in an instance with two different levels of precision. For example, the shares of common stock outstanding may be quoted as "707,662,632" on a financial statement cover sheet and as "707.7 million" in the balance sheet.
The lack of a standardised set of units can lead to
instances mixing unit attributes of
"millions of barrels of oil",
"billions of barrels of oil"
(measures of volume) and
"billions of barrels of oil equivalent"
” (a measure of energy content). Although XBRL can
define data types to distinguish volume and energy,
and can restrict the possible values of the
@decimals
and
@precision
attributes, methods for restricting the unit
references would appear to depend on
keyref
implementations that are not universal. In short,
XBRL seems to provide no mechanism for preventing an
instance from containing both
"millions"
and
"billions"
of barrels of oil.
XBRL does, however, provide a specific mechanism for
representing percentages. It is not only bad
practice but actually violates section 4.8.2 of
[XBRL 2.1]
to use types or units that imply a multiplier of .01
to indicate percentages. That section states
"To represent rates, percentages or ratios where
the numerator and the denominator would be the
same units, the fact MUST have a
unitRef
attribute identifying a unit element with a
single measure element as its only child. The
local part of the measure MUST be
pure
and the namespace prefix MUST resolve to the
namespace:
http://www.xbrl.org/2003/instance.
Rates, percentages and ratios MUST be reported
using decimal or scientific notation rather than
in percentages where the value has been
multiplied by 100."
Therefore, rates, percentages, and ratios
represented using a
pure
or
percentage
data type must have a unit of
pure.
Percentages are represented as decimals. For
example, use
".75" rather than "75".
Section 7.8.1 in [USPG] states the following:
Rounding can result in inconsistencies, as shown in
Table 1. The
@decimals
attribute is set to
"2"
for all three numbers because that is how many
digits are reported in the financial statement.
| Calculation Relationships | FY13 |
|---|---|
| Earnings per share, Basic | 1.30 |
| +1 Income (Loss) from Discontinued Operations, Net of Tax, Per Basic Share | .01 |
| +1 Income (Loss) from Continuing Operations, Per Basic Share | 1.28 |
In this example, XBRL validation software will identify an inconsistency in FY13. Adjusting the decimals attribute of "2" on the facts to "1" or "3" will not resolve this inconsistency. Adding hidden digits, such as changing .01 to .014 and 1.28 to 1.284, and setting the decimals attribute to "3" may resolve the calculation inconsistency, but the extra digits were not reported in the financial statement. It is a rounding inconsistency and should be left as it is.
Most monetary systems are based on a model such as the "dollar-cent" model where there are 100 smaller units in each larger unit of currency and the assumption that the smaller unit of currency is indivisible. The consequence of that fact is that "exact monetary amounts" are represented with two digits to the right of the decimal separator (usually a "." or a ",").
The logical leap thus commonly taken is that a value
of
decimals="2"
somehow represents that fact. However, this is
incorrect. If it is desired to represent an exact
monetary amount and to make the assertion that it
is, indeed, exact, then the fact should have the
attribute
decimals="INF"
since this is precisely what section 4.6 of
[XBRL 2.1]
states. i.e.,
"The meaning of
decimals="INF"
is that the lexical representation of the number
is the exact value of the fact being
represented."
The use of
decimals="2"
to indicate "exact monetary amounts" means that the
values transmitted in the document may have been
rounded to 2 decimal places and therefore might not
actually be "exact". Monetary amounts may have been
calculated from data that might result in fractional
parts of the smallest unit of currency being the
calculation result (for example, the average amount
of loans outstanding, this being the total amount
loaned divided by the number of borrowers). In this
case, if it is desired to report the result of the
calculation
as though it were
an exact monetary amount (e.g. in euros and
eurocents), rounding may have taken place (depending
on the values participating in the calculation). In
that case, the values are not, in fact, exact
monetary amounts at all, and therefore
decimals="2"
would
be correct.
As discussed above, percentages are to be
represented without scaling (e.g., 34% is to be
represented as 0.34). However, reported percentages
might have been derived from at least two different
sources. For example they might either be
percentages mandated by certain regulators or by
legislation (such as a taxation rate), or they might
be calculated percentages (such as the percentage of
outstanding loans in default). In the first case the
percentage is known exactly and so, as in the
previous point, should be reported using
decimals="INF". If they have been calculated and the requirement
is to report them to two decimal places of
percentage (e.g., 34.43%, being represented as
0.3443), then a value of
decimals="4"
would be correct.
Instances using a common taxonomy might use
different values of
@decimals, and thereby make the data difficult to validate or
aggregate.
Section 2.8.11 of
[FRIS]
requires that, as a best practice
for the readability of the instance
in financial reporting, numeric facts should use the
@decimals
attribute in preference to the
@precision
attribute.
Remember that
@decimals
and
@precision
are an indication of the accuracy of the source of
the data.
One or more regulators wishing to align their use of
@decimals
and
@precision
might develop a table like
Table 2
| Description of accuracy of amount | Attribute and attribute value to be used |
|---|---|
| exact monetary, percentage, basis point or any other amount |
decimals="INF"
|
| rounded or truncated to millions |
decimals="-6"
|
| rounded or truncated to thousands |
decimals="-3"
|
| rounded or truncated to units |
decimals="0"
|
| rounded or truncated to cents |
decimals="2"
|
| rounded or truncated to a whole percentage |
decimals="2"
|
| rounded or truncated to basis points |
decimals="4"
|
The item types of XBRL that are based on
xs:decimal, such as the
xbrli:monetaryItemType
and
xbrli:pureItemType
allow 0 to appear as their content, but as one may
conclude from the previous discussion, this alone
still leaves quite a range of ambiguity:
| Content | Attribute |
Possible Range of Source Values
(Expressed in Interval Notation ) |
|---|---|---|
| 0 |
decimals="INF"
|
[0,0] |
| 0 |
decimals="0"
|
(-0.5,0.5) |
| 0 |
decimals="1"
|
(-0.05,0.05) |
Zero is a somewhat special case unlike other
numbers. This is because the interpretation of
xsi:nil='true', as in for example:
<this xsi:nil="true" contextRef="c" unitRef="eur"/>
causes the fact to be treated by XBRL’s calculation
(and
essence-alias) arcs as if it were absent entirely. For
calculations only, that would have the same effect
as either having no such fact in the instance at
all, or having the following in the instance:
<this ... decimals="INF"> 0 </this>
If a taxonomy author found it necessary to constrain reporters to represent "exactly zero" in only one way, there are these alternatives, each with their own pros and cons:
xsi:nillable
fixed to be
false
and base it on a restriction of the
xs:decimal
base type that is the union of only positive
and negative values.summation-item,
the @fallbackValue attribute must be set to "0".xs:decimal
base type restricted to exclude zero values and
some validation method that will detect the
absence of the required fact.
nil value.
nil facts have to be explicitly
forced to zero inside the formula expression,
which leads to more complex formulae.decimals="INF".
However it should be noted that this cannot be
enforced by XML Schema unless all values of the
fact must have
decimals="INF".It is unclear, however, what would be the incremental value of mandating a single representation for zero.
Some users make use of the
@decimals
or
@precision
attributes in non-standard ways as in the following example.
Certain disclosures require the display of -0 (on a printed
document) to indicate that a value is between 0 and -999,999,99.
Accordingly, to indicate the reporting of this value, "-0" is
inserted in the instance and the fact given a
@decimals
attribute of "-6". Custom reports then recognise this
combination of values and use them to trigger a display of "-0"
in a rendered report.
This is, however, non-standard since this combination actually
indicates a value lying in the range
(-0.5 * 10-6, 0.5 * 10-6)
and so any software other than that which is written
specifically to handle this situation will interpret it
according to
[XBRL 2.1]
and not as the authors intended.
@decimals
and
@precision
have no impact on the rendering of output according to
[XBRL 2.1]. The user in this case has
created a special case where they have overloaded the semantics
of the
@decimals
attribute to have a specific meaning when encountered in
combination with a specific lexical representation of the value
zero. It should also be noted that
http://www.w3.org/TR/xmlschema-2/#decimal
provides that there is no difference between 0 and -0 as lexical
representations of the value zero, so this lexical
representation has also been overloaded by the approach taken.
Non-standard use of these attributes in ways such as this are to be avoided as a best practice since they present an issue for software interoperability.
Any calculation that is expressible using the XBRL
summation-item
relationship mechanism can be written as an equality of
the form:
s = w 1 *i 1 + … + w n *i n
Now, because of the information provided by
@decimals
or
@precision
attributes, each of s, i
1, … i
n
can be expressed as an interval of one of the forms
described in
A.1.
Let us call these intervals S, I
1, … I
n.
XBRL provides no mechanism to make any statement about the accuracy of the weights and so they should be considered to be singletons {w1} … {wn} (i.e. having precise values).
Thus, using interval arithmetic operations as summarised in A.2, we can express the interval I that contains the possible values for the result of the summation as
I = {w1}*I1+ … + {wn}*In.
To determine the consistency of the calculation we can thus make the following statements:
@precision
or
@decimals
value of
INF.
At the time that
[XBRL 2.1]
was originally drafted, this analysis was not understood
and so the definition of consistency as applied to
summation-item
relationships was expressed in terms of the algorithm a
conforming processor would have to implement in order to
determine that consistency, as follows:
"The total of a binding calculation is defined to be
the sum of the rounded values of the contributing
numeric items in the binding, each multiplied by the
value of the
weight
attribute on the item's associated
calculationArc. This multiplication takes place after any
necessary rounding is performed. The rounded value
of a numeric item is the result of rounding the
value of the numeric item to its precision or
inferred precision ... A binding calculation is
defined to be consistent if the rounded value of the
summation item is equal to the total rounded to the
precision or inferred precision of the summation
item."
This description has, because of its instructions to
perform rounding operations, served to compound the
misunderstandings that have arisen over the meaning of
@precision
and
@decimals
attributes. This is particularly unfortunate since, in
most cases that are likely to occur in practice,
executing this algorithm will produce an acceptable
result.
Consideration was given to modifying [XBRL 2.1] to incorporate interval arithmetic concepts in replacement of this section. However it was found that the implementation consequences of supporting a fully conformant interval arithmetic regime were such that there was considered to be no cost-benefit associated.
Therefore, in order to alleviate the negative consequences of this discrepancy between the normative text in [XBRL 2.1] and the correct mathematical interpretation of the concepts involved it was decided to address the issue in a way that provided the end user more control over how they wanted to define "consistency". This is being done by means of the [VALIDATION] and [CONSISTENCY ASSERTIONS] specifications which form part of the [FORMULA] package, to which the reader is directed for further information.
Software implementers are therefore encouraged to carefully review these specifications, which are in Candidate Recommendation status as of 2008-03-28, and are invited to comment both to the authors of those documents as well as to the authors of this RFC on the suitability of this approach, with particular focus on the implementation issues involved.
The above discussions and concepts do not address a notion which seems to have no official name in the literature, but which is given the name here of Lexical Consistency.
This arises from a process common in financial reporting that is typically referred to as "footing" (or, in the UK, as "casting"). The term "footing" in accounting means "to add a column of numbers" (the term "cross-footing", or "cross-casting" in the UK, is similar and refers to rows rather than columns). Thus a simple manual check that is often made on a financial report is to see whether it "foots". In other words, "do the numbers in the column actually add up to the value at the bottom of the column?"
Clearly the fact that numbers might have been rounded or
truncated, and so be included in an XBRL instance with a
@decimals
or
@precision
attribute not equal to
INF, can have consequences for the answer to this question.
Consider the following set of figures:
| Account | $ |
|---|---|
| Sales of Product "A" |
1,001,501.00
|
| Sales of Product "B" |
1,000,501.00
|
| Sales of Product "C" |
1,002,501.00
|
| TOTAL SALES |
3,004,503.00
|
but now consider the same data presented in thousands:
| Account | $ (000) |
|---|---|
| Sales of Product "A" |
1,002
|
| Sales of Product "B" |
1,001
|
| Sales of Product "C" |
1,003
|
| TOTAL SALES |
3,005
|
and the problem is immediately evident - the report does
not "foot" correctly - the value of
TOTAL SALES
is not the sum of the numbers in the individual rows
(which would be
3,006
if the numbers as presented were to be added).
Accountants are, of course, used to dealing with this situation. To do so they will adjust the figures applying the criteria of "materiality" (so as not to provide misleading information). This does not sit well with the purist mathematicians, of course, but is generally considered perfectly reasonable for communicating the necessary information. So, assuming that the accountant felt that the most appropriate adjustment would be to adjust the reported number for 'Sales of Product "A"' (by rounding down instead of up) this would manifest itself in an XBRL instance as follows:
| Account | $ (000) |
number to be included
in the instance |
accuracy attribute |
|---|---|---|---|
| Sales of Product "A" |
1,001
|
1001000 |
decimals="-3"
|
| Sales of Product "B" |
1,001
|
1001000 |
decimals="-3"
|
| Sales of Product "C" |
1,003
|
1003000 |
decimals="-3"
|
| TOTAL SALES |
3,005
|
3005000 |
decimals="-3"
|
The first problem with this is, of course, that the fact in the instance for Sales of Product "A" is not accurately reported but if the accountant feels this is not "material" it is considered acceptable.
Secondly, XBRL does not provide an ability to validate this document in the way that an accountant would (i.e. by checking that the numbers as presented add up). This suggests that a concept of Lexical Consistency could be valuable.
An XBRL instance is
lexically consistent
if it would be consistent with respect to the
summation-item
relationships contained in the document if all
contributing items were considered to have
precision="INF".
This RFC, therefore, seeks comments on the usefulness and feasibility (from an implementation perspective) of embodying this concept into the XBRL toolkit (most likely by means of an additional calculation relationship that could be added to the [LRR STRUCTURE]). This would involve software developers providing support for such a relationship and issuing appropriate error or warning messages.
This appendix provides some brief background about interval arithmetic. For some more detailed discussion there are many resources on the web including the Wikipedia article entitled "Interval Arithmetic" .
The following is the notation to be used in this discussion.
a, b, c, d are all members of the set of real numbers R
[a,b] is the subset of R such that for all x in [a,b], a ≤ x ≤ b (a closed interval)
[a,b) is the subset of R such that for all x in [a,b), a ≤ x < b (a half-closed interval)
(a,b] is the subset of R such that for all x in (a,b], a < x ≤ b (a half-closed interval)
(a,b) is the subset of R such that for all x in (a,b), a < x < b (an open interval)
{a} is the subset of R such that for all x in {a}, a = x (a closed interval – a singleton) – equivalent to [a,a]
The length of an interval (whose ends are a and b) is defined as b-a (where b ≥ a) – this definition applies regardless of whether the interval is closed, half closed or open.
The length of the interval I is denoted as L(I).
Many of these operations are not relevant to this analysis but are included here for completeness.
[a,b] + [c,d] = [a+c, b+d]
[a,b] - [c,d] = [a-d, b-c]
[a,b] * [c,d] = [min (a*c, a*d, b*c, b*d), max (a*c, a*d, b*c, b*d)]
[a,b] / [c,d] = [min (a/c, a/d, b/c, b/d), max
(a/c, a/d, b/c, b/d)]
Division by an interval containing zero is not
defined under the basic interval arithmetic.
[a,b) + [c,d] = [a+c, b+d)
[a,b) + [c,d) = [a+c, b+d)
(a,b] + [c,d] = (a+c, b+d]
(a,b] + (c,d] = (a+c, b+d]
(a,b] + [c,d) = (a+c, b+d)
(a,b] + (c,d) = (a+c, b+d)
[a,b) + (c,d) = (a+c, b+d)
[a,b) - [c,d] = [a-d, b-c)
[a,b) - [c,d) = [a-d, b-c)
(a,b] - [c,d] = (a-d, b-c]
(a,b] - (c,d] = (a-d, b-c)
(a,b] - [c,d) = (a-d, b-c]
(a,b] - (c,d) = (a-d, b-c)
[a,b) - (c,d) = (a-d, b-c)
[a,b) * [c,d] = (min (a*c, a*d, b*c, b*d), max (a*c, a*d, b*c, b*d))
[a,b) * [c,d) = (min (a*c, a*d, b*c, b*d), max (a*c, a*d, b*c, b*d))
(a,b] * [c,d] = (min (a*c, a*d, b*c, b*d), max (a*c, a*d, b*c, b*d))
(a,b] * (c,d] = (min (a*c, a*d, b*c, b*d), max (a*c, a*d, b*c, b*d))
(a,b] * [c,d) = (min (a*c, a*d, b*c, b*d), max (a*c, a*d, b*c, b*d))
(a,b] * (c,d) = (min (a*c, a*d, b*c, b*d), max (a*c, a*d, b*c, b*d))
[a,b) * (c,d) = (min (a*c, a*d, b*c, b*d), max (a*c, a*d, b*c, b*d))
[a,b) / [c,d] = (min (a/c, a/d, b/c, b/d), max
(a/c, a/d, b/c, b/d))
[a,b) / [c,d) = (min (a/c, a/d, b/c, b/d), max
(a/c, a/d, b/c, b/d))
(a,b] / [c,d] = (min (a/c, a/d, b/c, b/d), max
(a/c, a/d, b/c, b/d))
(a,b] / (c,d] = (min (a/c, a/d, b/c, b/d), max
(a/c, a/d, b/c, b/d))
(a,b] / [c,d) = (min (a/c, a/d, b/c, b/d), max
(a/c, a/d, b/c, b/d))
(a,b] / (c,d) = (min (a/c, a/d, b/c, b/d), max
(a/c, a/d, b/c, b/d))
[a,b) / (c,d) = (min (a/c, a/d, b/c, b/d), max
(a/c, a/d, b/c, b/d))
Division by an interval containing zero is not
defined under the basic interval arithmetic.
(a,b) + (c,d) = (a+c, b+d)
(a,b) - (c,d) = (a-d, b-c)
(a,b) * (c,d) = (min (a*c, a*d, b*c, b*d), max (a*c, a*d, b*c, b*d))
(a,b) / (c,d) = (min (a/c, a/d, b/c, b/d), max
(a/c, a/d, b/c, b/d))
Division by an interval containing zero is not
defined under the basic interval arithmetic.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to XBRL International or XBRL organizations, except as required to translate it into languages other than English. Members of XBRL International agree to grant certain licenses under the XBRL International Intellectual Property Policy ( www.xbrl.org/legal ).
This document and the information contained herein is provided on an "AS IS" basis and XBRL INTERNATIONAL DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The attention of users of this document is directed to the possibility that compliance with or adoption of XBRL International specifications may require use of an invention covered by patent rights. XBRL International shall not be responsible for identifying patents for which a license may be required by any XBRL International specification, or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention. XBRL International specifications are prospective and advisory only. Prospective users are responsible for protecting themselves against liability for infringement of patents. XBRL International takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Members of XBRL International agree to grant certain licenses under the XBRL International Intellectual Property Policy ( www.xbrl.org/legal ).
This document draws on experiences gained during implementations of XBRL projects, mailing list discussions associated with those projects and other valuable input from across the universe of XBRL implementations. Thanks are due to all who have given their consideration to the topics discussed herein and shared their thoughts with the authors.
| Date | Author | Details |
|---|---|---|
| 27 May 2008 | Walter Hamscher |
Initial draft created. Assembled a few known misconceptions and issues from existing materials as a first rough draft. |
| 09 July 2008 | Hugh Wallis |
Converted document to use XBRLSpec format. Rearranged document structure to place most earlier parts in appendices as background material. |
| 09 July 2008 | Walter Hamscher |
Suggested edits to break up background material into distinct issues. Addition of the Zero issue. |
| 15 July 2008 | Hugh Wallis |
Interval Arithmetic sections created Addition of Lexical Consistency discussion |
| 31 July 2008 | Hugh Wallis |
Editorial corrections from Paul Sappington Update references Reformat tables to improve appearance |
| 07 August 2008 | Hugh Wallis |
Update References Provide specific feedback e-mail address Remove internal commentary Editorial for publication |
| 25 September 2008 | Hugh Wallis |
Updates from Michele Romanelli Fix a few typographical errors found in the first PWD Add discussion of use of lexical artefacts such as minus signs to drive processing |
| 06 October 2008 | Hugh Wallis |
Editorial for publication as a 2nd PWD |
| 19 October 2016 |
Republished as a Base Specification WG Working Group Note, with disclaimer that contents are not endorsed by the group. |
This appendix contains a list of the errata that have been incorporated into this document. This represents all those errata corrections that have been approved by the XBRL International Base Specification Working Group up to and including 11 January 2017 . Hyperlinks to relevant e-mail threads may be followed only by those who have access to the relevant mailing lists. Access to internal XBRL mailing lists is restricted to members of XBRL International Inc.
No errata have been incorporated into this document.