search

ThatGeoGuy / chicken-miniKanren

Packages the canonical miniKanren implementation for CHICKEN Scheme (http://call-cc.org)
Other
10 stars 2 forks source link

Floating-point arithmetic #3

Open MostAwesomeDude opened 1 year ago

MostAwesomeDude commented 1 year ago

I'm currently exploring implementing Relational Floating-Point Arithmetic on top of this module. Would this be welcome as an upstream contribution? What kind of code style would be expected? Could extra operations like square-root, trigonometric functions, exponential functions, etc. be added, even though they aren't in the paper?

I'll note that my experiments are using symbols for special values, mostly to avoid Boolean blindness; I give the zeroes and infinities as (pos zero), (pos inf), (neg zero), and (neg inf). Otherwise, all of the technical choices made in the paper seem sound.

My motivation is abstract interpretation and relational interpretation of pure functions, particularly raytracers. By turning the precision down to less than five bits (say, two or three bits) it becomes practical to explore output spaces, run computations backwards, etc.

ThatGeoGuy commented 1 year ago

Hi @MostAwesomeDude: This sounds like a great contribution for the library. A few logistics up front:

  1. I don't have CI set up on this repo, and I'm not really familiar with GitHub Actions. I've debated moving this repository and the egg itself to GitLab, but I haven't felt a compelling need to do so (since I'm the only contributor for this egg currently, I just run tests locally). I probably won't do it right this moment if you have something prepared.
  2. I'd want to be sure that there's a set of tests we could run to be sure that these are working as intended. That doesn't necessarily mean they have to match the paper 1:1 (e.g. on the topic of pos / neg / zero), but the tests can be useful for understanding how the code should be used.
  3. I might ask that we prefix everything related to floating-point with fp-, including pos, neg, etc. This is purely stylistic, and mostly to separate from what's in mk-numbers.scm. It might make sense to just place all this work in a new file mk-floating.scm assuming you don't have to modify any existing code.
  4. Licensing: Would you be okay releasing this under the MIT license? I can't change the license since the upstream code is technically owned by Will Byrd et al., but I want to be sure you don't have a problem with the egg's licensing if you undertake this work. I'd prefer to keep all the code uniformly licensed if possible so that there isn't confusion downstream when users use the mini-Kanren egg.

Aside from that, I don't have strong opinions on style. I tend to use the default indentation setup from https://foldling.org/git/vim-scheme.git/ for vim. I understand emacs has some different defaults, but I'm not too picky. Try to keep it within 80-100 columns, roughly? The unfortunate bit with Scheme is that we don't have a good linter / formatter that the community holds as canon, so I can't make hard recommendations.

MostAwesomeDude commented 1 year ago

Cool! Thanks for the information. I've started hacking here. While this repository is licensed as AGPLv3, I expressly permit you (and other onlookers) to transcribe code from this module with your preferred style and call it MIT-licensed. (So that you don't have to wait for my PR if you (or onlookers) feel motivated to work on this!)

On (2), I don't mind writing a few unit tests. I also don't mind writing some property tests, which I think work nicely with relational approaches. I've found that getting branch coverage (conde coverage, basically) is enough.

On (3), agreed that a namespace of some sort would be good. I'm using "fp-" for now.