Which Result?
Quote from dandl on November 19, 2021, 12:07 pmThat isn't going to work. The first is a reference to a dog, one of many. The second is a reference to the dog, just one. The difference is more than mere definition.
I did worry that it might not work. And yes, the difference between one thing and one thing that is a collection of many things, is not always easy to be clear on.
At a language level it's legitimate to talk about a universe, one of many, a member of a class of things. In the multiverse there are many such.
Of course, the obvious response is "what is the multiverse a member of" but I'm happy to not go there.
A decimal approximation like 3.67 or 3.667 is far more typical, and whilst it may have been the case that in the early days of mechanised bookkeeping the use of decimal literals were grudgingly accepted because technical limitations precluded fractional notation -- and I'm only guessing that might have been the case -- all those who perhaps grudgingly endured it are long deceased now, so decimal notation is now not only technically easier, it's expected (for most uses) by business users.
There being 240 pence to a pound, a decimal approximation for the price of a 'penny chew' would rapidly get the tuck shop into trouble at school break. I had a Post Office savings book, first 'investment' by my grandparents, with a running balance totalled as £sd columns in copperplate -- and it paid interest. Decimalise that!
Fractional units were widespread across all bookkeeping in the UK and colonies: not only LSD but feet and inches, pounds and ounces, and so on. Metrication was advocated from the 17th century and rolled out as a real system in France during the 18th. It was well known and widely support in all computers A few extra features to help with LSD was a brief passing phase before the last of the hold-outs abandoned it in 1971.
It's easy to deal with fractional units (even the stupid American units) in languages that have good support for structs, in much the same way as we deal with dates and different calendars.
None of this makes a literal such as "3²⁄₃" intrinsically meaningful. We may recognise it on sight but only by convention, as some kind of fraction, but is it a number or even a value? Perhaps like 8½ it's just the name of a film. Context aka type is required to convey meaning.
Quote from Paul Vernon on November 19, 2021, 11:17 amLet me try this.
If I always have to nominate a type for every value either explicitly, or implicitly via some "context', how do I know that the following values are the same value
1:integer,1:rational,1:odd,1:1,1:alpha
Typically, the developer knows the type system (and its inheritance hierarchy, if it has an inheritance hierarchy); either that baked into the language or a standard library, or that defined by other developers.
(BTW, I'm not sure what 1:1 means.)
Usually, if they're the same value, the most specific type (I assume that's what you're talking about here) doesn't matter (they are, after all, ostensibly all the same type) until you need to specifically distinguish one from the other -- typically at the point of dispatching some operator that needs to behave differently when passed (say) odd integers vs the same operator name that handles the non-odd integers. Then the distinction appears exactly where you need it, but only where you need it. Otherwise, there is no distinction, which is exactly what you want.
By the way, I believe Date & Darwen would suggest a type hierarchy that ensures each value can appear in one and only one type. That's difficult to automatically verify (at least in a computationally feasible manner for many common types) but it's a reasonable policy, and one that can at least have sensible (if not necessarily desirable, at least tolerable and/or predictable) behaviour if violated.
but that these are not the same value
1:integer,1:string,1:bit,1:boolean?
(yes, I know an answer would be: use the
=(or==) operator, if it returnsfalseor an error, then the values are not the same. But I'm not sure I like that answer)
Same. The developer knows the type system. If it's a statically-typed language, many won't even allow your program to compile if you attempt to use the comparison operator on an integer and a string, or a string and a boolean, etc. If it's a dynamically-typed language, some throw a run-time error if you attempt to use the comparison operator on an integer and a string, or a string and a boolean, etc. Others don't. There are, as usual, tradeoffs associated with these (and other) choices of strategies.
Note again that types are fundamental to correct operator dispatch, whether automatic or done by the developer. If the language doesn't know the type of a value, it can't pick the right operator from a set of overloaded operators or verify that you aren't trying to divide today's date by someone's name. If it's not a language that provides operator overloading (or type checking), then you need to know the type of every value so that you can pick the right operator from a set of non-overloaded, distinctly-named operators.
The latter is hard to get right, as any FORTH or assembly language programmer will tell you.
Note again that types are fundamental to correct operator dispatch, whether automatic or done by the developer. If the language doesn't know the type of a value, it can't pick the right operator from a set of overloaded operators or verify that you aren't trying to divide today's date by someone's name. If it's not a language that provides operator overloading (or type checking), then you need to know the type of every value so that you can pick the right operator from a set of non-overloaded, distinctly-named operators.
The latter is hard to get right, as any FORTH or assembly language programmer will tell you.
Yes. This is in line with the idea of a value having meaning: What use is it? What can I do with it? What role can it play?
The concept of type is so fundamental and so pervasive we probably don't always notice it. But it's there.
Quote from dandl on November 19, 2021, 11:18 pmNone of this makes a literal such as "3²⁄₃" intrinsically meaningful. We may recognise it on sight but only by convention, as some kind of fraction, but is it a number or even a value? Perhaps like 8½ it's just the name of a film. Context aka type is required to convey meaning.
So I might say that 8¹⁄₂ (ignoring for this purpose that Unicode has a specific `½` code point) is both a number and a name of a film.
E.g typeOf(8¹⁄₂) might return: rational, real, name of film
If we had a function filmRunningTime() which takes the name of a film and (if it is the name of a film) returns the running length. Then filmRunningTime(8542) would return empty while filmRunningTime(8¹⁄₂) would return 138 mins(and maybe other values if someone remakes the film and gives their file the same name)
Going somewhat off topic, I know that another way of looking at this is to say that the name of the film is not 8¹⁄₂ (which is a number), but "8¹⁄₂" which is a string, and not a number.
Which leads me rather to I wonder if the concept of a string is always a good idea. I would claim that the concept of a "string" is not really something the general public uses. They would not really understand the difference between say the values 1 and "1" (unless they think the double quotes signify that someone said 1 or maybe were doing "air-quotes").
Wikipedia says that the film was called what it is because it was "a self-referential title referring principally (but not exclusively)[14] to the number of films he had directed up to that time.". So, the name of the film is a number, and to not allow it to be a number (e.g. to force it to be a string) seems maybe incorrect.
Names are usually words or word phrases, but not always.
A counter example I guess, is the film Seven (the stylised version with the backwards 7 is not a unicode character I believe). Seven (or should that be "Seven") is not a number, it is the name of (or word representation of) a number, right?
Quote from Paul Vernon on November 20, 2021, 6:52 pmQuote from dandl on November 19, 2021, 11:18 pmNone of this makes a literal such as "3²⁄₃" intrinsically meaningful. We may recognise it on sight but only by convention, as some kind of fraction, but is it a number or even a value? Perhaps like 8½ it's just the name of a film. Context aka type is required to convey meaning.
So I might say that
8¹⁄₂(ignoring for this purpose that Unicode has a specific `½` code point) is both a number and a name of a film.E.g
typeOf(8¹⁄₂)might return:rational,real,name of filmIf we had a function
filmRunningTime()which takes the name of a film and (if it is the name of a film) returns the running length. ThenfilmRunningTime(8542)would return empty whilefilmRunningTime(8¹⁄₂)would return138 mins(and maybe other values if someone remakes the film and gives their file the same name)
Going somewhat off topic, I know that another way of looking at this is to say that the name of the film is not
8¹⁄₂(which is a number), but"8¹⁄₂"which is a string, and not a number.Which leads me rather to I wonder if the concept of a string is always a good idea. I would claim that the concept of a "string" is not really something the general public uses. They would not really understand the difference between say the values
1and"1"(unless they think the double quotes signify that someone said1or maybe were doing "air-quotes").
The non-technical general public rarely thinks explicitly in terms of types, but often think implicitly in terms of types. E.g., this is a number, we can add, subtract, multiply, divide, take square root, etc. Or, this is a date, we can add so many days to it or determine the same day next year, or identify the Saturday after it, but we wouldn't divide it by a number. Or, this is a name, we cannot perform math on it, but we can capitalise it, count the number of spaces (if any) in it, determine its length, whether it's capitalised or not, and so on.
The name is, of course, a typical application of type string -- though non-technical folks tend not to describe it in such general or abstract terms as string.
They think in terms of specific types like number, date, address, name, size, temperature, and so forth. Which, from a "types are good" point of view, is a good way to think of types. String is usually too general, but so is number, except as "base" types from which concrete (and specific) types are derived.
The distinction between 1 and "1" is an interesting issue, to the point that some computer languages treat them as the same.
The semi-technical general public who are at least passably proficient with MS Excel often have a surprisingly good appreciation for types, which gives them a head start if they try programming either in Excel (VBA) or outside it (Python, Java, C#, whatever.)
Quote from Paul Vernon on November 20, 2021, 6:52 pmQuote from dandl on November 19, 2021, 11:18 pmNone of this makes a literal such as "3²⁄₃" intrinsically meaningful. We may recognise it on sight but only by convention, as some kind of fraction, but is it a number or even a value? Perhaps like 8½ it's just the name of a film. Context aka type is required to convey meaning.
So I might say that
8¹⁄₂(ignoring for this purpose that Unicode has a specific `½` code point) is both a number and a name of a film.
E.g
typeOf(8¹⁄₂)might return:rational,real,name of filmIf we had a function
filmRunningTime()which takes the name of a film and (if it is the name of a film) returns the running length. ThenfilmRunningTime(8542)would return empty whilefilmRunningTime(8¹⁄₂)would return138 mins(and maybe other values if someone remakes the film and gives their file the same name)
[There is a whole profession devoted to text normalisation: so downstream semantic processing doesn't have to worry about minor symbolic differences like that. Your brain does it automatically.]
Closer, much closer, but one more point: be very careful about thinking that a symbol (word/reference/string) carries with it a fixed list of types. Subject to syntactic limitations, any symbol can belong to any type, but you have to know which. It's the knowing which that gives it meaning.