December 21, 2017 at 5:11 pm
December 21, 2017 at 5:16 pm
Don Halloran - Thursday, December 21, 2017 5:11 PMHow I can be creating a straw man of my own position? I don't consider it "hard headed" to give up in this case, Tom has made it clear that he will not acknowledge the idea and said he saw no point in communicating further. I agreed with him - I also see no point in him continuing. I agree that it's usually worth an effort to clarify so that a discussion can move forward. But I think I have spent a more than reasonable amount of text trying to do that, and the more text I spend the less objective he seems to become. How much more text am I required to spend on him before you would say I not being "hard headed"?
How about because I don't see you doing anything but attacking. I don't see you trying to work out your differences, it is almost like you think you are always right and the rest of the world is wrong. Sometimes some one has to take a step back and try a fresh approach. This is your idea, you should be the one making more of an effort here, not the other way around. Find the common ground where you both can agree and then move forward from there.
December 22, 2017 at 12:13 am
It seems as though SSC decided that my reply should overwrite my previous comment, so now it appears as though I have somehow gone back in time. Fortunately you quoted the whole of the now-overwritten comment, so I will try to straighten the thread out so that it is comprehensible. To wit, I have undone the previous edit using your quote, and added my actual reply here.
---
"How about because I don't see you doing anything but attacking."
I think that's a mischaracterization. Sometimes a conversation with a lot of formal language can seem that way because it's impersonal, and there's a lot of formal language in this discussion. Is that what you mean? If not, then I disagree with your claim empirically. It wasn't until my fourth comment, after Tom repeated the same misunderstanding through three clarifications, that I said "this seems deliberately obtuse". But I still went on to provide further clarification. I also pointed out that his claims weren't implied by the text, and that his argument was a formal fallacy. If pointing out that a claim is not derivable from the text is "an attack" in your mind, then I accept that you see it as an attack. I don't agree that it is an attack, it's just the nature of a debate that it includes refutation.
Even so, I said "Perhaps I can come up with a completely way of demonstrating the idea. But I must also suggest that more careful consideration of what I've written might also help. I will try to improve my illustration", and then spent time doing just that - and I posted another illustration in the hope that things might come back on track. I consider this quite a reasonable effort on my part.
Tom's next comment, beginning with "OK, here it's clear what you are getting at", was - I thought - an indication that this had worked. But then he followed it up with a further comment which was seemingly a relapse to the time when he had not grasped the idea, including the phrases "Quite frankly I'm inclined to some extent to give up attempting to communicate", "I probably ought just to have suggested that you learn some SQL", and "I could of course have chosen to assume that what you said was not what you meant"
Why he chose to understand then idea, but then go back and comment on aspects he had not previously understood from the point of view of still not having understood them, I can't imagine.
If you still feel the same way, well, you're entitled to your feelings of course. I can't argue against feelings.
December 22, 2017 at 5:20 pm
Don Halloran - Friday, December 22, 2017 12:13 AMIt seems as though SSC decided that my reply should overwrite my previous comment, so now it appears as though I have somehow gone back in time. Fortunately you quoted the whole of the now-overwritten comment, so I will try to straighten the thread out so that it is comprehensible. To wit, I have undone the previous edit using your quote, and added my actual reply here.---
"How about because I don't see you doing anything but attacking."
I think that's a mischaracterization. Sometimes a conversation with a lot of formal language can seem that way because it's impersonal, and there's a lot of formal language in this discussion. Is that what you mean? If not, then I disagree with your claim empirically. It wasn't until my fourth comment, after Tom repeated the same misunderstanding through three clarifications, that I said "this seems deliberately obtuse". But I still went on to provide further clarification. I also pointed out that his claims weren't implied by the text, and that his argument was a formal fallacy. If pointing out that a claim is not derivable from the text is "an attack" in your mind, then I accept that you see it as an attack. I don't agree that it is an attack, it's just the nature of a debate that it includes refutation.
Even so, I said "Perhaps I can come up with a completely way of demonstrating the idea. But I must also suggest that more careful consideration of what I've written might also help. I will try to improve my illustration", and then spent time doing just that - and I posted another illustration in the hope that things might come back on track. I consider this quite a reasonable effort on my part.
Tom's next comment, beginning with "OK, here it's clear what you are getting at", was - I thought - an indication that this had worked. But then he followed it up with a further comment which was seemingly a relapse to the time when he had not grasped the idea, including the phrases "Quite frankly I'm inclined to some extent to give up attempting to communicate", "I probably ought just to have suggested that you learn some SQL", and "I could of course have chosen to assume that what you said was not what you meant"
Why he chose to understand then idea, but then go back and comment on aspects he had not previously understood from the point of view of still not having understood them, I can't imagine.If you still feel the same way, well, you're entitled to your feelings of course. I can't argue against feelings.
Okay, let me say it another way, you didn't seem to care if he understood what you were trying to say. Period. You made no attempt to truly make sure both of you were on the same page.
I have been in a discussion where the other didn't understand what I was trying to explain, I even had others tell me to drop it and walk a way. I kept working at, changing my tact at times until finally the other person figured out what I was trying to get across. This is where you are failing. This is why you have lost.
The ball is in your court if you want someone who obviously in your court. Tom obviously knows his stuff, do you want him to understand what it is you are proposing?
December 22, 2017 at 5:40 pm
You claim I didn't care whether he understood, but I spent 20 paragraphs working through various different explanations trying to provide that understanding. Does that not seem rather contradictory to you?
You're making a lot of claims. Half of them are mere ad hominem, and you've provided actual arguments or evidence in support of none of them. It would have been appropriate for me to respond by saying no more than that. Instead I have responded with reason and evidence, but I think this meta-discussion is unproductive.
If you have any thoughts on the actual topic I'd be interested.
December 22, 2017 at 5:55 pm
Don Halloran - Friday, December 22, 2017 5:40 PMYou claim I didn't care whether he understood, but I spent 20 paragraphs working through various different explanations trying to provide that understanding. Does that not seem rather contradictory to you?You're making a lot of claims. Half of them are mere ad hominem, and you've provided actual arguments or evidence in support of none of them. It would have been appropriate for me to respond by saying no more than that. Instead I have responded with reason and evidence, but I think this meta-discussion is unproductive.
If you have any thoughts on the actual topic I'd be interested.
You know, I can't get you to understand that you are just as much a part of the problem. I can see why Tom quit. Bye bye.
January 14, 2018 at 6:42 pm
Lynn Pettis - Friday, December 22, 2017 5:55 PMYou know, I can't get you to understand that you are just as much a part of the problem. I can see why Tom quit. Bye bye.
Of course you can't, you haven't provided any arguments in support of your position. What you've done is tell me is how this discussion makes you feel, but feelings and truths bear no necessary relation. If you want to persuade me of some position involving a truth claim - which you seem to want to do - use the tool appropriate to analysis of truth claims. That is to say, make a logical argument using reason and evidence. I'm not going to change my mind about anything - ever - based on your feelings.
January 14, 2018 at 10:55 pm
Don Halloran - Sunday, January 14, 2018 6:42 PMLynn Pettis - Friday, December 22, 2017 5:55 PMYou know, I can't get you to understand that you are just as much a part of the problem. I can see why Tom quit. Bye bye.Of course you can't, you haven't provided any arguments in support of your position. What you've done is tell me is how this discussion makes you feel, but feelings and truths bear no necessary relation. If you want to persuade me of some position involving a truth claim - which you seem to want to do - use the tool appropriate to analysis of truth claims. That is to say, make a logical argument using reason and evidence. I'm not going to change my mind about anything - ever - based on your feelings.
I am interested in the discussion between you and Tom. I don't have a horse in that race. As for what I am telling you is that you are just as at fault for the discussion ending and he is and that you need to figure out a way to keep it going without each of you attacking the other. You start by finding COMMON GROUND where you both agree and then move on to those areas where you don't and discuss them professionally and with some passion. Get it?
January 15, 2018 at 7:17 am
I don't like the idea. It disallows using columns in keys to specify overlapping sets.
Another thing I'm suspicious about incidently is that you're trying to develop a grand unifying theory to allow you to define an indistinct sloppy human condition. Phone numbers AT THEIR VERY FUNDAMENTAL LEVEL identify phone numbers and NOTHING ELSE. Yes, we try to make practical use of them and for the most part it works because most folks have phone numbers that stay pretty constant but still, folks can have multiple phone numbers, share phone numbers, you can have phone numbers without people, people without phone numbers, etc.
January 16, 2018 at 1:03 am
patrickmcginnis59 10839 - Monday, January 15, 2018 7:17 AMI don't like the idea. It disallows using columns in keys to specify overlapping sets.Another thing I'm suspicious about incidently is that you're trying to develop a grand unifying theory to allow you to define an indistinct sloppy human condition. Phone numbers AT THEIR VERY FUNDAMENTAL LEVEL identify phone numbers and NOTHING ELSE. Yes, we try to make practical use of them and for the most part it works because most folks have phone numbers that stay pretty constant but still, folks can have multiple phone numbers, share phone numbers, you can have phone numbers without people, people without phone numbers, etc.
Could you elaborate on the "disallows using columns in keys to specify overlapping sets" problem? Maybe an example will help.
Regarding your second paragraph: The idea here is not really *about* phone numbers or time intervals per se, I'm just using those as examples where the fundamental idea could be applied. If I take a tangent to discuss the specifics of the example for a moment then I agree, phone numbers can be shared and so on - actually I mentioned that in the original post, as well as the idea of a contact phone number being for a department or a desk rather than a person, as you mentioned. But in defense of the example qua the example (and not related to the idea itself), what is being identified here is not a person, but rather a contact. A common example where phone numbers really are identifiers at my business is when we run a competition. People submit entries via their phone number, which really is the key for the contact who entered the competition. There is no other candidate.
January 16, 2018 at 8:31 am
Could you elaborate on the "disallows using columns in keys to specify overlapping sets" problem? Maybe an example will help.
I would want my keys to be able to specify overlapping data. For instance, I'd like to be able to specify overlapping time ranges without any analysis applied beyond whether the combination of column values would be unique.
Like:
day shift, 8 am to 5 pm
swing shift, 12 noon to 9 pm
and those both be unique keys.
How about:
regions:
we could declare these with an ordered list of coordinates, and lets just say that we can and do specify regions like this routinely, and we use these specifications for things we do for regions like political boundaries. So one political boundary could CONTAIN multiple sub boundaries.
manufacturing assemblies.
obviously the "assembly id" would not overlap, but a sub assembly could belong to multiple assemblies. Does the intersection function apply here? Sure we only key on the assembly id for the assembly header, but for the assembly detail, if we read semantically into this to determine intersection, does your theory apply or not?
edit: in other words, whats so bad about overlapping sets, because as long as the intersection does not equal both sets (ie., the keys aren't equal), the keys specify unique and unequal things. What does the empty intersection buy us?
So intuitively I'm concerned at what problems this modeling of yours introduces (and obviously my analysis could be mistaken!), without any understanding of any solutions that your modeling assists in achieving or what advantages this modeling technique might facilitate. Is there any way you could distill the advantages of your intersection function would give? I understand this is to assist in evaluating candidate keys, but what advantages does the intersection offer versus simple equality, or alternatively what disadvantages does equality without the intersection test imply?
Heck maybe I'm just not understanding whats up, especially in this age of surrogate keys based on arbitrary integers 🙂
January 16, 2018 at 1:06 pm
patrickmcginnis59 10839 - Tuesday, January 16, 2018 8:31 AMCould you elaborate on the "disallows using columns in keys to specify overlapping sets" problem? Maybe an example will help.
I would want my keys to be able to specify overlapping data. For instance, I'd like to be able to specify overlapping time ranges without any analysis applied beyond whether the combination of column values would be unique.
Like:
day shift, 8 am to 5 pm
swing shift, 12 noon to 9 pm
and those both be unique keys.How about:
regions:
we could declare these with an ordered list of coordinates, and lets just say that we can and do specify regions like this routinely, and we use these specifications for things we do for regions like political boundaries. So one political boundary could CONTAIN multiple sub boundaries.manufacturing assemblies.
obviously the "assembly id" would not overlap, but a sub assembly could belong to multiple assemblies. Does the intersection function apply here? Sure we only key on the assembly id for the assembly header, but for the assembly detail, if we read semantically into this to determine intersection, does your theory apply or not?edit: in other words, whats so bad about overlapping sets, because as long as the intersection does not equal both sets (ie., the keys aren't equal), the keys specify unique and unequal things. What does the empty intersection buy us?
So intuitively I'm concerned at what problems this modeling of yours introduces (and obviously my analysis could be mistaken!), without any understanding of any solutions that your modeling assists in achieving or what advantages this modeling technique might facilitate. Is there any way you could distill the advantages of your intersection function would give? I understand this is to assist in evaluating candidate keys, but what advantages does the intersection offer versus simple equality, or alternatively what disadvantages does equality without the intersection test imply?
Heck maybe I'm just not understanding whats up, especially in this age of surrogate keys based on arbitrary integers 🙂
One good thing about looking at complete equality instead of intersection is that if key sequence A conflicts with key sequence B and key sequence B conflicts with key sequence C then we know that ket sequence A conflicts with key sequence C. If working on intersection of lists of partial keys we don't have that useful property - a can conflict with B and B with C and there be no confict between A and C (If A is {1,2} and B is {2,3} and C is {3,4} then there's no confict between A and C but B conficts with both A and C). So if we call the conflict between keys "equality" we have the interesting situation that equality is not transitive. So we'd better not call that relationship "equality".
I still worry about the statement that there's no declarative way of determining whether two finite sets intersect - I'll quote it as in the hope that Halloran will then not claim that he never made that statement:
It is quite common to encounter the problem of needing multiple versions of a thing, which cannot overlap in time. For example in a data warehouse with a slowly changing dimension, the interval represented by a version cannot overlap with the interval representing any other version. Another example might be the case of an employment relationship, where one person can only be employed by a company once at any given instant in time.
The problem with this sort of rule is that it cannot be declaratively enforced
It is a consequence of the Church-Turing thesis that anything that is effectively computable is a recursive function and a property of the lambda calculus that any any recursive function can be expressed in the lambda calculus and a property of expressing things in the lambda calculus that anything that's expressible that way can be expressed in a fully declarative functional programming language, so that statement amounts to a claim by Halloran that his ideas on intersecting keys are so mathematically productive that he has managed to disprove the Church-Turing thesis (and that's something that would amaze most living mathematicians, since it's generally felt that the thesis is actually a definition of "effectively computable" as we can't think of any other meaning to the phrase than something is effectively computable if and only if a Turing-complete device could compute it or, equivalently, if and only if a function to calculate it could be written using the lambda calculus). Or perhaps he's not making that claim, perhaps the problem is that when he says "declarative" he doesn't mean what the rest of the world means (expressible in a purely declarative language)?
Tom
January 16, 2018 at 5:57 pm
TomThomson - Tuesday, January 16, 2018 1:06 PMOne good thing about looking at complete equality instead of intersection is that if key sequence A conflicts with key sequence B and key sequence B conflicts with key sequence C then we know that ket sequence A conflicts with key sequence C. If working on intersection of lists of partial keys we don't have that useful property - a can conflict with B and B with C and there be no confict between A and C (If A is {1,2} and B is {2,3} and C is {3,4} then there's no confict between A and C but B conficts with both A and C). So if we call the conflict between keys "equality" we have the interesting situation that equality is not transitive. So we'd better not call that relationship "equality".
I don't know what a :"key sequence" is, and I don't know where you're getting the idea that a conflict between keys should be described as equality, since that's absolutely not the same as saying that finding key conflicts in a standard relational model is done using an equality test. But regardless, what you seem to be saying here is that tests of equality and tests of intersection are not the same operation. That's good, since my entire proposal hinges upon the idea that tests of equality and tests of intersection are not the same operation.
It is a consequence of the Church-Turing thesis that anything that is effectively computable is a recursive function and a property of the lambda calculus that any any recursive function can be expressed in the lambda calculus and a property of expressing things in the lambda calculus that anything that's expressible that way can be expressed in a fully declarative functional programming language, so that statement amounts to a claim by Halloran that his ideas on intersecting keys are so mathematically productive that he has managed to disprove the Church-Turing thesis
This is complete horseshit, and you surely know it is, but you think that by throwing terms that you desperately hope nobody else understands into the mix you will come across as sounding authoritative.
The limitation I am describing when I say "you cannot define this kind of key" has nothing to do with the limitations of Turing machines or declarative languages, it has to do with the limitations of relational modelling. Specifically, in a relational model I cannot declare a key as a set (extensionally as tuples, or intensionally as a rule) and ask that the test for key violations be a test of intersection with other key sets, even though a computer could obviously perform that kind of test, because in relational models the test for key violation is a test of equality against other key values, not a test of intersection against other key sets. This is precisely why I am suggesting that my proposal is an extension to relational models, not an extension to what a computer can possibly be. This is patently obvious, because if I was claiming that the limitation was a result of the nature of Turing machines or declarative langauges, then I could not possibly then be proposing an extension to a model which is implemented declaratively on Turing machines as a solution to that limitation.
Your objection in another form would look something like this: "Halloran is suggesting that an XML DOM can't be successfully parsed without a root element, but that he has an idea of how to to extend the XML DOM to make a situation like that parseable. Since he initially claimed it couldn't be done, I interpret that as a claim about the functional limitations of text parsing by Turing machines, not a claim about the limitations of the XML DOM". That would be an unbelievably stupid interpretation, but there you are.
Now run back to your hole, you insufferable git.
January 16, 2018 at 6:27 pm
Aha, I getcha.
The idea I'm proposing does not require that anything be subtracted from existing relational functionality, it is strictly an extension to the concept of what a key can be. So I would say that the kind of situation you're describing is really just a situation where we have a key composed of multiple columns rather than sets we don't want to intersect, and so that kind of situation is already covered by existing relational modelling, which remains unchanged under this proposal. The same seems true of the other examples you've proposed.
More generally I might put it like this: There are cases, like those you've cited, where we don't want to use the intersection of sets as the test of key violation. I don't mean to suggest that this is not the case, rather I am suggesting in these cases, when we're dealing with single tuples, intersection reduces to equality and therefore acts just the way things work now, but that there are other occasions where it is the case that an intersection test across multiple tuples (or intensionally defined sets) would be appropriate, and that these latter occasions cannot currently be modeled without some kind of extension such as the one I am proposing.
January 17, 2018 at 12:10 am
Don Halloran - Tuesday, January 16, 2018 5:57 PMTomThomson - Tuesday, January 16, 2018 1:06 PMOne good thing about looking at complete equality instead of intersection is that if key sequence A conflicts with key sequence B and key sequence B conflicts with key sequence C then we know that ket sequence A conflicts with key sequence C. If working on intersection of lists of partial keys we don't have that useful property - a can conflict with B and B with C and there be no confict between A and C (If A is {1,2} and B is {2,3} and C is {3,4} then there's no confict between A and C but B conficts with both A and C). So if we call the conflict between keys "equality" we have the interesting situation that equality is not transitive. So we'd better not call that relationship "equality".
I don't know what a :"key sequence" is, and I don't know where you're getting the idea that a conflict between keys should be described as equality, since that's absolutely not the same as saying that finding key conflicts in a standard relational model is done using an equality test. But regardless, what you seem to be saying here is that tests of equality and tests of intersection are not the same operation. That's good, since my entire proposal hinges upon the idea that tests of equality and tests of intersection are not the same operation.
It is a consequence of the Church-Turing thesis that anything that is effectively computable is a recursive function and a property of the lambda calculus that any any recursive function can be expressed in the lambda calculus and a property of expressing things in the lambda calculus that anything that's expressible that way can be expressed in a fully declarative functional programming language, so that statement amounts to a claim by Halloran that his ideas on intersecting keys are so mathematically productive that he has managed to disprove the Church-Turing thesis
This is complete horseshit, and you surely know it is, but you think that by throwing terms that you desperately hope nobody else understands into the mix you will come across as sounding authoritative.
The limitation I am describing when I say "you cannot define this kind of key" has nothing to do with the limitations of Turing machines or declarative languages, it has to do with the limitations of relational modelling. Specifically, in a relational model I cannot declare a key as a set (extensionally as tuples, or intensionally as a rule) and ask that the test for key violations be a test of intersection with other key sets, even though a computer could obviously perform that kind of test, because in relational models the test for key violation is a test of equality against other key values, not a test of intersection against other key sets. This is precisely why I am suggesting that my proposal is an extension to relational models, not an extension to what a computer can possibly be. This is patently obvious, because if I was claiming that the limitation was a result of the nature of Turing machines or declarative langauges, then I could not possibly then be proposing an extension to a model which is implemented declaratively on Turing machines as a solution to that limitation.
Your objection in another form would look something like this: "Halloran is suggesting that an XML DOM can't be successfully parsed without a root element, but that he has an idea of how to to extend the XML DOM to make a situation like that parseable. Since he initially claimed it couldn't be done, I interpret that as a claim about the functional limitations of text parsing by Turing machines, not a claim about the limitations of the XML DOM". That would be an unbelievably stupid interpretation, but there you are.
Now run back to your hole, you insufferable git.
Okay, that crossed the line of professionalism. There is absolutely no excuse for name calling on this site. Regardless of your personal feelings toward Tom and his comments you owe him an apology.
Viewing 15 posts - 16 through 30 (of 37 total)
You must be logged in to reply to this topic. Login to reply