On Monday, July 18, 2016 at 10:06:11 AM UTC+5:30, Chris Angelico wrote: > On Mon, Jul 18, 2016 at 2:16 PM, Rustom Mody wrote: > > On Saturday, July 16, 2016 at 3:16:48 PM UTC+5:30, Steven D'Aprano wrote: > > Here are the first couple of hits it gives (me) for “scheme exact number” > > > > | Scheme integers can be exact and inexact. For example, a number > > | written as 3.0 with an explicit decimal-point is inexact, but it > > | is also an integer. > > > > AIUI… > > There are two almost completely unrelated notions of exact > > > > 1. ⅓ in decimal cannot be exactly represented though 0.3 0.33 etc are > > approximations. > > We could call these inexact forms of ⅓ > > > > 2. Measurement and observation produces numbers. These are inexact > > inherently. > > > > Scheme's notion of exact is towards capturing the second notion. > > Why does that mean that 3.0 is inexact? In what way is 3.0 "inexact"? > It's an exact value representing the integer three.
[Assuming you are asking in good faith and in the same vein I am answering without claiming to know all this with much certainty] I believe we need to distinguish between the intention and its realization within the syntactic (in this case lexical) structures of the language. The INTENTION is that in addition to capturing the usual number tower ℕ ⊂ ℤ ⊂ ℝ (or parts therefore) scheme also captures ORTHOGONALLY (word in the docs) the (in)exactness attribute In the realization, the designers need to (over)load these different attributes onto numeric constants. So the ruse chosen is that fraction-constants by default are exact Decimal constants are inexact And one can override any of these by suitable a function [At least that's my understanding] -- https://mail.python.org/mailman/listinfo/python-list
