SQL
in [OOP]
|
From: Dmitry A. Kazakov on 18 Feb 2006 05:49 On 17 Feb 2006 15:05:23 -0800, topmind wrote: > I don't think so. However, I wish to see the definition you are using > for "static typing". http://en.wikipedia.org/wiki/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 is not the same value. It is the same chain of characters. Value is a meaning of the chain. That depends on the type assigned. "42" might be anything if the type is not specified. Maybe you mean that there are numbers representable in more that one numeric model? So what? >> How does this prove that there should be only one model? > > I did not claim that. Then what's your point? Which model has "42"? > 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. I didn't miss it. That was my point, you didn't get. Namely, such operation cannot be implemented as a function of two arguments. If it returns IDs, then it shall know the whole data set [=it is not a function of its arguments.] This proves that relational cannot decompose the problem presented [even having ADTs in cells.] End of story. > 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.) No, the point is that [a reasonable] relational decomposition cannot be better than O(n) in this case. At the same time, it is well known that there are much better than O(n) methods. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: topmind on 18 Feb 2006 18:12 Dmitry A. Kazakov wrote: > On 17 Feb 2006 15:05:23 -0800, topmind wrote: > > > I don't think so. However, I wish to see the definition you are using > > for "static typing". > > http://en.wikipedia.org/wiki/Static_typing That is a poorly written article (I fixed some of it). Is this what you are talking about?: "Static type systems for dynamic types usually need to explicitly represent the concept of an execution path, and allow types to depend on it." "Usually" in definitions is a yellow alert. > > >>>> 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 is not the same value. It is the same chain of characters. Value is a > meaning of the chain. That depends on the type assigned. "Meaning" to who or what? > "42" might be > anything if the type is not specified. Exactly. > > Maybe you mean that there are numbers representable in more that one > numeric model? So what? > > >> How does this prove that there should be only one model? > > > > I did not claim that. > > Then what's your point? > > Which model has "42"? Multiple math models can use the same input. > > > 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. > > I didn't miss it. That was my point, you didn't get. Namely, such operation > cannot be implemented as a function of two arguments. If it returns IDs, > then it shall know the whole data set [=it is not a function of its > arguments.] This proves that relational cannot decompose the problem > presented [even having ADTs in cells.] End of story. How does having to know the whole data set prove that it must use O(n)? Having the potential of seeing the whole data set and actually having to traverse the whole data set are two different things. You seem to be saying that EVERY potential implementation of: list_of_ids = withIn(x, miles=25); // find stuff within 25 miles of x has to traverse *every* point. Hogwash! > -- > Regards, > Dmitry A. Kazakov
From: Dmitry A. Kazakov on 19 Feb 2006 06:08 On 18 Feb 2006 15:12:24 -0800, topmind wrote: > Multiple math models can use the same input. Multiple math models model the same thing: real numbers. They do it differently, and ADT is a tool to specify what's going on. >>> 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. >> >> I didn't miss it. That was my point, you didn't get. Namely, such operation >> cannot be implemented as a function of two arguments. If it returns IDs, >> then it shall know the whole data set [=it is not a function of its >> arguments.] This proves that relational cannot decompose the problem >> presented [even having ADTs in cells.] End of story. > > How does having to know the whole data set prove that it must use O(n)? It doesn't. As I said, there are better methods. It is up to you to find one and show that it is relational-decomposable. So far you took, what I had presented: SELECT ... FROM ... WHERE D(X, Y) < T Already this defeats your point about "useless types", because it *requires* ADTs in cells to implement D(*,*) without rewriting the DBMS. But, even this is still O(n). To make it better one have to get rid of the engine. I.e. to have ADTs at the container level. P.S. The position you held before - to ignore anything relational cannot - was better defendable. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: topmind on 19 Feb 2006 15:19
> >>> 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. > >> > >> I didn't miss it. That was my point, you didn't get. Namely, such operation > >> cannot be implemented as a function of two arguments. If it returns IDs, > >> then it shall know the whole data set [=it is not a function of its > >> arguments.] This proves that relational cannot decompose the problem > >> presented [even having ADTs in cells.] End of story. > > > > How does having to know the whole data set prove that it must use O(n)? > > It doesn't. As I said, there are better methods. It is up to you to find > one and show that it is relational-decomposable. So far you took, what I > had presented: > > SELECT ... FROM ... WHERE D(X, Y) < T > > Already this defeats your point about "useless types", because it > *requires* ADTs in cells to implement D(*,*) without rewriting the DBMS. Huh? In the cells? Please clarify. > But, even this is still O(n). To make it better one have to get rid of the > engine. I.e. to have ADTs at the container level. That is not what I proposed in the later messages. You are beating a strawman. I agree that the approach you show above *would* probably be O(n). But that is why I showed a different route; a compromise that does not require entirely abandoning relational. Like I keep saying, reinventing 1/3 of a wheel is better than reinventing all of it. We have relational math and the domain "math". (The query language combines them.) Some things work well in the relational math and some don't. If stuff doesn't work well there, then shift the burden to the domain math. The downsides of doing that is that you may lose some integration with relational techniques. > > -- > Regards, > Dmitry A. Kazakov -T- |