[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: left-right (up-down) parsing may lead to over/underflow of prod
From: |
David Bateman |
Subject: |
Re: left-right (up-down) parsing may lead to over/underflow of prod |
Date: |
Tue, 22 Apr 2008 14:12:12 +0200 |
User-agent: |
Thunderbird 2.0.0.12 (X11/20080306) |
Rolf Fabian wrote:
> I consider the following 'feature' as a
> major drawback of Octave because
> it infringes the expected commutativity
> and associativity while building products.
>
> Parsing products from left to right (for vectors)
> or up-to-down (columnwise product of matrices)
> may lead to avoidable over /underflow if
> some involved factors are extraordinarily
> large and/or small
>
> :> computer, version
> i686-pc-msdosmsvc
> ans = 3.0.0
>
> EXAMPLE 1 (prod of a vector)
> :> x1 = [1e150, 1e160, 1e150, 1e160, 1e-310, 1e-310]
> It is obvious that the correct product of x is equal to 1,
> but Octave either overflows if the product is
> evaluated from left-to-right:
> :> prod (x)
> ans = Inf
>
> or underflows (without any warning)
> if the product is evaluated from right-to-left
> :> prod (fliplr (x))
> ans = 0
>
> Thus simply rearranging the order of factors changes
> Octave's result of the product from 'Inf' to '0', which
> is unexpected because generally a product should
> not depend on the ordering of its factors.
>
> Expected correct answer is returned by
> :> prod_via_sum_of_logs = exp (sum (log (x)))
> ans = 1
>
> Similar artefacts occur if input to prod is a matrix like:
> :> y = [1e300, 1e-200; 1e300, 1e-200; 1e-200, 1e300; 1e-200, 1e300]
>
> :> prod(y)
> ans =
> Inf 0
>
> :> prod (flipud (y))
> ans =
> 0 Inf
>
> The correct result can again be obtained via sums of logarithms:
> :> prod_via_sum_of_logs = exp (sum (log (y)))
> ans =
> 1.0000e+200 1.0000e+200
>
> Of course, some spurious complex noise might appear if some factors
> are negative while using sums of logarithms, but this can be adjusted
> easily.
>
> In order to avoid similar artefacts as outlined above I propose to implement
> the 'prod' function via (column) sums of logarithms of factors.
>
> Rolf
>
>
> -----
> Rolf Fabian
> <r dot fabian at jacobs-university dot de>
>
>
This is consistent with MatlabR2007b. See
>> x = [1e150, 1e160, 1e150, 1e160, 1e-310, 1e-310]
x =
1.0e+160 *
0.0000 1.0000 0.0000 1.0000 0.0000 0.0000
>> prod(x)
ans =
Inf
D.
--
David Bateman address@hidden
Motorola Labs - Paris +33 1 69 35 48 04 (Ph)
Parc Les Algorithmes, Commune de St Aubin +33 6 72 01 06 33 (Mob)
91193 Gif-Sur-Yvette FRANCE +33 1 69 35 77 01 (Fax)
The information contained in this communication has been classified as:
[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary
- left-right (up-down) parsing may lead to over/underflow of prod, Rolf Fabian, 2008/04/22
- Re: left-right (up-down) parsing may lead to over/underflow of prod,
David Bateman <=
- Re: left-right (up-down) parsing may lead to over/underflow of prod, Rolf Fabian, 2008/04/22
- Re: left-right (up-down) parsing may lead to over/underflow of prod, David Bateman, 2008/04/22
- Re: left-right (up-down) parsing may lead to over/underflow of prod, Jaroslav Hajek, 2008/04/22
- Re: left-right (up-down) parsing may lead to over/underflow of prod, Jaroslav Hajek, 2008/04/23
- Re: left-right (up-down) parsing may lead to over/underflow of prod, Rolf Fabian, 2008/04/23
- Re: left-right (up-down) parsing may lead to over/underflow of prod, Jaroslav Hajek, 2008/04/23
Re: left-right (up-down) parsing may lead to over/underflow of prod, Shai Ayal, 2008/04/22