Gmail Calendar Documents Web Reader more »
Recently Visited Groups | Help | Sign in
Google Groups Home
Any way around non-reversibility of floating point ops
There are currently too many topics in this group that display first. To make this topic appear first, remove this option from another topic.
There was an error processing your request. Please try again.
flag
  8 messages - Collapse all  -  Translate all to Translated (View all originals)
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Peter Seibel  
View profile  
 More options Nov 2 2008, 5:30 am
Newsgroups: sci.math.num-analysis
From: Peter Seibel <peter.sei...@gmail.com>
Date: Sun, 2 Nov 2008 08:30:20 -0800 (PST)
Local: Sun, Nov 2 2008 5:30 am
Subject: Any way around non-reversibility of floating point ops
I've got an algorithm for computing the probability of a candidate in
the presidential election winning a certain number of elector votes
that looks like this (in pseudo-code):

  define compute-ev-probabilites (state-probs)
    probs = make-array 0 .. 538
    probs[0] = 1
    foreach state-prob in state-probs
       fold-into probs state-prob.votes state-probs.probability

  define fold-into (probs votes prob)
    for i from 538 downto 0
      probs[i] = probs[i] * (1 - prob)
      if (votes <= i)
        probs[i] = probs[i] + (prob * probs[i - votes])

So far so good. Now I'd like to add this function which can back out
the effects of a single state:

  define back-out (probs votes prob)
     for i from 0 to 538
      if (= prob 1)
        probs[i] (i + votes) < probs.length ? probs[i + votes] : 0
      else
        if (votes <= i) probs[i] = probs[i] - probs[i - votes] * prob
        probs[i] = probs[i] / (1 - prob)

Mathematically this works--I've actually implemented this in Common
Lisp and when I use arbitrary-precision rational numbers it works
perfectly. But when I use floating point numbers the computations in
back-out get wildly out of whack. As best as I can tell this is
because small errors introduced because (x * y) / y isn't necessarily
exactly x get propagated throughout the whole array of probabilities
and perhaps amplified by inaccuracies in the subtraction. (I can't
just use rationals because I'm actually implementing this in
Javascript whose only numeric type is double float.)

Is there some obvious way to write this so I can still use floating
point numbers but have back-out work properly. I'd be happy to trade
some precision for reversibility.

-Peter


    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Gordon Sande  
View profile  
 More options Nov 2 2008, 8:13 am
Newsgroups: sci.math.num-analysis
From: Gordon Sande <g.sa...@worldnet.att.net>
Date: Sun, 02 Nov 2008 19:13:22 GMT
Local: Sun, Nov 2 2008 8:13 am
Subject: Re: Any way around non-reversibility of floating point ops
On 2008-11-02 12:30:20 -0400, Peter Seibel <peter.sei...@gmail.com> said:

If you are doing a lot of manipulations this numers that are 1 - eps
it may pay to use a bit of symbolic smarts to keep the 1 separate from
the eps. How to do this "depends". Working through an error analysis
should tell you where it might help. You would be using the symbolic
analysis to lower the sensitivity of the computation to error progation.

However since you had to ask one suspects that you may not be familiar
with doing the error analyses. (Yet another variation on the classic
comment on the pricing of yachts!)


    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Peter Seibel  
View profile  
 More options Nov 2 2008, 10:38 am
Newsgroups: sci.math.num-analysis
From: Peter Seibel <peter.sei...@gmail.com>
Date: Sun, 2 Nov 2008 13:38:11 -0800 (PST)
Local: Sun, Nov 2 2008 10:38 am
Subject: Re: Any way around non-reversibility of floating point ops
On Nov 2, 11:13 am, Gordon Sande <g.sa...@worldnet.att.net> wrote:

I'm aware only that one should do an error analysis but have no idea
how to go about it. I was just wondering if there was some well-known
simple trick for trading off precision. Sounds like not. Thanks--I'm
off to implement bignums in Javascript. ;-)

-Peter


    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Thomas M. Hermann  
View profile  
 More options Nov 2 2008, 12:27 pm
Newsgroups: sci.math.num-analysis
From: "Thomas M. Hermann" <tmh.pub...@gmail.com>
Date: Sun, 2 Nov 2008 15:27:16 -0800 (PST)
Local: Sun, Nov 2 2008 12:27 pm
Subject: Re: Any way around non-reversibility of floating point ops
On Nov 2, 10:30 am, Peter Seibel <peter.sei...@gmail.com> wrote:

> I've got an algorithm for computing the probability of a candidate in
> the presidential election winning a certain number of elector votes
> that looks like this (in pseudo-code):

>   define compute-ev-probabilites (state-probs)
>     probs = make-array 0 .. 538
>     probs[0] = 1
>     foreach state-prob in state-probs
>        fold-into probs state-prob.votes state-probs.probability

>   define fold-into (probs votes prob)
>     for i from 538 downto 0
>       probs[i] = probs[i] * (1 - prob)

Convert this line to : probs[i] = probs[i] - probs[i] * prob

>       if (votes <= i)
>         probs[i] = probs[i] + (prob * probs[i - votes])

> So far so good. Now I'd like to add this function which can back out
> the effects of a single state:

>   define back-out (probs votes prob)
>      for i from 0 to 538
>       if (= prob 1)
>         probs[i] (i + votes) < probs.length ? probs[i + votes] : 0
>       else
>         if (votes <= i) probs[i] = probs[i] - probs[i - votes] * prob
>         probs[i] = probs[i] / (1 - prob)

Convert this line to : probs[i] = probs[i] * (1 + prob) / (1 -
prob*prob)

The little experiment I ran indicated that the roundoff errors should
cancel out with those modification.

Cheers,

Tom H.


    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Peter Spellucci  
View profile  
 More options Nov 3 2008, 2:06 am
Newsgroups: sci.math.num-analysis
From: spellu...@fb04373.mathematik.tu-darmstadt.de (Peter Spellucci)
Date: Mon, 3 Nov 2008 14:06:25 +0100 (CET)
Local: Mon, Nov 3 2008 2:06 am
Subject: Re: Any way around non-reversibility of floating point ops

In article <7d6c2a14-36f5-426d-9563-b67f70e17...@a29g2000pra.googlegroups.com>,
 Peter Seibel <peter.sei...@gmail.com> writes:

as stated already by others, yuo must in principle use an error analysis based
on the (hopefully for your system ) correct model of the computer arithmetic

  (x machine operation y ) = (x exact operation y)(1+eta)

with abs(eta)<= eps = "machine precision" = 2^(-53) in double
but since vote is integer, it might suffice if you replace the test
   < i
by
  < dble(i)+0.25
?
(you compare variables which in orinciple should come out as integers,
hopefully the roundoff errors are not thta large that errors >=1 occur.)
hth
peter


    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Martin Eisenberg  
View profile  
 More options Nov 3 2008, 10:48 am
Newsgroups: sci.math.num-analysis
From: Martin Eisenberg <martin.eisenb...@udo.edu>
Date: 3 Nov 2008 21:48:40 GMT
Local: Mon, Nov 3 2008 10:48 am
Subject: Re: Any way around non-reversibility of floating point ops

Thomas M. Hermann wrote:
> On Nov 2, 10:30 am, Peter Seibel <peter.sei...@gmail.com> wrote:
>>       probs[i] = probs[i] * (1 - prob)

> Convert this line to :
> probs[i] = probs[i] - probs[i] * prob
>>       probs[i] = probs[i] / (1 - prob)

> Convert this line to :
> probs[i] = probs[i] * (1 + prob) / (1 - prob*prob)
> The little experiment I ran indicated that the roundoff errors
> should cancel out with those modification.

Is that transformation in the lore or has anyone written about it?

Martin

--
Quidquid latine scriptum est, altum videtur.


    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Peter Seibel  
View profile  
 More options Nov 3 2008, 7:11 pm
Newsgroups: sci.math.num-analysis
From: Peter Seibel <peter.sei...@gmail.com>
Date: Mon, 3 Nov 2008 22:11:13 -0800 (PST)
Local: Mon, Nov 3 2008 7:11 pm
Subject: Re: Any way around non-reversibility of floating point ops
On Nov 2, 3:27 pm, "Thomas M. Hermann" <tmh.pub...@gmail.com> wrote:

Hmmm, it didn't seem to help in my actual case. Thanks though.

-Peter


    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Thomas M. Hermann  
View profile  
 More options Nov 4 2008, 2:59 pm
Newsgroups: sci.math.num-analysis
From: "Thomas M. Hermann" <tmh.pub...@gmail.com>
Date: Tue, 4 Nov 2008 17:59:42 -0800 (PST)
Local: Tues, Nov 4 2008 2:59 pm
Subject: Re: Any way around non-reversibility of floating point ops
On Nov 3, 3:48 pm, Martin Eisenberg <martin.eisenb...@udo.edu> wrote:

It just something I came up with be devising a little, flawed,
experiment in javascript. I ran it on http://www.arachnoid.com/javascript/interactiveJavaScript.html

It started like this.

function roundoff_error(exact,approximate) {
  return Math.abs( approximate/exact - 1.0 );

}

function foo(x,y) {
  return x/(1-y);

}

function bar(x,y) {
  return x*(1-y);

}

function main()
{
  x=0.1;
  y=0.2;
  print("Roundoff error : " + roundoff_error(x,foo(bar(x,y),y)));

}

And the output was

Roundoff error : 2.220446049250313e-16

I think I got the idea for playing algebraic games from mucking around
in BLAS code or maybe it was something I read, regardless, I played
around with the equations until I found something that didn't exhibit
roundoff error for various x and y. The result was:

function foo(x,y)
{
return x*(1+y)/(1-y*y);

}

function bar(x,y)
{
return x-x*y;

}

I didn't want to spend a great deal of time verifying this, so I
didn't try a great number of inputs. In the process of writing this
reply, I just checked x=0.1 and y=0.22 which resulted in a roundoff
error of 1.1102230246251565e-16.

I didn't do anything formal, I was just doing a quick experiment with
some algebraic manipulation. Obviously, the quick adjective should be
replaced with flawed.

Tom H.


    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
End of messages
« Back to Discussions « Newer topic     Older topic »

Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2010 Google