Re: [Haskell-cafe] rounding errors with real numbers.
cancellation happens for instance here: 1 + 1e-50 - 1 == 0 the function again (in the wasteful original form, for clarity). where do you think cancellation may take place? isn't what you call canellation a generic rounding error? ++ normInterval :: [Double] - Double - Double - [Double] normInterval ps lower upper = repair (map (\ x - (x - oldLower) * stretch + lower) ps) where oldLower = head ps oldUpper = last ps stretch = (upper - lower) / (oldUpper - oldLower) -- fix rounding error: repair [i] = [upper] repair (h:t) = h : repair t ++ (x-oldLower)*a + (oldUpper-x)*b i got this into my head though. neat. thanks! i will rewrite the function right now. cheers, matthias signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] trying to understand runProcess handles
hi there, I am running some unix command. I just realized there is runInteractiveProcess in System.Process, so my problem is solved in practice: ++ showPlot :: String - IO (Handle, Handle, Handle, ProcessHandle) showPlot file = runInteractiveProcess executable arguments wd env where executable = /usr/bin/gnuplot arguments= [-geometry, -19+3, file, -] wd = Nothing env = Nothing ++ But first I tried to create the handles myself with createPipe from System.Posix.IO, and I failed for a reasons that I have no clue how to learn to understand. This is what the code looked like: ++ showPlot :: String - IO (ProcessHandle, Handle, Handle, Handle) showPlot file = do (stdinR, stdinW) - createPipeHandles (stdoutR, stdoutW) - createPipeHandles (stderrR, stderrW) - createPipeHandles h - runProcess executable arguments wd env (Just stdinR) (Just stdoutW) (Just stderr W) return (h, stdinW, stdoutR, stderrR) where executable = /usr/bin/gnuplot arguments= [-geometry, -19+3, file, -] wd = Nothing env = Nothing createPipeHandles :: IO (Handle, Handle) createPipeHandles = do (fR, fW) - createPipe hR - fdToHandle fR hW - fdToHandle fW return (hR, hW) ++ The problem is that gnuplot terminates right away after it tries to read from stdin (I can see the shadow of a window appear and vanish immediately). I tried setFdOption, with no effect. Is this because the handles passed to runProcess are closed in the parent process, and therefore the pipe is teared down and useless? I don't think so: If I run 'find /' instead of gnuplot, the process happily starts and I can hGetLine from stdout. If you have any clue I'd love to learn. Anyway, as I said, it's really better to simply use runInteractiveProcess in this simple case. thanks, Matthias signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] rounding errors with real numbers.
On Thu, 2 Mar 2006, Matthias Fischmann wrote: cancellation happens for instance here: 1 + 1e-50 - 1 == 0 the function again (in the wasteful original form, for clarity). where do you think cancellation may take place? isn't what you call canellation a generic rounding error? Cancellation is a special kind of rounding error. Rounding errors appear everywhere, in (*), sin, exp and so on, but cancellations only arise on differences. They are especially bad, because as the example above shows, even if all numbers are given in double precision in the computation a+b-a, no digit of the result is correct, that is 100% rounding error! The danger of cancellation is everywhere where you subtract numbers of similar magnitude. In your example: If lower=-10, upper=1, x approximately oldUpper then you get the effect at the '+' in ((x - oldLower) * stretch + lower). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] rounding errors with real numbers.
On Fri, Mar 03, 2006 at 01:29:06PM +0100, Henning Thielemann wrote: To: Matthias Fischmann [EMAIL PROTECTED] cc: haskell-cafe@haskell.org From: Henning Thielemann [EMAIL PROTECTED] Date: Fri, 3 Mar 2006 13:29:06 +0100 (MET) Subject: Re: [Haskell-cafe] rounding errors with real numbers. On Thu, 2 Mar 2006, Matthias Fischmann wrote: cancellation happens for instance here: 1 + 1e-50 - 1 == 0 the function again (in the wasteful original form, for clarity). where do you think cancellation may take place? isn't what you call canellation a generic rounding error? Cancellation is a special kind of rounding error. Rounding errors appear everywhere, in (*), sin, exp and so on, but cancellations only arise on differences. They are especially bad, because as the example above shows, even if all numbers are given in double precision in the computation a+b-a, no digit of the result is correct, that is 100% rounding error! The danger of cancellation is everywhere where you subtract numbers of similar magnitude. 1 + epsilon - 1 == epsilon, which is zero except for a very small rounding error somewhere deep in the e-minus-somethings. how is the error getting worse than that, for which numbers? m. signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] rounding errors with real numbers.
On Fri, 3 Mar 2006, Matthias Fischmann wrote: 1 + epsilon - 1 == epsilon, which is zero except for a very small rounding error somewhere deep in the e-minus-somethings. how is the error getting worse than that, for which numbers? I meant the relative error. epsilon should be the result, but the computer says 0, so the absolute error is epsilon and the relative error is 1, that is the number of reliable digits in the mantissa of the result is 0. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] rounding errors with real numbers.
ok, now i am intimidated enough to give up. (-:. thanks for trying, though. m. On Fri, Mar 03, 2006 at 03:19:44PM +0100, Henning Thielemann wrote: To: Matthias Fischmann [EMAIL PROTECTED] cc: haskell-cafe@haskell.org From: Henning Thielemann [EMAIL PROTECTED] Date: Fri, 3 Mar 2006 15:19:44 +0100 (MET) Subject: Re: [Haskell-cafe] rounding errors with real numbers. On Fri, 3 Mar 2006, Matthias Fischmann wrote: 1 + epsilon - 1 == epsilon, which is zero except for a very small rounding error somewhere deep in the e-minus-somethings. how is the error getting worse than that, for which numbers? I meant the relative error. epsilon should be the result, but the computer says 0, so the absolute error is epsilon and the relative error is 1, that is the number of reliable digits in the mantissa of the result is 0. signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] trying to understand runProcess handles
On Thu, 2 Mar 2006, Matthias Fischmann wrote: ... The problem is that gnuplot terminates right away after it tries to read from stdin (I can see the shadow of a window appear and vanish immediately). I tried setFdOption, with no effect. Is this because the handles passed to runProcess are closed in the parent process, and therefore the pipe is teared down and useless? I don't think so: If I run 'find /' instead of gnuplot, the process happily starts and I can hGetLine from stdout. That doesn't necessarily disprove your hypothesis, since find doesn't read input. You might try tr instead, for example. I don't see anything about what you were doing that would be obviously different from runProcessInteractive, but as long as you're making a pipe for error output, you may as well read it and see if gnuplot has left any clue to its problem there. Donn Cave, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Layout rule (was Re: PrefixMap: code reviewrequest)
Brian Hulley wrote:
Brian Hulley wrote:
One other thing I've been wanting to ask (not to change! :-)) for a
while is: how is the following acceptable according to the rules in
the Haskell98 report where where is one of the lexemes, which when
followed by a line more indented than the line the
layout-starting-lexeme is on, should start an implicit block:
module M where
data T = .-- not indented!
According to my understanding of the layout algorithm, the above code
would have to be written:
module M where
data T =
Can anyone shed some light on what the formal rule is that allows the
first (and very useful) way of laying out code to be ok?
The solution (as someone pointed out to me in an email) is that the layout
block only *finishes* when the current indentation is *less* than the
indentation of the lines in the layout block (rather than *starting* only
when the current indentation is *more* than the indentation of the line
containing the where etc).
However I think there is an error in the description of this in section 2.7
of the Haskell98 report, which states:
If the indentation of the non-brace lexeme immediately following a where,
let, do or of is less than or equal to the current indentation level, then
instead of starting a layout, an empty list {} is inserted, and layout
processing occurs for the current level ...
I dispute the or equal in the above statement, since it seems to be
clearly in contradiction to what is actually being done.
Regards, Brian.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] trying to understand runProcess handles
On Fri, Mar 03, 2006 at 09:05:49AM -0800, Donn Cave wrote: To: haskell-cafe@haskell.org From: Donn Cave [EMAIL PROTECTED] Date: Fri, 3 Mar 2006 09:05:49 -0800 (PST) Subject: Re: [Haskell-cafe] trying to understand runProcess handles On Thu, 2 Mar 2006, Matthias Fischmann wrote: ... The problem is that gnuplot terminates right away after it tries to read from stdin (I can see the shadow of a window appear and vanish immediately). I tried setFdOption, with no effect. Is this because the handles passed to runProcess are closed in the parent process, and therefore the pipe is teared down and useless? I don't think so: If I run 'find /' instead of gnuplot, the process happily starts and I can hGetLine from stdout. That doesn't necessarily disprove your hypothesis, since find doesn't read input. You might try tr instead, for example. I don't see anything about what you were doing that would be obviously different from runProcessInteractive, but as long as you're making a pipe for error output, you may as well read it and see if gnuplot has left any clue to its problem there. that doesn't work -- all the handles are closed at least after the process has died. hard to tell whether the process dying caused the handles to close or whether the handles were closed already by then. m. signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] trying to understand runProcess handles
On Fri, 3 Mar 2006, Matthias Fischmann wrote: ... but as long as you're making a pipe for error output, you may as well read it and see if gnuplot has left any clue to its problem there. that doesn't work -- all the handles are closed at least after the process has died. hard to tell whether the process dying caused the handles to close or whether the handles were closed already by then. Process exit closes the process' end of the pipes, but can't do anything to the other end. When it closes the write end, a read on the other end returns with end of file. The same pipe file descriptor may be inherited by multiple processes, any one of which may hold it open - only the last close matters. That's why functions like runProcess normally close the opposite ends of the pipe, in the parent child forks, so that the parent doesn't hold the child's open or vice versa. Donn Cave, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Layout rule (was Re: PrefixMap: code review request)
On 28/02/06, Brian Hulley [EMAIL PROTECTED] wrote: Why? Surely typing one tab is better than having to hit the spacebar 4 (or 8) times? I'm really puzled here. I've been using tabs to indent my C++ code for at least 10 years and don't see the problem. The only problem would be if someone mixed tabs with spaces. Since it has to be either tabs only or spaces only I'd choose tabs only to save keystrokes. I suppose though it is always going to be a matter of personal taste... It's easy to configure most editors (vim and emacs included of course) to treat multiple spaces as if they were tabs, but to only save spaces into your file. This is what I do, as it ensures that the way that the code looks to me in my editor is exactly what it looks like to the compiler. Quite often, if it looks better, I will align things past a tab stop with a few extra spaces (which only has to be done once, if your editor will start the next line at the same indentation as the previous). - Cale ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] afrp code base
I've been coming up to speed on afrp, and I see the code base is almost two years old. Is this the state of the art? Thanks. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] afrp code base
Instinctive wrote: I've been coming up to speed on afrp, and I see the code base is almost two years old. Is this the state of the art? Thanks. Henrik Nilsson wrote a paper[1] with (as far as I know unreleased) code for dynamic optimizations to yampa with GADTs. I believe that would be the state of the art, but I am not sure. - Sam [1] www.cs.nott.ac.uk/~nhn/Publications/icfp2005.pdf ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] afrp code base
instinctive: I've been coming up to speed on afrp, and I see the code base is almost two years old. Is this the state of the art? Thanks. Also, a practical application appeared this year with Frag -- Mun Hon Cheong's implementation of a Quake-like game in Haskell using OpenGL and Yampa. More details are in his undergraduate thesis, here: http://www.haskell.org/haskellwiki/Frag -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: haskell programming guidelines
On 01/03/06, Christian Maeder [EMAIL PROTECTED] wrote: In a more realistic example, the current dollars help to improve readability, I think, and that is my argument why $ should be right- associative: map (+ 1) $ filter (/= 0) $ Set.toList l An additional $ before the final argument ( $ l) looks stupid to me. I also find additional parentheses instead of the dollars more confusing, because of the other parts in parentheses. If you don't like map (+ 1) . filter (/= 0) . Set.toList $ l then map (+ 1) . filter (/= 0) $ Set.toList l works just as well. In this case it's also a fairly natural way to break up the thought process. Your main computation is solely a composition of list functions, and the conversion is part of how you get the input to it. - Cale ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
