I started to wonder what is the difference between div and / so they are
2 separate symbols. div: Take a Integral divide and round (down) (/): Take a Fractional divide and usually round In some applications I would like to use any of those but it is not possible. Is this unification taken into account while reworking numeric classes? I.e. why not: class Num a => Divisable a where (/) :: a -> a -> a class (Real a, Enum a, Divisable a) => Integral a where quot :: a -> a -> a rem :: a -> a -> a div = (/) mod :: a -> a -> a x `quotRem` y = (x `quot` y, x `rem y) x `divMod` y = (x `div` y, x `mod` y) toInteger :: a -> Integer class Divisable a => Fractional a where recip = (1/) :: a -> a fromRational :: Rational -> a (Example does not take into account other refactoring) Regards PS. Why is Fd/cPid etc. Integral or even Num? What does (stdin + stderr) `mod` stdout mean (result will be stdin). _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe signature.asc (853 bytes) Download Attachment |
One might expect a == (a/b)*b and other common arithmetic formulas to
hold for division? /Jonas On 31 May 2010 14:32, Maciej Piechotka <[hidden email]> wrote: > I started to wonder what is the difference between div and / so they are > 2 separate symbols. > > div: > Take a Integral divide and round (down) > > (/): > Take a Fractional divide and usually round > > In some applications I would like to use any of those but it is not > possible. Is this unification taken into account while reworking numeric > classes? > > I.e. why not: > > class Num a => Divisable a where > (/) :: a -> a -> a > > class (Real a, Enum a, Divisable a) => Integral a where > quot :: a -> a -> a > rem :: a -> a -> a > div = (/) > mod :: a -> a -> a > x `quotRem` y = (x `quot` y, x `rem y) > x `divMod` y = (x `div` y, x `mod` y) > toInteger :: a -> Integer > > class Divisable a => Fractional a where > recip = (1/) :: a -> a > fromRational :: Rational -> a > > (Example does not take into account other refactoring) > > Regards > > PS. Why is Fd/cPid etc. Integral or even Num? > What does (stdin + stderr) `mod` stdout mean (result will be stdin). > > _______________________________________________ > Haskell-Cafe mailing list > [hidden email] > http://www.haskell.org/mailman/listinfo/haskell-cafe > > Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
On Tuesday 01 June 2010 20:26:55, Jonas Almström Duregård wrote:
> One might expect a == (a/b)*b and other common arithmetic formulas to > hold for division? > > /Jonas Better not if one's using Float or Double. _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Maciej Piechotka
> What does (stdin + stderr) `mod` stdout mean (result will be stdin).
In my GHCi (6.12.1) with System.IO, this fails because Handle is not a numeric type. What implementation are you using? The underlying object here is a Unix file descriptor, which is just a number. In that sense, stdin is 0, stdout is 1, and stderr is 2, so this would be (0 + 2) (mod 1) = 0. _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
On Jun 1, 2010, at 12:20 PM, Aaron D. Ball wrote: > The underlying object here is a Unix file descriptor, which is just a > number. In that sense, stdin is 0, stdout is 1, and stderr is 2, so > this would be (0 + 2) (mod 1) = 0 Every integer is 0 (mod 1). _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Daniel Fischer-4
>> One might expect a == (a/b)*b and other common arithmetic formulas to
>> hold for division? > Better not if one's using Float or Double. I figured someone would say that :) What about this one: round (a/b/c) == round (a/(b*c)) Of course this doesn't work on Integers... /J On 1 June 2010 21:08, Daniel Fischer <[hidden email]> wrote: > On Tuesday 01 June 2010 20:26:55, Jonas Almström Duregård wrote: >> One might expect a == (a/b)*b and other common arithmetic formulas to >> hold for division? >> >> /Jonas > > Better not if one's using Float or Double. > _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
On Tuesday 01 June 2010 22:40:51, Jonas Almström Duregård wrote:
> >> One might expect a == (a/b)*b and other common arithmetic formulas to > >> hold for division? > > > > Better not if one's using Float or Double. > > I figured someone would say that :) *g* > > What about this one: > round (a/b/c) == round (a/(b*c)) Don't know, we have (a `quot` b) `quot` c == a `quot` (b*c) for Integers (overflow may or may not break that for Int), so if (/) were truncating division for Integral types, we'd have that. I like the distinction between (/) and div (and quot), but I have no problem using (/) for integer division in Python, C, Java or C#. > > Of course this doesn't work on Integers... > > /J > > On 1 June 2010 21:08, Daniel Fischer <[hidden email]> wrote: > > On Tuesday 01 June 2010 20:26:55, Jonas Almström Duregård wrote: > >> One might expect a == (a/b)*b and other common arithmetic formulas to > >> hold for division? > >> > >> /Jonas > > > > Better not if one's using Float or Double. _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Jonas Almström Duregård
On Tue, 2010-06-01 at 22:40 +0200, Jonas Almström Duregård wrote:
> >> One might expect a == (a/b)*b and other common arithmetic formulas to > >> hold for division? > > > Better not if one's using Float or Double. > > I figured someone would say that :) > > What about this one: > round (a/b/c) == round (a/(b*c)) > > Of course this doesn't work on Integers... > division operator is well - useful. I don't think it would create much confusion. At least no more than IEEE standard. [1] By co I mean Ruby, Python, Perl and others. There are no so many languages that do recognize the difference. _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe signature.asc (853 bytes) Download Attachment |
In reply to this post by Aaron D. Ball-3
On Tue, 2010-06-01 at 15:20 -0400, Aaron D. Ball wrote:
> > > What does (stdin + stderr) `mod` stdout mean (result will be stdin). > > In my GHCi (6.12.1) with System.IO, this fails because Handle is not a > numeric type. What implementation are you using? Ups. I missed the Handle with Fd. Which does not change point significantly. Regards _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe signature.asc (853 bytes) Download Attachment |
In reply to this post by Maciej Piechotka
> [1] By co I mean Ruby, Python, Perl and others. There are no so many
> languages that do recognize the difference. % python -Q new Python 2.4.6 (#1, Aug 3 2009, 17:05:16) [GCC 4.0.1 (Apple Inc. build 5490)] on darwin Type "help", "copyright", "credits" or "license" for more information. 10 / 3 #-> 3.3333333333333335 10 // 3 #-> 3 The python guys decided that int/int -> int was a mistake, but because it's an incompatible change, the removal process has been long (hence the -Q flag, or a from __future__ import). In fact, I think they gave up on making it the default before python 3. I appreciate that haskell has differentiated from the beginning. _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
On Tue, 2010-06-01 at 15:29 -0700, Evan Laforge wrote:
> > [1] By co I mean Ruby, Python, Perl and others. There are no so many > > languages that do recognize the difference. > > % python -Q new > Python 2.4.6 (#1, Aug 3 2009, 17:05:16) > [GCC 4.0.1 (Apple Inc. build 5490)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > 10 / 3 > #-> 3.3333333333333335 > 10 // 3 > #-> 3 > > > The python guys decided that int/int -> int was a mistake, but because > it's an incompatible change, the removal process has been long (hence > the -Q flag, or a from __future__ import). In fact, I think they gave > up on making it the default before python 3. > > I appreciate that haskell has differentiated from the beginning. If you have something like that: instance ... => Distribution (Linear a) a where rand (Linear f s) g = let (gf, gt) = genRange g (v, g') = next g in (g', f + (fromIntegral v * s) / fromIntegral (gt - gf)) (I haven't check it but IMHO it is right implementation) Now I have following options: - Implement per Int/Int8/... - Implement IntegerLinear and FractionalLinear separatly Neither of choices are IMHO not ideal. Regards _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe signature.asc (853 bytes) Download Attachment |
On Wednesday 02 June 2010 00:55:08, Maciej Piechotka wrote:
> On Tue, 2010-06-01 at 15:29 -0700, Evan Laforge wrote: > > > [1] By co I mean Ruby, Python, Perl and others. There are no so many > > > languages that do recognize the difference. > > > > % python -Q new > > Python 2.4.6 (#1, Aug 3 2009, 17:05:16) > > [GCC 4.0.1 (Apple Inc. build 5490)] on darwin > > Type "help", "copyright", "credits" or "license" for more information. > > 10 / 3 > > #-> 3.3333333333333335 > > 10 // 3 > > #-> 3 > > > > > > The python guys decided that int/int -> int was a mistake, but because > > it's an incompatible change, the removal process has been long (hence > > the -Q flag, or a from __future__ import). In fact, I think they gave > > up on making it the default before python 3. > > > > I appreciate that haskell has differentiated from the beginning. > > Well - i tried to write some package dealing with distributions etc. > > If you have something like that: > > instance ... => Distribution (Linear a) a where > rand (Linear f s) g = > let (gf, gt) = genRange g > (v, g') = next g > in (g', f + (fromIntegral v * s) / fromIntegral (gt - gf)) > > (I haven't check it but IMHO it is right implementation) > > Now I have following options: > > - Implement per Int/Int8/... > - Implement IntegerLinear and FractionalLinear separatly - use realToFrac instead of fromIntegral (using the logfloat package is probably not a bad idea then) > > Neither of choices are IMHO not ideal. Methinks that is not what you wanted to say ;) > > Regards _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
On Wed, 2010-06-02 at 01:13 +0200, Daniel Fischer wrote:
> On Wednesday 02 June 2010 00:55:08, Maciej Piechotka wrote: > > On Tue, 2010-06-01 at 15:29 -0700, Evan Laforge wrote: > > > > [1] By co I mean Ruby, Python, Perl and others. There are no so many > > > > languages that do recognize the difference. > > > > > > % python -Q new > > > Python 2.4.6 (#1, Aug 3 2009, 17:05:16) > > > [GCC 4.0.1 (Apple Inc. build 5490)] on darwin > > > Type "help", "copyright", "credits" or "license" for more information. > > > 10 / 3 > > > #-> 3.3333333333333335 > > > 10 // 3 > > > #-> 3 > > > > > > > > > The python guys decided that int/int -> int was a mistake, but because > > > it's an incompatible change, the removal process has been long (hence > > > the -Q flag, or a from __future__ import). In fact, I think they gave > > > up on making it the default before python 3. > > > > > > I appreciate that haskell has differentiated from the beginning. > > > > Well - i tried to write some package dealing with distributions etc. > > > > If you have something like that: > > > > instance ... => Distribution (Linear a) a where > > rand (Linear f s) g = > > let (gf, gt) = genRange g > > (v, g') = next g > > in (g', f + (fromIntegral v * s) / fromIntegral (gt - gf)) > > > > (I haven't check it but IMHO it is right implementation) > > > > Now I have following options: > > > > - Implement per Int/Int8/... > > - Implement IntegerLinear and FractionalLinear separatly > > - use realToFrac instead of fromIntegral > (using the logfloat package is probably not a bad idea then) > which would make result Integral or left it as it is and having (Fractional a, Real a) constraint. > > > > Neither of choices are IMHO not ideal. > > Methinks that is not what you wanted to say ;) > Ups. Sorry - it's rather late and I'm not native speaker (and my native language do use double negation). "Neither of the choices are ideal IMHO". > > > > Regards > Regards _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe signature.asc (853 bytes) Download Attachment |
In reply to this post by Maciej Piechotka
On Jun 2, 2010, at 9:18 AM, Maciej Piechotka wrote: > > Hmm. C, Java & co.[1] seems to not have this problem. Languages that do recognise a difference between integer quotient-and-remainder and multiplicative inverse: - MATHEMATICS - Algol 60, Algol W, Algol 68 - BCPL (/ is integer division, #/ is float division) - Simula 67 - Smalltalk - O'CAML (/ is integer division, /. is float division) - Prolog (/ is float division, // is integer division) - Erlang (/ is float division, // is integer division) - Pascal (/ float, div integer) - Ada - Scheme - Common Lisp - Mathematica (x/y -vs- Quotient[x,y]) ... > Also having common division operator is well - useful. I would like to see some evidence for this. The confusion goes back to Fortran, and was marginally excusable back when 48 characters was considered enough in a character set. (PL/I was also designed to work in an alphabet of 48 characters; the Algols were not.) > > I don't think it would create much confusion. At least no more than > IEEE > standard. > > [1] By co I mean Ruby, Python, Perl and others. There are no so many > languages that do recognize the difference. We can put it another way: C-like languages have so *many* problems that this particular one does not stand out. For what applications is it "useful" to use the same symbol for operations obeying (or in the case of floating point operations, *approximating* operations obeying) distinct laws? _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
On Wed, 2010-06-02 at 14:01 +1200, Richard O'Keefe wrote:
> For what applications is it "useful" to use the same symbol > for operations obeying (or in the case of floating point > operations, *approximating* operations obeying) distinct laws? > > If the given operations do share something in common. For example * is usually commutative. However you do use it with quaternions (Hamilton product). You even write ij = k despite the fact that ji = -k. I gave the code which might have work for both Integral and Fractional but it is not possible to type it in Haskell. Although I wouldn't mind something like: class Num a => Divisable a where (./.) :: a -> a -> a class (Real a, Enum a, Divisable a) => Integral a where div = (./.) ... class Divisable a => Fractional a where (/) = (./.) ... (/ and div preserve their meaning, ./. is the generalized division) Regards _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe signature.asc (853 bytes) Download Attachment |
On Wed, 2 Jun 2010, Maciej Piechotka wrote: > On Wed, 2010-06-02 at 14:01 +1200, Richard O'Keefe wrote: >> For what applications is it "useful" to use the same symbol >> for operations obeying (or in the case of floating point >> operations, *approximating* operations obeying) distinct laws? > > If the given operations do share something in common. For example * is > usually commutative. However you do use it with quaternions (Hamilton > product). You even write ij = k despite the fact that ji = -k. I do not like to see the type class mechanism as a way to use common identifiers and symbols in as many as possible applications. Instead for me type classes are a way to write algorithms in a way that they can be used for many particular types. So far I had no algorithm that works equally well on integral 'div' and fractional '/'. Can you give me an example of an algorithm, where in one case instantiation to Integer and 'div' is sensible and in another case instantation to Rational and '/' is sensible? _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Maciej Piechotka
Sorry, I missed this post.
Maciej Piechotka schrieb: > Well - i tried to write some package dealing with distributions etc. > > If you have something like that: > > instance ... => Distribution (Linear a) a where > rand (Linear f s) g = > let (gf, gt) = genRange g > (v, g') = next g > in (g', f + (fromIntegral v * s) / fromIntegral (gt - gf)) > > (I haven't check it but IMHO it is right implementation) > > Now I have following options: > > - Implement per Int/Int8/... > - Implement IntegerLinear and FractionalLinear separatly That is, what you need is a general division with rounding. But you might more generally want a custom type class with a method that selects an element from a set for given parameters gf, gt, v. This way, you could also handle distributions on Enumeration types. You certainly you do not want, say a division operation on Monday, Tuesday, ..., Sunday, but having a probability distribution of weekdays is very reasonable. Btw. you may want to have a look at: http://hackage.haskell.org/package/probability _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Maciej Piechotka
On Jun 3, 2010, at 1:13 AM, Maciej Piechotka wrote: > On Wed, 2010-06-02 at 14:01 +1200, Richard O'Keefe wrote: >> For what applications is it "useful" to use the same symbol >> for operations obeying (or in the case of floating point >> operations, *approximating* operations obeying) distinct laws? >> >> > > If the given operations do share something in common. For example * is > usually commutative. However you do use it with quaternions (Hamilton > product). You even write ij = k despite the fact that ji = -k. I think you just made my point: Commutativity is NOT one of the standard properties that * is EXPECTED to possess. However, it IS one of the properties that + is expected to possess, which is why Java's abuse of + for string concatenation is so bad. > > I gave the code which might have work for both Integral and Fractional > but it is not possible to type it in Haskell. This is what you wrote: If you have something like that: instance ... => Distribution (Linear a) a where rand (Linear f s) g = let (gf, gt) = genRange g (v, g') = next g in (g', f + (fromIntegral v * s) / fromIntegral (gt - gf)) Since I don't know what Linear is or what Distribution is it's hard for me to tell exactly what this is supposed to do, but I'll take a stab at it. (Linear f s) specifies an interval by giving a starting point f and a width s; the interval specified is the half-open interval [f,f+s). genRange g returns (l,u) where l is the smallest Int that g can return and u is the largest Int that g can return; these are INCLUSIVE bounds so the number of values to consider is u-l+1. For StdGen the bounds are (0,2147483562) Let's just see what would happen if - we used this code - g was an instance of StdGen - f was 0 :: Int - s was 1000000 :: Int next g --> (1079700,g') -- actual run fromIntegral 1079700 * 1000000 = 1079700000000 = 1663208704 :: Int 1663208704 `div` fromIntegral (2147483562 - 0) :: Int == 0 In fact almost all the answers you get will be 0. If f and s are of any bounded integral type, this is NOT going to do anything useful. And it's NOT because / is not aliased to div. It's because multiplication overflows. If you look at the Int and Double instance of Random in the Random.hs that comes with Hugs, you'll see they use different code. It's not because of any problem with / per se but because they need genuinely different algorithms. _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
Richard O'Keefe schrieb:
> > On Jun 3, 2010, at 1:13 AM, Maciej Piechotka wrote: > >> On Wed, 2010-06-02 at 14:01 +1200, Richard O'Keefe wrote: >>> For what applications is it "useful" to use the same symbol >>> for operations obeying (or in the case of floating point >>> operations, *approximating* operations obeying) distinct laws? >>> >>> >> >> If the given operations do share something in common. For example * is >> usually commutative. However you do use it with quaternions (Hamilton >> product). You even write ij = k despite the fact that ji = -k. > > I think you just made my point: Commutativity is NOT one of the standard > properties that * is EXPECTED to possess. However, it IS one of the > properties that + is expected to possess, which is why Java's abuse of > + for string concatenation is so bad. Java's (+) is not even associative: ("text" + 2) + 3 = "text23" "text" + (2+3) = "text5" _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Richard A. O'Keefe
On Thu, 2010-06-03 at 12:44 +1200, Richard O'Keefe wrote:
> On Jun 3, 2010, at 1:13 AM, Maciej Piechotka wrote: > > > On Wed, 2010-06-02 at 14:01 +1200, Richard O'Keefe wrote: > >> For what applications is it "useful" to use the same symbol > >> for operations obeying (or in the case of floating point > >> operations, *approximating* operations obeying) distinct laws? > >> > >> > > > > If the given operations do share something in common. For example * is > > usually commutative. However you do use it with quaternions (Hamilton > > product). You even write ij = k despite the fact that ji = -k. > > I think you just made my point: Commutativity is NOT one of the > standard > properties that * is EXPECTED to possess. speaking about people who deal with Mathematics - I mean 'average person' and 'average programmer'). > If you look at the Int and Double instance of Random in > the Random.hs that comes with Hugs, you'll see they use > different code. It's not because of any problem with / > per se but because they need genuinely different algorithms. > > Point taken. Regards _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe signature.asc (853 bytes) Download Attachment |
Free forum by Nabble | Edit this page |