Re: ANNOUNCE: GHC 6.8.3 Release Candidate

On Sun, Jun 01, 2008 at 01:13:06AM +0100, Ian Lynagh wrote:
Hi Serge,
On Sat, May 31, 2008 at 12:54:50PM +0400, Serge D. Mechveliani wrote:
This is a bug report for the ghc candidate of May 27, 2008 for ghc-6.8.3. A short program example for this bug candidate is on
http://botik.ru/pub/local/Mechveliani/ghcBugs/candidateMay27-08-bug.zip
Thanks, I've finally tracked this down. The problem is that when you evaluate something like f ^ 10 in 6.8.2 the result was res while in 6.8.3 it is 1 * res
I think this is actually a bug in your class instances, but I will try to look at http://hackage.haskell.org/trac/ghc/ticket/2306 before 6.8.3 which should, as a side-effect, make it work again.
?? Probably, 6.8.3 is wrong. Because when res :: Num a => a, 1*res means ((fromInteger 1) :: a) * res in Haskell-98. Right? And (fromInteger n) :: a can be defined arbitrarily by the programmer. For example, DoCon has the instance instance CommutativeRing a => Num (Pol a) where ... fromInteger _ = error "No (fromInteger n) :: Pol _ !\ \Apply instead fromi <samplePolynomial> n." -- something of this kind. This is why res and 1*res are not equivalent in Haskell-98 for res :: Num a => a. Am I missing something? ----------------- Serge Mechveliani mechvel@botik.ru

On Sun, Jun 01, 2008 at 05:39:49PM +0400, Serge D. Mechveliani wrote:
This is why res and 1*res are not equivalent in Haskell-98 for res :: Num a => a.
Am I missing something?
The library functions assume that class instances obey some unwritten laws; it's all a bit vague, but if your instances don't obey them then you might find that things go wrong when using library functions. For example, if your (*) isn't associative then (^) is going to give odd results, and if the type of the second argument to (^) doesn't do arithmetic in the normal way then very strange things could happen. Anyway, I've just tweaked the (^) definition again, so your code should work in 6.8.3. Thanks Ian

On Sun, Jun 01, 2008 at 03:34:00PM +0100, Ian Lynagh wrote:
On Sun, Jun 01, 2008 at 05:39:49PM +0400, Serge D. Mechveliani wrote:
This is why res and 1*res are not equivalent in Haskell-98 for res :: Num a => a.
Am I missing something?
The library functions assume that class instances obey some unwritten laws; it's all a bit vague, but if your instances don't obey them then you might find that things go wrong when using library functions. For example, if your (*) isn't associative then (^) is going to give odd results, and if the type of the second argument to (^) doesn't do arithmetic in the normal way then very strange things could happen.
Anyway, I've just tweaked the (^) definition again, so your code should work in 6.8.3.
Thank you. This helps -- in that the public DoCon-2.11 test will run (I hope). But I think that you have found a bug in the DoCon test program. Thank you. More precisely, here are my indeas. 1. Generally, for t = Num a => a, the expessions res :: t and ((fromInteger 1) :: t) * res are not equivalent in Haskell-98, and the compiler has not rigth to replace the former with the latter. Right? 2. But I guess, our current questions are different: (2.1) For t = Num a => a, has a Haskell implementation for (f^n) :: t right to base on certain natural properties of the operation fromInteger :: Integer -> t ? (2.2) Has a reliable mathematical application right to base on that for n > 0 the expression (f^n) :: Polynomial Integer does not imply computing fromInteger 1 :: Polynomial Integer ? Concerning (2.1): I do not know whether Haskell-98 allows to rely on that f^3 is equivalent to (fromInteger 1)*(f^3). But concerning (2.2), I think that (independently of the question (2.1)) a reliable mathematical application must not presume the above properties of (^) and fromInteger. Concerning f^3 :: UPol Integer in my test for DoCon: 1) fromInteger _ :: UPol _ is defined as error "... use fromi instead". 2) (*) is defined via polMul ... 3) The expression f ^ 3 relies on the Haskell-98 library for (^). The Haskell library defines (^) via (*) -- all right. 4) DoCon has the function `power' to use instead of (^), and its library avoids (^). But for n > 0, I considered f^n :: UPol _ as also correct. Because the Haskell library performs this via repeated application of (*). And I thought that if n > 0, then (fromInteger _ :: UPol _) will not appear. Maybe it does not appear in old GHC-s and does appear 6.8.3 ? I was using expressions like [(f ^ n) :: UPol Integer | n <- [2 .. 9]] in my _test programs_ for DoCon. But this relies on a particular property of the Haskell library definition for (f^n) :: a -- on that if n > 0 then (fromInteger _ :: a) does not appear in this computation. Now, I think, either I need to hide the standard (^) and overload it or to replace (^) with `power' in my examples too. Regards, ----------------- Serge Mechveliani mechvel@botik.ru

There are no rules written down. But the fast exponentiation
algorithm used by (^) assumes that (*) is associative.
I also don't think that fast exponentiation should ever multiply by 1.
-- Lennart
On Sun, Jun 1, 2008 at 6:34 PM, Serge D. Mechveliani
On Sun, Jun 01, 2008 at 03:34:00PM +0100, Ian Lynagh wrote:
On Sun, Jun 01, 2008 at 05:39:49PM +0400, Serge D. Mechveliani wrote:
This is why res and 1*res are not equivalent in Haskell-98 for res :: Num a => a.
Am I missing something?
The library functions assume that class instances obey some unwritten laws; it's all a bit vague, but if your instances don't obey them then you might find that things go wrong when using library functions. For example, if your (*) isn't associative then (^) is going to give odd results, and if the type of the second argument to (^) doesn't do arithmetic in the normal way then very strange things could happen.
Anyway, I've just tweaked the (^) definition again, so your code should work in 6.8.3.
Thank you. This helps -- in that the public DoCon-2.11 test will run (I hope).
But I think that you have found a bug in the DoCon test program. Thank you. More precisely, here are my indeas.
1. Generally, for t = Num a => a, the expessions res :: t and ((fromInteger 1) :: t) * res are not equivalent in Haskell-98, and the compiler has not rigth to replace the former with the latter. Right?
2. But I guess, our current questions are different:
(2.1) For t = Num a => a, has a Haskell implementation for (f^n) :: t right to base on certain natural properties of the operation fromInteger :: Integer -> t ? (2.2) Has a reliable mathematical application right to base on that for n > 0 the expression (f^n) :: Polynomial Integer does not imply computing fromInteger 1 :: Polynomial Integer ?
Concerning (2.1): I do not know whether Haskell-98 allows to rely on that f^3 is equivalent to (fromInteger 1)*(f^3).
But concerning (2.2), I think that (independently of the question (2.1)) a reliable mathematical application must not presume the above properties of (^) and fromInteger.
Concerning f^3 :: UPol Integer in my test for DoCon:
1) fromInteger _ :: UPol _ is defined as error "... use fromi instead". 2) (*) is defined via polMul ... 3) The expression f ^ 3 relies on the Haskell-98 library for (^). The Haskell library defines (^) via (*) -- all right.
4) DoCon has the function `power' to use instead of (^), and its library avoids (^). But for n > 0, I considered f^n :: UPol _ as also correct. Because the Haskell library performs this via repeated application of (*). And I thought that if n > 0, then (fromInteger _ :: UPol _) will not appear. Maybe it does not appear in old GHC-s and does appear 6.8.3 ?
I was using expressions like [(f ^ n) :: UPol Integer | n <- [2 .. 9]] in my _test programs_ for DoCon. But this relies on a particular property of the Haskell library definition for (f^n) :: a -- on that if n > 0 then (fromInteger _ :: a) does not appear in this computation.
Now, I think, either I need to hide the standard (^) and overload it or to replace (^) with `power' in my examples too.
Regards,
----------------- Serge Mechveliani mechvel@botik.ru
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Interesting * I think it is a Bad Idea for an application to assume that the implementation of (f^n) will not multiply by 1. Implementations of numeric algorithms probably make all sorts of ill-documented assumptions about the algebraic properties of numeric operations * On the other hand, it's a bit stupid for the implementation of (f^n) to multiply by 1, and Ian has, I think, already fixed this. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On | Behalf Of Serge D. Mechveliani | Sent: 01 June 2008 18:34 | To: Ian Lynagh | Cc: glasgow-haskell-users@haskell.org | Subject: Re: ANNOUNCE: GHC 6.8.3 Release Candidate | | On Sun, Jun 01, 2008 at 03:34:00PM +0100, Ian Lynagh wrote: | > On Sun, Jun 01, 2008 at 05:39:49PM +0400, Serge D. Mechveliani wrote: | > > | > > This is why res and 1*res are not equivalent in Haskell-98 for | > > res :: Num a => a. | > > | > > Am I missing something? | > | > The library functions assume that class instances obey some unwritten | > laws; it's all a bit vague, but if your instances don't obey them then | > you might find that things go wrong when using library functions. For | > example, if your (*) isn't associative then (^) is going to give odd | > results, and if the type of the second argument to (^) doesn't do | > arithmetic in the normal way then very strange things could happen. | > | > Anyway, I've just tweaked the (^) definition again, so your code should | > work in 6.8.3. | | | Thank you. | This helps -- in that the public DoCon-2.11 test will run (I hope). | | But I think that you have found a bug in the DoCon test program. | Thank you. | More precisely, here are my indeas. | | | 1. Generally, for t = Num a => a, the expessions res :: t and | ((fromInteger 1) :: t) * res | are not equivalent in Haskell-98, | and the compiler has not rigth to replace the former with the latter. | Right? | | 2. But I guess, our current questions are different: | | (2.1) For t = Num a => a, has a Haskell implementation for (f^n) :: t | right to base on certain natural properties of the operation | fromInteger :: Integer -> t ? | (2.2) Has a reliable mathematical application right to base on that | for n > 0 the expression (f^n) :: Polynomial Integer | does not imply computing fromInteger 1 :: Polynomial Integer | ? | | Concerning (2.1): I do not know whether Haskell-98 allows to rely on | that f^3 is equivalent to (fromInteger 1)*(f^3). | | But concerning (2.2), I think that (independently of the question (2.1)) | a reliable mathematical application must not presume the above properties | of (^) and fromInteger. | | Concerning f^3 :: UPol Integer in my test for DoCon: | | 1) fromInteger _ :: UPol _ is defined as | error "... use fromi instead". | 2) (*) is defined via polMul ... | 3) The expression f ^ 3 relies on the Haskell-98 library for (^). | The Haskell library defines (^) via (*) -- all right. | | 4) DoCon has the function `power' to use instead of (^), | and its library avoids (^). | But for n > 0, I considered f^n :: UPol _ | as also correct. Because the Haskell library performs this via repeated | application of (*). | And I thought that if n > 0, then (fromInteger _ :: UPol _) will not | appear. | Maybe it does not appear in old GHC-s and does appear 6.8.3 ? | | I was using expressions like [(f ^ n) :: UPol Integer | n <- [2 .. 9]] | in my _test programs_ for DoCon. | But this relies on a particular property of the Haskell library definition | for (f^n) :: a | -- on that if n > 0 then (fromInteger _ :: a) does not appear in this | computation. | | Now, I think, either I need to hide the standard (^) and overload it | or to replace (^) with `power' in my examples too. | | Regards, | | ----------------- | Serge Mechveliani | mechvel@botik.ru | | | | | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Hello Serge, I was looking at the cabal file used to build docon, I note the current flags are: ghc-options: -fglasgow-exts -fallow-overlapping-instances -fallow-undecidable-instances -fno-warn-overlapping-patterns -fwarn-unused-binds -fwarn-unused-matches -fwarn-unused-imports -O +RTS -M400m -RTS Do you gain any performance benefit using: -O2 -fvia-C -optc-O2 I'm wondering. Also, would you be interested in releasing the cabal bundle for docon on hackage.haskell.org , so it can be easily installed by others? -- Don mechvel:
On Sun, Jun 01, 2008 at 01:13:06AM +0100, Ian Lynagh wrote:
Hi Serge,
On Sat, May 31, 2008 at 12:54:50PM +0400, Serge D. Mechveliani wrote:
This is a bug report for the ghc candidate of May 27, 2008 for ghc-6.8.3. A short program example for this bug candidate is on
http://botik.ru/pub/local/Mechveliani/ghcBugs/candidateMay27-08-bug.zip
Thanks, I've finally tracked this down. The problem is that when you evaluate something like f ^ 10 in 6.8.2 the result was res while in 6.8.3 it is 1 * res
I think this is actually a bug in your class instances, but I will try to look at http://hackage.haskell.org/trac/ghc/ticket/2306 before 6.8.3 which should, as a side-effect, make it work again.
?? Probably, 6.8.3 is wrong. Because when res :: Num a => a, 1*res means ((fromInteger 1) :: a) * res in Haskell-98. Right? And (fromInteger n) :: a can be defined arbitrarily by the programmer. For example, DoCon has the instance instance CommutativeRing a => Num (Pol a) where ... fromInteger _ = error "No (fromInteger n) :: Pol _ !\ \Apply instead fromi <samplePolynomial> n." -- something of this kind. This is why res and 1*res are not equivalent in Haskell-98 for res :: Num a => a.
Am I missing something?
----------------- Serge Mechveliani mechvel@botik.ru _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

On Sun, Jun 01, 2008 at 01:46:43PM -0700, Don Stewart wrote:
Hello Serge,
I was looking at the cabal file used to build docon, I note the current flags are:
ghc-options: -fglasgow-exts -fallow-overlapping-instances -fallow-undecidable-instances -fno-warn-overlapping-patterns -fwarn-unused-binds -fwarn-unused-matches -fwarn-unused-imports -O +RTS -M400m -RTS
Do you gain any performance benefit using:
-O2 -fvia-C -optc-O2
I'm wondering.
I tried -O2 -fvia-C -optc-O2, together with making the very test (demotest/Main) under -O. In ghc-6.8.2 this does not gain anything in DoCon in comparison to -O, it makes things worse: * the speed of running the test preserves, * making the DoCon library becomes 4 times slower, * the library code becomes 10% larger, * making the test module becomes ? times slower, Concerning the speed of running the test, maybe -O2 does not help because DoCon uses Integer everywhere instead of Int, I do not know. I do not apply -O2 in making the test because this takes too much of time (hours, more than 50 times more than -Onot), and also because this would not increase perforamance, because all the time consuming inner loops are in the library, not in the test.
Also, would you be interested in releasing the cabal bundle for docon on hackage.haskell.org , so it can be easily installed by others?
Could you explain me, why currently DoCon is not easy to install? I thought, install.txt provides a short instruction which is easy to follow. What is difficult there, what could be improved? What is a cabal bundle? DoCon has the file docon.cabal. Is not this a cabal bundle? Regards, ----------------- Serge Mechveliani mechvel@botik.ru
participants (5)
-
Don Stewart
-
Ian Lynagh
-
Lennart Augustsson
-
Serge D. Mechveliani
-
Simon Peyton-Jones