[Haskell-cafe] Re: External Sort: Sort a 10-million integer file with just 256M of ram.
Bulat Ziganshin [EMAIL PROTECTED] wrote: Hello Albert, Saturday, October 25, 2008, 9:02:14 PM, you wrote: u = (putStrLn . show . last $ list) (putStrLn . show . head $ list) where list = [1..10^8::Int] i prefer to write it as main = do let list = [1..10^8] print (last list) print (head list) Don't you slam pointless style! -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: External Sort: Sort a 10-million integer file with just 256M of ram.
On Mon, Oct 27, 2008 at 6:47 AM, Achim Schneider [EMAIL PROTECTED] wrote: Don't you slam pointless style! main = mapM_ (($ [1..10^8::Int]) . (.) (putStrLn . show)) [last, head] =) -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Why 'round' does not just round numbers ?
Hi all: I just read about definitions of Prelude [1], and noticing that. In 6.4.6 Coercions and Component Extraction, it discribes like this: round x returns the nearest integer to x, the even integer if x is equidistant between two integers. I think this is unresonable. then try it in GHC 6.8.3. Prelude round 3.5 4 Prelude round 2.5 2 Is there any explanation about that ? [1] The Haskell 98 Report: Predefined Types and Classes http://haskell.org/onlinereport/basic.html Regards -- L.Guo 2008-10-27 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why 'round' does not just round numbers ?
On Mon, 27 Oct 2008, L.Guo wrote: I think this is unresonable. then try it in GHC 6.8.3. Prelude round 3.5 4 Prelude round 2.5 2 Is there any explanation about that ? It's the definition we learnt in school ... I think one reason is that repeated rounding should not be worse than rounding in one go. Consider the rule 'use ceiling when the first removed digit is 5'. Then 0.45 - (round to one place) - 0.5 - (round to integer) - 1 but 0.45 - (round to integer) - 0 This is avoided by the school definition. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Why 'round' does not just round numbers ?
Hi, That is a fairly standard implementation of rounding for financial institutions. Consider sum . map round Over the list [3.5,2.5] With rounding to the nearest even integer for 0.5's you get 6, otherwise if you always round up you get 7. If you bias towards rounding up you get a general upwards trend as numbers are rounded, which is bad, while the even condition ensures that statistically it averages to the same thing. For more details see: http://en.wikipedia.org/wiki/Rounding#Round-to-even_method Thanks Neil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of L.Guo Sent: 27 October 2008 9:49 am To: MailList Haskell-Cafe Subject: [Haskell-cafe] Why 'round' does not just round numbers ? Hi all: I just read about definitions of Prelude [1], and noticing that. In 6.4.6 Coercions and Component Extraction, it discribes like this: round x returns the nearest integer to x, the even integer if x is equidistant between two integers. I think this is unresonable. then try it in GHC 6.8.3. Prelude round 3.5 4 Prelude round 2.5 2 Is there any explanation about that ? [1] The Haskell 98 Report: Predefined Types and Classes http://haskell.org/onlinereport/basic.html Regards -- L.Guo 2008-10-27 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Instances of Lattice?
On Sun, 26 Oct 2008, Galchin, Vasili wrote: Hi Henning, I am rereading my emails and I don't believe I got an examples of instance Lattice. E.g. instance Lattice Bool. ?? Did you look into the Lattice module? Bool with respect to and || Sets with respect to union and intersection (a set is like multiple booleans) any real number type with respect to min and max Natural numbers with respect to GCD and LCM (consider the exponents of the prime factor decomposition) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why 'round' does not just round numbers ?
Henning Thielemann wrote: On Mon, 27 Oct 2008, L.Guo wrote: I think this is unresonable. then try it in GHC 6.8.3. Prelude round 3.5 4 Prelude round 2.5 2 Is there any explanation about that ? It's the definition we learnt in school ... Hmm, Henning, this is strange. The two of us went to the very same school, but I know for a fact that I learnt 2.5 to round to 3, not 2 as above. ;-) I think one reason is that repeated rounding should not be worse than rounding in one go. Consider the rule 'use ceiling when the first removed digit is 5'. Then 0.45 - (round to one place) - 0.5 - (round to integer) - 1 but 0.45 - (round to integer) - 0 That is of course true (and was the topic of heated discussion with my fourth grade math teacher), but does not explain 2.5 - 2. Ciao, Janis. -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why 'round' does not just round numbers ?
On Mon, 27 Oct 2008, Janis Voigtlaender wrote: Henning Thielemann wrote: On Mon, 27 Oct 2008, L.Guo wrote: I think this is unresonable. then try it in GHC 6.8.3. Prelude round 3.5 4 Prelude round 2.5 2 Is there any explanation about that ? It's the definition we learnt in school ... Hmm, Henning, this is strange. The two of us went to the very same school, but I know for a fact that I learnt 2.5 to round to 3, not 2 as above. ;-) I meant the school before GCG! :-] So it seems to differ between schools and even teachers. (Much like the question whether zero should be counted as natural number or not.) I think one reason is that repeated rounding should not be worse than rounding in one go. Consider the rule 'use ceiling when the first removed digit is 5'. Then 0.45 - (round to one place) - 0.5 - (round to integer) - 1 but 0.45 - (round to integer) - 0 That is of course true (and was the topic of heated discussion with my fourth grade math teacher), but does not explain 2.5 - 2. Because doing otherwise would be odd rounding. ;-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] using ghc as a library
I'm not quite sure what you are trying to do. But for what it's worth, you can load a specific file via setTarget [Target (TargetFile foo/blah.hs) True Nothing] see http://code.haskell.org/~nominolo/html/ghc/GHC.html#v%3AsetTargets Here're GHC's current haddocks (for HEAD): http://code.haskell.org/~nominolo/html/ghc/frames.html 2008/10/27 Anatoly Yakovenko [EMAIL PROTECTED]: Hi, Anatoly Sorry for don't answering your question in the first place, but for this kind of tasks I believe you might be better off using some lightweight wrapper of the GHC Api. thanks, that's really cool, but I am trying to figure out a way to embed haskell into another program so i can control and configure it using haskell. I managed to get farther by using the GHC api's that manipulate the ModuleInfo structure, but I am kind of stuck right now trying to figure out how to allow different scripts import each other. The problem is that i dont wan't to have to structure the input scripts as I would a regular haskell project. I basically want to be able to do import foo/blah.hs and read the blah.hs file directly. Any ideas? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why 'round' does not just round numbers ?
(Janis, sorry for e-mailiing just for you on the first time.) On Mon, Oct 27, 2008 at 8:15 AM, Janis Voigtlaender [EMAIL PROTECTED] wrote: That is of course true (and was the topic of heated discussion with my fourth grade math teacher), but does not explain 2.5 - 2. If you round to odd instead of round to even, then 4.5 rounds to 5, which would may need rounding again and introduce double rounding errors. For a simple example, 2.45 - 2.4 - 2 2.45 - 2.5 - 3 The Wikipedia article that was linked in this thread talks about this problem as well. -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why 'round' does not just round numbers ?
Felipe Lessa wrote: On Mon, Oct 27, 2008 at 8:15 AM, Janis Voigtlaender [EMAIL PROTECTED] wrote: That is of course true (and was the topic of heated discussion with my fourth grade math teacher), but does not explain 2.5 - 2. If you round to odd instead of round to even, then 4.5 rounds to 5, Well, of course I did not learn to round to odd. I learned to round .5 to above, but not to do repeated rounding. So we would never have either of 2.45 - 2.4 - 2 2.45 - 2.5 - 3 as you suggest. Instead, always in one go: 2.45 - 2 Because of the 4, whereas any digit following it would be ignored: 2.4x - x In fact, by your explanation, you would have: 3.46 - 3.5 - 4 Which is most odd. 3.46 is definitely closer to 3 than to 4. -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why 'round' does not just round numbers ?
Janis Voigtlaender wrote: 2.4x - x That's supposed to be 2.4x - 2, of course. -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why 'round' does not just round numbers ?
On Mon, Oct 27, 2008 at 8:30 AM, Janis Voigtlaender [EMAIL PROTECTED] wrote: Well, of course I did not learn to round to odd. I learned to round .5 to above, but not to do repeated rounding. Nobody rounds in passes, of course =). I was talking about two successive rounds. In fact, by your explanation, you would have: 3.46 - 3.5 - 4 Which is most odd. 3.46 is definitely closer to 3 than to 4. If you're doing a double rounding, then this error will always happen. Round to even avoids this error when the last digit was a 5, which is good. -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why 'round' does not just round numbers ?
Henning Thielemann wrote: I think one reason is that repeated rounding should not be worse than rounding in one go. Consider the rule 'use ceiling when the first removed digit is 5'. Then 0.45 - (round to one place) - 0.5 - (round to integer) - 1 But repeated rounding *is* worse than rounding in one go, under any reasonable scheme: 3.46 - 3.5 - 4 vs. 3.46 - 3 That was actually the debate with that teacher. Unbelievable as that still is to me today, she advocated the 3.46 - 3.5 - 4 route... And yes, Henning, you are right, we didn't yet share school in fourth grade when rounding was taught. Ciao, Janis. -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why 'round' does not just round numbers ?
Felipe Lessa wrote: On Mon, Oct 27, 2008 at 8:30 AM, Janis Voigtlaender [EMAIL PROTECTED] wrote: Well, of course I did not learn to round to odd. I learned to round .5 to above, but not to do repeated rounding. Nobody rounds in passes, of course =). Oh, Mrs. I forgot her name actually did ;-) -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why 'round' does not just round numbers ?
On Mon, 27 Oct 2008, Janis Voigtlaender wrote: Henning Thielemann wrote: I think one reason is that repeated rounding should not be worse than rounding in one go. Consider the rule 'use ceiling when the first removed digit is 5'. Then 0.45 - (round to one place) - 0.5 - (round to integer) - 1 But repeated rounding *is* worse than rounding in one go, under any reasonable scheme: 3.46 - 3.5 - 4 With the rounding-to-even route this would be 3.46 - 3.4 - 3 so rounding in passes is no worse than rounding in one go for this example. vs. 3.46 - 3 That was actually the debate with that teacher. Unbelievable as that still is to me today, she advocated the 3.46 - 3.5 - 4 route ... I also know a didact which tells teachers that 1 has no prime decomposition. Oh, I see, she may have copied that from Wikipedia: http://en.wikipedia.org/wiki/Prime_factorisation ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: External Sort: Sort a 10-million integer file with just 256M of ram.
Felipe Lessa [EMAIL PROTECTED] wrote: On Mon, Oct 27, 2008 at 6:47 AM, Achim Schneider [EMAIL PROTECTED] wrote: Don't you slam pointless style! main = mapM_ (($ [1..10^8::Int]) . (.) (putStrLn . show)) [last, head] =) Hmmm... Template Haskell... repetitive code... deficiency... -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Haskell on the JVM
Is there an interest in hosting GHC on the JVM (besides my own). There's interest but my understanding is that the GHC backend architecture is not at all friendly to work with. That said, I hear in the next release (I think 6.12, not the 6.10 that's in beta) will have a redesigned backend architecture that is supposed to be much easier to work with, which will make it easier to provide native code generators for many currently poorly-served platforms --- including the JVM if anyone is so inclined. I don't think it's so hard to translate GHC's Core language to the JVM. Apart from the treatment of tail recursion, for which various hacks are available. Eg Scala manages it. I don't think you want the C-- level (which is what the redesigned back end is about). However, there's more to it than generating bytecode: http://haskell.org/haskellwiki/GHC:FAQ#Why_isn.27t_GHC_available_for_.NET_or_on_the_JVM.3F It'd be a good project though! Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why 'round' does not just round numbers ?
L.Guo [EMAIL PROTECTED] wrote: round x returns the nearest integer to x, the even integer if x is equidistant between two integers. Is there any explanation about that ? Yes. math.h, rint() and IEEE. The Right Way(tm) to round is rounding every other n.5 into a different direction: round 1.5 = 2 round 2.5 = 2 round 3.5 = 4 round 4.5 = 4 and so on. It's statistically correct, that is, but also more computationally expensive. In practise, such things rarely matter, so you just don't need to care. If you have to care, pray that you know it. You're also bound to slam your nose into much, much messier issues then, too, wishing you'd learnt higher numerics in school, kind of like learning Haskell and wishing the first grade math curriculum was based on categories instead of sets. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why 'round' does not just round numbers ?
Janis Voigtlaender [EMAIL PROTECTED] writes: If you round to odd instead of round to even, then 4.5 rounds to 5, Well, of course I did not learn to round to odd. I learned to round .5 to above, but not to do repeated rounding. Since just about every floating point operation involves some sort of loss of precision, repeated rounding is a fact of life. Or use rationals. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why 'round' does not just round numbers ?
Am Montag, 27. Oktober 2008 11:46 schrieb Henning Thielemann: On Mon, 27 Oct 2008, Janis Voigtlaender wrote: Henning Thielemann wrote: I think one reason is that repeated rounding should not be worse than rounding in one go. Consider the rule 'use ceiling when the first removed digit is 5'. Then 0.45 - (round to one place) - 0.5 - (round to integer) - 1 But repeated rounding *is* worse than rounding in one go, under any reasonable scheme: 3.46 - 3.5 - 4 With the rounding-to-even route this would be 3.46 - 3.4 - 3 Wait, that cannot be. 6 5, so 3.46 - 3.5 even with banker's rounding. so rounding in passes is no worse than rounding in one go for this example. Rounding in passes is bad per se, because there are pretty large intervals where that gives a different result from a direct rounding. vs. 3.46 - 3 That was actually the debate with that teacher. Unbelievable as that still is to me today, she advocated the 3.46 - 3.5 - 4 route ... I also know a didact which tells teachers that 1 has no prime decomposition. Oh, I see, she may have copied that from Wikipedia: http://en.wikipedia.org/wiki/Prime_factorisation I can believe that makes sense to somebody who considers 0 an unnatural number, an empty product must be frightening for them. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why 'round' does not just round numbers ?
On Mon, 27 Oct 2008, Daniel Fischer wrote: Am Montag, 27. Oktober 2008 11:46 schrieb Henning Thielemann: On Mon, 27 Oct 2008, Janis Voigtlaender wrote: Henning Thielemann wrote: I think one reason is that repeated rounding should not be worse than rounding in one go. Consider the rule 'use ceiling when the first removed digit is 5'. Then 0.45 - (round to one place) - 0.5 - (round to integer) - 1 But repeated rounding *is* worse than rounding in one go, under any reasonable scheme: 3.46 - 3.5 - 4 With the rounding-to-even route this would be 3.46 - 3.4 - 3 Wait, that cannot be. 6 5, so 3.46 - 3.5 even with banker's rounding. You are right, my oversight. So only the method helps, that the last digit is marked, whether it was generated by rounding up or down. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why 'round' does not just round numbers ?
Daniel Fischer [EMAIL PROTECTED] wrote: Am Montag, 27. Oktober 2008 11:46 schrieb Henning Thielemann: I also know a didact which tells teachers that 1 has no prime decomposition. Oh, I see, she may have copied that from Wikipedia: http://en.wikipedia.org/wiki/Prime_factorisation I can believe that makes sense to somebody who considers 0 an unnatural number, an empty product must be frightening for them. That is just mathematical trickery and dodgery, silently defining 1 as prime by including it (even infinitely many times!) in any prime factor, denying its existence there (by defining all units to be non-prime) and then calling the whole algebra paradox-free, hoping that noone notices. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why 'round' does not just round numbers ?
Ketil Malde wrote: Janis Voigtlaender [EMAIL PROTECTED] writes: If you round to odd instead of round to even, then 4.5 rounds to 5, Well, of course I did not learn to round to odd. I learned to round .5 to above, but not to do repeated rounding. Since just about every floating point operation involves some sort of loss of precision, repeated rounding is a fact of life. Of course. But that was not the point of the discussion... -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why 'round' does not just round numbers ?
Am Montag, 27. Oktober 2008 12:35 schrieb Achim Schneider: Daniel Fischer [EMAIL PROTECTED] wrote: Am Montag, 27. Oktober 2008 11:46 schrieb Henning Thielemann: I also know a didact which tells teachers that 1 has no prime decomposition. Oh, I see, she may have copied that from Wikipedia: http://en.wikipedia.org/wiki/Prime_factorisation I can believe that makes sense to somebody who considers 0 an unnatural number, an empty product must be frightening for them. That is just mathematical trickery and dodgery, silently defining 1 as prime by including it (even infinitely many times!) in any prime factor, Who does such horrible things? Repeat after me: 1 is NOT a prime. Never, under no circumstances. denying its existence there (by defining all units to be non-prime) and then calling the whole algebra paradox-free, hoping that noone notices. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why 'round' does not just round numbers ?
Thank you all for instructions. I am not the same education route with you, so i just heard round-to-even for the very first time. Now I understand why it exists in theory. And then, in haskell, is that means, I have to use 'floor . (.5+)' instead of 'round' to get the common round function ? Or else, is there any other alter-round-function in haskell to do this ? -- L.Guo 2008-10-27 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why 'round' does not just round numbers ?
On Mon, 27 Oct 2008, L.Guo wrote: And then, in haskell, is that means, I have to use 'floor . (.5+)' instead of 'round' to get the common round function ? That's certainly the best to do. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why 'round' does not just round numbers ?
Henning Thielemann [EMAIL PROTECTED] wrote: On Mon, 27 Oct 2008, L.Guo wrote: And then, in haskell, is that means, I have to use 'floor . (.5+)' instead of 'round' to get the common round function ? That's certainly the best to do. Hmmm... I'm wondering whether there's a standard C way to set the rounding direction. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why 'round' does not just round numbers ?
On Mon, Oct 27, 2008 at 10:20 AM, Achim Schneider [EMAIL PROTECTED] wrote: Hmmm... I'm wondering whether there's a standard C way to set the rounding direction. nearbyint() and rint() may be used, and the rounding mode can be set by fesetround(). IIRC, this is C99. -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why 'round' does not just round numbers ?
Daniel Fischer [EMAIL PROTECTED] wrote: Am Montag, 27. Oktober 2008 12:35 schrieb Achim Schneider: Daniel Fischer [EMAIL PROTECTED] wrote: Am Montag, 27. Oktober 2008 11:46 schrieb Henning Thielemann: I also know a didact which tells teachers that 1 has no prime decomposition. Oh, I see, she may have copied that from Wikipedia: http://en.wikipedia.org/wiki/Prime_factorisation I can believe that makes sense to somebody who considers 0 an unnatural number, an empty product must be frightening for them. That is just mathematical trickery and dodgery, silently defining 1 as prime by including it (even infinitely many times!) in any prime factor, Who does such horrible things? Repeat after me: 1 is NOT a prime. Never, under no circumstances. Then chase it out of your prime factor products. You'd be the first one to break a monoid and locate unsafeCalculate#. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why 'round' does not just round numbers ?
Felipe Lessa [EMAIL PROTECTED] wrote:
On Mon, Oct 27, 2008 at 10:20 AM, Achim Schneider [EMAIL PROTECTED]
wrote:
Hmmm... I'm wondering whether there's a standard C way to set the
rounding direction.
nearbyint() and rint() may be used, and the rounding mode can be set
by fesetround(). IIRC, this is C99.
Yes, they are, thanks.
Because of stuff like this, I sometimes wish Haskell supported not only
morphisms of the type
Hask a - Hask b
but
(Hask h, RoundDownwards h) = h a - h b
{-# LANGUAGE CategoryClasses #-} ?
--
(c) this sig last receiving data processing entity. Inspect headers
for copyright history. All rights reserved. Copying, hiring, renting,
performance and/or quoting of this signature prohibited.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why 'round' does not just round numbers ?
2008/10/27 Janis Voigtlaender [EMAIL PROTECTED]: Janis Voigtlaender wrote: 2.4x - x That's supposed to be 2.4x - 2, of course. Ah, damn it. I was hoping for a long discussion on just what math would look like with rounding like that ;-) /M -- Magnus Therning(OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why 'round' does not just round numbers ?
Am Montag, 27. Oktober 2008 13:34 schrieb Achim Schneider:
Who does such horrible things?
Repeat after me: 1 is NOT a prime. Never, under no circumstances.
Then chase it out of your prime factor products. You'd be the first one
to break a monoid and locate unsafeCalculate#.
Huh? I don't understand what you are trying to say here.
In which way do you use the term prime factor product?
If you're referring the value of the product, 1 is a perfectly legitimate
value, that of the empty product.
If you're referring the expression \prod_{i \in I}p_i, that doesn't contain 1.
So out of where shall it (I think that refers to 1, does it?) be chased?
And what has that to do with breaking monoids?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why 'round' does not just round numbers ?
It is certainly what I learnt in school. But that was another school. On Mon, Oct 27, 2008 at 12:15 PM, Janis Voigtlaender [EMAIL PROTECTED] wrote: Henning Thielemann wrote: On Mon, 27 Oct 2008, L.Guo wrote: I think this is unresonable. then try it in GHC 6.8.3. Prelude round 3.5 4 Prelude round 2.5 2 Is there any explanation about that ? It's the definition we learnt in school ... Hmm, Henning, this is strange. The two of us went to the very same school, but I know for a fact that I learnt 2.5 to round to 3, not 2 as above. ;-) I think one reason is that repeated rounding should not be worse than rounding in one go. Consider the rule 'use ceiling when the first removed digit is 5'. Then 0.45 - (round to one place) - 0.5 - (round to integer) - 1 but 0.45 - (round to integer) - 0 That is of course true (and was the topic of heated discussion with my fourth grade math teacher), but does not explain 2.5 - 2. Ciao, Janis. -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why 'round' does not just round numbers ?
But you shouldn't use the common round function, you should use the Haskell round function. That's the one that is mathematically better and has hardware support. On Mon, Oct 27, 2008 at 2:05 PM, L.Guo [EMAIL PROTECTED] wrote: Thank you all for instructions. I am not the same education route with you, so i just heard round-to-even for the very first time. Now I understand why it exists in theory. And then, in haskell, is that means, I have to use 'floor . (.5+)' instead of 'round' to get the common round function ? Or else, is there any other alter-round-function in haskell to do this ? -- L.Guo 2008-10-27 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why 'round' does not just round numbers ?
Lennart Augustsson wrote: It is certainly what I learnt in school. But that was another school. Hmm, on reflection, taking Neil's explanation into account and the fact that this rounding mode was referred to as banker's rounding, the point may be that it was not only another school, but another world (politically, pre-'89 ;-). -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why 'round' does not just round numbers ?
I can't remember the method being called anything. It was just what we were being taught. With the obvious explanation that .5 is right in the middle so always going one way would introduce a bias. This was circa 1969. On Mon, Oct 27, 2008 at 3:30 PM, Janis Voigtlaender [EMAIL PROTECTED] wrote: Lennart Augustsson wrote: It is certainly what I learnt in school. But that was another school. Hmm, on reflection, taking Neil's explanation into account and the fact that this rounding mode was referred to as banker's rounding, the point may be that it was not only another school, but another world (politically, pre-'89 ;-). -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why 'round' does not just round numbers ?
Lennart Augustsson wrote: I can't remember the method being called anything. It was just what we were being taught. With the obvious explanation that .5 is right in the middle so always going one way would introduce a bias. This was circa 1969. Well, I wasn't serious about the political explanation. And yes, the avoiding bias explanation makes sense, but not the this way of rounding makes repeated rounding safe explanation. -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why 'round' does not just round numbers ?
On Mon, Oct 27, 2008 at 9:48 AM, L.Guo [EMAIL PROTECTED] wrote: Hi all: I just read about definitions of Prelude [1], and noticing that. In 6.4.6 Coercions and Component Extraction, it discribes like this: round x returns the nearest integer to x, the even integer if x is equidistant between two integers. I think this is unresonable. then try it in GHC 6.8.3. Prelude round 3.5 4 Prelude round 2.5 2 Is there any explanation about that ? [1] The Haskell 98 Report: Predefined Types and Classes http://haskell.org/onlinereport/basic.html This behaviour is not what I expect after reading the description at http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:round . Given that this behaviour has caused a bit of confusion I think a change to the documention might be in order. /M -- Magnus Therning(OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why 'round' does not just round numbers ?
On Mon, Oct 27, 2008 at 1:37 PM, Lennart Augustsson [EMAIL PROTECTED] wrote: I can't remember the method being called anything. It was just what we were being taught. With the obvious explanation that .5 is right in the middle so always going one way would introduce a bias. This was circa 1969. By the time I was in the Swedish school system that seems to have changed. I had never heard of this method of rounding before reading this thread :-) /M -- Magnus Therning(OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why 'round' does not just round numbers ?
[1] The Haskell 98 Report: Predefined Types and Classes http://haskell.org/onlinereport/basic.html This behaviour is not what I expect after reading the description at http://haskell.org/ghc/docs/latest/html/libraries/base/ Prelude.html#v:round . Given that this behaviour has caused a bit of confusion I think a change to the documention might be in order. Given that the documentation says round x returns the nearest integer to x, I think pretty much any behavior can be expected -- there's no single integer nearest to 2.5. The documentation certainly needs updated though. Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why 'round' does not just round numbers ?
On 2008 Oct 27, at 6:00, Henning Thielemann wrote: On Mon, 27 Oct 2008, L.Guo wrote: I think this is unresonable. then try it in GHC 6.8.3. Prelude round 3.5 4 Prelude round 2.5 2 Is there any explanation about that ? It's the definition we learnt in school ... Maybe you did; I learned 5/9 rounding. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Re: Current XML libraries status
Hello David, I tried to use HXT's readDocument with its tagsoup option for my application. I couldn't find a way to construct the operation that didn't run out of memory. I'll attach some code using HaXml's saxParse so you can see what I want. Is that easy to do in HXT? I simply want the text of PMID and AbstractText elements. here's an example, that reads the input in a lazy way. I ran this in ghci with a file containing 2^20 XML Elements. The file was about 18Mb in size. A normal parse with the standard parsec parser ran out of memory on my 1Gb box. This one used within ghci about 200Mb max. module Main where import Text.XML.HXT.Arrow import System main = do mapM_ main' names main = do (name:_) - getArgs runX ( readDoc name fromLA (deep (hasName PIMD -- select the nodes + hasName AbstractText ) getChildren -- get the text getText ) arrIO putStrLn ) putStrLn main finished readDoc = readDocument [ (a_tagsoup, v_1) , (a_parse_xml, v_1) , (a_remove_whitespace, v_1) , (a_encoding, isoLatin1) , (a_issue_warnings, v_0) , (a_trace, 1) ] - Cheers, Uwe Schmidt -- Uwe Schmidt Web: http://www.fh-wedel.de/~si/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why 'round' does not just round numbers ?
Janis Voigtlaender [EMAIL PROTECTED] writes: Since just about every floating point operation involves some sort of loss of precision, repeated rounding is a fact of life. Of course. But that was not the point of the discussion... Well, allow me to contribute to keeping the discussion on topic by stating that when I was in school, I was taught to round up. Now if you will excuse a momentary digression: The point *I* wanted to make is that we have two qualitatively different rounding modes: round up on 0.5, or round to even (or randomly, or alternating), and they make sense in different contexts. Doing computations with fixed precision, you keep losing precision, and rounding bias accumulates - thus the need to use some non-biased rounding. Doing (small scale) calculations on paper, you can avoid repeated rounding, and only round the result. In which case rounding up is okay, you don't introduce the amount of bias as with repeated rounding. And if your input happens to be truncated, rounding up becomes the right thing to do. Of course, Haskell should discard the rather tasteless IEEE754 crud, and do its calculations on infinite streams of digits. Then, rounding upwards after 'take'ing a sufficient amount of decimals will be the right thing to do. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why 'round' does not just round numbers ?
Ketil Malde wrote: Janis Voigtlaender [EMAIL PROTECTED] writes: Since just about every floating point operation involves some sort of loss of precision, repeated rounding is a fact of life. Of course. But that was not the point of the discussion... Well, allow me to contribute to keeping the discussion on topic by stating that when I was in school, I was taught to round up. Now if you will excuse a momentary digression: The point *I* wanted to make is that we have two qualitatively different rounding modes: round up on 0.5, or round to even (or randomly, or alternating), and they make sense in different contexts. Doing computations with fixed precision, you keep losing precision, and rounding bias accumulates - thus the need to use some non-biased rounding. Doing (small scale) calculations on paper, you can avoid repeated rounding, and only round the result. In which case rounding up is okay, you don't introduce the amount of bias as with repeated rounding. And if your input happens to be truncated, rounding up becomes the right thing to do. Of course, Haskell should discard the rather tasteless IEEE754 crud, and do its calculations on infinite streams of digits. Then, rounding upwards after 'take'ing a sufficient amount of decimals will be the right thing to do. Yes, that all makes sense. And I did not intend to cut you short. -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why 'round' does not just round numbers ?
This behaviour is not what I expect after reading the description at http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:round . Given that this behaviour has caused a bit of confusion I think a change to the documention might be in order. The authority here is the report which says round x returns the nearest integer to x, the even integer if x is equidistant between two integers. However I agree the haddock ought to mirror the report. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why 'round' does not just round numbers ?
2.4x - x That's supposed to be 2.4x - 2, of course. Ah, damn it. I was hoping for a long discussion on just what math would look like with rounding like that ;-) I think it has a name... modulo maybe? Stefan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why 'round' does not just round numbers ?
Ketil Malde wrote: Of course, Haskell should discard the rather tasteless IEEE754 crud, and do its calculations on infinite streams of digits. Then, rounding upwards after 'take'ing a sufficient amount of decimals will be the right thing to do. Except arbitrary-precision real arithmetic is not as trivial as you make it sound, and using an infinite stream of digits is not sufficient by itself. See also: http://www.haskell.org/haskellwiki/Exact_real_arithmetic Martijn. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why 'round' does not just round numbers ?
It's well known from numerical analysis that you can achieve the best general behavior by rounding to even in half the cases, and rounding to odd in half the cases. It's usually deterministic by looking at the digit to the right of the round point. Regards, John A. De Goes N-BRAIN, Inc. http://www.n-brain.net [n minds are better than n-1] On Oct 27, 2008, at 10:59 AM, Jules Bean wrote: This behaviour is not what I expect after reading the description at http://haskell.org/ghc/docs/latest/html/libraries/base/ Prelude.html#v:round . Given that this behaviour has caused a bit of confusion I think a change to the documention might be in order. The authority here is the report which says round x returns the nearest integer to x, the even integer if x is equidistant between two integers. However I agree the haddock ought to mirror the report. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why 'round' does not just round numbers ?
L.Guo wrote: Hi all: I just read about definitions of Prelude [1], and noticing that. In 6.4.6 Coercions and Component Extraction, it discribes like this: round x returns the nearest integer to x, the even integer if x is equidistant between two integers. I think this is unresonable. then try it in GHC 6.8.3. Prelude round 3.5 4 Prelude round 2.5 2 Is there any explanation about that ? This is the same exact behavior found in the FPU of most processors, except that you usually don't notice because the rounding occurs between very small values. The reason for doing it this way is that e.g. 2.5 is exactly between 2 and 3, and rounding *up* every time would cause an uneven bias toward 3. To counteract that effect, rounding to the nearest even integer is used, which causes the half of the x.5 values to round up, and the other half to round down. Pete ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] strange ghc output
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 i have a small program i have been using routinely that has stopped working. the last alteration of my install configuration was to upgrade the haskell-feed package as arch linux recommended. here is the error i get: - - $ runghc newspage.hs GHCi runtime linker: fatal error: I found a duplicate definition for symbol fps_minimum whilst processing object file /usr/lib/bytestring-0.9.1.3/ghc-6.8.2/HSbytestring-0.9.1.3.o This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. GHCi cannot safely continue in this situation. Exiting now. Sorry. - - i have reinstalled the haskell-bytestring package, to no avail. here is the actual code i am trying to run: http://hpaste.org/11514#a0 its fairly straightforward. any clues? thanks - brad -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkkF8ScACgkQxRg3RkRK91OosgCfeZIA378PleCnaxwymabNz97F TXAAnRzOhL4zQ9n9RG1oDp146a1b4ajK =qtCU -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] strange ghc output
On Mon, Oct 27, 2008 at 4:49 PM, brad clawsie [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 i have a small program i have been using routinely that has stopped working. the last alteration of my install configuration was to upgrade the haskell-feed package as arch linux recommended. here is the error i get: - - $ runghc newspage.hs GHCi runtime linker: fatal error: I found a duplicate definition for symbol fps_minimum whilst processing object file /usr/lib/bytestring-0.9.1.3/ghc-6.8.2/HSbytestring-0.9.1.3.o This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. GHCi cannot safely continue in this situation. Exiting now. Sorry. - - i have reinstalled the haskell-bytestring package, to no avail. here is the actual code i am trying to run: http://hpaste.org/11514#a0 its fairly straightforward. any clues? Hi Brad, This happens when, for example, your code imports a library which was compiled with a previous version of bytestring. Replacing bytestring on its own isn't enough to solve the problem. To make things more awkward, it could be several libraries which use the old bytestring. Using ghc --make, it seems this error can be ignored, but it's annoying if you want to use the interactive GHC. The only answer I know of is to systematically examine the dependencies of each failing library as it is loaded in GHCi. Then rebuild this library with the new bytestring and try again. This is what I did in the end. Maybe cabal-install provides more sophisticated features for this nowadays; its development seems to be quite pacy! Cheers, D ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell on the JVM
On Mon, Oct 27, 2008 at 10:58:11AM +, Simon Peyton-Jones wrote: Is there an interest in hosting GHC on the JVM (besides my own). Yep. I wrote a JVM backend for GHC (LambdaVM). It is suffering from bit-rot though. I think this thread has re-spaked my interest in it though. I don't think it's so hard to translate GHC's Core language to the JVM. Definitely not. That is more or less the route I took (I actually transform STG it into yet another simple intermediate laguage that is more JVM friendly, this was more for optimization purposes though). While C-- looks fantastic for generating native code, it just didn't seem worth the effort to shoehorn it into the JVM. Although I haven't looked at any of the new backend stuff, I suspect it still won't be suitable for the JVM. -Brian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] using ghc as a library
On Mon, Oct 27, 2008 at 3:27 AM, Thomas Schilling [EMAIL PROTECTED] wrote: I'm not quite sure what you are trying to do. But for what it's worth, you can load a specific file via setTarget [Target (TargetFile foo/blah.hs) True Nothing] right, but I cant do that from inside a module in place of an import. Is there any way to for me to somehow tell ghc, or my wrapper, that I want to load a module from a specific directory, regardless of what the current include flags are? Anatoly ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell on the JVM
On Mon, Oct 27, 2008 at 12:02 PM, Brian Alliet [EMAIL PROTECTED] wrote: On Mon, Oct 27, 2008 at 10:58:11AM +, Simon Peyton-Jones wrote: Is there an interest in hosting GHC on the JVM (besides my own). Yep. I wrote a JVM backend for GHC (LambdaVM). It is suffering from bit-rot though. I think this thread has re-spaked my interest in it though. I don't think it's so hard to translate GHC's Core language to the JVM. Definitely not. That is more or less the route I took (I actually transform STG it into yet another simple intermediate laguage that is more JVM friendly, this was more for optimization purposes though). While C-- looks fantastic for generating native code, it just didn't seem worth the effort to shoehorn it into the JVM. Although I haven't looked at any of the new backend stuff, I suspect it still won't be suitable for the JVM. -Brian _ Being able to integrate Haskell into a rather large Java codebase might have made me not choose Erlang. Luckily, the OTP Erlang distribution had a lot of other really desirable features for the project I was working, yet I feel the lack of strong type checking hurt my productivity a bit, especially when trying to come up with a way to specify the real INs and OUTs between the Java and the Erlang code in terms of types. The right way to solve that problem is with a stronger specification between the Java team, and the Erlang team (aka me), however, it was still a really positive experience in the ways of functional programming, and I suppose I could have used Haskell to generate the glue between Java and Erlang had I been a better Haskeller :-). __ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell on the JVM
Please, oh please, get it into GHC Head! You'll be my hero. Regards, John A. De Goes N-BRAIN, Inc. http://www.n-brain.net [n minds are better than n-1] On Oct 27, 2008, at 3:02 PM, Brian Alliet wrote: On Mon, Oct 27, 2008 at 10:58:11AM +, Simon Peyton-Jones wrote: Is there an interest in hosting GHC on the JVM (besides my own). Yep. I wrote a JVM backend for GHC (LambdaVM). It is suffering from bit-rot though. I think this thread has re-spaked my interest in it though. I don't think it's so hard to translate GHC's Core language to the JVM. Definitely not. That is more or less the route I took (I actually transform STG it into yet another simple intermediate laguage that is more JVM friendly, this was more for optimization purposes though). While C-- looks fantastic for generating native code, it just didn't seem worth the effort to shoehorn it into the JVM. Although I haven't looked at any of the new backend stuff, I suspect it still won't be suitable for the JVM. -Brian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why 'round' does not just round numbers ?
On Mon, 27 Oct 2008, Ketil Malde wrote: Of course, Haskell should discard the rather tasteless IEEE754 crud, and do its calculations on infinite streams of digits. Then, rounding upwards after 'take'ing a sufficient amount of decimals will be the right thing to do. When I implemented just this in http://darcs.haskell.org/numericprelude/src/Number/Positional.hs I used redundant sets of digits. In a base-n number I use the digits 1-n to n-1. That is, the truncated number abc.def actually represents the interval [abc.def-0.001, abd.def+0.001]. This representation is not unique (more non-unique than standard base-n representation), but testing numbers with infinitely many places for equality is not possible anyway. So (==) is obsolete, just like for floating point numbers. The advantage is that carries are reduced considerably. It allows to compute (sqrt 2)^2, which is not possible in standard representation, because one can never decide whether the result is 2.0... or 1.9 (Pentium's division algorithm also uses digits -1, 0, 1 (we could call them mone (minus one), none, one) for reduced carries.) In this redundant representation one could simply round by truncation, the result depends on the particular sequence of digits used to represent a number, and the rounding would not become worse by repeated rounding (also because it is already worse than the Haskel 98 rounding since the error with respect to the last digit is not only 0.5 but up to 1 :-). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why 'round' does not just round numbers ?
On Mon, 27 Oct 2008, Janis Voigtlaender wrote: Lennart Augustsson wrote: I can't remember the method being called anything. It was just what we were being taught. With the obvious explanation that .5 is right in the middle so always going one way would introduce a bias. This was circa 1969. Well, I wasn't serious about the political explanation. And yes, the avoiding bias explanation makes sense, but not the this way of rounding makes repeated rounding safe explanation. In measured data the .5-case should be very rare - a null set? However I assume that .5 happens more often in practice - because of prior rounding, which was shown to be bad practice in this thread. :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problem with haddock 2.3.0
What the ..? Is that some sort of a virus? On 28 Oct 2008, at 01:05, Fegaras, Leonidas wrote: You have received a secure message Read your secure message by opening the attachment, securedoc.html. You will be prompted to open (view) the file or save (download) it to your computer. For best results, save the file first, then open it in a Web browser. To access from a mobile device, forward this message to [EMAIL PROTECTED] to receive a mobile login URL. If you have concerns about the validity of this message, contact the sender directly. First time users - will need to register after opening the attachment. Help - https://res.cisco.com/websafe/help?topic=RegEnvelope About Cisco Registered Email Service - https://res.cisco.com/websafe/about securedoc.html___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] using ghc as a library
Not at the moment. I was thinking about abstracting out the finder, which might be useful for other things, too. Can you maybe describe your actual goal? Adding an import foo/bar would not parse, so you must have some kind of preprocessing going on, so you might be able to insert some dummy imports there which you then have to provide. E.g.: import foo/bar.hs ~~ import CafeF00d.Foo.Bar, and you then copy (or symlink) foo/bar.hs to CafeF00d/Foo/Bar.hs. You can put those into a special directory which you prepend to the list of searched directories. I still can't see a good use case for this, though. 2008/10/27 Anatoly Yakovenko [EMAIL PROTECTED]: On Mon, Oct 27, 2008 at 3:27 AM, Thomas Schilling [EMAIL PROTECTED] wrote: I'm not quite sure what you are trying to do. But for what it's worth, you can load a specific file via setTarget [Target (TargetFile foo/blah.hs) True Nothing] right, but I cant do that from inside a module in place of an import. Is there any way to for me to somehow tell ghc, or my wrapper, that I want to load a module from a specific directory, regardless of what the current include flags are? Anatoly ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] IORef sharing
Hello Rodney,
Tuesday, October 28, 2008, 1:27:26 AM, you wrote:
Now I define an IORef and a couple of counters that share
the IORef,
iio :: IO (IORef Int)
iio = newIORef 0
ic1 = do { io - iio ; count io 0 }
ic2 = do { io - iio ; count io 0 }
So apparently my mental picture of an IORef as a pointer
to a value is wrong. I need a new mental picture. What's
going on here?
this part is right. but iio = newIORef 0 doesn't define IORef,
instead it defines *operation* that creates new IORef and returns it
then ic1 and ic2 are *operations* that performs iio, creating new IORef
on each call, and then use this new IORef in further operation
look at http://haskell.org/haskellwiki/IO_inside
--
Best regards,
Bulatmailto:[EMAIL PROTECTED]
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Problem with haddock 2.3.0 (again)
Sorry for the previous message. I am sending it again. Dear fellow haskell programmers, I tried to install a package in hackageDB and got a strange error from haddock: haddock: internal Haddock or GHC error: Maybe.fromJust: Nothing Here is the complete log: http://hackage.haskell.org/packages/archive/HXQ/0.10.0/logs/failure/ghc-6.8 When I build it using Cabal 1.6.0.1 and haddock 2.2.2 using 'runhaskell Setup.lhs haddock', it works fine (I get warnings but no errors). Also haddock 2.3.0 is not available in hackageDB so I can't test it myself. Where I can find haddock 2.3.0? Thank you for your help, Leonidas Fegaras _ Stay organized with simple drag and drop from Windows Live Hotmail. http://windowslive.com/Explore/hotmail?ocid=TXT_TAGLM_WL_hotmail_102008___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problem with haddock 2.3.0 (again)
I think this is a bug in Haddock related to template-haskell declarations. It will hopefully be fixed soon, but I'm afraid it won't part of the 2.3.0 version that will come with GHC 6.10.1. David 2008/10/27 Leonidas Fegaras [EMAIL PROTECTED]: Sorry for the previous message. I am sending it again. Dear fellow haskell programmers, I tried to install a package in hackageDB and got a strange error from haddock: haddock: internal Haddock or GHC error: Maybe.fromJust: Nothing Here is the complete log: http://hackage.haskell.org/packages/archive/HXQ/0.10.0/logs/failure/ghc-6.8 When I build it using Cabal 1.6.0.1 and haddock 2.2.2 using 'runhaskell Setup.lhs haddock', it works fine (I get warnings but no errors). Also haddock 2.3.0 is not available in hackageDB so I can't test it myself. Where I can find haddock 2.3.0? Thank you for your help, Leonidas Fegaras _ Stay organized with simple drag and drop from Windows Live Hotmail. http://windowslive.com/Explore/hotmail?ocid=TXT_TAGLM_WL_hotmail_102008___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] What's this algebraic structure called?
Is there a special name for an operator monoid where the structure that's acted on is an Abelian group? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Why 'round' does not just round numbers ?
G'day all. Quoting Mitchell, Neil [EMAIL PROTECTED]: With rounding to the nearest even integer for 0.5's you get 6, otherwise if you always round up you get 7. If you bias towards rounding up you get a general upwards trend as numbers are rounded, which is bad, while the even condition ensures that statistically it averages to the same thing. There are also many numeric algorithms for which the rounding pattern in the least-significant digit is somewhat systematic. A simple example might be this: x - round(x + 0.5) x - round(x - 0.5) x - round(x + 0.5) x - round(x - 0.5) ... etc If you try this procedure starting with, say, x = 1.5, you can see a clear difference between round-up and round-to-even. With round-up, the rounding error is keeps increasing as the procedure continues. With round-to-even, the error is bounded. Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why 'round' does not just round numbers ?
G'day all. Quoting Daniel Fischer [EMAIL PROTECTED]: Who does such horrible things? Repeat after me: 1 is NOT a prime. Never, under no circumstances. The definition of prime is well-understood standard terminology, but that doesn't escape the fact that it's arbitrary and human-defined. I'll bet you insist on the non-triviality axiom for fields, too. Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Why 'round' does not just round numbers ?
G'day all. Henning Thielemann suggested: In measured data the .5-case should be very rare - a null set? However I assume that .5 happens more often in practice - because of prior rounding, which was shown to be bad practice in this thread. The usual case in floating point is usually not 0.5, but some power of 0.5 just beyond the precision of the mantissa. And this is actually one of the most common cases in rounding, due to the fact that we use binary arithmetic. Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why 'round' does not just round numbers ?
On 27 Oct 2008, at 11:00 pm, Henning Thielemann wrote: On Mon, 27 Oct 2008, L.Guo wrote: I think this is unresonable. then try it in GHC 6.8.3. Prelude round 3.5 4 Prelude round 2.5 2 Is there any explanation about that ? It's the definition we learnt in school ... Check http://en.wikipedia.org/wiki/Rounding where you will find that the version of rounding generally taught in elementary schools is the one used in Pascal, namely round(X) = truncate(X + 0.5*sign(X)) (The Wikipedia entry says that Pascal uses a different algorithm, but ISO 7185 says If x is positive or zero, round(x) shall be equivalent to trunc(x +0.5); otherwise, round(x) shall be equivalent to trunc(x-0.5).) I think one reason is that repeated rounding should not be worse than rounding in one go. That would be nice, but while round-to-even _reduces_ the harm from double rounding, it does not eliminate it. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What's this algebraic structure called?
On Tue, 2008-10-28 at 13:54 +1300, Richard O'Keefe wrote: Is there a special name for an operator monoid where the structure that's acted on is an Abelian group? This should just be equivalent to a ring, maybe without distributivity. Maybe missing some other properties depending on what you mean by operator. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why 'round' does not just round numbers ?
On 28 Oct 2008, at 11:11 am, Henning Thielemann wrote: In measured data the .5-case should be very rare - a null set? However I assume that .5 happens more often in practice - because of prior rounding, Think about money. When I was a child, farthings (1/4 of a penny) had just been dropped. (By now, our smallest coin is 10c, formerly a shilling, so in ~ 50 years the value of the smallest coin has eroded by a factor of 48.) Ha'pennies (1/2 of a penny) were still around. If you were adding up a sum of money, sums ending with 1/2 were actually quite common. When the ha'penny went the way of the farthing, one still had to round sums in pounds shillings and pence to sums in pounds and shillings, and sixpence (0.5 of a shilling) was not an unlikely amount. Now that the smallest coin is 10c, supermarkets still price things in multiples of 1c, so in order to give change, they have to round to a multuple of 10c. Sums that end with 5c are not at all unusual. Considering that the point of the thread is what should we expect rounding to do, it may be of interest that a couple of years after the death of the 5c piece, supermarkets *still* display their rounding rule at the cash registers. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Memory efficiency questions for real-time graphics
As my first Haskell exposure, I've been working through Real World Haskell. I am considering converting some of my C++ graphics libraries to Haskell. I've done a fair amount of googling on the subject, however I haven't quite been able to find clear answers to some of following issues. (1) Using an OpenGL vertex array (a contiguous chunk of memory which is handed to the graphics card) is important. I see the source code of Frag does this, so it looks like we're good. Check. (2) In-place modification of the vertex array is important. Every vertex changes on each frame update. And we always want more vertices. (3) Growing and shrinking the vertex array efficiently is important. Here the behavior of C++ std::vector happens to be ideal. When growing, extend the array in-place if possible (using reserved space if any), otherwise allocate a new chunk (amortized constant time). When shrinking, do nothing but record the smaller size; the unused memory chunk is reserved for possible future growth. (4) Doing little to no allocations each frame update is important. In the current C++ version, zero allocations occur during a normal frame update. When the vertex array changes, that is the only allocation which happens. To give a context for all of this, I am applying a non-linear transformation to an object on every frame. (Note: non-linear, so a matrix transform will not suffice.) The object is described by a certain function, and is generated from a 3D domain grid. The user can change the resolution of the grid on the fly, while the object is moving. (Hence the need for grow/shrink efficiency.) Given that (1) is out of the way, what's the best I expect from Haskell concerning (2)-(4)? Thanks, T. Willingham ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Memory efficiency questions for real-time graphics
t.r.willingham: As my first Haskell exposure, I've been working through Real World Haskell. I am considering converting some of my C++ graphics libraries to Haskell. I've done a fair amount of googling on the subject, however I haven't quite been able to find clear answers to some of following issues. (1) Using an OpenGL vertex array (a contiguous chunk of memory which is handed to the graphics card) is important. I see the source code of Frag does this, so it looks like we're good. Check. (2) In-place modification of the vertex array is important. Every vertex changes on each frame update. And we always want more vertices. I imagine these are mutable arrays, so that's fine. (3) Growing and shrinking the vertex array efficiently is important. Here the behavior of C++ std::vector happens to be ideal. When growing, extend the array in-place if possible (using reserved space if any), otherwise allocate a new chunk (amortized constant time). When shrinking, do nothing but record the smaller size; the unused memory chunk is reserved for possible future growth. Easy enough. You're working with raw arrays of memory , I assume (e.g. UArrays or Ptr a?) (4) Doing little to no allocations each frame update is important. In the current C++ version, zero allocations occur during a normal frame update. When the vertex array changes, that is the only allocation which happens. This is certainly possible. To confirm it, look at the generated Core code, produced by GHC (with the ghc-core tool). See the realworldhaskell chapter on optimisation. To give a context for all of this, I am applying a non-linear transformation to an object on every frame. (Note: non-linear, so a matrix transform will not suffice.) The object is described by a certain function, and is generated from a 3D domain grid. The user can change the resolution of the grid on the fly, while the object is moving. (Hence the need for grow/shrink efficiency.) Given that (1) is out of the way, what's the best I expect from Haskell concerning (2)-(4)? Seems fine. You'll be working at a low level, with strict, mutable, unboxed data structures, but that's fine: the machine loves them. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Poll: Do you need to be able to build darcs from source on GHC 6.6?
Hello, I would like to find out if any darcs users who build from the source are still using ghc 6.6? If you are such a user, please let me know. Thanks, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Problems building HOC
Hi all, I'm trying to get HOC to build because I'd like to take Yi for a spin and see how it works. I followed the instructions in the Yi README, but I can't get HOC to build. It seems like HOC is under pretty heavy development right now, so maybe this is something transient. I didn't build libffi because according to the Yi docs that's not required on Leopard. HOC built and installed ok, however it failed on the bindings generation step - I've pasted the full compile output below. Am I doing something daft? I'm an (almost) total Haskell newbie so this is entirely possible... I'm using GHC 6.8.2 from MacPorts, and OSX 10.5.5. Thanks for any help! Cheers, Colin ~/dev/haskell/hoc/Bindings bash make-bindings-macos.sh --user *** Processing Framework Foundation *** NSObjCRuntime.h:139:32: NSIntegerMax undefined [ ] NSObjCRuntime.h:139:32: Couldn't handle enum value for NSNotFound ] NSPropertyList.h:13:55: kCFPropertyListImmutable undefined] NSPropertyList.h:13:55: Couldn't handle enum value for NSPropertyListImmutable] NSPropertyList.h:14:71: kCFPropertyListMutableContainers undefined] NSPropertyList.h:14:71: Couldn't handle enum value for NSPropertyListMutableContainers NSPropertyList.h:16:1: kCFPropertyListMutableContainersAndLeaves undefined] NSPropertyList.h:16:1: Couldn't handle enum value for NSPropertyListMutableContainersAndLeaves NSPropertyList.h:20:65: kCFPropertyListOpenStepFormat undefined ] NSPropertyList.h:20:65: Couldn't handle enum value for NSPropertyListOpenStepFormat NSPropertyList.h:21:65: kCFPropertyListXMLFormat_v1_0 undefined ] NSPropertyList.h:21:65: Couldn't handle enum value for NSPropertyListXMLFormat_v1_0 NSPropertyList.h:23:1: kCFPropertyListBinaryFormat_v1_0 undefined NSPropertyList.h:23:1: Couldn't handle enum value for NSPropertyListBinaryFormat_v1_0 NSNumberFormatter.h:39:57: kCFNumberFormatterNoStyle undefined*** ] NSNumberFormatter.h:39:57: Couldn't handle enum value for NSNumberFormatterNoStyle NSNumberFormatter.h:40:67: kCFNumberFormatterDecimalStyle undefined NSNumberFormatter.h:40:67: Couldn't handle enum value for NSNumberFormatterDecimalStyle NSNumberFormatter.h:41:69: kCFNumberFormatterCurrencyStyle undefined NSNumberFormatter.h:41:69: Couldn't handle enum value for NSNumberFormatterCurrencyStyle NSNumberFormatter.h:42:67: kCFNumberFormatterPercentStyle undefined NSNumberFormatter.h:42:67: Couldn't handle enum value for NSNumberFormatterPercentStyle NSNumberFormatter.h:43:73: kCFNumberFormatterScientificStyle undefined NSNumberFormatter.h:43:73: Couldn't handle enum value for NSNumberFormatterScientificStyle NSNumberFormatter.h:45:1: kCFNumberFormatterSpellOutStyle undefined NSNumberFormatter.h:45:1: Couldn't handle enum value for NSNumberFormatterSpellOutStyle NSNumberFormatter.h:189:73: kCFNumberFormatterPadBeforePrefix undefined NSNumberFormatter.h:189:73: Couldn't handle enum value for NSNumberFormatterPadBeforePrefix NSNumberFormatter.h:190:71: kCFNumberFormatterPadAfterPrefix undefined NSNumberFormatter.h:190:71: Couldn't handle enum value for NSNumberFormatterPadAfterPrefix NSNumberFormatter.h:191:73: kCFNumberFormatterPadBeforeSuffix undefined NSNumberFormatter.h:191:73: Couldn't handle enum value for NSNumberFormatterPadBeforeSuffix NSNumberFormatter.h:193:1: kCFNumberFormatterPadAfterSuffix undefined NSNumberFormatter.h:193:1: Couldn't handle enum value for NSNumberFormatterPadAfterSuffix NSNumberFormatter.h:200:67: kCFNumberFormatterRoundCeiling undefined NSNumberFormatter.h:200:67: Couldn't handle enum value for NSNumberFormatterRoundCeiling NSNumberFormatter.h:201:63: kCFNumberFormatterRoundFloor undefined NSNumberFormatter.h:201:63: Couldn't handle enum value for NSNumberFormatterRoundFloor NSNumberFormatter.h:202:61: kCFNumberFormatterRoundDown undefined NSNumberFormatter.h:202:61: Couldn't handle enum value for NSNumberFormatterRoundDown NSNumberFormatter.h:203:57: kCFNumberFormatterRoundUp undefined NSNumberFormatter.h:203:57: Couldn't handle enum value for NSNumberFormatterRoundUp NSNumberFormatter.h:204:69: kCFNumberFormatterRoundHalfEven undefined NSNumberFormatter.h:204:69: Couldn't handle enum value for NSNumberFormatterRoundHalfEven NSNumberFormatter.h:205:69: kCFNumberFormatterRoundHalfDown undefined NSNumberFormatter.h:205:69: Couldn't handle enum value for NSNumberFormatterRoundHalfDown NSNumberFormatter.h:207:1: kCFNumberFormatterRoundHalfUp undefined NSNumberFormatter.h:207:1: Couldn't handle enum value for NSNumberFormatterRoundHalfUp NSDecimal.h:49:1: problem parsing struct61% [*** ] NSDateFormatter.h:40:53: kCFDateFormatterNoStyle undefined*** ] NSDateFormatter.h:40:53: Couldn't handle enum value for NSDateFormatterNoStyle NSDateFormatter.h:41:59: kCFDateFormatterShortStyle undefined NSDateFormatter.h:41:59: Couldn't handle enum value for
Re: [Haskell-cafe] What's this algebraic structure called?
On 28 Oct 2008, at 2:54 pm, Derek Elkins wrote: On Tue, 2008-10-28 at 13:54 +1300, Richard O'Keefe wrote: Is there a special name for an operator monoid where the structure that's acted on is an Abelian group? This should just be equivalent to a ring, maybe without distributivity. Maybe missing some other properties depending on what you mean by operator. Yes, it's close to a ring, but we have ((M,*,1),(X,+,0,-)) where (M,*,1) is the monoid and (X,+,0,-) is the Abelian group. For what I have in mind the sets M and X are disjoint. For a ring they would be identical. (This being Haskell-Café, I knew types would come in useful...) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What's this algebraic structure called?
On Tue, 2008-10-28 at 15:43 +1300, Richard O'Keefe wrote: On 28 Oct 2008, at 2:54 pm, Derek Elkins wrote: On Tue, 2008-10-28 at 13:54 +1300, Richard O'Keefe wrote: Is there a special name for an operator monoid where the structure that's acted on is an Abelian group? This should just be equivalent to a ring, maybe without distributivity. Maybe missing some other properties depending on what you mean by operator. Yes, it's close to a ring, but we have ((M,*,1),(X,+,0,-)) where (M,*,1) is the monoid and (X,+,0,-) is the Abelian group. For what I have in mind the sets M and X are disjoint. For a ring they would be identical. (This being Haskell-Café, I knew types would come in useful...) Some variation on a module then: http://en.wikipedia.org/wiki/Module_(mathematics) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [darcs-users] Poll: Do you need to be able to build darcs from source on GHC 6.6?
On Mon, Oct 27, 2008 at 07:24:31PM -0700, Jason Dagit wrote: I would like to find out if any darcs users who build from the source are still using ghc 6.6? If you are such a user, please let me know. Yep. OpenBSD is still at ghc-6.6. Ciao, Kili -- Trust your brain, not the machine. -- Nick Holland ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Memory efficiency questions for real-time graphics
On Mon, Oct 27, 2008 at 10:07 PM, Don Stewart [EMAIL PROTECTED] wrote: Seems fine. You'll be working at a low level, with strict, mutable, unboxed data structures, but that's fine: the machine loves them. Thanks for the quick reply. One last question -- is it at all possible to segfault with strict, mutable, unboxed structures? I don't quite understand how it knows not to overwrite or underwrite. Cheers, T. Willingham ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Memory efficiency questions for real-time graphics
t.r.willingham: On Mon, Oct 27, 2008 at 10:07 PM, Don Stewart [EMAIL PROTECTED] wrote: Seems fine. You'll be working at a low level, with strict, mutable, unboxed data structures, but that's fine: the machine loves them. Thanks for the quick reply. One last question -- is it at all possible to segfault with strict, mutable, unboxed structures? I don't quite understand how it knows not to overwrite or underwrite. It depends on the operations (safe indexing or unsafe indexing). Being strict or unboxed doesn't determine the safety. So be careful if you have a 'Ptr a' or start using unsafeWrite. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal and GHCi
reiner.pope: Hi, Is there a way to use GHCi with code which is cabal-buildable but not ghc --make-able? The emacs haskell-mode makes a pretty good guess by :cd-ing into the directory with the .cabal file; however, if there is a different source-dir this doesn't work so well. A number of more advanced cabal features are even harder to handle. Not currently. Duncan's interested in implementing this, so if you add a tacket for a 'cabal ghci' mode, that loads up the main-is target in ghci, with all the appropriate flags, he might well implement it :-) -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What's this algebraic structure called?
On Tue, 2008-10-28 at 15:43 +1300, Richard O'Keefe wrote: On 28 Oct 2008, at 2:54 pm, Derek Elkins wrote: On Tue, 2008-10-28 at 13:54 +1300, Richard O'Keefe wrote: Is there a special name for an operator monoid where the structure that's acted on is an Abelian group? This should just be equivalent to a ring, maybe without distributivity. Maybe missing some other properties depending on what you mean by operator. Yes, it's close to a ring, but we have ((M,*,1),(X,+,0,-)) where (M,*,1) is the monoid and (X,+,0,-) is the Abelian group. For what I have in mind the sets M and X are disjoint. For a ring they would be identical. (This being Haskell-Café, I knew types would come in useful...) Actually modules more or less come back to rings. The issue again comes back to what you mean by operator. Let's pick a general notion. You haven't provided enough information above because you've given no way to connect M and X, which I'll call G for clarity. So let's posit an operation, a monoid action, M x G - G to have M operate on G. M - End(G) is isomorphic (via an isomorphism we all know and love.) End(G) is at least a non-distributive ring with * = o, and + = + (pointwise). So for a given f : M - End(G), f(M) ~ H \subset End(G). H is a submonoid of End(G) which we can extend with all sums of elements in H into a non-distributive ring that is a subset of End(G). If f(m) for all m in M does distribute over +, then the extension step is unnecessary and H is a ring. This is a bunch of random unchecked math. At any rate, I don't think there is a specific name for exactly what you want, though I'm still not sure quite what you want. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why 'round' does not just round numbers ?
Peter Gavin pgavin at gmail.com writes: The reason for doing it this way is that e.g. 2.5 is exactly between 2 and 3, and rounding *up* every time would cause an uneven bias toward 3. To counteract that effect, rounding to the nearest even integer is used, which causes the half of the x.5 values to round up, and the other half to round down. Everyone keeps providing this rationale, but of course if you want half the values to round up and the other half down it does just as well to round positive values up and negative values down. I think given that the Haskell 98 Report is pretty explicit about the behavior of round, we're stuck with it, but I don't like it. It's yet another tiny impediment to Haskell newbies, as demonstrated by the original post. (I'm not at all opposed to having a round-to-even function; it should just be called roundHalfEven to make it clear what it does. If it were up to me, I would probably elide the name round altogether in favor of roundHalfEven.) I have written floating point code that depends on consistent rounding in the past. Being able to depend on round (1 + x) = 1 + round x is sometimes useful, but not possible for round-to-even. Also note that for a common case, rounding numbers in the range -x..x, there's still a strange slight bias toward the center, since round-to-even rounds both 0.5 and -0.5 to 0. BTW, in case anyone is unclear, IEEE 854 supports a large variety of required and optional rounding modes; it takes no strong position on a correct rounding strategy. In particular, round-up (round-half-up) and round-to-even (round-half-even) are both required. However, there is an IEEE 854 subset, ANSI X3.274, that does make rounding modes other than round-up optional, presumably in conformance with common PL practice. This might make an implementation of the Report's round function on some FPU I've never heard of slightly more expensive. Bart Massey bart at cs.pdx.edu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Memory efficiency questions for real-time graphics
On Mon, Oct 27, 2008 at 11:04 PM, Don Stewart [EMAIL PROTECTED] wrote: It depends on the operations (safe indexing or unsafe indexing). Being strict or unboxed doesn't determine the safety. OK, that makes sense. This is a huge load off my conscience. I can now dig into Real World Haskell without hesitation, knowing that what I want in the end is actually possible. Thanks again, TW ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Memory efficiency questions for real-time graphics
By the way, T, feel free to lean on me if you run into any problems. I did something along the lines of what you were describing some time ago, my particular non-linear transform being converting a vertex array to/from polar coordinates and updating in realtime. -- Jeff On Tue, Oct 28, 2008 at 12:00 AM, T Willingham [EMAIL PROTECTED] wrote: On Mon, Oct 27, 2008 at 11:04 PM, Don Stewart [EMAIL PROTECTED] wrote: It depends on the operations (safe indexing or unsafe indexing). Being strict or unboxed doesn't determine the safety. OK, that makes sense. This is a huge load off my conscience. I can now dig into Real World Haskell without hesitation, knowing that what I want in the end is actually possible. Thanks again, TW ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- I try to take things like a crow; war and chaos don't always ruin a picnic, they just mean you have to be careful what you swallow. -- Jessica Edwards ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why 'round' does not just round numbers ?
On 2008-10-27, Bart Massey [EMAIL PROTECTED] wrote: Peter Gavin pgavin at gmail.com writes: The reason for doing it this way is that e.g. 2.5 is exactly between 2 and 3, and rounding *up* every time would cause an uneven bias toward 3. To counteract that effect, rounding to the nearest even integer is used, which causes the half of the x.5 values to round up, and the other half to round down. Everyone keeps providing this rationale, but of course if you want half the values to round up and the other half down it does just as well to round positive values up and negative values down. Except, of course, that it is quite common to work with just positive numbers. Working just with numbers near (even + 0.5) or (odd + 0.5) is extremely rare. I have written floating point code that depends on consistent rounding in the past. Being able to depend on round (1 + x) = 1 + round x is sometimes useful, but not possible for round-to-even. Also not for round-up -- consider floating point values where the precision changes and it rounds differently than you, or the point where adjacent floating point values are now 2 apart. You basically can't depend on any nice behaviour once floating point enters the room. -- Aaron Denney -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What's this algebraic structure called?
On 28 Oct 2008, at 3:51 pm, Derek Elkins wrote: Some variation on a module then: http://en.wikipedia.org/wiki/Module_(mathematics) When you have M acting on X and X is an abelian group: M is a field = vector space M is a ring = module M is a semiring = module over a semiring M is a monoid = ??? Maybe I can generalise M to a ring after all... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal and GHCi
On Tue, Oct 28, 2008 at 2:23 PM, Don Stewart [EMAIL PROTECTED] wrote: reiner.pope: Hi, Is there a way to use GHCi with code which is cabal-buildable but not ghc --make-able? The emacs haskell-mode makes a pretty good guess by :cd-ing into the directory with the .cabal file; however, if there is a different source-dir this doesn't work so well. A number of more advanced cabal features are even harder to handle. Not currently. Duncan's interested in implementing this, so if you add a tacket for a 'cabal ghci' mode, that loads up the main-is target in ghci, with all the appropriate flags, he might well implement it :-) -- Don Done: http://hackage.haskell.org/trac/hackage/ticket/382 :-) Reiner ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
