From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Sebastien Vauban" Subject: Re: Estimate ranges in column view Date: Thu, 24 Nov 2011 16:44:35 +0100 Message-ID: <807h2p5xuk.fsf@somewhere.org> References: <10E98231-262C-45D4-82A2-2B660068A55E@gmail.com> <20100622.143610.09007983.mikelygee@no8wireless.co.nz> <80bosdwh7g.fsf@somewhere.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: 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: emacs-orgmode-mXXj517/zsQ@public.gmane.org Hello, "Sebastien Vauban" wrote: > 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? Another note: wouldn't it better to just write "2" when both bounds (min and max) are equal, that is *not* displaying an estimate of "2-2"? Best regards, Seb -- Sebastien Vauban