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

  • From: John Scipione <jscipione@xxxxxxxxx>
  • To: "haiku-development@xxxxxxxxxxxxx" <haiku-development@xxxxxxxxxxxxx>
  • Date: Wed, 3 Feb 2010 13:50:55 -0500



On Feb 3, 2010, at 4:27 AM, Stephan Assmus <superstippi@xxxxxx> wrote:


On 2010-02-03 at 09:19:06 [+0100], Ingo Weinhold <ingo_weinhold@xxxxxx>
wrote:
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@pinc-softwar e.de>
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.

And don't forget to extend the expression history that DeskCalc maintains
with those numbers for result expressions. Or simply store the full
precision number in the history and fit them to display width any time an
expression gets pulled from the history.

Best regards,
-Stephan

All of this sounds like a good idea. I could attire the MAPM value somewhere so that the result could be computed to a different precision. However I didn't do thy because I didn't want to include the headers in the deskcalc app. Why not just keep the result as is? Sure you may lose some precision but that is not any different from any other calculator app. The way it works with my patch applied is already better than the default calculator either windows and Mac OS X.

John Scipione

Other related posts: