First and second class citizens in TTM
Quote from dandl on June 9, 2019, 7:02 amGiven a single NUMBER type there is no overloading.
I grant that D per se says nothing about numeric types and does not even require that they exist. But in Tutorial D there are disjoint types INTEGER and RATIONAL, and the latest Tutorial D spec says only that RATIONAL provides the "usual arithmetic and comparison operators" without saying which ones they are: the usual mathematical operations on rational numbers, or the usual computer operations on floating-point "numbers". They are different. So if mathematical operations are intended, then the use of floating-point operations is erroneous, and vice versa. Nor is it just a matter of rounding: there are many differences.
It is not generally possible to represent fractions exactly as single values.
What counts as a "single value" is an implementation question, or more fundamentally a matter of point of view. I at least think of rational fractions as single values like integers. You can represent 355/113 as the ordered pair <355, 113>, but then you can represent 32767 as the ordered list [3, 2, 7, 6, 7] and vice versa, or in many other ways, the most common of which at present is [63, 31, 0, 0, 0, 0, 0, 0].
As I wrote above, floats are simply a subset of values represented as type NUMBER.
In fact not all floats are rational numbers: see my post above.
If you want operations on them to treat them as intervals then you can do so, but that property is inherent in the operator, not in the value itself.
Quite so. But then IM PRE 17 precludes you from calling integer and float multiplication by the same name * , which was my original point.
Quote from johnwcowan on June 9, 2019, 4:24 pmI grant that D per se says nothing about numeric types and does not even require that they exist. But in Tutorial D there are disjoint types INTEGER and RATIONAL, and the latest Tutorial D spec says only that RATIONAL provides the "usual arithmetic and comparison operators" without saying which ones they are: the usual mathematical operations on rational numbers, or the usual computer operations on floating-point "numbers". They are different. So if mathematical operations are intended, then the use of floating-point operations is erroneous, and vice versa. Nor is it just a matter of rounding: there are many differences.
I think there is enough in TTM that a D has to provide 3 types: boolean, numeric and character. The choice of including floating point numbers for Tutorial D was entirely optional, and not in my view ideal for business software. Likewise overloading the numeric operators was a choice made, not mandated. But if you don't, and if you have multiple numeric types then the syntax gets messy. Apart from choosing floats, the Tutorial D choices are reasonable.
It is not generally possible to represent fractions exactly as single values.
What counts as a "single value" is an implementation question, or more fundamentally a matter of point of view. I at least think of rational fractions as single values like integers. You can represent 355/113 as the ordered pair <355, 113>, but then you can represent 32767 as the ordered list [3, 2, 7, 6, 7] and vice versa, or in many other ways, the most common of which at present is [63, 31, 0, 0, 0, 0, 0, 0].
You can also think of vectors, matrices, complex numbers and so on as single values but that's not relevant to my point. The numeric format I proposed is a superset of integer, float, decimal and float decimal. It's a compact compressible variable length format with none of the inherent issues of float. But it's not a good choice for fast computation.
I don't know what format you intend, but 32767 has 15 bits and your list has only 11. I would think it's more like [255, 127, 0, 0] or [0xff, 0x7f, 0, 0]. Treating the individual bytes as base 100 digits, the same value in my number format would be [3, 27, 67]. Base 254 is a more efficient use of storage, but hard to work with manually.
In fact not all floats are rational numbers: see my post above.
All floats that are numbers are rational. The exceptions are things like NaN, which can be represented in my format as special strings if required. Indeed, as many as you want!
If you want operations on them to treat them as intervals then you can do so, but that property is inherent in the operator, not in the value itself.
Quite so. But then IM PRE 17 precludes you from calling integer and float multiplication by the same name
*, which was my original point.
I'm not absolutely sure about that. The IM is optional, but even if in force it would seem one could have shortcuts like this without breaking anything. I think that's what Rel does.
Quote from dandl on June 10, 2019, 1:00 amI think there is enough in TTM that a D has to provide 3 types: boolean, numeric and character.
The 2016 TTM does not contain the words integer or rational at all, except in the change log, and only in direct reference to Tutorial D. Booleans on the other hand are mandated by RM PRE 1. It's true that the degree and cardinality of a relation are integers, but there is no requirement for an operator that returns them.
I don't know what format you intend, but 32767 has 15 bits and your list has only 11. I would think it's more like [255, 127, 0, 0]
Yes, of course: a brain fart on my part, nothing more.
If you want operations on them to treat them as intervals then you can do so, but that property is inherent in the operator, not in the value itself.
The fact (and it is a fact) is the fast float arithmetic is simply not rational arithmetic.
Quote from johnwcowan on June 10, 2019, 4:06 amQuote from dandl on June 10, 2019, 1:00 amI think there is enough in TTM that a D has to provide 3 types: boolean, numeric and character.
The 2016 TTM does not contain the words integer or rational at all, except in the change log, and only in direct reference to Tutorial D. Booleans on the other hand are mandated by RM PRE 1. It's true that the degree and cardinality of a relation are integers, but there is no requirement for an operator that returns them.
TTM is the definition of a language D. It mentions things that have a numeric value (cardinality, degree, zero) and things that have names (database, type, variable). It's hard to imagine that a D could satisfy all requirements and yet not have types for numbers and names. Feel free to show how.
If you want operations on them to treat them as intervals then you can do so, but that property is inherent in the operator, not in the value itself.
The fact (and it is a fact) is the fast float arithmetic is simply not rational arithmetic.
Of course, and it is indeed those operators that we value, not the bit patterns they work on. Personally, I find visualising numbers as digit strings like this highly effective in understanding how conversions between formats behave or misbehave. I've never tried to create an actual implementation.
Quote from dandl on June 10, 2019, 9:03 amQuote from johnwcowan on June 10, 2019, 4:06 amQuote from dandl on June 10, 2019, 1:00 amI think there is enough in TTM that a D has to provide 3 types: boolean, numeric and character.
The 2016 TTM does not contain the words integer or rational at all, except in the change log, and only in direct reference to Tutorial D. Booleans on the other hand are mandated by RM PRE 1. It's true that the degree and cardinality of a relation are integers, but there is no requirement for an operator that returns them.
TTM is the definition of a language D. It mentions things that have a numeric value (cardinality, degree, zero) and things that have names (database, type, variable). It's hard to imagine that a D could satisfy all requirements and yet not have types for numbers and names. Feel free to show how.
More accurately, though I don't recall Date &/or Darwen describing it as such, TTM is the definition of a language family D, i.e., any language that adheres to the TTM prescriptions and proscriptions. On the other hand, the Tutorial D description found in the various Date & Darwen books is a definition of a single language that belongs to the D family.
It's not difficult to imagine a D that has no numeric types. If it's a useful general-purpose D (i.e., a member of the D language family) it might be up to the user or standard library to provide them, but they need not be part of the language. If it's an esoteric or domain-specific D, it might have no numeric values at all.
Names are identifiers and thus do not usually belong to a string or CHAR type. Like the above, an esoteric or domain-specific D might have no CHAR type at all (and might not even have identifiers.)
Only BOOLEAN is mandated, per RM Pre 1, as noted above.
Dave Voorhis is absolutely right in noting that the only scalar type that TTM mandates is BOOLEAN. (It also mandates tuple and relation types, of course.) Imagining a D that has no numeric types might not be too difficult, he surmises, but I note that, for example, Tutorial D's COUNT operator would not be available as defined. My favourite programming language, Rexx (because it's (a) fun and (b) particularly useful for most of the coding I've had or chosen to do since the mid-1980s), doesn't have numeric types but supports numerical operators on character strings, returning character strings, an approach that works fine for my purposes.
Our reason for mandating BOOLEAN was to correct what we retrospectively regarded as an omission by Codd, and our reason for not mandating any other scalar types was to emphasise the neutrality of the RM with respect to scalar types. We didn't consider it our business to prescribe or even very strongly suggest which others should be supported.
Hugh
Yes, we both forgot about COUNT.
Long and long and long ago, I wrote a QBE demonstration program for OS/2. The user was presented with a spreadsheet in Excel that contained all the tables in the database. They then ran an Excel macro that wrote out the spreadsheet in CSV format and triggered a Rexx program. This created a dynamic SQL query, fetched the answers from DB/2, wrote them out in CSV, and told Excel to read the new CSV in. Worked like a charm.
Later I discovered NetRexx, which makes the statically typed JVM interoperate smoothly with the Rexx style. If you wrote A = 12 and A was hitherto unknown, it would be statically given the type of Rexx (the character/number sum type you describe), since all literals were of that type, and A would have to stick to that type thereafter. But A = Int gave it the Java type Int (32-bit integer) but no value, and A = Int 12 both typed it and assigned it. So you could totally ignore types unless you needed to call a Java API, and then you could use static variables or casts of the form Int 12.
Quote from Hugh on June 11, 2019, 10:40 amOur reason for mandating BOOLEAN was to correct what we retrospectively regarded as an omission by Codd, ...
Thanks Hugh, which particular omission was that? (I ask because I can think of several.)
Mandating BOOLEAN is indeed sensible in practice; but in theory ...
RM Pre 1 for BOOLEAN prescribes "D shall support all four monadic and 16 dyadic logical operators, directly or indirectly, for this type." Then we could mimic Boolean operators using DUM, DEE as the values and traditional relational operators for all the logic you might need.
TTM prescribes BOOLEAN types to describe the results of evaluating integrity constraints (RM Pre 23). Typical practice (in Tutorial D) is that the formula for an integrity constraint is of the form IS_EMPTY( ... ).
We'd want DEE to correspond to TRUE, so the equivalent of IS_EMPTY( ... ) in constraints would be DEE NOT MATCHING ( ... ).
It's not very clear (IIRC from Chris's analysis of Codd's early papers) whether Codd omitted degree zero relations; or whether he anticipated them but suppressed that thought because it would cause conniptions amongst IBM engineers and top brass(?)
Quote from Hugh on June 11, 2019, 10:40 amDave Voorhis is absolutely right in noting that the only scalar type that TTM mandates is BOOLEAN. (It also mandates tuple and relation types, of course.) Imagining a D that has no numeric types might not be too difficult, he surmises, but I note that, for example, Tutorial D's COUNT operator would not be available as defined. My favourite programming language, Rexx (because it's (a) fun and (b) particularly useful for most of the coding I've had or chosen to do since the mid-1980s), doesn't have numeric types but supports numerical operators on character strings, returning character strings, an approach that works fine for my purposes.
Our reason for mandating BOOLEAN was to correct what we retrospectively regarded as an omission by Codd, and our reason for not mandating any other scalar types was to emphasise the neutrality of the RM with respect to scalar types. We didn't consider it our business to prescribe or even very strongly suggest which others should be supported.
Hugh
Your point is correct of course. I merely proposed that a D is likely to need numeric and character types because those types or objects of those types are mentioned in TTM. But as you say, it's perfectly possible to have a very substantial language with only a single data type, either integer or character. I've used examples of both. TCL anyone?
So while we might know of a stripped down language with only a single non-boolean type, the type system is at the heart of TTM and I find it hard to imagine a D that satisfies all of TTM without a rich type system. And how could one have a rich type system and yet somehow omit numeric and character types?
Quote from dandl on June 11, 2019, 2:35 pmQuote from Hugh on June 11, 2019, 10:40 amDave Voorhis is absolutely right in noting that the only scalar type that TTM mandates is BOOLEAN. (It also mandates tuple and relation types, of course.) Imagining a D that has no numeric types might not be too difficult, he surmises, but I note that, for example, Tutorial D's COUNT operator would not be available as defined. My favourite programming language, Rexx (because it's (a) fun and (b) particularly useful for most of the coding I've had or chosen to do since the mid-1980s), doesn't have numeric types but supports numerical operators on character strings, returning character strings, an approach that works fine for my purposes.
Our reason for mandating BOOLEAN was to correct what we retrospectively regarded as an omission by Codd, and our reason for not mandating any other scalar types was to emphasise the neutrality of the RM with respect to scalar types. We didn't consider it our business to prescribe or even very strongly suggest which others should be supported.
Hugh
Your point is correct of course. I merely proposed that a D is likely to need numeric and character types because those types or objects of those types are mentioned in TTM. But as you say, it's perfectly possible to have a very substantial language with only a single data type, either integer or character. I've used examples of both. TCL anyone?
So while we might know of a stripped down language with only a single non-boolean type, the type system is at the heart of TTM and I find it hard to imagine a D that satisfies all of TTM without a rich type system. And how could one have a rich type system and yet somehow omit numeric and character types?
"Rich" is in the eye of the beholder. I'm merely noting the theoretical possibility, not advocating it.
Hugh