From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Sebastien Vauban" Subject: Re: Estimate ranges in column view Date: Tue, 15 Nov 2011 16:14:43 +0100 Message-ID: <80bosdwh7g.fsf@somewhere.org> References: <10E98231-262C-45D4-82A2-2B660068A55E@gmail.com> <20100622.143610.09007983.mikelygee@no8wireless.co.nz> Mime-Version: 1.0 Content-Type: text/plain Return-path: In-Reply-To: (Carsten Dominik's message of "Mon, 19 Jul 2010 14:03:29 +0200") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org-mXXj517/zsQ@public.gmane.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org-mXXj517/zsQ@public.gmane.org To: Carsten Dominik Cc: emacs-orgmode-mXXj517/zsQ@public.gmane.org, Michael Gauland Hi Carsten and Michael, Carsten Dominik wrote: > On Jun 22, 2010, at 4:36 AM, Michael Gauland wrote: >> Here is a patch for a new 'est+' summary type, including corresponding >> changes for xemacs and the manual. I've done basic testing on the GNU emacs >> version, but not the xemacs code. >> >> [...] >> >> + @{est+@} @r{Add low-high estimates.} >> >> [...] >> >> +For example, suppose you had ten tasks, each of which was estimated at 0.5 >> +to 2 days of work. Straight addition produces an estimate of 5 to 20 days, >> +representing what to expect if everything goes either extremely well or >> +extremely poorly. In contrast, 'est+' estimates the full job more >> +realistically, at 10-15 days. Though, if we take 2 tasks, with an estimation of: - exactly 1 day for task 1, and - between 0.5 day (min) and 0.75 day (max) for task 2, we get an estimation of 2 days for both together... #+BEGIN: columnview :hlines 1 :maxlevel 2 | Task | Estim. | |---------------+----------| | * Development | 2-2 | | ** Task 1 | 1 | | ** Task 2 | 0.5-0.75 | #+END: >> +(defun org-estimate-print (e &optional fmt) >> + "Prepare a string representation of an estimate, as two numbers with a >> -' in between them." >> + (if (null fmt) (set 'fmt "%.0f")) >> + (format "%s" (mapconcat (lambda (n) (format fmt n)) e "-"))) That's because of the rounding to the closest integer, done in the above function. Shouldn't we allow for 1 or 2 decimals? Or is there a possible way to guess what the best rounding could be? >> (provide 'org-colview) > > I have applied the patch - please check it if it is still working correctly. > > - Carsten Best regards, Seb -- Sebastien Vauban