Chung-chieh Shan

(As discussed at f37339ecadbdd1d52e0ede74fe1b543c73e0b929)

I don't mind at all the different nesting of `weight` and `if`, but it's too bad that the `` in `t63.expected` (summing two measures over `unit`) does not go away...

Yeah, Section 3 of ppaml/writing/multi.tex should document this pipeline. It welcomes your feedback.

Regarding the output of simplifying `t62.expected.hk`: I agree that the result is buggy and I agree that the `signum` is weird but it doesn't seem to me that the generated...

To elaborate on my "concern": * If `x1=0` and `x0=42` (say), and if `signum(0)` returns zero (or a positive number), and if I'm thinking correctly, then the program `t62.expected.hk` before...

Maybe it's worth telling Maplesoft about this `solve` bug?

The `Prob` type synonym was added to `Language.Hakaru.Runtime.LogFloatPrelude` and `Language.Hakaru.Runtime.Prelude` in 772a9860fdd07468ac525da1ad4cc402ae941e13, then used in 1509e85651e491bf4458e24c0142807ff501e506. Neither of these commits is in `v0.4`. Would you please clarify which version you're...

I agree that all 3 occurrences of `product` in https://github.com/hakaru-dev/tcp/blob/11a5498f9fd2f05838d9d39470e7a242819fb4d9/src/LDA/lda_simp.hk under `categorical` should `simplify` away, because if `d == ...` is false then the body of the `product` is `1`....

I forgot to say: In order to fire, the rewrite in `eval_piecewise` (line 76 onward in `NewSLO/Piecewise.mpl`) needs to know that the value that the loop variable `d` is compared...

@JacquesCarette, I'm not sure why you're talking about the variable name `in`, because I don't see it used or generated anywhere...?