#5203 closed enhancement (fixed)
DeskCalc doesn't display numbers with more than 19 digits without scrolling (easy)
Reported by: | Queue29 | Owned by: | stippi |
---|---|---|---|
Priority: | low | Milestone: | R1 |
Component: | Applications/DeskCalc | Version: | R1/alpha1 |
Keywords: | DeskCalc easy digits | Cc: | seth.a.hoenig@…, WPJvanderMeer@… |
Blocked By: | Blocking: | ||
Platform: | All |
Description
Any number with 20 or more digits will be hidden without manually using the cursor to click-select-scroll to view the lesser significant digits.
A couple of possible solutions might include:
- Representing the number in scientific notation after it reaches 15 or so digits.
- dynamically reducing the font size so more digits can fit in the text box
- Allowing the calculator window to be expanded wider than it is now
Attachments (6)
Change History (14)
comment:1 by , 15 years ago
Cc: | added |
---|
by , 15 years ago
Attachment: | deskcalc.patch added |
---|
comment:2 by , 15 years ago
Some things I don't get in the patch:
- why not ask the app_server the width of the standard notation string and if too big switch to scientific ?
- the switch from log to ln and log10 to log should have been notified in your patch comment.
comment:3 by , 15 years ago
Cc: | added |
---|
jscipione, I am not sure if you are still working on your patch, but I wanted to give it a try myself, I hope you don't mind.
For the patch I decided to use only string operations to convert to scientific notation in order to preserve the calculation precision of the MAPM library. The implementation also allows the user to adjust the window size to show more/less digits after the result is shown.
comment:4 by , 15 years ago
Nice work! Almost no coding style violations either. :-) My only wish would be that DeskCalc does not switch to scientific notation as long as there are "enough" digits left. In that case it should merely truncate the result I think. So before switching to scientific notation, it should only regard the digits before the decimal point. If there is not enough room for those, switch to scientific notation, otherwise truncate only. What do you think?
comment:5 by , 15 years ago
Thanks for the quick reply! *Almost* no style violations? I'd like to know where I went wrong :)
Yeah, I see what you mean, as long as the period and one digit after is inside the view, there is no need to switch to scientific notation.
Of course, just truncate won't work, it is better to properly round off the value.
I'll see what I can do to make it work that way.
by , 15 years ago
Attachment: | deskcalc-wim.diff added |
---|
Fit calculations results to the window, switching to scientific notation if necessary, rounding the value
comment:6 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Applied in hrev36402, many thanks!
by , 15 years ago
Attachment: | coding_style.diff added |
---|
Patch showing the coding style fixes that were applied.
comment:7 by , 15 years ago
Wim, I've attached a patch showing some coding style improvements that I've made after Axel gave some suggestions on the haiku-commits list, just in case you are not subscribed to that list. Hope you don't take it the wrong way, I know we are a bit pedantic about the coding style, but one comes to appreciate it after a while when everything follows the same style.
by , 15 years ago
Attachment: | precise_pi_and_e.patch added |
---|
This patch increases the precision of pi and e using the MAPM library
by , 15 years ago
Attachment: | log_to_ln.patch added |
---|
Changes log to ln and log10 to log (which is what most people expect)
by , 15 years ago
Attachment: | simple_error.patch added |
---|
on error just print "error" instead of printing the specific error message
comment:8 by , 15 years ago
Hi John, the patches probably deserved new tickets, but never mind. I applied the precise_pi_and_e patch in hrev36462 and the log_to_ln patch in hrev36463. I wouldn't like to apply the simple error patch, since I think it should be done differently. You probably know that DeskCalc places previous expressions into the expression history, which remembers strings. Somehow it should associate the error with the expression from the history, and when the user types the up arrow to go back to the previous expression that had an error, DeskCalc could then display the corresponding digit in the expression in red or something similar. Again best would be to create a new ticket for this enhancement.
And thanks for working on these!
Patch to make DeskCalc always fit the result in the window converting to scientific notation if necessary