This page is part of the web mail archives of SRFI 77 from before July 7th, 2015. The new archives for SRFI 77 contain all messages, not just those from before July 7th, 2015.
Thank you for the stories, Brad. Bradley Lucier <lucier@xxxxxxxxxxxxxxx> wrote: > Since you say so, I believe that the challenge, given your > constraints, is to avoid overflow, but I don't know why. Because that reference implementation is intended to run in R5RS-conforming implementations, and the R5RS doesn't require exact integer arithmetic of unbounded precision, and doesn't guarantee any behavior on which I could rely had I allowed intermediate results to overflow. > Your routine also assumes the availability of r5rs:*, but not, > presumably, r5rs:modulus; that fixnum-div0+mod0 was written before, > and not needing, fixnum*/2; and that you'd prefer to manipulate bit > fields (which I presume you're doing, since I presume that *half- > modulus*, etc., are powers of two) using fixnum-div0+mod0 instead of > using shifts and logical operations, etc. > > As these constraints seem to me very artificial, I do not find this > application of, or need for, fixnum-div0+mod0 compelling. I didn't claim it was a "compelling" application. You had written that "div0 and mod0...are useful in no algorithms of which I am aware." My goal was to make you aware of a use. I also attempted to explain a rationale. That attempt did use the word "compelling". Will