Title (Kirq) Gtt instances in session/history
Priority bug Status chatting
Superseder Nosy List christopher, cjr
Assigned To christopher Keywords

Created on 2011-08-15.18:53:02 by cjr, last changed by cjr.

msg281 (view) Author: cjr Date: 2012-01-25.03:15:18
Appending is what I intended, for the reason you state.  It would be
nice to clean up the formatting a bit.  It may also be that we'll want
to include some other information in the lineage record.  This is
stuff that we'll figure out as we work with the software.
msg280 (view) Author: christopher Date: 2012-01-25.02:33:51
Maybe I am slightly confused about the requirement.

If a subsequent analysis yields the same table, would you prefer to
overwrite or append to the lineage? I guess appending would make sense
that way the user can view all the conditions which led to the table.

I can deal with the timestamp no problem. Would also be nice to spruce
up the formatting to make it a bit more readable.
msg279 (view) Author: cjr Date: 2012-01-25.02:17:08
Sorry for the delay in responding.  I like what I see, although on my
system it appear to only be recording the first call.  Since we've had
some problems with my build system (which I haven't yet tracked down),
I'm wondering if the problem might only be on my end?

I like the name "lineage" for the feature.  The one addition that I
would make would be to prefix each entry with a timestamp, which will
provide a useful way of distinguishing entries from each other.
msg278 (view) Author: christopher Date: 2012-01-23.00:51:53
Ok, I have pushed a potential fix which implements your suggestion.

If you right click on a history item you will see an action called
"lineage". This is a dialog which pops up all the relevant information
under which a table was created. Hence, lineage. (We can change what
its called if you would like.)

I have left this as a very basic implementation on purpose. We can
format the text and the dialog however you want. Also, we can add any
items to the lineage which you feel are relevant. I just want to make
sure you feel like this is what you want before I commit anymore time
to improving it.
msg239 (view) Author: cjr Date: 2011-12-13.23:06:53
I just reread your last message regarding this issue and think that I finally
understand what you're saying.  In fact, we have the same issue with regard to
the data set--if a user goes back and changes which causal conditions are
included, the new truth table is appended under the original data set (since,
per my specification, a data set instance is defined by data set and outcome). 
And that is the correct behavior (at least for the data sets).

We've got two conflicting issues here.  On the one hand, we want to eliminate
duplicate truth tables and concov tables from the session.  We currently have
that in place--if a duplicated truth table or concov table would be created, we
simply jump to the existing table.  I don't want to lose this--I think it's a
huge benefit of Kirq.

But we also need the ability to map truth tables and concov tables back onto the
data set or truth table that generated them.  For sufficiency concov tables,
this is relatively simple as the only way that the parental truth table can
change is with regard to the coding of the outcome column and the simplification
level.  For necessity concov tables and for truth tables, however, this is more
complicated--there are different causal conditions that can be included and the
analysis parameters can change as well.

I'm open to different ideas here.  One that comes to mind--could we append a
history attribute to the gtt and concov instances?  This history attribute would
list each (possibly unique) action that generated this particular table (I'm not
sure if we'd want to eliminate duplicate attempts or not).  Perhaps the history
entries would simply be the parent table(s) that generated this particular
table; to inspect the parent table, the user could open it as a child window (in
the same manner that Kirq's session already permits).  We'd need to come up with
some naming convention for these tables, but that shouldn't be too bad.

I'm not sure that this is the best solution; it's just what comes to mind at the
msg154 (view) Author: christopher Date: 2011-08-15.22:31:25
I understand what you are saying and I understand the problem. However, this is not such a 
simple fix for a variety of reasons. By the way, the numbers after suf_concov_<> are indicative 
of the simplification level (keep that in mind below).

The only way to truly tell if there is another truth table in the history that is not identical 
is to look at its outcome column at that point in time and match it with the other truth 
table's outcome columns. The fact that the outcome column can be edited creates an inherent 
flaw in keeping unique truth tables. When you change an outcome column that outcome is 
committed back to the truth table. By continuing to append new truth tables based on a single 
or multiple changes in the outcome would introduce a lot of conflicts. We would end up with 
multiple matching tables at any point if someone didn't reduce a truth table right away or even 
if they did (not to mention we end up with a duplicate truth table every time we change an 
outcome and reduce). I think this would cause a lot of confusion to the user because there is 
no way to tell if the truth table that you are looking at is the one that created its children. 

I think that a good temporary solution is that if we reduce a modified truth table (modified 
from its original state) we should tags the resulting concov history item so that it is visible 
what outcomes were changed. For example a suf_concov_2 that had a modified outcome would become 
"suf_concov_2 -- row2 => True" (Maybe this isn't the best example but you know what I mean!). 
This is what we do for data sets.

I agree that there is a problem, but I think its more of a design issue than a bug. The design 
issue being that Gtt does not have static content. The bug is in the fact that the user doesn't 
know whether or not outcomes were changed to result in the concov table they are viewing. This 
is different from data sets in the fact that with data set we are only interested in appending 
new values for 1 causal condition.

There is more to this problem but I hope I think I touched on enough of it for now. I can 
explain this better in person if you wish.
msg151 (view) Author: cjr Date: 2011-08-15.18:53:02
Let's say that you have a truth table (gtt_suf1) and reduce.  The corresponding
concov table will be called something like "concov_suf_2".  That works as it should.

Now you go back to the truth table (gtt_suf1) and edit some of the outcome cells
to generate a new concov table.  The resulting concov table will also be called
"concov_suf_2" and attached to the same truth table instance (gtt_suf1).

I think that there are two intermingled issues here.  The obvious one is that
the new concov table should have a unique name.  But the other is that if the
truth table has been edited, Kirq should create a new truth table instance in
the session history.  If the second issue is fixed, I expect that it will also
fix this first issue.

I suspect that the solution is the same as what we used for recording the
dataset/outcome instance--record the truth table instance to the session when
generating the concov table, not when the truth table is created.  (And it
appears that saving a session takes a snapshot of the Kirq's current state such
that the current dataset/outcome is saved even if a truth table hasn't been
generated yet.  This is very nice.  I assume that this will also work for saving
truth tables?)
Date User Action Args
2012-01-25 03:15:18cjrsetmessages: + msg281
2012-01-25 02:33:52christophersetmessages: + msg280
2012-01-25 02:17:08cjrsetmessages: + msg279
2012-01-23 00:51:54christophersetmessages: + msg278
2011-12-13 23:06:53cjrsetmessages: + msg239
2011-08-15 22:31:25christophersetstatus: unread -> chatting
messages: + msg154
2011-08-15 18:53:03cjrcreate