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.

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 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.

[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.

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

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

On Thu, 3 Jun 2010, Maciej Piechotka wrote:

Hmm. Thanks - however I fail to figure out how to do something like:

"generate a random number with normal distribution with average avg and standard deviation stdev".

Unfortunately the package is restricted to discrete distributions so far.

On Thu, 2010-06-03 at 06:48 -0700, mokus@deepbondi.net wrote:

...

On Thu, 3 Jun 2010, Maciej Piechotka wrote:

...

Hmm. Thanks - however I fail to figure out how to do something like:

"generate a random number with normal distribution with average avg and standard deviation stdev".

Unfortunately the package is restricted to discrete distributions so far.

Shameless self-advertisement: The random-fu package (whimsically named, sorry) implements a modest variety of continuous distributions with what I believe to be a user-friendly and flexible interface.

This thread inspired me to finish up and upload the 0.1 release (just announced on haskell-cafe as well). The public interface is slightly different from earlier releases and the haddock docs for the new one failed to build on hackage, but earlier versions have essentially the same end-user interface aside from some changes in the module export lists so if you'd like to get an idea of the basic spirit of the system you can browse the docs for the earlier releases. Alternatively, feel free to browse the source and steal some of the implementations (many of which were, in turn, translated from other sources such as wikipedia or the Numerical Recipes book).

Unfortunately, the old documentation is much sparser and terser than the new documentation that failed to build, but if nothing else you can download and build the docs yourself for the new one.

I build docs anyway ;). I discovered random-fu just before 0.1 release and it have nice, monadic interface :D I guess all it lacks is something to 'just' use IO without state etc. for fast typing in ghci - otherwise is IMHO perfect. Regards

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

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.

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.

I don't think that many people expect * to be not commutative (I'm not 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

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).