Sent from my moss-covered three-handled family gradunza
> On Jan 15, 2017, at 5:29 PM, Xiaodi Wu <[email protected]> wrote: > >> On Sun, Jan 15, 2017 at 7:24 PM, Dave Abrahams <[email protected]> wrote: >> >> on Sun Jan 15 2017, Xiaodi Wu <xiaodi.wu-AT-gmail.com> wrote: >> >> > On Sun, Jan 15, 2017 at 6:42 PM, David Sweeris <[email protected]> wrote: >> > >> >> >> >> >> >> >> >> >> >> On Jan 15, 2017, at 18:02, Xiaodi Wu <[email protected]> wrote: >> >> >> >> "Mathematically correct" integers behave just like Int in that there is >> >> not a multiplicative inverse. What we're trying to do here is to determine >> >> how much of what we know about mathematics is usefully modeled in the >> >> standard library. The answer is not zero, because there is more than just >> >> counting that people do with integers. >> >> >> >> >> >> It's an interesting problem... When I was in school, "integer" division >> >> "returned" a "quotient and remainder", a "fraction" (which, occasionally, >> >> could be simplified to just an integer), or a "real". We never talked >> >> about >> >> division in the context of "(Int, Int) -> Int", though. OTOH, I never took >> >> any math classes past Differential Equations or Linear Algebra, either... >> >> I'm *aware* of areas of math where you formally restrict yourself to the >> >> kind of "(Int, Int) -> Int" operations we're doing here, but I don't >> >> really know much about it. Is division even well-defined in that context? >> >> >> >> - Dave Sweeris >> >> >> > >> > I'm no mathematician, and I'm not sure how to tackle the question of >> > "well-defined." Hopefully someone who is more knowledgable can chime in >> > here. >> > >> > But I'll have a go at replying to your point as it relates to the practical >> > issue here. Two Int values can be "divided" to produce another Int, and >> > that gives a predictable and well-understood result. It's an operation >> > that's always going to be there--first, because it'd be insane to remove it >> > since much working code relies on it, and second, because we're only >> > re-designing integer protocols and not the concrete types. However, it _is_ >> > true that such an operation has very different semantics from division as >> > you learned it in math. >> > >> > This is why I'm advocating for perhaps another look at the top of this >> > integer protocol hierarchy. At the moment, `Arithmetic` offers reasonable >> > semantic guarantees for a lot of things, but `/` has different semantics >> > for integer types and floating point types >> >> Well, that really depends on how closely you look. From one >> point-of-view, floating point division and integer division *both* >> produce approximate results. > > Yes, from a certain point of view. I remember we did discuss this at one > point on the list; I asked whether FloatingPoint was meant to model only the > countable set of representable values or whether it was meant to model the > uncountable set of reals. The answer was that here in Swift-land we're trying > to model the latter, and the approximate result is an artifact of the > imperfect modeling. Integer division, however, is not such an artifact, but > fundamentally a different operation. That's right. Thanks for keeping us honest and reminding us of our guiding stars. 👌🏻 >> > and is really closer to just syntax. Other mathematical types--which >> > certainly the stdlib doesn't have to offer, but the stdlib protocol >> > hierarchy shouldn't preclude their conformance to relevant protocols >> > if it's possible--such as fractions and complex numbers, share with >> > floating point types the semantics of `/` that qualify these types as >> > fields. Dave A's question as to practical uses can probably best be >> > answered in this way: to the extent that any generic algorithm relies >> > on `/` having semantics and can be applied to fractions and real >> > numbers, it would be useful to distinguish such an operation from >> > integer "division." >> >> That's not a bad answer. Ruminating on this... >> >> -- >> -Dave >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
