SQL
in [OOP]
|
From: topmind on 15 Feb 2006 20:28 Dmitry A. Kazakov wrote: > 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. >From an ADT/type perspective, let me word it this way: Relational requires that the "expression engine" used by the cells AT LEAST have operation(s) that can be interpretable as Boolean. (Which is not hard to do since anything that returns more than 1 value can be interpretable as Boolean if we define some ranges to map. Whether it is always practical or not is another matter.) Whatever other operations there are besides those that return/interpreterable-as Boolean are a bonus and generally *outside of relational*, not a requirement of relational. Thus, if you want to use imaginary numbers with relational, it is theoretically do-able. > > >>> 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. If you are calling error conditions a "type", then I would like to see a formal definition of "type" (that is not so vague that it is everything and anything and unfalsifiable). You are spreading the concept too thin to be useful it seems. But to avoid the error-is-a-type issue for now, assume that our math operation returns the string "error" instead of stops program execution. Example usage: x = divide(a, b, maxDecimals); if (x=="error") { print("Houston we have a problem"); } else { print("Result: " & x); } > > >> 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]. No! This is false. It is determined by the "user", i.e. the particular operation/library/function. One function may treat it as a string, another as a number. Library A may "declare" it type "Zorko", library B may "declare" it type "Flink", and library C declare it type "Fonk" on Wednesdays, and type "Errrp" on Fridays. (Dr. Suess would love context typing.) The language and interpreter/compiler has no inharent concept of "type". In context typing, "typing is in the mind and only in the mind (or a custom library with its own rules)". Being in the mind, it is not externally testable. > > 2. It is not determined by the context of the call. Wrong. It is. > > 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." No. Dynamic typing carries a hidden flag. Here is dynamic typing in action: x = 1; print(typeName(x)); // result: "number" x = "1"; print(typeName(x)); // result: "string" In context typing on the other hand, you canNOT do this. There is no way for a "typeName" function to work because there is no side/hidden flag. Some semi-context-typed languages make a distinction between scalars and arrays, but this is mixed models -- that is a mix of dynamic and context typing. They are context-typing for scalars at least. Perl, ColdFusion, and Tcl are examples I believe. PHP is an example of a dynamically-typed language (and frankly it is annoying) because it does have hidden/side flags that can be tested/printed. Some operations will act differently depending on how it is declared because they look at the type flag. > > > 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! (:-)) No I am not. It exists (to some extent) in languages that I had no influence over. (I admit maybe I am using the wrong name for the concept, but have not found a widely consistent one yet.) > > There is only A and B. Your C is one of them. So cannot claim that C is > "orthogonal", "better" etc. Well, it appears you are learning about a typing model that you did not know existed. > > >>> "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. I am only pointing out that runnable and developer-friendly may be very different issues. If you want to show how ADT's are useful for custom biz apps using code scenarios, be my guest... > > >>>>> 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. Oh, so that is what you are talking about. No, I did not claim that 20 was magical. It was only an *example* default, and I think one showing the limits of infix notation (+,-,*,etc.). I was *not* necessarily endorsing such. There appears to be a miscommunication. > 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. Context typing does not prevent other models. In fact, decimal models similar to the examples I showed are are a library with functions and/or classes. They don't have to be installed into the language natively to be used. Now, you might argue that using such models in a context typing language are slower than a strong-typed language. You might be right. I won't bother to defend speed for such. In some domains it may be important, but not all. BTW, whatever happened to the relational O(n) sub-debate? That was more interesting than math libraries IMO. Have you conceded or plead boredom or abandonment of that? > > -- > Regards, > Dmitry A. Kazakov -T-
From: Dmitry A. Kazakov on 16 Feb 2006 04:20 On 15 Feb 2006 17:28:41 -0800, topmind wrote: > Dmitry A. Kazakov wrote: >> 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. > >>From an ADT/type perspective, let me word it this way: > > Relational requires that the "expression engine" used > by the cells AT LEAST have operation(s) that can be > interpretable as Boolean. (Which is not hard to do > since anything that returns more than 1 value > can be interpretable as Boolean if we define > some ranges to map. Whether it is > always practical or not is another matter.) > > Whatever other operations there are besides those > that return/interpreterable-as Boolean are a bonus > and generally *outside of relational*, not a requirement > of relational. > > Thus, if you want to use imaginary numbers with > relational, it is theoretically do-able. So you have chosen 1 and dropped 2. >>>>> 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. > > If you are calling error conditions a "type", then I would like to see > a formal definition of "type" (that is not so vague that it is > everything and anything and unfalsifiable). Read it as: it is of a non-numeric type, in which case type check generates an error. This is a dynamically typed system. >>>> 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]. > > No! This is false. It is determined by the "user", i.e. the particular > operation/library/function. One function may treat it as a string, > another as a number. Library A may "declare" it type "Zorko", library B > may "declare" it type "Flink", and library C declare it type "Fonk" on > Wednesdays, and type "Errrp" on Fridays. (Dr. Suess would love context > typing.) The language and interpreter/compiler has no inharent concept > of "type". In context typing, "typing is in the mind and only in the > mind (or a custom library with its own rules)". Being in the mind, it > is not externally testable. This changes nothing. If checking rules vary from function to function, that only means that you have a mix of [weak in your case] static and dynamic typing. Technically it goes as follows, when you call a function from the library A, the string argument is converted to the type "Zorko"-string, because the formal parameter of A is of that type. The conversion does nothing, it lets the string as-is [this is why it is weakly typed.] Then, within the function, the value is of "Zorko"-string. That value is dynamically checked for being "Zorko"-numeric. The type flag is stored in the "Zorko"-string [this is why it is dynamically typed.] If it is "Zorko"-numeric, the function continues, otherwise, it generates an error. >> 2. It is not determined by the context of the call. > > Wrong. It is. No. Even with the modification you made, it is not a context, but, in part, it is the contract of the library A, in part, it is the [polymorphic] value. Note that all modern statically typed languages go this way when dealing with polymorphic objects. This doesn't make them context-typed. There is no such thing. [ A truly context-typing would mean that what a function does, depends not only on the type tag of the value and the signature of the function [as it happens in the example above], but also, on the context of the call. NOBODY would like to have such thing. It would be an ultimate mess. It would make functional decomposition impossible, because the developer of a function would be unable to design it INDEPENDENTLY on the call contexts, which are UNKNOWN in advance. ] >>> 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. > > Oh, so that is what you are talking about. No, I did not claim that 20 > was magical. It was only an *example* default, and I think one showing > the limits of infix notation (+,-,*,etc.). I was *not* necessarily > endorsing such. There appears to be a miscommunication. > >> 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. > > Context typing does not prevent other models. So, we can finally commit that different numeric models are required? Now to be able to use them you need a way to distinguish values of different models. That's *all* types about. It is no matter how would you do it, it is typed anyway. > BTW, whatever happened to the relational O(n) sub-debate? That was more > interesting than math libraries IMO. Have you conceded or plead boredom > or abandonment of that? Huh, there cannot be any debate! 1. Enumerating rows of an unsorted table is O(n), whatever sorting order is applied. 2. There exist no order for spaces of dimensions greater than 1. Ergo: tables are useless for spatial data. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: topmind on 16 Feb 2006 20:47 Dmitry A. Kazakov wrote: > On 15 Feb 2006 17:28:41 -0800, topmind wrote: > > > Dmitry A. Kazakov wrote: > >> 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. > > So you have chosen 1 and dropped 2. I don't see them as mutually exclusive. The requirements of relational are kind of like requiring all cars to have a hook on the back that fits given specifications. The *rest* of the car's design is not dictated. Adding the hook is a minor price to pay that generally will not affect the rest of the "math" being used. I have yet to see any "math system" that is damaged in order to fit relational's requirements. Got any? Otherwise, I shall consider your complaint not a practical limitation regardless of whether it clouds your personal definition space or not. > > >>>>> 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. > > > > If you are calling error conditions a "type", then I would like to see > > a formal definition of "type" (that is not so vague that it is > > everything and anything and unfalsifiable). > > Read it as: it is of a non-numeric type, in which case type check generates > an error. This is a dynamically typed system. That is validation. How are "types" different from "validation"? Is validation types, is it a subset of types? A super-set? Again, your definition of "types" appears to be wide and non-falsifiable. Note that different libraries may accept different inputs. For example, library A may accept scientific notation (ex: "2.7e5"), while library B may not. > >> 1. Whether the thing is a number is determined solely by the value > >> [contents of the string]. > > > > No! This is false. It is determined by the "user", i.e. the particular > > operation/library/function. One function may treat it as a string, > > another as a number. Library A may "declare" it type "Zorko", library B > > may "declare" it type "Flink", and library C declare it type "Fonk" on > > Wednesdays, and type "Errrp" on Fridays. (Dr. Suess would love context > > typing.) The language and interpreter/compiler has no inharent concept > > of "type". In context typing, "typing is in the mind and only in the > > mind (or a custom library with its own rules)". Being in the mind, it > > is not externally testable. > > This changes nothing. If checking rules vary from function to function, > that only means that you have a mix of [weak in your case] static and > dynamic typing. > > Technically it goes as follows, when you call a function from the library > A, the string argument is converted to the type "Zorko"-string, because the > formal parameter of A is of that type. The conversion does nothing, it lets > the string as-is [this is why it is weakly typed.] Then, within the > function, the value is of "Zorko"-string. That value is dynamically checked > for being "Zorko"-numeric. The type flag is stored in the "Zorko"-string > [this is why it is dynamically typed.] If it is "Zorko"-numeric, the > function continues, otherwise, it generates an error. Each function/library does not necessarily have to use a type flag or tracker of any kind. It was only an example. > > >> 2. It is not determined by the context of the call. > > > > Wrong. It is. > > No. Even with the modification you made, it is not a context, but, in part, > it is the contract of the library A, in part, it is the [polymorphic] > value. Note that all modern statically typed languages go this way when > dealing with polymorphic objects. This doesn't make them context-typed. > There is no such thing. Bull. It exists. Note that compiled languages generally track "flags" during compiling, not necessarily during running. The "flag" is assocated with a variable, not with a value. (Compiled languages can also be flag-free if anything can jam anything it wants in any variable. Assember is kind of like this. Variables are simply slot names, or more precisely, start-of-slot-addresses. This is kind of similar to the dynamic version: the variable name is simply a slot name that carries no other attributes besides the name. When slots or internal variable tracking tables have a type flag(s), then it is no longer context typing.) > > [ A truly context-typing would mean that what a function does, depends not > only on the type tag of the value and the signature of the function [as it > happens in the example above], but also, on the context of the call. NOBODY > would like to have such thing. It would be an ultimate mess. It would make > functional decomposition impossible, because the developer of a function > would be unable to design it INDEPENDENTLY on the call contexts, which are > UNKNOWN in advance. ] Perhaps "context" is not the best name for it. "Flag-free" or "untagged types" may be a better name. Again, I don't want to get caught up in a name battle. I don't care what it is called as long as it is clear what is being talked about in this debate. > >> 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. > > > > Oh, so that is what you are talking about. No, I did not claim that 20 > > was magical. It was only an *example* default, and I think one showing > > the limits of infix notation (+,-,*,etc.). I was *not* necessarily > > endorsing such. There appears to be a miscommunication. > > > >> 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. > > > > Context typing does not prevent other models. > > So, we can finally commit that different numeric models are required? Now > to be able to use them you need a way to distinguish values of different > models. No we don't. Example: x = "123456.789012"; y = "7"; x = decimalLibrary.divide(x, y, 20); print(...); x = floatingPointLibrary.divide(x, y, 4); // last param is number of bytes print(...); The same inputs can be used by both math models. > That's *all* types about. It is no matter how would you do it, it > is typed anyway. Sorry, I don't see it. > > > BTW, whatever happened to the relational O(n) sub-debate? That was more > > interesting than math libraries IMO. Have you conceded or plead boredom > > or abandonment of that? > > Huh, there cannot be any debate! > > 1. Enumerating rows of an unsorted table is O(n), whatever sorting order is > applied. > > 2. There exist no order for spaces of dimensions greater than 1. > > Ergo: tables are useless for spatial data. You have yet to present a scenario of unexcapable O(n). I showed a solution to the "distance" calculation by moving that operation to the internal (domain) notation. We don't have to throw out the baby with the bathwater. > > -- > Regards, > Dmitry A. Kazakov -T-
From: Dmitry A. Kazakov on 17 Feb 2006 04:20 On 16 Feb 2006 17:47:01 -0800, topmind wrote: > Bull. It exists. Note that compiled languages generally track "flags" > during compiling, not necessarily during running. The "flag" is > assocated with a variable, not with a value. This is called static typing, as I have pointed out. >> [ A truly context-typing would mean that what a function does, depends not >> only on the type tag of the value and the signature of the function [as it >> happens in the example above], but also, on the context of the call. NOBODY >> would like to have such thing. It would be an ultimate mess. It would make >> functional decomposition impossible, because the developer of a function >> would be unable to design it INDEPENDENTLY on the call contexts, which are >> UNKNOWN in advance. ] > > Perhaps "context" is not the best name for it. "Flag-free" or "untagged > types" may be a better name. Again, I don't want to get caught up in a > name battle. I don't care what it is called as long as it is clear what > is being talked about in this debate. Static typing it is. >> So, we can finally commit that different numeric models are required? Now >> to be able to use them you need a way to distinguish values of different >> models. > > No we don't. Example: > > x = "123456.789012"; > y = "7"; > x = decimalLibrary.divide(x, y, 20); > print(...); > x = floatingPointLibrary.divide(x, y, 4); // last param is number of > bytes > print(...); What does this example show? It uses two different models: decimal fixed-point delta 10e-20 and floating-point digits 6. How does this prove that there should be only one model? The code above is flawed. I presume that decimalLibrary.divide(,,20) results in fixed-point delta 10e-20. It is unclear from the code (yet another flaw), but let it be so. This number cannot be represented as fixed-point delta 10e-20 without a precision loss. Then floatingPointLibrary.divide silently converts arguments to floating-point digits 6, with another loss, of course. Carefully observe that binary floating-point numbers of IEEE standard, which your rubbish library would use, cannot exactly represent decimal fractions. As a matter of fact, try to print 0.1! So when the result is converted to your beloved string [=back to a decimal fixed-point model] you loose once again. Ergo: nobody could predict the accuracy of the result of your computation. Can you? Therefore the program above can be replaced with equivalent: x = 42 >>> BTW, whatever happened to the relational O(n) sub-debate? That was more >>> interesting than math libraries IMO. Have you conceded or plead boredom >>> or abandonment of that? >> >> Huh, there cannot be any debate! >> >> 1. Enumerating rows of an unsorted table is O(n), whatever sorting order is >> applied. >> >> 2. There exist no order for spaces of dimensions greater than 1. >> >> Ergo: tables are useless for spatial data. > > You have yet to present a scenario of unexcapable O(n). I don't. I needn't any scenario where the Earth isn't flat, because I'm quite sure that it isn't. > I showed a > solution to the "distance" calculation by moving that operation to the > internal (domain) notation. If you don't believe in facts, that's your problem. You are free to write an SQL application and measure the computation times on different table sizes. Draw a graphic... -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: topmind on 17 Feb 2006 18:05
Dmitry A. Kazakov wrote: > On 16 Feb 2006 17:47:01 -0800, topmind wrote: > > > Bull. It exists. Note that compiled languages generally track "flags" > > during compiling, not necessarily during running. The "flag" is > > assocated with a variable, not with a value. > > This is called static typing, as I have pointed out. I don't think so. However, I wish to see the definition you are using for "static typing". > >> So, we can finally commit that different numeric models are required? Now > >> to be able to use them you need a way to distinguish values of different > >> models. > > > > No we don't. Example: > > > > x = "123456.789012"; > > y = "7"; > > x = decimalLibrary.divide(x, y, 20); > > print(...); > > x = floatingPointLibrary.divide(x, y, 4); // last param is number of > > bytes > > print(...); > > What does this example show? That the same value can be used with different models. > It uses two different models: decimal > fixed-point delta 10e-20 and floating-point digits 6. For clarification, "20" is the max number of decimal places in the first call, not the number of bytes. I should have commented it (however it was already described in a prior message). > How does this prove > that there should be only one model? I did not claim that. > >>> BTW, whatever happened to the relational O(n) sub-debate? That was more > >>> interesting than math libraries IMO. Have you conceded or plead boredom > >>> or abandonment of that? > >> > >> Huh, there cannot be any debate! > >> > >> 1. Enumerating rows of an unsorted table is O(n), whatever sorting order is > >> applied. > >> > >> 2. There exist no order for spaces of dimensions greater than 1. > >> > >> Ergo: tables are useless for spatial data. > > > > You have yet to present a scenario of unexcapable O(n). > > I don't. I needn't any scenario where the Earth isn't flat, because I'm > quite sure that it isn't. Nearly useless info to others unless you present evidence. > > > I showed a > > solution to the "distance" calculation by moving that operation to the > > internal (domain) notation. > > If you don't believe in facts, that's your problem. You are free to write > an SQL application and measure the computation times on different table > sizes. Draw a graphic... You missed the point of my final example of that. The revised distance operation was not directly part of the relational engine. I moved the distance calculation to the "domain math" and outside of the relational math. The domain operation simply returned ID's of those items within the given range. That operation can use your favorite distance algorithm. Thus, it does *not* have to visit every point, as you claim. Perhaps you can argue that the requirement for unique keys slows things down, but not to O(n). (Note that we can do the same with compound keys, it is just more complicted to work with them that way.) > > -- > Regards, > Dmitry A. Kazakov -T- |