The Third Manifesto ForumDatabases: Database TheoryWhich Logical Difference?

Please or Register to create posts and topics.

Which Logical Difference?

#1 · December 1, 2021, 7:54 pm

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 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:

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 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:

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 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"?

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:

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 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:

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 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"?

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?

#2 · December 1, 2021, 8:38 pm

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.

#3 · December 1, 2021, 8:49 pm

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.).

#4 · December 1, 2021, 10:19 pm

Quote from Paul Vernon on December 1, 2021, 8:49 pm

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.).

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

#5 · December 1, 2021, 10:47 pm

Quote 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 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.).

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.

#6 · December 2, 2021, 1:08 am

Quote from dandl on December 2, 2021, 1:08 am

Quote from Paul Vernon on December 1, 2021, 8:49 pm

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.).

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 Paul Vernon on December 1, 2021, 8:49 pm

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.).

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

Andl - A New Database Language - andl.org

#7 · December 2, 2021, 6:24 am

Quote from AntC on December 2, 2021, 6:24 am

Quote from Dave Voorhis on December 1, 2021, 10:19 pm

Quote 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 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.).

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 pm

Quote 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 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.).

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.

#8 · December 2, 2021, 9:44 am

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...

#9 · December 2, 2021, 10:09 am

Quote from Paul Vernon on December 2, 2021, 10:09 am

Quote from dandl on December 2, 2021, 1:08 am

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.

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,-3and 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, 1:08 am

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.

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,-3and 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.

#10 · December 2, 2021, 12:49 pm

Quote from dandl on December 2, 2021, 12:49 pm

Quote from Paul Vernon on December 2, 2021, 10:09 am

Quote from dandl on December 2, 2021, 1:08 am

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.

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

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

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,-3and 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

No, 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 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)

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.

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.

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 am

Quote from dandl on December 2, 2021, 1:08 am

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.

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

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

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,-3and 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

No, 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 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)

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.

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.

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).

Andl - A New Database Language - andl.org

The Forum for Discussion about The Third Manifesto and Related Matters

Which Logical Difference?