Rational sequence
With GHC-5.02.2, I do $ ghci Prelude :m Ratio Ratio [1%2..10%2] [1 % 2,3 % 2,5 % 2,7 % 2,9 % 2,11 % 2] The question is, why is there 11%2 at the end of the list? It's inconsistent with the (good) rules for Integer, since Ratio [1,3..10] [1,3,5,7,9] Is this intentional? Feri. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Rational sequence
Ferenc Wagner [EMAIL PROTECTED] writes: $ ghci Prelude :m Ratio Ratio [1%2..10%2] [1 % 2,3 % 2,5 % 2,7 % 2,9 % 2,11 % 2] H, the CVS copy of Hugs seems to suffer from a different problem: Prelude [0.5,1.5..5.5]::[Rational] [0 % 1,1 % 1,2 % 1,3 % 1,4 % 1,5 % 1] I'm expecting to see: [1 % 2,3 % 2,5 % 2,7 % 2,9 % 2,11 % 2] -- Alastair Reid ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Rational sequence
Alastair Reid: Ferenc Wagner [EMAIL PROTECTED] writes: H, the CVS copy of Hugs seems to suffer from a different problem: Prelude [0.5,1.5..5.5]::[Rational] [0 % 1,1 % 1,2 % 1,3 % 1,4 % 1,5 % 1] I'm expecting to see: [1 % 2,3 % 2,5 % 2,7 % 2,9 % 2,11 % 2] Rationals in Hugs were always a bit obscure. What do you think, what is the Rational form of 2.3 ? (GHCi says 23/10). The answer is: 2589569785738035 % 1125899906842624 (Old Hugs, Feb. 2001) If you look at the Prelude, you will see that the algorithms used for rationals are not always a rocket science. I replaced (for myself) that stuff by the continued fraction expansions which are fast and give decent results. The rational arithmetics can also be optimised by using algorithms in the 2nd volume of Knuth (the favourite book of Ralf Hinze...) I found similar bugs in sequences as above already (if I am not mistaken) about 7 - 8 years ago, when we discussed a bit the usage of Haskell to some numerics. But nobody really cared about it, and it seems that some small but nasty insects are still alive. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: Rational sequence
The Report says that the Enum instance for Ratio uses the same rule as for Float/Double, namely that [a..b] means takeWhile (= (b+1/2)) [a, a+1, a+2, ...] You may say that the = should be but that's what the Report says. Certainly if you do [1%3..10%3] you'll get more values than your rule suggests. I'm not sure what your rule should be, though. (What about [2%4, ... 20%4]?) Anyway, it's a bit late to change the Report Simon | -Original Message- | From: Ferenc Wagner [mailto:wferi;bolyai1.elte.hu] | Sent: 22 October 2002 11:12 | To: [EMAIL PROTECTED] | Subject: Rational sequence | | With GHC-5.02.2, I do | | $ ghci | Prelude :m Ratio | Ratio [1%2..10%2] | [1 % 2,3 % 2,5 % 2,7 % 2,9 % 2,11 % 2] | | The question is, why is there 11%2 at the end of the list? | It's inconsistent with the (good) rules for Integer, since | | Ratio [1,3..10] | [1,3,5,7,9] | | Is this intentional? | Feri. | ___ | Haskell-Cafe mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Rational sequence
Simon Peyton-Jones [EMAIL PROTECTED] writes: The Report says that the Enum instance for Ratio uses the same rule as for Float/Double, Now I can see that the revised Report contains more about this than the one on haskell.org. But I still can't see the statement you cited above. Where should I look? On the other hand, I found that 'the instance for Ratio t simply lifts the corresponding operations over t.' What does this mean with respect to Enum? namely that [a..b] means takeWhile (= (b+1/2)) [a, a+1, a+2, ...] You may say that the = should be but that's what the Report says. Well, neither makes more sense to me. For an imprecise type I don't expect precise behaviour. I'm not sure what your rule should be, though. (What about [2%4, ... 20%4]?) Rationals are represented precisely, so that well defined precise mathematical rules apply to them: [2%4..20%4] == [1%2..10%2] == [1%2,3%2,5%2,7%2,9%2], that's to say [a..b] = takeWhile (= b) [a, a+1, a+2, ...] Those fuzzy 1/2-s are inserted solely to 'overcome' the imprecise floating point representation, and make 'simple stupid' programs work and programming newbies happy, aren't they? For serious work they don't count, only create one more peculiarity to observe. Please correct me if I'm mistaken. And please don't feel offended, I suppose that our opinions differ on this point, as shown by a previous thread. Still I don't think things like this promote Haskell, or make it more acceptable for anyone. Anyway, it's a bit late to change the Report As I told above, I can't see anything to change, except implementation. If it's only my stupidity, then sorry for the nitpicking. Feri. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Rational sequence
Jerzy Karczmarczuk [EMAIL PROTECTED] writes: Rationals in Hugs were always a bit obscure. What do you think, what is the Rational form of 2.3 ? (GHCi says 23/10). The answer is: 2589569785738035 % 1125899906842624 (Old Hugs, Feb. 2001) I'm afraid the new release won't fix this. Once the release is out the door and things settle down a bit (both in Hugs and in my personal life), I'd like to cleanup the Hugs' internals which have gotten quite confused by layer upon layer of backward compatability code. Practical benefits I hope for are: - Make Float mean 'C float' and Double mean 'C double'. Most of the code is actually in Hugs already but it was disabled because of some long-irrelevant issue involving the foreign function interface. - Implement literal constants using Rational (as described by the standard) instead of using Double (which, of course, usually means 'float'). [This is a separate task from the first which I would be delighted to have someone else do.] Along the way, inessential things like compatability with GreenCard 1 (which died about 5 years ago) will die, people using GreenCard 2 (what most people call 'GreenCard') with Hugs will lose the option of generating Hugs-specific code instead of generating portable FFI code, deprecated types (like Addr) will disappear, etc. -- Alastair ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Rational sequence
Jerzy Karczmarczuk wrote (on 22-10-02 13:05 +0200): What do you think, what is the Rational form of 2.3 ? (GHCi says 23/10). The answer is: 2589569785738035 % 1125899906842624 Er, why? Because 2.3 is not representable using a double precision float or something? -- Frank ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: representation getting verbose...
Thanks for your reply... Paul Hudak [EMAIL PROTECTED] writes: case expr of C f - ... V (Variable (VVariable s)) - ... ... I think you mean: case expr of C f - ... V (VVariable s) - ... which is not quite as verbose. Yes, I think I should have checked my examples more carefully. I don't think that the problem is as bad as you make it out to be. If you adopt my use of short constructor names, then something like: (snip) Well, my example wasn't very good, and is quite a bit simpler than the actual application I'm developing. I think I will take your advice on shorter names, however. To give you an idea of the kind of code I'm ending up with, here's a construction from my program: Variable (VVariable(varName, (Value (Number (NNumber (varValue, varDimension)) Here VVariable and NNumber are newtype constructors of tuples, and the entire expression is an Expression which, among other things has: data Expression = Value Value | Variable Variable | ... and Value has data Value = Number Number | ... Now the newtype constructors seem a bit unnecessary, perhaps, but I guess they increase the type-checking. So I still feel that the above construtor is overly verbose. On the other hand, there are much deeper issues at play here regarding the representation of a language with variables as a data type. The reference you gave on higher-order abstract syntax may be quite useful. I have also been looking over your paper on using Haskell as an Embedded DSL, which is extremely appealing for my application. I'm attempting to synthesize all of this into a coherent game plan... What I did in my book was very simple, and the use of variables was only given as an exercise (by the way, you left out the Let constructor, which presuambly has the form Let String Expr). Yes indeed. I guess I should have tried compiling my example. I have the urge to post my solution to that exercise just so you know I did it right :-) I'm about to post an SOE question separately. peace, Isaac ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
SOE exercise
(I'm not sure why my postings seem somewhat anonymous, I'll mess with the headers in this post to see if that fixes it. I post to other mailman lists and haven't noticed this problem.) I'm working through Paul Hudak's SOE, and have a question about problem 9.4, which is to define a function applyEach. I've come up with several versions, but not one which usefully uses currying (the exercise doesn't explicitly say to use currying, but that's the only thing in this section). My real question is whether I should be trying to apply currying here. Solutions are welcome, but I can think of several good reasons not to post solutions to this forum. The behavior of applyEach should be obvious from my attempts below. Output: applyEach [(+1), (+3), (+2)] 1 = [2,4,3] :: [Integer] Recursive version: applyEach :: [a-b] - a - [b] applyEach [] _ = [] applyEach (h:t) x = (h x) : (applyEach t x) Now with higher order functions: applyEach' :: [a-b] - a - [b] applyEach' funs x = map applyx funs where applyx (fun) = fun x With Lambda: applyEach'' :: [a-b] - a - [b] applyEach'' funs x = map (\fun- fun x) funs With Currying: ? peace, isaac P.S. I'm enjoying this book a great deal :-) ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: SOE exercise
applyEach [(+1), (+3), (+2)] 1 = [2,4,3] :: [Integer] applyEach' :: [a-b] - a - [b] applyEach' funs x = map applyx funs where applyx (fun) = fun x ...or more simply: applyEach' l x = map ($x) l ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Rational sequence
Frank Atanassow wrote (on 22-10-02 15:08 +0200): Jerzy Karczmarczuk wrote (on 22-10-02 13:05 +0200): What do you think, what is the Rational form of 2.3 ? (GHCi says 23/10). The answer is: 2589569785738035 % 1125899906842624 Er, why? Because 2.3 is not representable using a double precision float or something? Oh, sorry. I understand Jerzy to be saying that that big long fraction was the result that he _wanted_, but instead the opposite seems to be true. That explains things. :) -- Frank ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Odd Performance
Tim Otten writes: : | Can anyone suggest why the tighter algorithm exhibits significantly | worse performance? Is takeWhile significicantly more expensive than | take? No. | Is the \z lambda expression expensive? No. | The intsqrt isn't recalculated each time takeWhile evalutes a | prime, is it? Probably. Try replacing this (\z - z = (intsqrt x)) with this (\z - z^2 = x) or moving the O(sqrt(n)) step[1] into a let expression let zmax = intsqrt x in ... (\z - z = zmax) ... | Slightly confused, | Tim Otten | | [1] Note that intsqrt calculates the floor of the square root of x. | intsqrt x = intsqrt' 1 x | intsqrt' n x | | (n*n x) = n-1 | | otherwise = intsqrt' (n+1) x ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Odd Performance
Tom Pledger writes: | Tim Otten writes: | : | | Can anyone suggest why the tighter algorithm exhibits significantly | | worse performance? Is takeWhile significicantly more expensive than | | take? | | No. Correction (before anyone else pounces on it): Only if the predicate function (the p in takeWhile p xs) is significantly more expensive than a constant-cost piece of arithmetic and pattern-matching. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: representation getting verbose...
Variable (VVariable(varName, (Value (Number (NNumber (varValue, varDimension)) Here VVariable and NNumber are newtype constructors of tuples, and the entire expression is an Expression which, among other things has: data Expression = Value Value | Variable Variable | ... and Value has data Value = Number Number | ... Now the newtype constructors seem a bit unnecessary, perhaps, but I guess they increase the type-checking. So I still feel that the above construtor is overly verbose. Not every embedding has to add constructors. If you look at the types: VVariable :: (String,Value) - Variable Variable :: Variable - Expression, you see that you are just using the constructor as a simple way to embed your subtype of variables in the type of expressions. To leave out the intermediate constructor, redefine data Expression = .. | Variable (String,Value) | .. and write your own embedding function, with the same type as the old constructor, that does not preserve the intermediate constructor: variable :: Variable - Expression variable (VVariable (s,v)) = Variable (s,v) However, my real reason for posting is to recommend a paper you might enjoy, which deals with extensible union types in the context of interpreters, using type classes to automate the embeddings: Monad Transformers and Modular Interpreters, Sheng Liang, Paul Hudak, and Mark P. Jones, In Conference Record of POPL'95: 22nd ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, San Francisco, CA, January 1995. http://www.cse.ogi.edu/~mpj/pubs/modinterp.html Hth, Claus -- Haskell Communities and Activities Report (November 2002 edition) All contributions are due in by the end of October! http://www.haskell.org/communities/ ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: representation getting verbose...
G'day all. On Thu, Oct 17, 2002 at 11:08:57AM -0400, [EMAIL PROTECTED] wrote: For an interpreter I'm writing, I found myself writing a function constructVarExpr :: String - Expr just to make it easier. As an alternative opinion, I don't think there's anything wrong with this. A constructor is just a function, and if you need to do more work than just construct one constructor, there's no reason not to use a real function. In OO design pattern terminology they call this a factory function, though in Haskell the term smart constructor might also apply if the function does real work. Were the wiki working, I would point you to the relevant page there, but it isn't, so I won't. Cheers, Andrew Bromage ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
using IOExts...
Hi All I don't know what I'm doing wrong here but for some reason no matter what esoteric command line option I seem to be able to dream up I can get ghc to include IOExts..I want to use the side-affect IO commands but cannot. I am using ghc-5.02.2for Win32. Can someone just give me a command line example that alows me tocompile a filethat includesIOExts? Thanks J.
