[haiku-development] Re: DeskCalc Improvements (was need strtold() function)

  • From: Ingo Weinhold <ingo_weinhold@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Wed, 03 Feb 2010 09:19:06 +0100

On 2010-02-03 at 00:09:22 [+0100], John Scipione <jscipione@xxxxxxxxx> wrote:
> On Tue, Feb 2, 2010 at 5:02 PM, Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> wrote:
> > John Scipione <jscipione@xxxxxxxxx> wrote:
> >> I have attached a new patch to ticket #5203 at
> >> http://dev.haiku-os.org/ticket/5203
> >>
> >> This patch will ensure that deskcalc will (almost) always fit the
> >> result in the display window. An easy way to test the code is to make
> >> the window short and wide and type pi or sin(0.5) and watch the digits
> >> fill the screen. Then make the window tall and narrow and watch the
> >> result come back puny and inaccurately.
> >
> > I know I'm a bit late with this objection, but I find it pretty strange
> > to limit the computation accuracy to the window size. Can't we just
> > make sure that the interesting part of the result is alway shown (and
> > you'd have to scroll to get more accuracy)?
> > Or does it internally still use the more accurate number for further
> > computations?
> DeskCalc could be made to use some arbitrary accuracy independent of
> the window size, in fact, that is how it worked before I began (32
> digits). But then the result may or may not fit in the text view which
> is ugly, the cursor gets put at the rightmost end of the result
> (correctly) but that is ugly because you can't see the beginning of
> the result without resizing or scrolling. Scrolling is of course an
> option but doesn't really solve the underlying problem.
> I could see imposing a maximum precision (lets say 32 digits) and not
> calculating beyond that no matter what your window size is but I don't
> see a reason why I should. Most users won't notice or care, for the
> few who want more accuracy they'll be able to get it. Either way the
> result will fit in the text view and look nice.

A straight-forward solution would be to extend ExpressionParser to return 
arbitrary precision numbers (a nice wrapper class for the ugly MAPM class 
would be in order) and only convert them for presentation.

CU, Ingo

Other related posts: