Title (Kirq) If truth table already generated, don't regenerate
Priority bug Status chatting
Superseder Nosy List christopher, cjr
Assigned To christopher Keywords

Created on 2013-04-16.17:59:40 by cjr, last changed by cjr.

msg435 (view) Author: cjr Date: 2013-05-18.20:08:34
I wonder if the code may have evolved this way due to churn in; in particular, with regard to the truth table factory

So I'll reassign this bug to you and you can fix it whenever.  It's
not critical to fix immediately.
msg434 (view) Author: christopher Date: 2013-05-18.19:33:55
Hey Claude,

This is pretty neat actually, some good catches! When I tested this initially I 
was only worried about when the GttGenerator thread itself was spawned.

Basically, the only reason I *think* I did this is because I was struggling with 
passing custom PyQt_PyObject's between threads (Note that GttGenerator is a 
QThread). I cannot remember the specific details and it was probably a 
workaround I did to just get it working when I was experimenting with threading.

The only other reason I can think of is that the TruthTable class was modified 
in some way and when I adapted changes I did not take this issue into account. I 
can't really make a case for this since I don't remember.

Either way you are right, It should be simple to pass the TruthTable directly in 
the SIGNAL and I will add it as soon as I get a chance, barring any issues in 
the thread implementation.

You definitely aren't missing anything. Spot on. The code on the receiving end 
is a bit obtuse now that I look at it. I think I can clean it up and generally 
make it easier to read.

Did I miss anything?
msg433 (view) Author: cjr Date: 2013-05-18.19:00:37
I'm following up on this question about whether the truth table might be being
generated twice.

One minor thing that I noticed in appears to be a redundant call to
TruthTableFactory() within GttGenerator.generateGtt:  There's one on line 781
and then another on line 794.

Setting that aside, I want to make sure that I'm understanding the programming
flow correctly.  There are two paths to generating a sufficiency concov table,
one by clicking "Reduce" and one by clicking "Truth Table" and then "Reduce".

On the first path (just clicking Reduce), the class SufConcovGeneratorNoGtt is
instantiated, and the truth table factory is instantiated at line 724.  This
seems fine and only instantiates the truth table factory once.

On the second path (clicking Truth Table and then Reduce), the class
GttGenerator is instantiated and then the truth table factory is instantiated at
line 781 (let's ignore the redundant ttf call on line 794).  The truth table is
then created on line 797.  What I don't understand about this function is why
the truth table is then coerced to a string representation on line 802.

Next, the SufConcovGeneratorFromGtt class is called with the string
representation of the truth table being passed in.  Then the generateConcov()
function recreates the truth table on line 652, taking the string representation
as input (and coercing it to a CSV-file object).  So it looks like the truth
table is being created twice.  Instead of coercing the truth table to a string
representation in GttGenerator, couldn't you just pass the truth table instance
directly into SufConcovGeneratorFromGtt.generateConcov() ?

It's quite possible that I'm misunderstanding something.
msg417 (view) Author: cjr Date: 2013-04-19.04:16:27
Ok.  I'm going to leave this bug open until I can confirm but reassign
it to myself.  I expect that you're right and that my test was
probably flawed, so don't worry about it until/unless I think that
something else is going on.
msg416 (view) Author: christopher Date: 2013-04-19.04:04:13
I can confirm that in the simple case you described, Kirq is not requesting a 
regeneration of any existing truth table.

My test case was simple and naive too. I put a print statement in on 
line 798.

This is where kirqlib would generally update the main ui with a status message 
and then call this code:

# ttf = TruthTableFactory()
tt = ttf.from_dataset(qcadata,

Because the print statement doesn't output whenever the gtt table exists, i'm 
fairly certain that in the case you describe and a few others I tested, it's not 
regenerated. I could be missing something though. Thanks.
msg413 (view) Author: cjr Date: 2013-04-16.17:59:40
It appears that Kirq is regenerating the truth table when it doesn't need to. 
Specifically: say that you've generated a truth table using the "Truth Table"
button.  If you then click the "Reduce" button, you shouldn't need to regenerate
the truth table; instead, Kirq can just use the existing one.  But it appears
that Kirq may be regenerating the truth table each time.

My testing for this is pretty quick and crude, so I'm not 100 percent positive
that this is occurring.  Can you confirm?

(Suf does generate the truth table anew each time, but that's because suf always
starts from the data set step.)
Date User Action Args
2013-05-18 20:08:35cjrsetassignedto: cjr -> christopher
messages: + msg435
2013-05-18 19:33:55christophersetmessages: + msg434
2013-05-18 19:00:37cjrsetmessages: + msg433
2013-04-19 04:16:27cjrsetassignedto: christopher -> cjr
messages: + msg417
2013-04-19 04:04:13christophersetstatus: unread -> chatting
messages: + msg416
2013-04-16 17:59:40cjrcreate