Skip to content

Commit 57d4af6

Browse files
committed
Clarify mixed-type add/sub docs; add explicit-operand pattern
Closes #94
1 parent 75dffb5 commit 57d4af6

1 file changed

Lines changed: 33 additions & 18 deletions

File tree

docsite/source/appendices/mixed_math.rst

Lines changed: 33 additions & 18 deletions
Original file line numberDiff line numberDiff line change
@@ -107,28 +107,23 @@ Mixed Types: Addition and Subtraction
107107
This describes the behavior of addition and subtraction operations
108108
where one operand is a bitmath type and the other is a number type.
109109

110-
Mixed-math addition and subtraction **always** return a type from the
111-
:py:mod:`numbers` family (integer, float, etc...). This rule is
112-
true regardless of the placement of the operands, with respect to the
113-
operator.
110+
Mixed-math addition and subtraction return a type from the
111+
:py:mod:`numbers` family (integer, float, etc...) regardless of the
112+
placement of the operands, with one exception: when the left operand
113+
is exactly ``0``, the result is the bitmath instance itself.
114114

115-
.. note::
115+
This exception exists so that Python's built-in :py:func:`sum`
116+
function works correctly with iterables of bitmath objects, since
117+
``sum()`` starts accumulation from ``0`` by default:
116118

117-
**Exception: zero as the left operand.** When the left operand is
118-
exactly ``0`` (e.g. ``0 + KiB(1)``), the result is the bitmath
119-
instance itself rather than a number. This special case exists so
120-
that Python's built-in :py:func:`sum` function works correctly with
121-
iterables of bitmath objects, since ``sum()`` starts accumulation
122-
from ``0`` by default.
123-
124-
.. code-block:: python
119+
.. code-block:: python
125120
126-
>>> import bitmath
127-
>>> sum([bitmath.Byte(1), bitmath.MiB(1), bitmath.GiB(1)])
128-
Byte(1074790401.0)
121+
>>> import bitmath
122+
>>> sum([bitmath.Byte(1), bitmath.MiB(1), bitmath.GiB(1)])
123+
Byte(1074790401.0)
129124
130-
For all non-zero numeric left operands the documented behaviour
131-
(returning a number) is unchanged.
125+
For all non-zero numeric operands the behaviour (returning a number)
126+
applies.
132127

133128
**Discussion:** Why do ``100 - KiB(90)`` and ``KiB(100) - 90`` both
134129
yield a result of ``10.0`` and not another bitmath instance, such as
@@ -197,6 +192,26 @@ what unit the operand was *intended* to carry. Therefore, the behavior
197192
of bitmath is **conservative**. It will meet us half way and do the
198193
math, but it will not return a unit in the result.
199194

195+
**Keeping the result as a bitmath type**
196+
197+
If the intent is to add or subtract a quantity of the *same unit* —
198+
for example, incrementing ``Byte(1)`` by one more byte — use an
199+
explicit bitmath operand on both sides:
200+
201+
.. code-block:: python
202+
203+
>>> Byte(1) + Byte(1)
204+
Byte(2.0)
205+
206+
>>> KiB(10) - KiB(3)
207+
KiB(7.0)
208+
209+
This makes the unit explicit rather than relying on implicit
210+
conversion, which eliminates ambiguity — ``KiB(10) - 3`` could mean
211+
"subtract 3 KiB" or "subtract the number 3 from the prefix value."
212+
bitmath does not guess; using a bitmath operand on both sides states
213+
the intent clearly.
214+
200215

201216
Mixed Types: Multiplication and Division
202217
========================================

0 commit comments

Comments
 (0)