5 kyu
Propositional SAT Problem
34Dr Gabo
Loading description...
Logic
Mathematics
Algorithms
View
This comment has been reported as {{ abuseKindText }}.
Show
This comment has been hidden. You can view it now .
This comment can not be viewed.
- |
- Reply
- Edit
- View Solution
- Expand 1 Reply Expand {{ comments?.length }} replies
- Collapse
- Spoiler
- Remove
- Remove comment & replies
- Report
{{ fetchSolutionsError }}
-
-
Your rendered github-flavored markdown will appear here.
-
Label this discussion...
-
No Label
Keep the comment unlabeled if none of the below applies.
-
Issue
Use the issue label when reporting problems with the kata.
Be sure to explain the problem clearly and include the steps to reproduce. -
Suggestion
Use the suggestion label if you have feedback on how this kata can be improved.
-
Question
Use the question label if you have questions and/or need help solving the kata.
Don't forget to mention the language you're using, and mark as having spoiler if you include your solution.
-
No Label
- Cancel
Commenting is not allowed on this discussion
You cannot view this solution
There is no solution to show
Please sign in or sign up to leave a comment.
Sample test needs to be updated:
test.expect(m4 == {p} or m2 == {q} or m2 == {p, q})
should betest.expect(m4 == {p} or m4 == {q} or m4 == {p, q})
I fixed both points! Hope it's better now.
Then
Literal
's__eq__
should be defined to allow this. CurrentlyLiteral('p') == Literal('p')
givesFalse
. Only every same-named instance in the input formula is equal to each other.Definitely an issue. Fixed it!
warning: you need then to actually implement
hash
in the same way. For now, it works for the only same reason, but if you fixe the behavior for one, you have to fix it for the other too.__hash__
? ;-)Don't worry, I also implemented the hash function accordingly.
@Voile: ofc. ('didn't think I'd have to be blatant about that... ;p )
@DrGabo: not good enough: you actually need to implement both functions for both classes. And to have something efficient enough, you'll need to store the string representation as a property, so that the hash won't become too much time cosuming
To be honest, I don't know how I feel about defining equality for complex formulas, since I have to ignore commutativity and associativity to make an effective implementation. I did it for consistency reasons by comparing the string representation (it should be correct), but I'm not quite sure if it's for the best :/
True. But considering that you're the one buildigng the trees, you can guarantee the consistency about that. :)
Hi again,
IMO, there's something fishy. Either in the description, or in the conception of the task ;o
How are we supposed to use the formula instances? I'd assume a meaningful implementation of those would provide getters for leaves/values too. Like
left/right/child
for AND, OR and NEG, andsymbol
or something like that for the litterals. Do, there is no such things... Meaning for now, the only idea that comes to my mind is to print the formula and parse the string... Which seems pretty unnecessary/uninteresting thing here, considering we are provided with a tree in the first place... I'd honestly be tempted to hack the Formula class to solve the kata... :pAm I missing something?
well, see my solution. I find the setup of your kata pretty weird... :o (but that's interesting)
oh god... :/ I totally missed the description of
args
, actually... :/ But I'm not surprised I forgot about it: you didn't actually tell what it was (-> a list of children nodes)I didn't want to use that terminology (children nodes) because operands or subformulae are the accepted names in the field, but I will add a clarification to make it more clear.
I'm glad you could solve it :)
especially, make it perfectly clear that this list can have any length (and/or operators!)
Hi,
litteral
should beis_litteral
or the equivalent getterThe first change I can make with no problem. Altough it does not change much, I understand the concern. On the other hand, the second change does not make sense from a semantic standpoint. A literal is a kind of formula, but not the other way around.
First suggestion implemented!
:+1:
In the sample test, I'd recommend putting each test immediately after the user's solution is computed. This makes it easier to for debugging / logging values, as each function call is grouped separately.
You are right. I modified the sample tests.