[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.

*To*: sebastian.egner@xxxxxxxxxxx, srfi-77@xxxxxxxxxxxxxxxxx*Subject*: Re: Integer residue-classes [was: Questions about srfi-77 Generic Arithmetic]*From*: William D Clinger <will@xxxxxxxxxxx>*Date*: Tue, 21 Feb 2006 12:39:44 -0500*Cc*: will@xxxxxxxxxxx*Delivered-to*: srfi-77@xxxxxxxxxxxxxxxxx

Dr Sebastian Egner wrote: > Will wrote: > > Denying the ad hockitude doesn't make it go away. > > [...] > > I therefore raise this as an issue: Should we choose the > > representatives based on the sign of the second argument, > > as in Egner et al and in SRFI 77, or should we redefine > > div and mod to choose the representatives consistently in > > all cases, and define a second pair of procedures that use > > the second most important choice of representatives? > > I would really appreciate if you read my posting before you > repeat parts of it in a rather annoying and personal fashion, > and put them forward as your own inventions. I'm sorry, Sebastian, but the idea of defining a second pair of Scheme procedures was so obvious that it entered even my mind as soon as I understood Dr Lucier's objection, which was several days before you mentioned the idea in your recent post. I admit to being annoyed by your up-front denial ("No, it is not "ad hoc.") coupled with your later admission, buried as it was within all the number-theoretic background. ("Of course there is no mathematical need for using the sign of the modulus in this way---and in this sense this choice is 'ad hoc.') When you finally admitted the ad hockitude, you immediately said "But it turns out to be useful." The only argument you ever gave against the separate procedures and in favor of the ad hockitude was this: > This makes the system > of representatives a static property of the program, > but I doubt that this is helpful in any way. The down > side is that there is no representation readily available > for the choice of system of representives. That first sentence was not very convincing. I don't know what you meant by the second sentence, so it just went over my head. > And, yes, I do understand "Dr. Lucier's objection" and it > is not worth a lot, as I explained. Brad had two objections. You don't seem to understand his objection to the ad hockitude of using an argument's sign to select between two sets of representatives. Brad's other objection is that the general property you want, that "x ~ y <=> m divides (x - y)" where m is the modulus, uses the notion of "divides" that is usually defined to mean there exists an integer n such that n*m=(x-y). That is why you made an exception to that property for m=0, "for reasons that will become clear later." You did explain later, and I accept your explanation as an argument for having (div q 0) return 0. Unfortunately, you dismissed Brad's objection as a "reflex" and wrote that he "confuses residue-class operation 'div' with the *field* operation '/'." As I explained in the paragraph immediately above this one, Brad's objection was indeed based on the usual number-theoretic definition that you yourself cited. For you to attribute his objection to mathematical incompetence in "a rather annoying and personal fashion" was rather annoying. > > The background material you provided will help me to explain > > how little is at stake here to those who are wondering > > what this is about, and I thank you for that. > > I see. You are probably right, discussing this with you > is indeed a waste of my time. > > Sincerely, > > Dr. Egner Thank you for wasting your time with us. Will

- Prev by Date:
**unsubscribe** - Next by Date:
**div and mod.** - Previous by thread:
**Re: Integer residue-classes** - Next by thread:
**Re: Integer residue-classes [was: Questions about srfi-77 Generic Arithmetic]** - Index(es):