Re: why infix:div:(Int, Int -- Rat)
On 2008-Dec-4, at 3:08 pm, Mark J. Reed wrote: Using div instead of / should make it pretty clear that you're disposing of the remainder. I misremembered div vs. idiv, but how standard is it? I know div commonly means int division, but not always. On the one hand, some things you just have to learn; on the other, lots of P6 operators have word-names as well as symbols, and div is the obvious way to spell / (what else would you call it?). A way to get both [quotient and reminder] in one fell swoop would be nice Agreed; though having two different operators seems a bit unperlish. Int-div could return two values, but that seems prone to accidentally interpolating unwanted remainders into lists or things like that. Would it make sense to include the remainder as a trait on the quotient? Or return some other special compound type that numifies to the quotient. -David
Re: why infix:div:(Int, Int -- Rat)
On Fri, Dec 5, 2008 at 9:10 AM, David Green [EMAIL PROTECTED] wrote: I misremembered div vs. idiv, but how standard is it? I know div commonly means int division, but not always. True enough. In ANSI C, / already does integer division, but there's also a div() function - the difference there is that div() is guaranteed to round toward zero, whereas the rounding semantics of / is implementation-dependent. On the one hand, some things you just have to learn; on the other, lots of P6 operators have word-names as well as symbols, and div is the obvious way to spell / (what else would you call it?). Well, respelling it is OK, just not sure how. Python 3 uses // for integer division, but we don't want to open up that can of worms again.. A way to get both [quotient and reminder] in one fell swoop would be nice Would it make sense to include the remainder as a trait on the quotient? Maybe, but it smacks of the old and smelly 0 but true type hacks to me. Or return some other special compound type that numifies to the quotient. There could be a special-purpose Quotient type with the desired behavior, but maybe Perl6 would benefit from a generic stealth list type, like Lisp's multiple values. Such an object behaves like a simple scalar, even in list context, but if you use the right methods you can access additional values beyond the obvious one. -- Mark J. Reed [EMAIL PROTECTED]
Re: why infix:div:(Int, Int -- Rat)
HaloO, Mark J. Reed wrote: Well, respelling it is OK, just not sure how. Python 3 uses // for integer division, but we don't want to open up that can of worms again.. We still haven't used '÷' which is Latin1. But if we use that it should be as infix:÷:(Int, Int -- Rat) because this doesn't need to be accompanied with a mod. That allows div on two Ints to return an Int which complies to the general prescription for overloading div and mod homogenously. Regards, TSa. -- The unavoidable price of reliability is simplicity -- C.A.R. Hoare Simplicity does not precede complexity, but follows it. -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: why infix:div:(Int, Int -- Rat)
HaloO, David Green wrote: On 2008-Dec-4, at 3:08 pm, Mark J. Reed wrote: Using div instead of / should make it pretty clear that you're disposing of the remainder. I strongly agree to that. Actually you are disposing of the fractional part. I misremembered div vs. idiv, but how standard is it? IIRC, that was in the discussion about the euclidean modulo operation. The final outcome at the time was to have floor semantics by default. I know div commonly means int division, but not always. On the one hand, some things you just have to learn; on the other, lots of P6 operators have word-names as well as symbols, and div is the obvious way to spell / (what else would you call it?). It's not only the name that is at stake but the rest of the specification of the div and mod pair. It is specced to be type specific. E.g. if one implements the Gaussian integers---that is complex numbers with integer coordinates---I would expect div to be *closed* on that type and not lead out of the type as it is prescribed in the Int case. In general I would expect that a type Foo that supports a notion of division implements div and mod with signature :(Foo, Foo -- Foo). Note that the wording of the spec enforces infix:/:(Num,Complex--Num) instead of infix:/:(Num,Complex--Complex) and I wonder how a Complex is numified. This should be changed, too. The mixed signature cases of div and mod should return the larger of the two types. E.g. :(Rat, Int -- Rat) and :(Num, Int -- Num) as long as Num can hold the result. Does Num in general failover to Rat? A way to get both [quotient and reminder] in one fell swoop would be nice Agreed; though having two different operators seems a bit unperlish. We have the pair of infix (!) operators min, max and the operator minmax that delivers both values in one go. Copying that prior art would simply mean to define divmod. I'm fine with that. Regards, TSa. -- The unavoidable price of reliability is simplicity -- C.A.R. Hoare Simplicity does not precede complexity, but follows it. -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
why infix:div:(Int, Int -- Rat)
HaloO, I realized from the typed literal thread that S03 now explicitly states that div on two Ints returns a Rat. I remember the state of affairs being that it returns an Int that adheres to the division of an Int $y by another Int $x such that $y == ($y div $x) * $x + ($y mod $x) holds with floor semantics as the default. This is now not the case anymore. Why? Isn't the special handling of integer division by infix:/ enough? There the result becomes a Num only if needed such that it preserves precision as long as possible. Question: does such a 'Num but Rat' type dispatch to the Rat versions of operators? Regards, TSa. -- The unavoidable price of reliability is simplicity -- C.A.R. Hoare Simplicity does not precede complexity, but follows it. -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: why infix:div:(Int, Int -- Rat)
On 2008-Dec-4, at 9:42 am, TSa wrote: I remember the state of affairs being that [div] returns an Int Something more explicit like idiv was suggested for integral division. Personally, I'm happy not to have anything special provided for it, on the grounds that having to say, e.g. floor($i/$j), forces you to be blatantly clear that you're disposing of the remainder and how. -David
Re: why infix:div:(Int, Int -- Rat)
On Thu, Dec 4, 2008 at 3:26 PM, David Green [EMAIL PROTECTED] wrote: Something more explicit like idiv was suggested for integral division. Personally, I'm happy not to have anything special provided for it, on the grounds that having to say, e.g. floor($i/$j), forces you to be blatantly clear that you're disposing of the remainder and how. Using div instead of / should make it pretty clear that you're disposing of the remainder. The sorts of calculations that involve heavy use of integer quotients typically also involve heavy use of the remainders, and it's only reasonable that both halves be treated with equal respect in terms of language support. A way to get both in one fell swoop would be nice (e.g. Ruby's Integer#divmod), but at the very least, if we have mod (%), we should have div, too. -- Mark J. Reed [EMAIL PROTECTED]
