Show HN: A deterministic I Ching engine, cross-validated against another impl https://ift.tt/Yj2AvkE

Show HN: A deterministic I Ching engine, cross-validated against another impl I built a deterministic engine for I Ching (六爻 / Liu Yao) hexagram casting and open-sourced the core (Apache-2.0). I want to be upfront that the interesting part here is not the divination — it's a testing problem, and I'd like feedback on how I handled it. The engine takes a moment in time plus a coin toss and mechanically derives a fully annotated chart: the hexagram, its palace, the stem-branch (najia) assignments, the "six relatives," moving lines, void days, and the line-strength skeleton. It does not interpret anything — it only emits hard, mechanical facts. The problem that made this interesting: the rules are ~3000 years old, written in classical Chinese, and different schools contradict each other. There is no official answer key, and human experts disagree and are sometimes wrong. So the tests I'd naturally write just encode the same assumptions my code does — if I misread a rule, the code and its test are wrong together and both stay green. The self-validation paradox. My way out was differential testing against independent oracles. I diff every field of the chart against `najia` (a separate MIT implementation) and a second machine-readable rule table, over random-but-seeded samples in CI. A field is only trusted when all three agree. The calendar layer (which is zero-tolerance — a day-pillar off by one silently corrupts everything downstream) gets its own diff, sxtwl vs lunar-python, focused on the nasty boundaries: solar-term month divisions, the 23:00 day change, and cross-timezone casting. That principle ended up driving the design: anything that can't be independently cross-validated doesn't enter the core. That's why the traditional "auspicious stars" (神煞), true-solar-time correction, and school-mixing are all deliberately excluded — not because they're "wrong," but because I have no way to prove the code computes them correctly. I'm in UTC+8 (China) so replies from me may lag by a few hours during your daytime — but I'll be around all day when I'm awake. Happy to go deep on any of it. https://ift.tt/noM3rjF July 11, 2026 at 01:24AM