From: Chris Schlaeger (cs_at_suse.de)
Date: Wed May 07 2003 - 09:53:22 CEST
From: Chris Schlaeger <cs@suse.de> Date: Wed, 7 May 2003 09:53:22 +0200 Message-Id: <200305070953.37975.cs@suse.de> Subject: Re: [taskjuggler] timingresolution bug
On Tuesday 06 May 2003 19:02, Lutz Vieweg wrote:
> Hi,
>
> the following test project demonstrates a problem
> with smaller "timingresolution" values:
>
> --------------------------------------------------
> project test "test" "0.1" 2003-05-01 2003-07-30 {
> now 2003-05-01
> timingresolution 12 min
> dailyworkinghours 8
> }
>
> resource harry "harry"
>
> task work1 "work1" {
> start 2003-05-02
> effort 2d
> allocate harry
> }
>
>
> htmlresourcereport "test.html" {
> sortresources sequenceup
> columns name, daily, effort
> hidetask 0
> loadunit hours
> }
> --------------------------------------------------
>
> Instead of taking 2 working days, the task
> is scheduled to take 2 days + 12 minutes (0.2 hours).
>
> The unit passed to "effort" doesn't matter, the
> same happenes e.g. for "effort 16h".
>
> Maybe some sort of rounding/precision problem?
Yes, it is. The daily efforts are accumulated as float values and a <=
operation terminates the allocation. In your case the rounding error leads to
a result that is one LSB below the end value and gives you another time slot.
I've fixed this in the CVS.
Chris
-- KDE 3.1: Conquer your Enterprise Desktop! See http://www.kde.org! GPG Key: 1024D/0500838B A5FE C051 2AFC 9A14 768A 5125 5829 5750 0500 838B
This archive was generated by hypermail 2.1.7 : Wed May 07 2003 - 09:55:38 CEST