[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PSPP-BUG: moments_calculate error

From: John Darrington
Subject: Re: PSPP-BUG: moments_calculate error
Date: Sun, 30 Dec 2012 09:40:43 +0100
User-agent: Mutt/1.5.20 (2009-06-14)

On Wed, Dec 19, 2012 at 09:49:37PM -0800, Ben Pfaff wrote:
     John Darrington <address@hidden> writes:
     > The pertinent assertion is:
     >      /* After the second pass we can calculate any stat.  We
     >          don't support "online" computation during the second
     >          pass, so As a simple self-check, the total weight for
     >          the passes must agree. */
     >       assert (m->w1 == m->w2);
     > and when I ran it through gdb, I see:
     > Breakpoint 1, moments_calculate (m=0x81430c0, weight=0xbffff1c0, 
mean=0xbffff1b8, variance=0xbffff1b0, skewness=0xbffff1a8, 
     >     kurtosis=0xbffff1a0) at /home/john/pspp-master/src/math/moments.c:233
     > 233           assert (m->w1 == m->w2);
     > (gdb) print m
     > $2 = {max_moment = MOMENT_KURTOSIS, pass = 2, w1 = 2257.1583655975705, 
sum = 970999467.71251988, mean = 430186.6818527166, 
     >   w2 = 2257.1583655975778, d1 = 6.8955123424530029e-06, d2 = 
1504554313897766, d3 = 2.7440683550398496e+21, 
     >   d4 = 9.0176522508330139e+27}
     > So it would appear that this is simply a floating point
     > precision problem (which inevitably arises when doing equality
     > comparisons with floating points).  So I suggest that this
     > assertion be deleted.
     w1 and w2 are each calculated as the sum of the same sequence of
     values in the same order.  

No.  They are calculated in different orders.  The first pass iterates the data 
in the original data.  Then the data is sorted, and iterated for the the second
pass.  It is done this way, in order to minimise the number of iterations 
the data.  

If we are going to leave this assertion in the code, then we must explicitly add
a precondition that the two passes must be iterated in the same order.

(independently, there is at least one other bug which Zoltan's example provokes)


PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://keys.gnupg.net or any PGP keyserver for public key.

Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]