Send Beginners mailing list submissions to
beginners@haskell.org
To subscribe or unsubscribe via the World Wide Web, visit
http://www.haskell.org/mailman/listinfo/beginners
or, via email, send a message with subject or body 'help' to
beginners-requ...@haskell.org
You can reach the person managing the list at
beginners-ow...@haskell.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."
Today's Topics:
1. Re: lhs2TeX (Daniel Seidel)
2. Re: [xmonad] xmonad vs. full screen (Thomas Friedrich)
3. High precision doubles (Aaron MacDonald)
4. Re: High precision doubles (Andrew Hunter)
5. Re: High precision doubles (Aaron MacDonald)
6. Re: High precision doubles (Sean Bartell)
7. Re: Re: [xmonad] xmonad vs. full screen (styx)
8. Re: High precision doubles (Daniel Fischer)
9. Re: High precision doubles
(Rafael Gustavo da Cunha Pereira Pinto)
----------------------------------------------------------------------
Message: 1
Date: Wed, 24 Jun 2009 08:47:04 +0200
From: Daniel Seidel <seid...@tcs.inf.tu-dresden.de>
Subject: Re: [Haskell-beginners] lhs2TeX
To: Thomas Friedrich <i...@suud.de>
Cc: beginners <beginners@haskell.org>
Message-ID: <4a41cbe8.50...@tcs.inf.tu-dresden.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Thomas Friedrich wrote:
> Hi everyone,
>
> A Google-search wasn't successful, that's why I am asking here. I want
> to use the program lhs2TeX. In the manual it says there are different
> styles that you can use, and some examples how they look like. But they
> never say how to call them. If I like to see the verbatim-style or the
> tt-style. What do I include in my document?
Hi,
lhs2TeX --verb input.lhs > output.tex
or everything else instead of --verb.
It is explained in
http://people.cs.uu.nl/andres/lhs2TeX-IFIP.pdf
Greetings,
Daniel.
------------------------------
Message: 2
Date: Wed, 24 Jun 2009 18:38:30 -0400
From: Thomas Friedrich <i...@suud.de>
Subject: [Haskell-beginners] Re: [xmonad] xmonad vs. full screen
To: beginners <beginners@haskell.org>
Message-ID: <4a42aae6.10...@suud.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Rickard Nilsson wrote:
> Quoting Thomas Friedrich <i...@suud.de>:
>> 2) I would propose going back to the old behavior of handling
>> full-screen-programs in xmonad. It really should be the *user* who
>> decides how "full-screen" a full-screen-program shall be. Isn't this
>> also more following the philosophy of xmonad? You as a user decide,
>> what is happening on your screen? It might be not as intuitive, when
>> switching to xmonad and you are used to other WMs, where full-screen
>> means *full screen*. I really miss that functionality, now that its
>> gone. What do you think?
>
> I think the old behaviour made much more sense. As it is now, it's not
> possible to play a web flash movie in a separate, arbitrarily sized,
> window. You either have to watch it fullscreen-floating, or integrated
> in the web-page.
>
> @Thomas - Did you ever manage to revert Xmonad to the old behaviour?
>
No unfortunately I didn't. I changed my manageHook to
myManageHookDef = scratchpadManageHook (W.RationalRect 0.25 0.375 0.5
0.35) <+> composeAll
[ ...
, isFullscreen --> doFullFloat
, isDialog --> doCenterFloat
]
This way, when I want to watch a Flash-Movie in full screen, the video
window actually covers the full screen. However, the downside of it is
that also xpdf and others start flouting when going to full screen.
Which is stupid, as I always have to push them back into the tiling,
when I want to have a "full screen" xpdf next to, say, emacs. Also you
will have a little border around the flouting window, which doesn't look
good in full screen. But I don't want to remove the borders from
flouting windows, as I like to have a border, when a flouting window is
not covering the whole screen.
So as you see, the solution is far from optimal.
Cheers,
Thomas
------------------------------
Message: 3
Date: Wed, 24 Jun 2009 20:46:04 -0300
From: Aaron MacDonald <aaro...@eastlink.ca>
Subject: [Haskell-beginners] High precision doubles
To: beginners@haskell.org
Message-ID: <ac540dfe-f2e4-4976-a4dc-78038ddb2...@eastlink.ca>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Is there anything in Haskell that can represent doubles with higher
precision than the regular kind? I'm working with formulas that
generate sets of values, and values that I know should be zero are
ending up as things like -7.105427357601002e-15 or
-1.7763568394002505e-14, which is causing all kinds of butterfly
effects.
I've heard of Rational, but I need to also work with irrational
numbers (namely, pi and anything that comes from cos and sin). What
other options do I have?
- Aaron
------------------------------
Message: 4
Date: Wed, 24 Jun 2009 18:18:19 -0700
From: Andrew Hunter <ahun...@cs.hmc.edu>
Subject: Re: [Haskell-beginners] High precision doubles
To: beginners@haskell.org
Message-ID: <20090625011819.ga14...@knuth.cs.hmc.edu>
Content-Type: text/plain; charset=us-ascii
On Wed, Jun 24, 2009 at 08:46:04PM -0300, Aaron MacDonald wrote:
> Is there anything in Haskell that can represent doubles with higher
> ^^^^^^^
No, I'm pretty sure "double precision" will be double precision
everywhere (systems not supporting IEEE-754 notwithstanding.) Want to
represent floating point numbers more precisely? That's feasible.
> precision than the regular kind? I'm working with formulas that generate
> sets of values, and values that I know should be zero are ending up as
> things like -7.105427357601002e-15 or -1.7763568394002505e-14, which is
> causing all kinds of butterfly effects.
>
> I've heard of Rational, but I need to also work with irrational numbers
> (namely, pi and anything that comes from cos and sin). What other options
> do I have?
>
Some systems have support for "long doubles", typically an 80-bit type
on x86; I don't know if Haskell provides any access to this. I doubt
it. If you want a more sledgehammerish approach, packages like HMPFR:
http://hackage.haskell.org/package/hmpfr
can provide arbitrary precision calculations. They're slow, though.
More to the point, however: you don't want more precision. Welcome to
the world of numerical algorithms; floating point arithmetic is
inherently inexact. Get used to it. For example, I'll bet your
errors are caused by testing for equality against zero, and if I had
to guess, you're probably trying to terminate a procedure when some
value hits zero? It's not going to; you need to introduce the concept
of tolerances, and accept if |val| < tol. This is a simplistic
solution and not really right in most cases, but might help. If you
want more advice about how to handle floating-point inaccuracy, could
you provide a program and what's going wrong?
For way more information, consult "What Every Computer Scientist
Should Know About Floating-Point Arithmetic."
http://docs.sun.com/source/806-3568/ncg_goldberg.html
HTH,
AHH
------------------------------
Message: 5
Date: Wed, 24 Jun 2009 23:10:45 -0300
From: Aaron MacDonald <aaro...@eastlink.ca>
Subject: Re: [Haskell-beginners] High precision doubles
To: beginners@haskell.org
Message-ID: <fef43202-538a-4f4b-b7ce-faf2fe19b...@eastlink.ca>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
On 24-Jun-09, at 10:18 PM, Andrew Hunter wrote:
> More to the point, however: you don't want more precision. Welcome to
> the world of numerical algorithms; floating point arithmetic is
> inherently inexact. Get used to it. For example, I'll bet your
> errors are caused by testing for equality against zero, and if I had
> to guess, you're probably trying to terminate a procedure when some
> value hits zero? It's not going to; you need to introduce the concept
> of tolerances, and accept if |val| < tol. This is a simplistic
> solution and not really right in most cases, but might help. If you
> want more advice about how to handle floating-point inaccuracy, could
> you provide a program and what's going wrong?
What I'm specifically working on is a maze generator. The generator
is based on Prim's algorithm: starting with a graph containing a
single node, I connect new nodes to existing nodes that are not
surrounded yet until I've reached a specified number of nodes in the
graph.
In my case, the maze is on a hexagonal grid. There are no boundaries
around the maze, so the generator may attach hexagonal cells, or
nodes, from any side (I don't particularly care if the generator
sometimes makes one long hallway). Each hexagonal cell is represented
in the graph as a co-ordinate representing the cell's centre. I have
a function that takes a co-ordinate and returns a list of co-ordinates
representing the centres of the adjacent cells. Keeping track of the
hexagons' positions is important because these mazes will be levels
for a game I hope to somehow put together; the potions would be used
for drawing the maze and for AI pathfinding.
When adding a new node/hex to the graph/maze, I pick an existing node
and get all of its neighbour co-ordinates, filtering out co-ordinates
that represent nodes already present in the graph. The problem is
that, due to floating point errors, these co-ordinates are not be
exact. If hex A has the co-ordinate for hex B in its list of adjacent
hexes, hex B would not necessarily have the co-ordinate for hex A in
its own list. Things get mismatched quickly.
------------------------------
Message: 6
Date: Wed, 24 Jun 2009 22:14:19 -0400
From: Sean Bartell <wingedtachik...@gmail.com>
Subject: Re: [Haskell-beginners] High precision doubles
To: Aaron MacDonald <aaro...@eastlink.ca>
Cc: beginners@haskell.org
Message-ID:
<dd3762960906241914p5aae3348p3162273088f06...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
>
> When adding a new node/hex to the graph/maze, I pick an existing node and
> get all of its neighbour co-ordinates, filtering out co-ordinates that
> represent nodes already present in the graph. The problem is that, due to
> floating point errors, these co-ordinates are not be exact. If hex A has the
> co-ordinate for hex B in its list of adjacent hexes, hex B would not
> necessarily have the co-ordinate for hex A in its own list. Things get
> mismatched quickly.
You won't be able to get it working easily with floating-point numbers.
Ideally, you would use integers for the code you're describing, then scale
them to the proper floating-point values later.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www.haskell.org/pipermail/beginners/attachments/20090624/f275bdb5/attachment-0001.html
------------------------------
Message: 7
Date: Thu, 25 Jun 2009 12:04:37 +0300
From: styx <styx...@gmail.com>
Subject: Re: [Haskell-beginners] Re: [xmonad] xmonad vs. full screen
To: beginners@haskell.org
Message-ID: <200906251204.40323.styx...@gmail.com>
Content-Type: Text/Plain; charset="iso-8859-1"
On Thursday 25 June 2009 01:38:30 Thomas Friedrich wrote:
> Rickard Nilsson wrote:
> > Quoting Thomas Friedrich <i...@suud.de>:
> >> 2) I would propose going back to the old behavior of handling
> >> full-screen-programs in xmonad. It really should be the *user* who
> >> decides how "full-screen" a full-screen-program shall be. Isn't this
> >> also more following the philosophy of xmonad? You as a user decide,
> >> what is happening on your screen? It might be not as intuitive, when
> >> switching to xmonad and you are used to other WMs, where full-screen
> >> means *full screen*. I really miss that functionality, now that its
> >> gone. What do you think?
> >
> > I think the old behaviour made much more sense. As it is now, it's not
> > possible to play a web flash movie in a separate, arbitrarily sized,
> > window. You either have to watch it fullscreen-floating, or integrated
> > in the web-page.
> >
> > @Thomas - Did you ever manage to revert Xmonad to the old behaviour?
>
> No unfortunately I didn't. I changed my manageHook to
>
> myManageHookDef = scratchpadManageHook (W.RationalRect 0.25 0.375 0.5
> 0.35) <+> composeAll
> [ ...
> , isFullscreen --> doFullFloat
> , isDialog --> doCenterFloat
> ]
>
> This way, when I want to watch a Flash-Movie in full screen, the video
> window actually covers the full screen. However, the downside of it is
> that also xpdf and others start flouting when going to full screen.
> Which is stupid, as I always have to push them back into the tiling,
> when I want to have a "full screen" xpdf next to, say, emacs. Also you
> will have a little border around the flouting window, which doesn't look
> good in full screen. But I don't want to remove the borders from
> flouting windows, as I like to have a border, when a flouting window is
> not covering the whole screen.
>
> So as you see, the solution is far from optimal.
>
> Cheers,
> Thomas
>
> _______________________________________________
> Beginners mailing list
> Beginners@haskell.org
> http://www.haskell.org/mailman/listinfo/beginners
Have a look at 'myLayout' section at
http://richardriley.net/projects/xmonad/index.html
--
Thursday 25 June 2009, 12:04:17
Regards, Mikhail S. Pobolovets
------------------------------
Message: 8
Date: Thu, 25 Jun 2009 14:17:06 +0200
From: Daniel Fischer <daniel.is.fisc...@web.de>
Subject: Re: [Haskell-beginners] High precision doubles
To: beginners@haskell.org
Message-ID: <200906251417.07146.daniel.is.fisc...@web.de>
Content-Type: text/plain; charset="iso-8859-15"
Am Donnerstag 25 Juni 2009 04:14:19 schrieb Sean Bartell:
> > When adding a new node/hex to the graph/maze, I pick an existing node and
> > get all of its neighbour co-ordinates, filtering out co-ordinates that
> > represent nodes already present in the graph. The problem is that, due to
> > floating point errors, these co-ordinates are not be exact. If hex A has
> > the co-ordinate for hex B in its list of adjacent hexes, hex B would not
> > necessarily have the co-ordinate for hex A in its own list. Things get
> > mismatched quickly.
>
> You won't be able to get it working easily with floating-point numbers.
> Ideally, you would use integers for the code you're describing, then scale
> them to the proper floating-point values later.
Say the hexagons have side length 2, the centre of one is at (0,0) and one of
its vertices
at (2,0).
Then the centre of any hexagon has coordinates (3*k,m*sqrt 3), for some
integers k, m and
any vertex has coordinates (i,j*sqrt 3) for integers i, j. So in this case, he
could work
with floating point values; using a large tolerance, he could build a gigantic
grid before
having false results.
But of course, it is much better to use (k,m), resp. (i,j), as coordinates and
translate
that to floating point only for drawing.
------------------------------
Message: 9
Date: Thu, 25 Jun 2009 10:24:41 -0300
From: Rafael Gustavo da Cunha Pereira Pinto
<rafaelgcpp.li...@gmail.com>
Subject: Re: [Haskell-beginners] High precision doubles
To: beginners@haskell.org
Message-ID:
<351ff25e0906250624m7358f133o2b642765c92e9...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
I am reading this and still don't understand what is the question. You
should never operate two floating point numbers expecting to result zero.
Period.
Floating point numbers are intrinsically imprecise. Every time you write an
interactive process with floating points in the exit conditions, you should
use some tolerance, either relative or absolute.
Absolute exit condition:
abs (xnew - xold) < epsilon
Relative exit condition (valid only when dealing with non-zero values)
abs ((xold+xnew)/xnew) <epsilon
If you cannot apply this, then either:
1) You are dealing with VERY small values, close to the minimal precision
(2.2250738585072014e-308, on 64-bit doubles),
2) You are dealing with small and big numbers, differing by 37 orders of
magnitude amongst them, when the small number will be set to 0
To solve this you should:
for 1) Scale your numbers... double, multiply by 1024, whatever, as long as
they separate from the minimal precision. It is like putting your maze under
a HUGE microscope!
for 2) Addition in situations as this one is like adding a pinch of salt on
the ocean. For multiplications, try using Log-domain operations... That
might work... Praying might work as well...
Where epsilon is
On Thu, Jun 25, 2009 at 09:17, Daniel Fischer <daniel.is.fisc...@web.de>wrote:
> Am Donnerstag 25 Juni 2009 04:14:19 schrieb Sean Bartell:
> > > When adding a new node/hex to the graph/maze, I pick an existing node
> and
> > > get all of its neighbour co-ordinates, filtering out co-ordinates that
> > > represent nodes already present in the graph. The problem is that, due
> to
> > > floating point errors, these co-ordinates are not be exact. If hex A
> has
> > > the co-ordinate for hex B in its list of adjacent hexes, hex B would
> not
> > > necessarily have the co-ordinate for hex A in its own list. Things get
> > > mismatched quickly.
> >
> > You won't be able to get it working easily with floating-point numbers.
> > Ideally, you would use integers for the code you're describing, then
> scale
> > them to the proper floating-point values later.
>
> Say the hexagons have side length 2, the centre of one is at (0,0) and one
> of its vertices
> at (2,0).
> Then the centre of any hexagon has coordinates (3*k,m*sqrt 3), for some
> integers k, m and
> any vertex has coordinates (i,j*sqrt 3) for integers i, j. So in this case,
> he could work
> with floating point values; using a large tolerance, he could build a
> gigantic grid before
> having false results.
>
> But of course, it is much better to use (k,m), resp. (i,j), as coordinates
> and translate
> that to floating point only for drawing.
> _______________________________________________
> Beginners mailing list
> Beginners@haskell.org
> http://www.haskell.org/mailman/listinfo/beginners
>
--
Rafael Gustavo da Cunha Pereira Pinto
Electronic Engineer, MSc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www.haskell.org/pipermail/beginners/attachments/20090625/01e28f93/attachment.html
------------------------------
_______________________________________________
Beginners mailing list
Beginners@haskell.org
http://www.haskell.org/mailman/listinfo/beginners
End of Beginners Digest, Vol 12, Issue 12
*****************************************
