Extending section on fixed-point types#1317
Conversation
gusthoff
commented
Feb 16, 2026
gusthoff
commented
- Adding subsections on ordinary fixed-point types.
- Adding subsection on type conversions and machine representation.
- Adding subsection on integer multiplication and division.
gusthoff
force-pushed
the
content/advanced_ada/new_content/numerics/fixed_point_types/20260215
branch
from
c5abbcb to
96719a8
Compare
gusthoff
force-pushed
the
content/advanced_ada/new_content/numerics/fixed_point_types/20260215
branch
from
96719a8 to
021a0a2
Compare
… types Adding subsection on multiplication/division and ordinary fixed-point types in the context of universal fixed types .
gusthoff
force-pushed
the
content/advanced_ada/new_content/numerics/fixed_point_types/20260215
branch
from
021a0a2 to
defd5b3
Compare
swbaird
left a comment
swbaird
left a comment
There was a problem hiding this comment.
Lots of good stuff here.
I've got a few comments.
| :ada:`Decimal` type. | ||
|
|
||
| Let's now focus on subtypes of ordinary fixed-point types: | ||
|
|
There was a problem hiding this comment.
The immediately preceding line says we are about to declare a subtype of a Decimal type.
| delta D | ||
| range -1.0 .. 1.0 - D; | ||
|
|
||
| subtype Coefficient is Short_Fixed; |
There was a problem hiding this comment.
Impose a constraint? For the derived type example, we declared a derived type that agreed with its parent type with respect to constraints (and predicates). We don't need to illustrate all possible combinations, but perhaps we should mix it up a little. Add some case where "X in Short_Fixed" yields True and "X in Coefficient" yields False? Feel free to ignore this suggestion - there are always more cases that could be described and we have to draw the line somewhere.
| is | ||
| V_Local : T_Fixed; | ||
|
|
||
| V_Int_Overlay : T_Int_Fixed |
There was a problem hiding this comment.
As before, do we want an assertion that the size and/or alignments match for an overlay?
|
|
||
| package Angles is | ||
|
|
||
| D : constant := 0.2; |
There was a problem hiding this comment.
Perhaps add a comment emphasizing that D is not an exact power of two? Maybe not.
| range -2 ** (Angle'Size - 1) .. | ||
| 2 ** (Angle'Size - 1) - 1; | ||
|
|
||
| type Angle_Adj is |
There was a problem hiding this comment.
Perhaps a comment that Angle'Small /= Angle'Delta, while Angle_Adj'Small = Angle_Adj'Delta? Maybe not if this point (i.e. if not explicitly specified, then Small is a power of two) is already covered elsewhere.
| Here, we write :ada:`TQ31 (V_15)` to convert the value of :ada:`V_15` from the | ||
| :ada:`TQ15` to the :ada:`TQ31` type. Likewise, we write :ada:`TQ15 (V_31)` to | ||
| convert the value of :ada:`V_31` from the :ada:`TQ31` to the :ada:`TQ15` type. | ||
|
|
There was a problem hiding this comment.
Show the output generated by Show_Fixed_Point_Conversions? This is like reading a mystery novel and then finding that the last chapter is missing!
[A digression:
I don't know if you want to get into it, but a type conversion whose operand is a call to a universal-fixed-valued operator is an interesting beast. It is essentially all one operation. Usually a type conversion proceeds in two steps: evaluate the operand (ignoring the fact that it is the operand of a type conversion) and then perform the conversion. But in this universal-fixed case, it is all rolled into one. In a case like
Fx1 (Fx2'(X) * Fx3'(Y))
where there are 3 different fixed point types, the result depends on the 3 different Small values (one for each of the fixed point types) as well as the integer values of X and Y.]
| generic | ||
| type T_Decimal is delta <> digits <>; | ||
| procedure Gen_Show_Decimal_Type_Info | ||
| (Dummy : T_Decimal; |
There was a problem hiding this comment.
Again, why Dummy? And yet again below.
| test application: | ||
|
|
||
| +--------+-----------------------------------+-----------------------------------+ | ||
| | Real | Original / source | Target | |
There was a problem hiding this comment.
"real" vs. "actual" seems like an unclear distinction. Perhaps "mathematically exact" vs. "exactly representable", or something like that.
| | 225.00 | :ada:`T2_D6` | 22500 | 225.0 | :ada:`T2_D12` | 22500 | 225.0 | | ||
| +--------+---------------+---------+---------+---------------+---------+---------+ | ||
|
|
||
| As expected, when converting to a type with less accuracy |mdash| i.e. whose |
There was a problem hiding this comment.
I think it is correct to says that a fixed point type with a smaller Small is more accurate than one with a larger Small, but it still seems like it might be confusing. Would it be too pedantic to point out that it is possible for a particular value to be exactly representable in the "less precise" representation but not in the "more precise" representation? If so, then feel free to ignore this comment.
| with Angles.Show_Info_Procs; | ||
| use Angles.Show_Info_Procs; | ||
|
|
||
| procedure Show_Machine_Representation |
There was a problem hiding this comment.
Is this a duplicate of a version of Show_Machine_Representation that was declared earlier?
2 participants
