ccshan
2018-7-8 10:27:42

ccshan
2018-7-8 10:28:42

It seems easy to run PSI to beef up our exact-inference evaluation. Is it easy for me to log onto your machine so that I can run on the same hardware as you?


rjnw
2018-7-8 14:35:58

@ccshan the hakaru code for likelihood returns a Prob type and I use log from our LogFloatPrelude. So it is log of likelihood right?


rjnw
2018-7-8 14:39:35

For AugurV2 update time, can I divide sweep time by total updates? (JAGS is calculated the same way)


ccshan
2018-7-8 15:50:48

Yes and yes, thanks!


rjnw
2018-7-8 19:00:38

rjnw
2018-7-8 19:01:15

Augur every 100 sweeps Hakaru every sweep. Jags second sweep is at 500


ccshan
2018-7-8 19:55:52

I like this picture. By “JAGS seconds sweep is at 500”, do you mean it takes 500 seconds for JAGS to do one sweep? Would you please change the horizontal axis label to "Time in seconds” and make another plot for “Log likelihood”?


rjnw
2018-7-9 01:27:13

Yes JAGS takes ~500 seconds for one full update.


rjnw
2018-7-9 01:29:04

A mistake in this graph, when removing warmup time I also removed the 500 seconds for the first update. Or should I count that as warmup? I am not really sure so for now this has outcome of first sweep at time0 for all three.


ccshan
2018-7-9 01:36:18

I’m ok with having “outcome of first sweep at time0 for all three”, but is that the case for LLVM-backend, since you measured updates within a sweep for it?


rjnw
2018-7-9 03:12:50

Oh yeah I forgot about that


rjnw
2018-7-9 03:13:06

Oh in NaiveBayes I don’t do that


rjnw
2018-7-9 03:13:15

It’s only in LDA


ccshan
2018-7-9 03:44:17

Being consistent in this regard (across curves and benchmarks) would help the writing a lot.


rjnw
2018-7-9 03:52:26

The problem with NaiveBayes and JAGS is the 500 second sweep time with ~3hr startup.


ccshan
2018-7-9 04:08:58

How about being consistent in the following way? In every plot, the horizontal axis is seconds after startup. Startup is defined by the table. So “time 0” on each curve is always the time after the startup as listed in the table.


rjnw
2018-7-9 04:11:32

Okay, that sounds good to me. Gmm and NaiveBayes already follow that rule.


rjnw
2018-7-9 05:01:03

I am trying to change the vertical axis range for naive bayes accuracy. If I do 45–85 there is no place for legend.


rjnw
2018-7-9 05:01:13

rjnw
2018-7-9 05:14:03

@ccshan I have psi running on my machine how do you want to run the code you committed?


rjnw
2018-7-9 05:14:25

I tried just giving the file name to psi it’s feels like stuck.


ccshan
2018-7-9 05:15:04

Maybe it’s stuck because it is :notes:slow:notes:


ccshan
2018-7-9 05:15:16

Change n from 100 to 10?


rjnw
2018-7-9 05:16:22

yeah that works.


rjnw
2018-7-9 05:16:48
~/w/h/o/psi > time ./psi ../../testcode/psisrc/clinicalTrial.psi
p(isEffective) = 4199/10007·δ(1)[isEffective]+5808/10007·δ(0)[isEffective]
1.62user 0.02system 0:01.64elapsed 99%CPU (0avgtext+0avgdata 61024maxresident)k
0inputs+0outputs (0major+13175minor)pagefaults 0swaps

ccshan
2018-7-9 05:26:52

So if for each of the two exact inference benchmarks you could make a plot of time in seconds versus data size, just for PSI, that’s be great


ccshan
2018-7-9 05:27:34

Of course there’s trade-off in how many times you run each n (resulting in smaller error bars) vs how large n you get to


ccshan
2018-7-9 05:28:28

And maybe in the spirit of up=better, the horizontal axes should be time in seconds and the vertical axes should be data size.