denis_berthier wrote:Again finding cantankerous Space's logorrhoea in some thread.
That's underwhelming. I'm disappointed that you couldn't come up with a fresh insult despite your impressive vocabulary. You've now twice in a row used the same fancy word to imply that I have brain damage or a mental illness. That's getting repetitive. (I've been banned for much less but who's counting.)
Misspelling my handle is getting old too. Speaking in third person? Come on, that's not even trying. You should work on your insults to compensate for the lacking arguments.
Quite funny when I remember he proposed to be the ambassador of whips. Typical reaction of a dismissed lover turned into a hater ?
It's taken me this long to respond because I haven't been able to stop laughing after I read that. I didn't know you had such a vivid imagination and a great sense of humor!
Did I lead you on? Did I make you think I was in love with whips (or you)? I'm so sorry! Now I know what it's like to be a woman and accidentally smile at a guy who reads too much into it.
This is what I actually said:
SpAce wrote:In fact I find it a bit interesting that you're not exactly eager to help, even though it should be in your own interest. If I learn and happen to like your system, I'll probably start spreading the gospel.
I meant that too. Too bad I haven't found much to like as a manual solver, so looks like I'm spared of missionary duty. That said, it wasn't exactly easy to wade through the heavy smokescreens to be able to pass judgment.
There are two recurring themes that make learning your system very hard. One is that simple concepts are hidden behind very complex theory. The other is that complex logic is hidden behind deceptively simple chains. Both result in massive failures to communicate.
Later I also said this
this:
Btw, now that I apparently understand what a whip is, I must say that I really like the name! It's actually very descriptive.
I still like the
name, but please don't read too much into it.
Space has already largely proven in his previous posts that he doesn't understand what the confluence property means
What an impressive deduction! I never claimed that I'd understood confluence perfectly. You shouldn't be too proud of that either. If my cognitive skills (and apparently eleven's too) aren't enough to get an accurate picture of such a simple concept, there just might be a bit of a problem with the presentation. (Of course that's not possible; what am I even suggesting?)
Nevertheless, I probably did figure out its practical worth, which is absolutely zero for a manual solver. (If you disagree, I suggest you produce evidence that proves me wrong.) That doesn't mean it's necessarily useless for other purposes, such as rating systems and research.
My focus is solely on manual solving, so anything I say should be understood in that context only, unless otherwise specified. In general, it's obvious that the possible strengths of your system lie elsewhere.
Obviously, he doesn't understand either the difference between a braid and T&E.
You wish. T&E is a procedure to find contradictions, while braids (like whips) are found contradiction patterns. Apples and oranges. You really think I don't understand such fundamental differences? Lol. You can't find any evidence in what I wrote to support such an idiotic conclusion, except by intentionally misreading it (which you seem very capable of when it serves your agenda).
My fundamental theorem stating that any elimination done by one can be done by the other doesn't imply that they are the same thing.
And I never claimed anything else (see above) because I'm not an idiot. In fact, it seems to me that you don't see the boundary quite as clearly yourself.
That said, there's no manually applicable procedure that can find complex braids without applying some form of T&E, so it's fair to say that all of them are products of T&E. They're certainly not patterns that can be just seen in the grid, unless they're simple enough to be seen as something more elegant anyway.
Whatever pattern-matching magic your software might do to find braids directly is inapplicable in manual solving, so don't even bring it up. If you claim otherwise, you're either a genius manual solver or you don't know what you're talking about. I've seen no evidence of the former possibility.
Personally I consider any contradiction step to be a form of T&E, because that's what making an assumption and running into a contradiction is, by definition. I only count directly found verities as non-T&E steps, which means that no braids nor whips could ever qualify.
A solution with braids will generally take less than a page. A solution with T&E will take 20 pages
Now you're comparing apples and oranges yourself. T&E is not a notation, nor does it have any standard one. Thus, that claim makes zero sense.
That said, if a T&E solution is presented in any legible notation, it will surely take more space than the corresponding braid notation. The simple reason is that the latter hides all the details that would make it understandable. That's in direct violation of your own self-righteous claims about the purpose of notation.
and will not give the shortest possible braids when one tries to translate it into braids.
There's absolutely no logical basis for that claim. Since every braid is findable through T&E (and there's no other manual way to find them), it's just a matter of doing it systematically and picking the shortest ones before actually applying them. Thus, a thorough enough T&E process will certainly find the shortest possible braids eventually, though perhaps not as efficiently as your pattern-matching software.
Of course none of that is relevant for a manual solver who'd probably use whatever they find first, or otherwise focus on picking the most effective or elegant steps, instead of obsessing about the shortest ones. It's unlikely that they'd document those T&E eliminations as braids either, unless they're more concerned about saving space or licking your boots than presenting understandable logic.
The purpose of a language, be it natural or formal, is to communicate.
Considering your notations, that's pretty funny.
Prefixing every step of my resolution paths with the name of the pattern involved fits this purpose.
Including the prefix as an optional component just for communication purposes would be ok, but making it actually necessary to interpret a chain correctly is absolutely horrible. It's an architectural flaw that makes the notation complex and brittle.
(Sure, it doesn't fit the absurd purpose of having the most possible compact illegible notation.)
Fortunately your braid and whip notations fill that gap. In both cases, but especially braids, the logic is compacted beyond recognition. I'm a fan of compactness but not when if it's done by removing relevant information and writing links that aren't real. Your chains have no resemblance to what's actually in the grid, and that makes them unreadable.
Symbols in my nrc notation always have the same meaning:
Except the most important one:
— always denotes a direct link between two candidates; the only thing that may change is, in braids, this direct link can be to the target or to a previous rlc (as is announced in the name of the pattern and its definition).
Just a minor foot note. Lol. The only intuitive interpretation of a link a-b is that a and b are linked, but with braids it doesn't necessarily mean that at all. There's simply no excuse for that. Then again, it's obvious that you don't much care about intuitiveness or learning curves anyway. Your only answer to any related criticism is that one has to read the prefix and its definition. Like I said, complex and brittle.
And nothing is hidden: the t- and z- candidates are not part of my chains.
In other words your chains don't contain the full logic, which makes them both unreadable and deceptively simple-looking. Sure, they can be deciphered when one knows the exact rules governing each prefix, but that's exactly what it takes: deciphering.
It's funny that you emphasize the "simplest first" strategy so much, yet the only measures of complexity you use are the prefix and the length. Did it ever occur to you that those t- and z-candidates add a lot of real complexity for a manual solver, and it's impossible to evaluate that just by looking at your chains because the information simply isn't there. That complexity doesn't disappear from the grid even if you hide it in your chains. It's much more relevant than the length.
On the other hand, if you look at a Eureka chain/net, you get immediately a very good idea of the level of complexity and what the chain looks like in the grid. In most cases the logic can be easily traced without even seeing the grid. There's not even a remote chance of that with your tz-chains/whips/braids, because they're so far removed from the grid reality.
If a t- or z- candidate disappears during solving, the whip/braid.. containing it is unchanged!
Sounds like an extremely valuable feature, well-worth sacrificing readability! Just to be sure, that was sarcasm. I can't imagine how that would be relevant for a manual solver at all. I'm guessing it's related to your software optimizations and nothing else.
But, obviously, one has to read the definitions in order to understand them before criticising them.
That (and this whole discussion) reminds me of a classic joke by Ronald Reagan. What's the definition of a communist? One who's read the works of Marx and Lenin. What's the definition of an anti-communist? One who's understood the works of Marx and Lenin.
