[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [Bug 115645] New: [patch] getdata returns wrong results with MULTIPLY
From:       "D.V.Wiebe" <dwiebe () physics ! utoronto ! ca>
Date:       2005-11-03 23:48:36
Message-ID: 20051104004835.115645.dwiebe () physics ! utoronto ! ca
[Download RAW message or body]

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
         
http://bugs.kde.org/show_bug.cgi?id=115645         
           Summary: [patch] getdata returns wrong results with MULTIPLY or
                    LINCOM of fields with different samples/frame
           Product: kst
           Version: unspecified
          Platform: Slackware Packages
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: NOR
         Component: general
        AssignedTo: kst kde org
        ReportedBy: dwiebe physics utoronto ca


Version:           1.2.0_devel (using KDE KDE 3.4.2)
Installed from:    Slackware PackagesSlackware Packages
Compiler:          gcc (GCC) 3.3.6 
OS:                Linux

This patch fixes two bugs in getdata's MULTIPLY and LINCOM generation when dealing \
with fields with differing samples per frame.  The two bugs are:

* getdata didn't return the number of samples requested, even when it could, but \
rounded the number of samples returned to an integer multiple of one of the fields' \
samples per frame.

* getdata didn't fetch the proper range of data from the second field when the start \
of the range was specified in samples and not frames.  As a result the derived vector \
returned was incorrect.  This was because first_frame and first_samp were being \
passed naively to the second DoField without taking into account the difference in \
samples per frame.

The supplied patch fixes both of these bugs.  For the second bug, first_frame and \
first_samp are taken to refer exclusively to the first field in the LINCOM (or \
MULTIPLY).  The starting sample for successive fields is calculated relative to this. \
This is what is expected, since the samples per frame of the vector returned by \
getdata is equal to the samples per frame of the first field in the derived field \
specification.


[prev in list] [next in list] [prev in thread] [next in thread]