# Which Logical Difference?

**Page 1 of 2**Next

Quote from Paul Vernon on December 1, 2021, 7:54 pm(BTW apologies for the topic title. I did not set out to create a series of similarly named topics - if I had I might have given more thought to their names.)

I was considering again the claim from Database Explorations that "Integers aren’t rational numbers", and the following sentences struck me as the heart of the matter

But isomorphic doesn’t mean identical! There’s a clear logical difference between the two systems.

Now, Wikipedia has this to say

In certain areas of mathematics, notably category theory, it is valuable to distinguish between

equalityon the one hand andisomorphismon the otherwhich rather suggests that in some areas of mathematics it is

not valuableto distinguish between equality and isomorphism.The question then is: In which area of mathematics is the relational model?

Should we

distinguishthe integers from the integer rationals because they are "only" isomorphic, and not (depending on the construction) "the same", or should we forgo that distinction and, as mathematicians would say "identify the integers and the rationals".As Stuart and Tall in The Foundations of Mathematics (2nd ed, pg 197) say:

Mathematicians take a more pragmatic route. They 'identify' ℕ₀ and ℤ⁺, that is, they ignore the technical set-theoretic distinction between them for purposes of arithmetic and order. This causes no harm because these two systems have exactly the same mathematical structure as regards arithmetic and order. If we ignore the distinction, we can consider ℕ₀ to be a subsystem of ℤ. This fits with how the human mind simplifies the situation by thinking of ℕ₀ and ℤ⁺ as different ways to represent the same underlying mathematical concept.[ℕ₀ being the natural numbers starting from 0, and ℤ⁺ being the non-negative integers]

If mathematicians can be pragmatic enough to "ignore the technical set-theoretic distinction", should database systems not also be similarly pragmatic - or do we aspire to higher things?

Should we distinguish between the natural numbers and the positive integers for the same reason? I.e. because you can construct the Integers as equivalence classes of order pairs of natural numbers (including 0) and that in such a construction, the natural numbers are then

nota subset of the integers.Is is

usefulto distinguish`+1`

and`1`

so that`SIGN()`

can return`+`

for the first value and "error" or`∅`

for the second? So that`+1 == 1`

is true but`+1 === 1`

is false? Is itusefulto distinguish`¹⁄₁`

from`1`

so that e.g.`DENOMINATOR()`

can return`1`

from the first value and "error" or`∅`

for the second?I say it is

notuseful for the basic number values and arithmetic operators that you might reasonably expect to be built into a database system to work in the above way.I say we should take the the approach that mathematics find "unaesthetic". From Stuart and Tall again:

There are various ways to get round this problem. One is to replace the elements of`ℤ⁺`

by the corresponding elements of`ℕ₀`

, creating a hybrid system with the elements`0`

,`1`

,`2`

, ... in`ℕ₀`

as the non-negative integers and the ordered pairs`(m, m + n)`

as the negative integers`-n`

.This hybrid system contains`ℕ₀`

as a genuine subset, and extends to include elements of the form`(m, m + n)`

.However, this method is inelegant and lacks the aesthetic simplicity desired in mathematics

So, for the set of rationals, we "replace"

`¹⁄₁`

(and`²⁄₂`

,`³⁄₃`

etc) with`1`

and replace`²⁄₁`

(and`⁴⁄₂`

etc) with`2`

and so on. This allows our integers to be asubsetof our rationals, which is surely the best place to be. We need to disregard issues of internal (possible) representation.Which gets me back to the old maxim that "Logical Differences are big differences". Maybe the maxim actually needs to be:

Logical Differences

past isomorphismare big differencesand hence

Logical Differences up to an isomorphism are small differences

P.S. Wikipedia further refines the ideas here with that of a

naturalisomorphism - "an isomorphism that does not depend on an arbitrary choice" - which is probably also informative to any debate here. I.e. "Logical Differencespast a natural isomorphismare big differences"?

Googling for "logical difference" gets this nice stackexchange question with this reasonable attempted definition of the term

A concept is logically the same as another concept if for each possible context in which the concept can be used has the same result for each concept. Conversely if the results are different, then there is a logical difference.So really it is all about context. If two objects are isomorphic within our chosen context(s), then we should consider them the same object, if not, we should recognise their difference. Agree?

(BTW apologies for the topic title. I did not set out to create a series of similarly named topics - if I had I might have given more thought to their names.)

I was considering again the claim from Database Explorations that "Integers aren’t rational numbers", and the following sentences struck me as the heart of the matter

But isomorphic doesn’t mean identical! There’s a clear logical difference between the two systems.

Now, Wikipedia has this to say

In certain areas of mathematics, notably category theory, it is valuable to distinguish between *equality* on the one hand and *isomorphism* on the other

which rather suggests that in some areas of mathematics it is *not valuable* to distinguish between equality and isomorphism.

The question then is: In which area of mathematics is the relational model?

Should we *distinguish* the integers from the integer rationals because they are "only" isomorphic, and not (depending on the construction) "the same", or should we forgo that distinction and, as mathematicians would say "identify the integers and the rationals".

As Stuart and Tall in The Foundations of Mathematics (2nd ed, pg 197) say:

[ℕ₀ being the natural numbers starting from 0, and ℤ⁺ being the non-negative integers]

If mathematicians can be pragmatic enough to "ignore the technical set-theoretic distinction", should database systems not also be similarly pragmatic - or do we aspire to higher things?

Should we distinguish between the natural numbers and the positive integers for the same reason? I.e. because you can construct the Integers as equivalence classes of order pairs of natural numbers (including 0) and that in such a construction, the natural numbers are then *not* a subset of the integers.

Is is *useful* to distinguish `+1`

and `1`

so that `SIGN()`

can return `+`

for the first value and "error" or `∅`

for the second? So that `+1 == 1`

is true but `+1 === 1`

is false? Is it *useful* to distinguish `¹⁄₁`

from `1`

so that e.g. `DENOMINATOR()`

can return `1`

from the first value and "error" or `∅`

for the second?

I say it is **not** useful for the basic number values and arithmetic operators that you might reasonably expect to be built into a database system to work in the above way.

I say we should take the the approach that mathematics find "unaesthetic". From Stuart and Tall again:

`ℤ⁺`

by the corresponding elements of `ℕ₀`

, creating a hybrid system with the elements `0`

, `1`

, `2`

, ... in `ℕ₀`

as the non-negative integers and the ordered pairs `(m, m + n)`

as the negative integers `-n`

.`ℕ₀`

as a genuine subset, and extends to include elements of the form `(m, m + n)`

.

So, for the set of rationals, we "replace" `¹⁄₁`

(and `²⁄₂`

, `³⁄₃`

etc) with `1`

and replace `²⁄₁`

(and `⁴⁄₂`

etc) with `2`

and so on. This allows our integers to be a *subset* of our rationals, which is surely the best place to be. We need to disregard issues of internal (possible) representation.

Which gets me back to the old maxim that "Logical Differences are big differences". Maybe the maxim actually needs to be:

Logical Differences *past isomorphism* are big differences

and hence

Logical Differences up to an isomorphism are small differences

P.S. Wikipedia further refines the ideas here with that of a *natural *isomorphism - "an isomorphism that does not depend on an arbitrary choice" - which is probably also informative to any debate here. I.e. "Logical Differences *past a natural isomorphism* are big differences"?

*A concept is logically the same as another concept if for each possible context in which the concept can be used has the same result for each concept. Conversely if the results are different, then there is a logical difference.*

So really it is all about context. If two objects are isomorphic within our chosen context(s), then we should consider them the same object, if not, we should recognise their difference. Agree?

Quote from Darren Duncan on December 1, 2021, 8:38 pmI would say it is entirely up to the specific programming language for how they choose to make concepts distinct or not.

For example, it is up to each language whether they want to have an INTEGER type plus a RATIONAL type such that "1 = 1.0" returns true or false.

This doesn't seem like the kind of thing where there is a single best way to decide that, independent of the language.

I would say it is entirely up to the specific programming language for how they choose to make concepts distinct or not.

For example, it is up to each language whether they want to have an INTEGER type plus a RATIONAL type such that "1 = 1.0" returns true or false.

This doesn't seem like the kind of thing where there is a single best way to decide that, independent of the language.

Quote from Paul Vernon on December 1, 2021, 8:49 pmI would rather think about database systems specifically.

Programming languages in which you might want to do "systems programming" might well want to make such distinctions explicit for reasons of performance and "being closer to the hardware".

In a database system where the goal should be (in my opinion anyway) about "modelling reality" (maybe "reality as perceived" if you prefer), then I think there is one best way, and that is that the Natural numbers

are a subsetof the integers, and that the integersare a subsetof the rationals (and the rationalsa subsetof the reals, and the realsa subsetof the imaginary numbers and so on if appropriate.).

I would rather think about database systems specifically.

Programming languages in which you might want to do "systems programming" might well want to make such distinctions explicit for reasons of performance and "being closer to the hardware".

In a database system where the goal should be (in my opinion anyway) about "modelling reality" (maybe "reality as perceived" if you prefer), then I think there is one best way, and that is that the Natural numbers **are a subset** of the integers, and that the integers **are a subset** of the rationals (and the rationals **a subset** of the reals, and the reals **a subset **of the imaginary numbers and so on if appropriate.).

Quote from Dave Voorhis on December 1, 2021, 10:19 pmQuote from Paul Vernon on December 1, 2021, 8:49 pmI would rather think about database systems specifically.

Programming languages in which you might want to do "systems programming" might well want to make such distinctions explicit for reasons of performance and "being closer to the hardware".

In a database system where the goal should be (in my opinion anyway) about "modelling reality" (maybe "reality as perceived" if you prefer), then I think there is one best way, and that is that the Natural numbers

are a subsetof the integers, and that the integersare a subsetof the rationals (and the rationalsa subsetof the reals, and the realsa subsetof the imaginary numbers and so on if appropriate.).I've argued here before that database systems are fundamentally about modelling

data, which is not quite the same thing as modelling reality. As such, sometimes performance will be critical and override any other considerations, and sometimes a mathematically-derived subtype hierarchy of numeric representations will override performance considerations.Other requirements may drive other -- equally valid, given their requirements -- approaches.

Quote from Paul Vernon on December 1, 2021, 8:49 pmI would rather think about database systems specifically.

are a subsetof the integers, and that the integersare a subsetof the rationals (and the rationalsa subsetof the reals, and the realsa subsetof the imaginary numbers and so on if appropriate.).

I've argued here before that database systems are fundamentally about modelling *data*, which is not quite the same thing as modelling reality. As such, sometimes performance will be critical and override any other considerations, and sometimes a mathematically-derived subtype hierarchy of numeric representations will override performance considerations.

Other requirements may drive other -- equally valid, given their requirements -- approaches.

*I'm the forum administrator and lead developer of Rel. Email me at dave@armchair.mb.ca with the Subject 'TTM Forum'. Download Rel from https://reldb.org*

Quote from Darren Duncan on December 1, 2021, 10:47 pmQuote from Paul Vernon on December 1, 2021, 8:49 pmare a subsetof the integers, and that the integersare a subsetof the rationals (and the rationalsa subsetof the reals, and the realsa subsetof the imaginary numbers and so on if appropriate.).I believe in principle there should be an integer-only type, and any rational type is disjoint from it. While performance or systems programming can benefit, the primary reason for this is logic and modelling data or reality.

Models always start from simple concepts and build up more complex concepts in terms of them. Integers are about the simplest numerical concept there is, and there is an enormous amount of data and logic that is specific to integers and which more general types like rationals give no benefit and just add complexity or are just invalid.

Also saying one just has the more generic rational type etc of which an integer is a special case or subtype, this is an infinite rabbit hole. As integers are a subset of rationals, so are those of reals, so are those of complex, so of those are of quaternions, so are those of octernions, and so on. If you pick rational as your main type, then how do you represent complex numbers etc?

So making integers their own disjoint thing, in databases, and selectively adding each additional layer of more general type out as far as you want (and users can define ones the system doesn't), is a much more elegant and logical solution.

Quote from Paul Vernon on December 1, 2021, 8:49 pmare a subsetof the integers, and that the integersare a subsetof the rationals (and the rationalsa subsetof the reals, and the realsa subsetof the imaginary numbers and so on if appropriate.).

I believe in principle there should be an integer-only type, and any rational type is disjoint from it. While performance or systems programming can benefit, the primary reason for this is logic and modelling data or reality.

Models always start from simple concepts and build up more complex concepts in terms of them. Integers are about the simplest numerical concept there is, and there is an enormous amount of data and logic that is specific to integers and which more general types like rationals give no benefit and just add complexity or are just invalid.

Also saying one just has the more generic rational type etc of which an integer is a special case or subtype, this is an infinite rabbit hole. As integers are a subset of rationals, so are those of reals, so are those of complex, so of those are of quaternions, so are those of octernions, and so on. If you pick rational as your main type, then how do you represent complex numbers etc?

So making integers their own disjoint thing, in databases, and selectively adding each additional layer of more general type out as far as you want (and users can define ones the system doesn't), is a much more elegant and logical solution.

Quote from dandl on December 2, 2021, 1:08 amQuote from Paul Vernon on December 1, 2021, 8:49 pmI would rather think about database systems specifically.

are a subsetof the integers, and that the integersare a subsetof the rationals (and the rationalsa subsetof the reals, and the realsa subsetof the imaginary numbers and so on if appropriate.).I don't think there is any point responding to the ruminations above, but this assertion is worth considering. Nothing to do with 'performance' or 'database vs systems', and not even remotely connected to 'reality' but a valid question nonetheless.

Computer systems that store and manipulate externally-derived data have no (known) choice but to deal with values that belong to types, and to express their algorithms in programming languages. [I make this point because there is good evidence that the human brain can do the same things and does not do it the same way, but this is the only way we know how to do it.]

So in this constrained context your assertions have no meaning, unless we give it one. Perhaps you meant to say:

naturalis the name of a typeintegeris the name of a type- any value that is an
integeris also at the same time anatural(but not vice versa), or- any value that is an
integeris equal to some value that is anatural(but not vice versa), or- any value that is an
integercan be converted to and from a corresponding value that is anatural(but not vice versa), or- any
integervalue is within the domain of every function onnaturaland will return the very same value (but is that value anintegeror anaturalor both?)- ???
As I have said before, a great proportion of all disagreements turn out to be due to reliance on poorly defined terms or failure to think through the detail. I think this is one of them.

FWIW in my '9 type model'

integeris distinguished by by having a successor functionrationalis distinguished by being able to exactly represent numeric valuesfloatis distinguished by convenience as to size, scale and hardware support (all floats are also rationals)complexis astructwith two members

Quote from Paul Vernon on December 1, 2021, 8:49 pmI would rather think about database systems specifically.

are a subsetof the integers, and that the integersare a subsetof the rationals (and the rationalsa subsetof the reals, and the realsa subsetof the imaginary numbers and so on if appropriate.).

I don't think there is any point responding to the ruminations above, but this assertion is worth considering. Nothing to do with 'performance' or 'database vs systems', and not even remotely connected to 'reality' but a valid question nonetheless.

Computer systems that store and manipulate externally-derived data have no (known) choice but to deal with values that belong to types, and to express their algorithms in programming languages. [I make this point because there is good evidence that the human brain can do the same things and does not do it the same way, but this is the only way we know how to do it.]

So in this constrained context your assertions have no meaning, unless we give it one. Perhaps you meant to say:

**natural**is the name of a type**integer**is the name of a type- any value that is an
**integer**is also at the same time a**natural**(but not vice versa), or - any value that is an
**integer**is equal to some value that is a**natural**(but not vice versa), or - any value that is an
**integer**can be converted to and from a corresponding value that is a**natural**(but not vice versa), or - any
**integer**value is within the domain of every function on**natural**and will return the very same value (but is that value an**integer**or a**natural**or both?) - ???

As I have said before, a great proportion of all disagreements turn out to be due to reliance on poorly defined terms or failure to think through the detail. I think this is one of them.

FWIW in my '9 type model'

**integer**is distinguished by by having a successor function**rational**is distinguished by being able to exactly represent numeric values**float**is distinguished by convenience as to size, scale and hardware support (all floats are also rationals)**complex**is a**struct**with two members

Quote from AntC on December 2, 2021, 6:24 amQuote from Dave Voorhis on December 1, 2021, 10:19 pmQuote from Paul Vernon on December 1, 2021, 8:49 pm... In a database system where the goal should be (in my opinion anyway) about "modelling reality" (maybe "reality as perceived" if you prefer), then I think there is one best way, and that is that the Natural numbers

are a subsetof the integers, and that the integersare a subsetof the rationals (and the rationalsa subsetof the reals, and the realsa subsetof the imaginary numbers and so on if appropriate.).A database is modelling a designed/deliberate abstraction from "reality". You [Paul] are unfortunately sounding dangerously like Fabian Pascal, whose 'logic' drives him to a position that a database must be isomorphic to "reality" such that we must model each bean of each tin of each carton of each palette on the warehouse floor; and each bean is identifiable in principle by its DNA. Pacal regards his 'logic' as incontrovertible -- that is, that nobody (other than possibly McGoveran) is adequately qualified to disagree with him.

I've argued here before that database systems are fundamentally about modelling

data, which is not quite the same thing as modelling reality. As such, sometimes performance will be critical and override any other considerations, and sometimes a mathematically-derived subtype hierarchy of numeric representations will override performance considerations.Yes this.

Other requirements may drive other -- equally valid, given their requirements -- approaches.

For example: the reality of interacting with a banking system is that cash values must be in dollars and cents/pounds and pence -- which are neither integer nor floating point, nor usefully modelled as rationals. So @dandl's list is inadequate for some business applications:

integer...rational...float...complex...@Paul is your thread title deliberately riffing on D&D's favourite quote about "Logical differences"?

In which area of mathematics is the relational model?

Shibboleth Alert! Alert! There is no single *the* relational model. Relationland is diverse. Go put a question on Stackoverflow, be careful to tag it

`[relational-algebra]`

and say "*the* relational ..."; the trolls will circle very quickly.

Quote from Dave Voorhis on December 1, 2021, 10:19 pmQuote from Paul Vernon on December 1, 2021, 8:49 pm... In a database system where the goal should be (in my opinion anyway) about "modelling reality" (maybe "reality as perceived" if you prefer), then I think there is one best way, and that is that the Natural numbers

are a subsetof the integers, and that the integersare a subsetof the rationals (and the rationalsa subsetof the reals, and the realsa subsetof the imaginary numbers and so on if appropriate.).

A database is modelling a designed/deliberate abstraction from "reality". You [Paul] are unfortunately sounding dangerously like Fabian Pascal, whose 'logic' drives him to a position that a database must be isomorphic to "reality" such that we must model each bean of each tin of each carton of each palette on the warehouse floor; and each bean is identifiable in principle by its DNA. Pacal regards his 'logic' as incontrovertible -- that is, that nobody (other than possibly McGoveran) is adequately qualified to disagree with him.

data, which is not quite the same thing as modelling reality. As such, sometimes performance will be critical and override any other considerations, and sometimes a mathematically-derived subtype hierarchy of numeric representations will override performance considerations.

Yes this.

Other requirements may drive other -- equally valid, given their requirements -- approaches.

For example: the reality of interacting with a banking system is that cash values must be in dollars and cents/pounds and pence -- which are neither integer nor floating point, nor usefully modelled as rationals. So @dandl's list is inadequate for some business applications:

integer...rational...float...complex...

@Paul is your thread title deliberately riffing on D&D's favourite quote about "Logical differences"?

In which area of mathematics is the relational model?

Shibboleth Alert! Alert! There is no single *the* relational model. Relationland is diverse. Go put a question on Stackoverflow, be careful to tag it `[relational-algebra]`

and say "*the* relational ..."; the trolls will circle very quickly.

Quote from Paul Vernon on December 2, 2021, 9:44 amThank you all for your replies.

To answer Anthony's question "@Paul is your thread title deliberately riffing on D&D's favourite quote about "Logical differences"? I can say absolutely, and (if you will indulge me) I'll state my question again:

When should we(as database people)consider two isomorphic things as being "logically different" vs considering them "logically the same"?It appears that the general answer to my original post is that "it depends" or that it is "a specific programming language choose". I guess I was hoping for something a little more interesting. Q. Should I stop at the red light ahead? A. It depends. I know both options are possible, but can't we say anything more about which might be better? Feel free to re-read my original message if that would help.

P.S. To the matter of "modelling reality", I feel the need to start a new post...

Thank you all for your replies.

To answer Anthony's question "@Paul is your thread title deliberately riffing on D&D's favourite quote about "Logical differences"? I can say absolutely, and (if you will indulge me) I'll state my question again:

**When should we **(as database people) **consider two isomorphic things as being "logically different" vs considering them "logically the same"?**

It appears that the general answer to my original post is that "it depends" or that it is "a specific programming language choose". I guess I was hoping for something a little more interesting. Q. Should I stop at the red light ahead? A. It depends. I know both options are possible, but can't we say anything more about which might be better? Feel free to re-read my original message if that would help.

P.S. To the matter of "modelling reality", I feel the need to start a new post...

Quote from Paul Vernon on December 2, 2021, 10:09 amQuote from dandl on December 2, 2021, 1:08 amPerhaps you meant to say:

naturalis the name of a typeintegeris the name of a type- any value that is an
integeris also at the same time anatural(but not vice versa), or- any value that is an
integeris equal to some value that is anatural(but not vice versa), or- any value that is an
integercan be converted to and from a corresponding value that is anatural(but not vice versa), or- any
integervalue is within the domain of every function onnaturaland will return the very same value (but is that value anintegeror anaturalor both?)- ???
As I have said before, a great proportion of all disagreements turn out to be due to reliance on poorly defined terms or failure to think through the detail. I think this is one of them.

OK. Let me try to use your terms.

In the first case where we consider that there

is no logical differencebetween`ℕ₀`

and`ℤ⁺`

, we have

naturalis the name of a type and its values are`0`

,`1`

,`2`

,`3`

and so on. I.e. these are the Natural Numbers but I'm including`0`

. Mathematically, this is the set`ℕ₀`

integeris the name of a type and its values are`0`

,`1`

,`-1`

,`2`

,`-2`

,`3`

,`-3`

and so on. Mathematically, this is the set`ℤ`

- any value that is a
naturalis also at the same time aninteger. Mathematically,`ℕ₀`

is a subset of`ℤ`

- an operator
is provided that returns true for values that are the same. So,`=`

`1 = 1`

returns true for example, or using`:`

to indicate the type of a value,`1:natural = 1:integer`

returns trueIn the second case where we consider that there

is a logical differencebetween`ℕ₀`

and`ℤ⁺`

, we have

naturalis the name of a type and its values are`0`

,`1`

,`2`

,`3`

and so on. I.e. these are the Natural Numbers but I'm including`0`

. Mathematically, this is the set`ℕ₀`

integeris the name of a type and its values are`+0`

,`+1`

,`-1`

,`+2`

,`-2`

,`+3`

,`-3`

and so on. Mathematically, this is the set`ℤ`

- no value is both a
naturaland at the same time aninteger. Mathematically,`ℕ₀`

is disjoint from`ℤ`

- an operator
is provided that returns`==`

`true`

for isomorphic values. So,`1 == +1`

returns true- an operator
is provided that returns`===`

`true`

for values that have no logical difference (that are the same). So,`1 === +1`

returns`false`

If you object to the above, let me try it this way for the second case (and we can call this the third case)

naturalis the name of a type and its values are`0`

,`1`

,`2`

,`3`

and so on. I.e. these are the Natural Numbers but I'm including`0`

. Mathematically, this is the set`ℕ₀`

integeris the name of a type and its values are`0`

,`1`

,`-1`

,`2`

,`-2`

,`3`

,`-3`

and so on. Mathematically, this is the set`ℤ`

- values are meaningless without an attached type. We use
`:`

to indicate the type of a value- it is somewhat meaningless to ask if a value is both a
naturaland at the same time aninteger. Values without an attached type are meaningless- an operator
is provided that returns`==`

`true`

for isomorphic values. So,`1:natural == 1:integer`

returns`true`

- an operator
is provided that returns`===`

`true`

for values that have no logical difference (that are the same). So,`1:natural === 1:integer`

returns`false`

My claim is that the first case is simpler. Hence - all other things being equal - it is the better choice.

Quote from dandl on December 2, 2021, 1:08 amPerhaps you meant to say:

naturalis the name of a typeintegeris the name of a type- any value that is an
integeris also at the same time anatural(but not vice versa), or- any value that is an
integeris equal to some value that is anatural(but not vice versa), or- any value that is an
integercan be converted to and from a corresponding value that is anatural(but not vice versa), or- any
integervalue is within the domain of every function onnaturaland will return the very same value (but is that value anintegeror anaturalor both?)- ???

OK. Let me try to use your terms.

In the first case where we consider that there **is no logical difference** between `ℕ₀`

and `ℤ⁺`

, we have

**natural**is the name of a type and its values are`0`

,`1`

,`2`

,`3`

and so on. I.e. these are the Natural Numbers but I'm including`0`

. Mathematically, this is the set`ℕ₀`

**integer**is the name of a type and its values are`0`

,`1`

,`-1`

,`2`

,`-2`

,`3`

,`-3`

and so on. Mathematically, this is the set`ℤ`

- any value that is a
**natural**is also at the same time an**integer**. Mathematically,`ℕ₀`

is a subset of`ℤ`

- an operator
is provided that returns true for values that are the same. So,`=`

`1 = 1`

returns true for example, or using`:`

to indicate the type of a value,`1:natural = 1:integer`

returns true

In the second case where we consider that there **is a logical difference** between `ℕ₀`

and `ℤ⁺`

, we have

**natural**is the name of a type and its values are`0`

,`1`

,`2`

,`3`

and so on. I.e. these are the Natural Numbers but I'm including`0`

. Mathematically, this is the set`ℕ₀`

**integer**is the name of a type and its values are`+0`

,`+1`

,`-1`

,`+2`

,`-2`

,`+3`

,`-3`

and so on. Mathematically, this is the set`ℤ`

- no value is both a
**natural**and at the same time an**integer**. Mathematically,`ℕ₀`

is disjoint from`ℤ`

- an operator
is provided that returns`==`

`true`

for isomorphic values. So,`1 == +1`

returns true - an operator
is provided that returns`===`

`true`

for values that have no logical difference (that are the same). So,`1 === +1`

returns`false`

If you object to the above, let me try it this way for the second case (and we can call this the third case)

**natural**is the name of a type and its values are`0`

,`1`

,`2`

,`3`

and so on. I.e. these are the Natural Numbers but I'm including`0`

. Mathematically, this is the set`ℕ₀`

**integer**is the name of a type and its values are`0`

,`1`

,`-1`

,`2`

,`-2`

,`3`

,`-3`

and so on. Mathematically, this is the set`ℤ`

- values are meaningless without an attached type. We use
`:`

to indicate the type of a value - it is somewhat meaningless to ask if a value is both a
**natural**and at the same time an**integer**. Values without an attached type are meaningless - an operator
is provided that returns`==`

`true`

for isomorphic values. So,`1:natural == 1:integer`

returns`true`

- an operator
is provided that returns`===`

`true`

for values that have no logical difference (that are the same). So,`1:natural === 1:integer`

returns`false`

My claim is that the first case is simpler. Hence - all other things being equal - it is the better choice.

Quote from dandl on December 2, 2021, 12:49 pmQuote from Paul Vernon on December 2, 2021, 10:09 amQuote from dandl on December 2, 2021, 1:08 amPerhaps you meant to say:

naturalis the name of a typeintegeris the name of a type- any value that is an
integeris also at the same time anatural(but not vice versa), or- any value that is an
integeris equal to some value that is anatural(but not vice versa), orintegercan be converted to and from a corresponding value that is anatural(but not vice versa), orintegervalue is within the domain of every function onnaturaland will return the very same value (but is that value anintegeror anaturalor both?)- ???
OK. Let me try to use your terms.

In the first case where we consider that there

is no logical differencebetween`ℕ₀`

and`ℤ⁺`

, we haveIn the spirit of 'defining terms' how do you define 'logical difference'? But I digress...

naturalis the name of a type and its values are`0`

,`1`

,`2`

,`3`

and so on. I.e. these are the Natural Numbers but I'm including`0`

. Mathematically, this is the set`ℕ₀`

integeris the name of a type and its values are`0`

,`1`

,`-1`

,`2`

,`-2`

,`3`

,`-3`

and so on. Mathematically, this is the set`ℤ`

- any value that is a
naturalis also at the same time aninteger. Mathematically,`ℕ₀`

is a subset of`ℤ`

- an operator
is provided that returns true for values that are the same. So,`=`

`1 = 1`

returns true for example, or using`:`

to indicate the type of a value,`1:natural = 1:integer`

returns trueNo, it doesn't get any better. Let's try it with a concrete example. Assume we start with the value 5 and subtract 3 from it, and then again from the result.

- If 5 is a natural, the first subtraction returns 2 and the second fails.
- If 5 is an integer, the first subtraction returns 2 and the second returns -1.
These are ordinary English descriptions of basic arithmetic, which happen to align perfectly with what would happen in a suitable programming language. You need to know the type in order to know the result of applying a function to a value. You can't punt. Values of different types are different values.

In the second case where we consider that there

is a logical differencebetween`ℕ₀`

and`ℤ⁺`

, we have

naturalis the name of a type and its values are`0`

,`1`

,`2`

,`3`

and so on. I.e. these are the Natural Numbers but I'm including`0`

. Mathematically, this is the set`ℕ₀`

integeris the name of a type and its values are`+0`

,`+1`

,`-1`

,`+2`

,`-2`

,`+3`

,`-3`

and so on. Mathematically, this is the set`ℤ`

- no value is both a
naturaland at the same time aninteger. Mathematically,`ℕ₀`

is disjoint from`ℤ`

- an operator
is provided that returns`==`

`true`

for isomorphic values. So,`1 == +1`

returns true- an operator
is provided that returns`===`

`true`

for values that have no logical difference (that are the same). So,`1 === +1`

returns`false`

If you object to the above, let me try it this way for the second case (and we can call this the third case)

This is a feature of some programming languages, such as JS and Python. It's usable, but it can result in difficult bugs. Doesn't address the problem with operators.

naturalis the name of a type and its values are`0`

,`1`

,`2`

,`3`

and so on. I.e. these are the Natural Numbers but I'm including`0`

. Mathematically, this is the set`ℕ₀`

integeris the name of a type and its values are`0`

,`1`

,`-1`

,`2`

,`-2`

,`3`

,`-3`

and so on. Mathematically, this is the set`ℤ`

- values are meaningless without an attached type. We use
`:`

to indicate the type of a value- it is somewhat meaningless to ask if a value is both a
naturaland at the same time aninteger. Values without an attached type are meaningless- an operator
is provided that returns`==`

`true`

for isomorphic values. So,`1:natural == 1:integer`

returns`true`

- an operator
is provided that returns`===`

`true`

for values that have no logical difference (that are the same). So,`1:natural === 1:integer`

returns`false`

My claim is that the first case is simpler. Hence - all other things being equal - it is the better choice.

Einstein is quoted as saying: everything should be as simple as possible, but not simpler.

There are better ways. One possibility is inheritance (see TTM IM). Another is type traits, that allow groups of operators defined for one type to be applied to others (see Haskell).

Quote from Paul Vernon on December 2, 2021, 10:09 amQuote from dandl on December 2, 2021, 1:08 amPerhaps you meant to say:

naturalis the name of a typeintegeris the name of a type- any value that is an
integeris also at the same time anatural(but not vice versa), or- any value that is an
integeris equal to some value that is anatural(but not vice versa), orintegercan be converted to and from a corresponding value that is anatural(but not vice versa), orintegervalue is within the domain of every function onnaturaland will return the very same value (but is that value anintegeror anaturalor both?)- ???
OK. Let me try to use your terms.

In the first case where we consider that there

is no logical differencebetween`ℕ₀`

and`ℤ⁺`

, we have

In the spirit of 'defining terms' how do you define 'logical difference'? But I digress...

naturalis the name of a type and its values are`0`

,`1`

,`2`

,`3`

and so on. I.e. these are the Natural Numbers but I'm including`0`

. Mathematically, this is the set`ℕ₀`

integeris the name of a type and its values are`0`

,`1`

,`-1`

,`2`

,`-2`

,`3`

,`-3`

and so on. Mathematically, this is the set`ℤ`

- any value that is a
naturalis also at the same time aninteger. Mathematically,`ℕ₀`

is a subset of`ℤ`

- an operator
is provided that returns true for values that are the same. So,`=`

`1 = 1`

returns true for example, or using`:`

to indicate the type of a value,`1:natural = 1:integer`

returns trueNo, it doesn't get any better. Let's try it with a concrete example. Assume we start with the value 5 and subtract 3 from it, and then again from the result.

- If 5 is a natural, the first subtraction returns 2 and the second fails.
- If 5 is an integer, the first subtraction returns 2 and the second returns -1.
These are ordinary English descriptions of basic arithmetic, which happen to align perfectly with what would happen in a suitable programming language. You need to know the type in order to know the result of applying a function to a value. You can't punt. Values of different types are different values.

In the second case where we consider that there

is a logical differencebetween`ℕ₀`

and`ℤ⁺`

, we have

naturalis the name of a type and its values are`0`

,`1`

,`2`

,`3`

and so on. I.e. these are the Natural Numbers but I'm including`0`

. Mathematically, this is the set`ℕ₀`

integeris the name of a type and its values are`+0`

,`+1`

,`-1`

,`+2`

,`-2`

,`+3`

,`-3`

and so on. Mathematically, this is the set`ℤ`

- no value is both a
naturaland at the same time aninteger. Mathematically,`ℕ₀`

is disjoint from`ℤ`

- an operator
is provided that returns`==`

`true`

for isomorphic values. So,`1 == +1`

returns true- an operator
is provided that returns`===`

`true`

for values that have no logical difference (that are the same). So,`1 === +1`

returns`false`

This is a feature of some programming languages, such as JS and Python. It's usable, but it can result in difficult bugs. Doesn't address the problem with operators.

naturalis the name of a type and its values are`0`

,`1`

,`2`

,`3`

and so on. I.e. these are the Natural Numbers but I'm including`0`

. Mathematically, this is the set`ℕ₀`

integeris the name of a type and its values are`0`

,`1`

,`-1`

,`2`

,`-2`

,`3`

,`-3`

and so on. Mathematically, this is the set`ℤ`

- values are meaningless without an attached type. We use
`:`

to indicate the type of a value- it is somewhat meaningless to ask if a value is both a
naturaland at the same time aninteger. Values without an attached type are meaningless- an operator
is provided that returns`==`

`true`

for isomorphic values. So,`1:natural == 1:integer`

returns`true`

- an operator
is provided that returns`===`

`true`

for values that have no logical difference (that are the same). So,`1:natural === 1:integer`

returns`false`

Einstein is quoted as saying: everything should be as simple as possible, but not simpler.

There are better ways. One possibility is inheritance (see TTM IM). Another is type traits, that allow groups of operators defined for one type to be applied to others (see Haskell).

**Page 1 of 2**Next