On Feb 3, 2010, at 4:27 AM, Stephan Assmus <superstippi@xxxxxx> wrote:
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.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 tomake the window short and wide and type pi or sin(0.5) and watch thedigits 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 furthercomputations?DeskCalc could be made to use some arbitrary accuracy independent of the window size, in fact, that is how it worked before I began (32digits). But then the result may or may not fit in the text view whichis 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 optionbut 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 resultwill 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 classwould be in order) and only convert them for presentation.And don't forget to extend the expression history that DeskCalc maintainswith those numbers for result expressions. Or simply store the fullprecision number in the history and fit them to display width any time anexpression gets pulled from the history. Best regards, -Stephan
John Scipione