SQL
in [OOP]
|
From: topmind on 12 Feb 2006 16:19 Dmitry A. Kazakov wrote: > On 11 Feb 2006 12:54:38 -0800, topmind wrote: > > > Dmitry A. Kazakov wrote: > >> On 10 Feb 2006 23:10:35 -0800, topmind wrote: > >> > > Well, I think it is a definition game being played here. Anyhow, being > > useful for A does not necessarily extrapolate to B. I agree that > > systems software may be a place where "types" are fairly useful. > > No, they are useful for software in general. To a point. One can use them barely or heavily. >Even SQL cannot avoid them. SQL is more or less based on "COBOL thinking". It is not the best possible nor most type-free that a relational query language can be. Bashing SQL as a language is like pointing out flaws in Java and painting all of OOP by those flaws. > > >>>> This is wrong, I gave an implementation with a pre-defined integer type > >>>> which also does not define any new type. This didn't satisfy you and you > >>>> switched to: > >>>> > >>>> "You are using the out-of-the-box 8-byte version here, not configurable > >>>> ones." > >>>> > >>>> I showed that modern languages have no problem with defining new integer > >>>> types. [SQL is unable to do this.] > >>> > >>> I don't think I would call that feature a "type". A "constraint" > >>> perhaps. > >> > >> If you add X with one constraint to Y with other constraint and what would > >> be the constraint of the result? > > > > I am not sure what you are asking. Please attempt to reword it. > > That was your idea to separate types and constraints, or? So was my > question. > > [ Constraints are applied to types. Constrained types are subtypes. In > general it is called specialization. ] You are *calling* constraint parameters "subtypes". One can also view them as simply constraints without any connection to types. In other words, you are looking at the world through type-colored glasses. I don't dispute that such "can be viewed as types". Perhaps every language *can* be viewed as types. However, as stated many messages ago, that does not mean that everything *is* types or should use the concept more. In short, you are getting carried away with a viewpoint. It would be just like some FP or Smalltalk fanatic saying, "I can view everthing as closures. Therefore we should use the concept more and view everything as closures." I hope you see the flaw in that reasoning. > > >>>> So, what is your point? That cell types can be any? This is wrong, they > >>>> have to be at least copyable and comparable. That relational is defined on > >>>> this class of types? This was my starting point. > >>> > >>> Sorry, but I don't see the practical significence of that from an > >>> application perspective. > >> > >> So we can agree that from theoretical point of view relational is not a > >> paradigm, but a case. > > > > No. > > Please don't elude, practical issues were addressed in the following > paragraph. > > >> A for practice, this has a direct implication. With > >> proper ADTs I can have a relational container library and forget about that > >> nasty SQL and clumsy, slow, buggy RDBMSs. > > > > So something tested by an internal QA team and hundreds of thousands of > > users is going to be more buggy than something you roll your own in a > > few months? > > Carefully re-read the paragraph above. It says nothing about who will > develop that library. The word "library" implies reuse, right? > > RDBMS exist only because in 70s there were no languages capable to provide > a relational library. A desire to have it integrated into *normal* > languages would become obvious, if we consider embedded SQL. Since then > nobody of sound mind could even imagine SQL in place of a universal-purpose > language. There is a lot of code written in PL/SQL and Transact-SQL, which is SQL with procedural additions. I don't necessarily agree with this approach, but I am pointing out that route exists in decent quantities now. The biggest problem I see with it is that different app languages are better for different kinds of apps. One of the benefits of databases is that they allow multiple languages and tools to use the same "attribute model" (database). It facilitates sharing across tools. I have also used languages which allowed things resembling: PERFORM myFunction(x, y) WHERE y < 3 It was pretty nifty. Those kinds of things are fairly common in "collection oriented languages". > >> No, you keep on trying to say that numeric types aren't necessary. This > >> could only be true, if there were a universal numeric type (which you call > >> "no type".) It is a clear contradiction with: > >> > >>> Same with the type-free approach. If you want a big number, no problem: > >>> > >>> x = 2342423423412342343423423.23342039480934509243 > >>> > >>> Same as > >>> > >>> x = "2342423423412342343423423.23342039480934509243" > >>> > >>> Now, whether a given function(s) can handle such a number is another > >>> matter. A string-based decimal library can. > >> > >> See above. You still don't understand that number is not a chain of digits > >> or a set of bits. Number is a type having various properties. I don't need > >> numbers if it is unknown how to handle them. > > > > Not "unknown" but rather "situational". > > Situation determines the semantics of "+" is exactly same as: situation > determines the type. This changes nothing. I am only saying that your "unknown" statement is false. And I am not talking about operator overloading. What a given function/procedure/operation does with a given variable is purely up to it. It carries no hidden flags or markers that limit or suggest how to handle it or what operations can be used on it. This is the difference between "type free" and "dynamic typing". > > > You are thinking in "is-a" > > mode. These kinds of numbers don't carry around a "type flag" that says > > only a given set of operations can be used on it. > > So, the flag carries "situation", and, what is changed? I don't understand your question. I carries nothing that cannot be seen. These are the same as far as such a language would be concerned: x = "123"; foo(x); AND: x = 123; foo(x); "Foo" would have no way to tell the difference in a type-free lang. There is no hidden or side marker that indicates how it was declared. > > >> Please: compute "1"/"3" in > >> your library! > > > > Ideally the library would have a decimal limitation parameter and I > > believe dedicated decimal packages do. It may resemble: > > > > x = divide(a, b, 20) > > Excellent, why not > > x = divide(a, b, 21) > > Note that the value 20 vs. 21, 22, 23... and the very semantics of "divide" > [truncation to n decimal digits] constitute a numeric type. This model is > called fixed-point arithmetic. And there are zillions of applications where > fixed-point is unacceptable. Unacceptable reads: with *any* realistic value > of n. I did not mean to suggest that this was meant for all kinds of domains. A scientific library would probably look different than a financial one, with different truncation/rounding parameters, etc. I should also point out that "string-based" numbers is probably not appropriate for scientific apps either. But again the "expression system" is orthogonal to relational. > > >> Again: for any library you have, I can find a counter example where it will > >> not work. It is a hard mathematical *fact*. > > > > I am not sure what your point is. > > We better close this topic. Recommended reading: > > http://en.wikipedia.org/wiki/Category:Computer_arithmetic > http://en.wikipedia.org/wiki/Rational_numbers > http://en.wikipedia.org/wiki/Fixed-point > http://en.wikipedia.org/wiki/Bignum > http://en.wikipedia.org/wiki/Floating_point > http://en.wikipedia.org/wiki/Interval_arithmetic > http://www.cs.utep.edu/interval-comp/main.html Again, I did not propose that decimal math is appropriate for all domains. > > >>>> This changes nothing. The result is *sorted*. To sort using some *external* > >>>> key you have to visit *all* rows. This is at least O(n). It seems that you > >>>> don't well understand the background. Read, for example: > >>>> > >>>> http://en.wikipedia.org/wiki/Space_partitioning > >>> > >>> I see nothing that keeps an RDBMs engine from using such techniques to > >>> speed up spacial queries. > >> > >> O(n) > > > > This is only for your "external key" assumption. A custom engine does > > not have to use that. A relational interface does not dictate > > implementation. > > I don't care about interface, give me a relational *implementation*! [ As > for interfaces, I already proposed to reissue all maps in the form of > tables. You weren't much impressed. ] I would have to study a good set of use-cases from the domain to see what kind of operations need the most optimization. Not sure I want to bother with that right now anyhow. Remember that the ability to have custom operations does not necessarily violate relational. Thus, one can make: SELECT * FROM mytable WHERE foo(x, y, z) < bar(m,n) As long as the expression "foo(x, y, z) < bar(m,n)" returns something that can be interpreted as Boolean, relational is generally happy with it. Dr. Codd did not hard-wire the math domain into relational anywhere that I saw. (And if he did, we can remove it without hurting the spirit of relational.) > > > If dead Girbals can be used to make it run certain > > kinds of operations faster, then go for it. > > > > A relational-intended "expression engine" could have a > > DistanceBetween(locatID1, locatID2) operation that uses whatever the > > best implementation is for such. > > LOL! Dear topmind, it is O(n) with *any* implementation of DistanceBetween! I guess I am not understanding what you are proposing as an alternative. How about a use-case which exposes this alleged flaw. DistinctBetween does not iterate, so I don't see where you are getting O(n) for that particular operation. Perhaps you want something that can return the closest n roads/cities/points without having to visit them all. We could perhaps have a function called getClosestNodes(targetLocat, distance). It would return the ID's of nodes matching using your favorite fast implemenation. We could use it something like this: SELECT cityName FROM cities WHERE cityID IN getClosestCities(&targetCityID&, 200) "targetCityID" is the inserted variable (from app). For that particular case we had to go outside of relational to get needed speed, but we don't have to abandon relational *entirely* in order to do it. (Whether it can be done inside relational, I don't know. I haven't found a way, but this is not my domain so I am rusty there.) Thus, it is not an all-or-nothing issue even if by chance relational cannot do the entire thing. Reinventing 1/3 of the wheel is usually better than reinventing all of it. > > >> you cannot decompose custom problems into relational. > > > > Yes you can. It is a similar issue as the Turing Tarpit. Some things do > > it well, some do it poorly. > > Right. For the problems I have presented, relational doesn't work. This is > all I wished to say. You have not shown this. At best you have shown cases where it is slow (still under dispute). Being slow and "not working" are different issues. And even the slow areas can probably be remedied without full abandonment of relational. > > -- > Regards, > Dmitry A. Kazakov -T-
From: Dmitry A. Kazakov on 13 Feb 2006 09:46 On 12 Feb 2006 13:19:28 -0800, topmind wrote: > Dmitry A. Kazakov wrote: >>Even SQL cannot avoid them. > > SQL is more or less based on "COBOL thinking". It is not the best > possible nor most type-free that a relational query language can be. > Bashing SQL as a language is like pointing out flaws in Java and > painting all of OOP by those flaws. Which flaws you are talking about? SQL has types, is it a flaw? So far you have shown no traces of any concept, which could make relational independent on types. It is a mistake of your own. I saw no indications that it is anyhow shared by DB community. Look at what respected people like C.J. Date do. Do they propose to get rid of types in DBs? Nope, they do exactly the *opposite*. They might disagree with some of OO dogmas, I disagree with many of them too. But, again, nobody of sound mind would attack extensible types systems. People are only disagree on how a types system should look like. >>>>>> This is wrong, I gave an implementation with a pre-defined integer type >>>>>> which also does not define any new type. This didn't satisfy you and you >>>>>> switched to: >>>>>> >>>>>> "You are using the out-of-the-box 8-byte version here, not configurable >>>>>> ones." >>>>>> >>>>>> I showed that modern languages have no problem with defining new integer >>>>>> types. [SQL is unable to do this.] >>>>> >>>>> I don't think I would call that feature a "type". A "constraint" >>>>> perhaps. >>>> >>>> If you add X with one constraint to Y with other constraint and what would >>>> be the constraint of the result? >>> >>> I am not sure what you are asking. Please attempt to reword it. >> >> That was your idea to separate types and constraints, or? So was my >> question. >> >> [ Constraints are applied to types. Constrained types are subtypes. In >> general it is called specialization. ] > > You are *calling* constraint parameters "subtypes". One can also view > them as simply constraints without any connection to types. Then answer my question. The result should have a constraint, which constraint it will have in your "disconnected" view. It is a simple question. Should your customer know when your program will crash or not? > The biggest problem I see with it is that different app languages are > better for different kinds of apps. Limited applicability of relational approach by no means imply that no more general approach can exist. >>>> No, you keep on trying to say that numeric types aren't necessary. This >>>> could only be true, if there were a universal numeric type (which you call >>>> "no type".) It is a clear contradiction with: >>>> >>>>> Same with the type-free approach. If you want a big number, no problem: >>>>> >>>>> x = 2342423423412342343423423.23342039480934509243 >>>>> >>>>> Same as >>>>> >>>>> x = "2342423423412342343423423.23342039480934509243" >>>>> >>>>> Now, whether a given function(s) can handle such a number is another >>>>> matter. A string-based decimal library can. >>>> >>>> See above. You still don't understand that number is not a chain of digits >>>> or a set of bits. Number is a type having various properties. I don't need >>>> numbers if it is unknown how to handle them. >>> >>> Not "unknown" but rather "situational". >> >> Situation determines the semantics of "+" is exactly same as: situation >> determines the type. This changes nothing. > > I am only saying that your "unknown" statement is false. Either you know the "situation" or not. When you know it, so you know the type. Then you cast the value to that type and continue. This is what you propose: explicit casting all over the program! >> So, the flag carries "situation", and, what is changed? > > I don't understand your question. I carries nothing that cannot be > seen. > > These are the same as far as such a language would be concerned: > > x = "123"; > foo(x); > > AND: > > x = 123; > foo(x); > > "Foo" would have no way to tell the difference in a type-free lang. I.e. it will crash, because the internal representation of both is different, and as you said Foo() cannot determine which one it deals with. Dynamically typed /= untyped. >>>> Please: compute "1"/"3" in >>>> your library! >>> >>> Ideally the library would have a decimal limitation parameter and I >>> believe dedicated decimal packages do. It may resemble: >>> >>> x = divide(a, b, 20) >> >> Excellent, why not >> >> x = divide(a, b, 21) >> >> Note that the value 20 vs. 21, 22, 23... and the very semantics of "divide" >> [truncation to n decimal digits] constitute a numeric type. This model is >> called fixed-point arithmetic. And there are zillions of applications where >> fixed-point is unacceptable. Unacceptable reads: with *any* realistic value >> of n. > > I did not mean to suggest that this was meant for all kinds of domains. > A scientific library would probably look different than a financial > one, with different truncation/rounding parameters, etc. So? Can you name the parameters to satisfy *any* financial application? > Again, I did not propose that decimal math is appropriate for all > domains. But you do claim that it (decimal fixed-point arithmetic) is suitable for all financial domains and for all domains where a DB comes in consideration? > Remember that the ability to have custom operations does not > necessarily violate relational. Didn't I say that? I said that relational could be consequently applied only with ADTs available for the cells. > Thus, one can make: > > SELECT * FROM mytable WHERE foo(x, y, z) < bar(m,n) > > As long as the expression "foo(x, y, z) < bar(m,n)" returns something > that can be interpreted as Boolean, relational is generally happy with > it. The problem is not in how "<" is computed. It is in how SELECT and WHERE interact. And there is no way in relational to influence this. As I said, it is O(n). To get it better than O(n) one need change the engine to kd-trees for example. Then it will no more decoupled from the data, because kd-tree won't let you change WHERE clause. kd-trees aren't decomposable this way. A relational interface fits to a kd-tree as a beach umbrella does to penguin. That's the whole point. In relational there is no way to spell "engine." This level of abstraction is beyond relational decomposition. You can interface a kd-tree engine relationally, but you cannot implement it this way. >> Right. For the problems I have presented, relational doesn't work. This is >> all I wished to say. > > You have not shown this. At best you have shown cases where it is slow > (still under dispute). Being slow and "not working" are different > issues. And even the slow areas can probably be remedied without full > abandonment of relational. "Not working" is defined as economically infeasible. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: topmind on 13 Feb 2006 21:17 Dmitry A. Kazakov wrote: > On 12 Feb 2006 13:19:28 -0800, topmind wrote: > > > Dmitry A. Kazakov wrote: > > >>Even SQL cannot avoid them. > > > > SQL is more or less based on "COBOL thinking". It is not the best > > possible nor most type-free that a relational query language can be. > > Bashing SQL as a language is like pointing out flaws in Java and > > painting all of OOP by those flaws. > > Which flaws you are talking about? SQL has types, is it a flaw? Perhaps I used "flaw" too losely. My point is that what SQL needs is not necessarily what relational needs. > > So far you have shown no traces of any concept, which could make relational > independent on types. And you've showed nothing that makes it dependent on them (barring a minimal set of operations). > It is a mistake of your own. I saw no indications > that it is anyhow shared by DB community. Look at what respected people > like C.J. Date do. Do they propose to get rid of types in DBs? Nope, they > do exactly the *opposite*. Like I've said multiple times, the type system is or can be orthogonal to relational. > They might disagree with some of OO dogmas, I > disagree with many of them too. But, again, nobody of sound mind would > attack extensible types systems. People are only disagree on how a types > system should look like. Are you talking about relational proponents, or general programming language proponents? I will agree that "dynamic relational" has not been something that seems to have many backers, but it has does not have any declared detractors that I know (other than you perhaps). We have programming languages with various type systems to various levels, so I see no reason not to extrapolate the idea to relational. As far as I can tell, relational only requires an "expression system" that can return Boolean-interpretable results on operations on columns. (This does not mean that all operations have to return Boolean-able results, only that they exist.) What makes up the expression engine is not dictated by the philosophy of relational. Also note that it does not have to return an explicit Boolean "type", only a convention that the relational engine can recognize as being "true" or "false". Thus, for context typing we may define "false" as being any one of "0","false","no", and blank (where spaces and capitalization are ignored) and everything else as "true". > >> [ Constraints are applied to types. Constrained types are subtypes. In > >> general it is called specialization. ] > > > > You are *calling* constraint parameters "subtypes". One can also view > > them as simply constraints without any connection to types. > > Then answer my question. The result should have a constraint, which > constraint it will have in your "disconnected" view. It is a simple > question. Should your customer know when your program will crash or not? I think two different subjects got confused here. One is how to classify your range clause feature, and the other is whether type-free (context typing) systems are useful. What to call something and whether it is useful are different issues. > > > The biggest problem I see with it is that different app languages are > > better for different kinds of apps. > > Limited applicability of relational approach by no means imply that no more > general approach can exist. "General" does not necessarily equate to "better". Relational is a philosophy of organization; and to fit it you must follow certain rules and guidelines. Obviously the same stuff can be done *outside* such guidelines. However, the result is often shanty-town roll-your-own every-man-a-Picasso software or structures. It is a tradeoff of standards versus non-standards. I don't claim that *everything* should be forced into the relational standard, only that those that fit it do better under it because we don't have to conceptually and perhaps physically reinvent the wheel, at least not the entire wheel. > > >>>> No, you keep on trying to say that numeric types aren't necessary. This > >>>> could only be true, if there were a universal numeric type (which you call > >>>> "no type".) It is a clear contradiction with: > >>>> > >>>>> Same with the type-free approach. If you want a big number, no problem: > >>>>> > >>>>> x = 2342423423412342343423423.23342039480934509243 > >>>>> > >>>>> Same as > >>>>> > >>>>> x = "2342423423412342343423423.23342039480934509243" > >>>>> > >>>>> Now, whether a given function(s) can handle such a number is another > >>>>> matter. A string-based decimal library can. > >>>> > >>>> See above. You still don't understand that number is not a chain of digits > >>>> or a set of bits. Number is a type having various properties. I don't need > >>>> numbers if it is unknown how to handle them. > >>> > >>> Not "unknown" but rather "situational". > >> > >> Situation determines the semantics of "+" is exactly same as: situation > >> determines the type. This changes nothing. > > > > I am only saying that your "unknown" statement is false. > > Either you know the "situation" or not. When you know it, so you know the > type. Then you cast the value to that type and continue. This is what you > propose: explicit casting all over the program! There is no "casting" in "context typing". Casting requires a hidden or side "flag(s)" that tells what type a variable is. Context-typing vars have no such flag. Every variable is generally tracked as a string (or array of strings, depending on how arrays are implemented) with no other indicator/flag/marker of any kind. Just a naked string. > > >> So, the flag carries "situation", and, what is changed? > > > > I don't understand your question. I carries nothing that cannot be > > seen. > > > > These are the same as far as such a language would be concerned: > > > > x = "123"; > > foo(x); > > > > AND: > > > > x = 123; > > foo(x); > > > > "Foo" would have no way to tell the difference in a type-free lang. > > I.e. it will crash, because the internal representation of both is > different, and as you said Foo() cannot determine which one it deals with. > Dynamically typed /= untyped. No, internally both assignment statements result in *exactly* the same thing. The interpreter does *not* track whether it was assigned with quotes or not in context typing. Dynamic typing perhaps does, but not context typing. In context typing the "types" are purely in the mind of the programmer and/or library writers. They don't exist in the language, and thus are a fuzzy, situational, conceptual concept if they are "there" at all. The interpreter tracks zilch type info. The interpreter itself has no concept of "types". There is no objective way to look at the context-typed language definition nor interpreter and identify anything about "types" in it. > >> Note that the value 20 vs. 21, 22, 23... and the very semantics of "divide" > >> [truncation to n decimal digits] constitute a numeric type. This model is > >> called fixed-point arithmetic. And there are zillions of applications where > >> fixed-point is unacceptable. Unacceptable reads: with *any* realistic value > >> of n. > > > > I did not mean to suggest that this was meant for all kinds of domains. > > A scientific library would probably look different than a financial > > one, with different truncation/rounding parameters, etc. > > So? Can you name the parameters to satisfy *any* financial application? "Any" is a very tough request. I might hit 99%, but I cannot anticipate everything. > > > Again, I did not propose that decimal math is appropriate for all > > domains. > > But you do claim that it (decimal fixed-point arithmetic) is suitable for > all financial domains and for all domains where a DB comes in > consideration? First, I don't know if "fixed point" is an appropriate description. It tends to mirror how people do arithmetic on paper. Second, see above with regard to "all". > > > Remember that the ability to have custom operations does not > > necessarily violate relational. > > Didn't I say that? I said that relational could be consequently applied > only with ADTs available for the cells. Please clarify. > > > Thus, one can make: > > > > SELECT * FROM mytable WHERE foo(x, y, z) < bar(m,n) > > > > As long as the expression "foo(x, y, z) < bar(m,n)" returns something > > that can be interpreted as Boolean, relational is generally happy with > > it. > > The problem is not in how "<" is computed. It is in how SELECT and WHERE > interact. And there is no way in relational to influence this. As I said, > it is O(n). To get it better than O(n) one need change the engine to > kd-trees for example. Then it will no more decoupled from the data, because > kd-tree won't let you change WHERE clause. kd-trees aren't decomposable > this way. A relational interface fits to a kd-tree as a beach umbrella does > to penguin. That's the whole point. In relational there is no way to spell > "engine." This level of abstraction is beyond relational decomposition. You > can interface a kd-tree engine relationally, but you cannot implement it > this way. I would like to investigate example use-cases. Was the snipped-out "distance" an example of what you talk about? That was the one where I suggested: ...WHERE cityID IN getClosestCities(&targetCityID&, 200) I suspect that a domain-specific operation can be devised for the situations you talk about to take such calculations into the "expression domain" instead of direct relational queries. Relational does *not* have to be all or nothing. Another approach that I did not mention is to let the query optimizer recognize special cases and automatically optimize the query to use the special domain-specific engine. However, this requires fancier parsing on the part of the optimizer. For the distance example, the optimizer can say, "Hey, we are doing distance-based calculations here. Let's use the special engine instead of our default looper." Again, relational "math" specifies what you want, not how to get it. Thus, if the parser can find an execution shortcut but still satisfy the requirements, then it does not violate the meaning of the relational equation. By following a known set of relational rules, such "optimization math" is easier to do or build. > > >> Right. For the problems I have presented, relational doesn't work. This is > >> all I wished to say. > > > > You have not shown this. At best you have shown cases where it is slow > > (still under dispute). Being slow and "not working" are different > > issues. And even the slow areas can probably be remedied without full > > abandonment of relational. > > "Not working" is defined as economically infeasible. Next time please say, "not feasible" instead of "not working". The second implies that an answer will never come or that the machine will crash. Either way, your alleged big-Oh claim is still being scrutinized. > > -- > Regards, > Dmitry A. Kazakov -T-
From: Dmitry A. Kazakov on 14 Feb 2006 05:40 On 13 Feb 2006 18:17:05 -0800, topmind wrote: > Dmitry A. Kazakov wrote: >> So far you have shown no traces of any concept, which could make relational >> independent on types. > > And you've showed nothing that makes it dependent on them (barring a > minimal set of operations). > >> It is a mistake of your own. I saw no indications >> that it is anyhow shared by DB community. Look at what respected people >> like C.J. Date do. Do they propose to get rid of types in DBs? Nope, they >> do exactly the *opposite*. > > Like I've said multiple times, the type system is or can be orthogonal > to relational. Please, re-read what you have answered, and choose one thing. >>>> [ Constraints are applied to types. Constrained types are subtypes. In >>>> general it is called specialization. ] >>> >>> You are *calling* constraint parameters "subtypes". One can also view >>> them as simply constraints without any connection to types. >> >> Then answer my question. The result should have a constraint, which >> constraint it will have in your "disconnected" view. It is a simple >> question. Should your customer know when your program will crash or not? > > I think two different subjects got confused here. I.e. you cannot. >>>> Situation determines the semantics of "+" is exactly same as: situation >>>> determines the type. This changes nothing. >>> >>> I am only saying that your "unknown" statement is false. >> >> Either you know the "situation" or not. When you know it, so you know the >> type. Then you cast the value to that type and continue. This is what you >> propose: explicit casting all over the program! > > There is no "casting" in "context typing". Casting requires a hidden or > side "flag(s)" that tells what type a variable is. Context-typing vars > have no such flag. Every variable is generally tracked as a string (or > array of strings, depending on how arrays are implemented) with no > other indicator/flag/marker of any kind. Just a naked string. When "+'" takes two strings it have to parse them to figure out what numbers they represent. The result of this parsing *is* the type flag. Note also that in this case it is not the context which determines the types, but solely the actual values. I.e. it is dynamic typing, with "String" substituted for "Object." The exclusive properties of your "system": 1. Utterly inefficient implementation 2. Exceptionally space consuming 3. Very unsafe because nobody actually knows what x + y could mean. 4. It can be used as a video game: the players write arbitrary strings and trying to predict the outcome of +, -, /, * etc And of course, there is no such thing as "context typing." > "Any" is a very tough request. I might hit 99%, but I cannot anticipate > everything. ADT can it. >>> Again, I did not propose that decimal math is appropriate for all >>> domains. >> >> But you do claim that it (decimal fixed-point arithmetic) is suitable for >> all financial domains and for all domains where a DB comes in >> consideration? > > First, I don't know if "fixed point" is an appropriate description. It is. Read the links I posted before. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Dmitry A. Kazakov on 15 Feb 2006 05:11
On 14 Feb 2006 17:05:50 -0800, topmind wrote: > May I suggest you re-word and/or number your question(s). I don't know > which one you are referencing. I thought I answered everything. If I > missed something, it was not intentional I assure you. Statement 1. Relational depends on a [minimal] set of operations, Statement 2. The type system is orthogonal to relational. You have to choose. (1) implies a definite class of types admissible in cells. (2) implies that cells can hold anything. >>> There is no "casting" in "context typing". Casting requires a hidden or >>> side "flag(s)" that tells what type a variable is. Context-typing vars >>> have no such flag. Every variable is generally tracked as a string (or >>> array of strings, depending on how arrays are implemented) with no >>> other indicator/flag/marker of any kind. Just a naked string. >> >> When "+'" takes two strings it have to parse them to figure out what >> numbers they represent. The result of this parsing *is* the type flag. > > Please clarify. The result is a flag? In what sense? The result should > either be a string of digits or an error. = the value is either of numeric type (="string of digits") or not (="an error") I hope, you understand that the way this *type* information is encoded in the value is irrelevant to the discussion. The type information is in the value. Full stop. >> Note >> also that in this case it is not the context which determines the types, >> but solely the actual values. I.e. it is dynamic typing, with "String" >> substituted for "Object." The exclusive properties of your "system": > > You can call a type system with only one type a "type system" if you > really want to, but I don't see what that gets you. OK, I repeat: 1. Whether the thing is a number is determined solely by the value [contents of the string]. 2. It is not determined by the context of the call. From this follows that types in the presented case aren't determined by the context, so it is not "context-typed." It is dynamically typed per definition: "some types are determinable no earlier than at run-time." > It goes by > different names and if you don't like my working name, you are welcome > to call it something else. No, it isn't about names. You are trying to present something well-known (with all its disadvantages and advantages, which also are well known), as a new paradigm. You aren't Bill Gates, to get away with this! (:-)) There is only A and B. Your C is one of them. So cannot claim that C is "orthogonal", "better" etc. >>> "Any" is a very tough request. I might hit 99%, but I cannot anticipate >>> everything. >> >> ADT can [do] it. > > So can assembler. But you don't! We could discuss merits of assembler vs. OOPL, but you are out independently on any possible outcome of that debate. >>>>> Again, I did not propose that decimal math is appropriate for all >>>>> domains. >>>> >>>> But you do claim that it (decimal fixed-point arithmetic) is suitable for >>>> all financial domains and for all domains where a DB comes in >>>> consideration? >>> >>> First, I don't know if "fixed point" is an appropriate description. >> >> It is. Read the links I posted before. > > Sorry, but I don't know what criteria you are using to assertain > fixed-ness. > > If you do 12.34 * 56.78, you get 700.6652 > > The number of decimal places went from 2 to 4. Nothing "fixed" there > that I see. Read that stuff, please! If you want to switch the debate to arbitrary-precision arithmetic I'll beat you there. So far, you claimed that there is some magical number 20, which limits the number of decimal places. That was fixed-point. If the number of places is unlimited, then, please, do 1/3, sqrt(2), pi**2. I have said it before - for *any* numeric model there are real-life counter examples. This is the only reason why they all exist. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de |