General TC > Programming & Scripting - Unofficial
Flume math app BETA version 0.9.0
Frank:
0.99? Not here. TinyCore 3.2, with Flume downloaded via the appbrowser.
EDIT:
Ah, okay, you subtract 3.0, not 3. That's cheating.
tinypoodle:
flume as well as flpicsee seem to ignore all fltk parameters defined in ~/.Xdefaults - as opposed to the fltk apps in TC base.
To illustrate the difference attached a screenshot.
[attachment deleted by admin]
MikeLockmoore:
@Frank: Flume has different display modes. Generally, the last number in an expression will switch the mode to that type. The "3" is considered an integer, so Flume assumes you want the answer printed as an integer too. Tinypoodle showed you to to avoid this assumption.
I've debated with myself if this is the best behavior, and I agree it can be confusing, although it is useful sometimes.
Maybe if either number in an expression is a "real number" type, the result should be too. But then I need a way to easily convert results into other formats, which you can now do by simply multiplying by 1 in the desired format.
Let me think about it. ;)
Frank:
MikeLockmoore, a nice explanation, but it misses the forest for the trees. Your heuristic ("last number entered determines the output format") may be convenient from the programmer's point of view. However, it leads to outputs that violate basic school mathematics. "3.99 - 3 = 0" is not confusing. It is wrong.
Most other calculators use a different heuristic: "the result determines the output format." That heuristic gives mathematically correct outputs. It also saves the user from having to memorize non-obvious and undocumented rules for the formatting of the input numbers. A win-win situation.
MikeLockmoore:
@Frank: Point taken. However, since Flume strives to allow the user to easily mix numbers in different formats, it's not trivial to know what to display. I can come up with a method to handle your case. I don't know if I can come up with a way to consistently handle all permutations of the allowed number formats for the binary operations and functions and not confuse or misplease somebody. For example:
0b0101 * 0xFF = 0b101110101001? 0xBA9?? 2985?
2.4e1 - 3.0 = 1.7e1? 17.0? 17?
I can go on. I hope you appreciate this will require a fairly sophisticated approach.
I've been busy with Fluff for the new TC 3.3 release :) But when I can get back to Flume, I think I will try to implement something like:
The number formats have a priority, and the result of a binary operation will generally be the higher priority of the two operands. In some operations like division, inspection of the result may promote the result's format to a higher priority (e.g. the result of 10 / 3 won't be integer, it will be promoted to a real: 3.33333333). In your example, since one of the operands is real, the result will be real.
Then to allow the user to see the result in alternative formats, I may introduce new syntax:
10 + 5.0 as hex = 0x0F
1.23e1 - 0.21e1 as real = 10.2
The "as" word may just be syntactic sugar, perhaps it can be optional.
The post-fix functions like "hex" and "real" force the result to the format implied by the name.
There may be different expectations for the integer format function on whether they would round or not, and if not, should the truncation be always toward zero or toward neg. infinity ("floored"). Poll ten users and I bet you'd get at least two supporters for each of these "convert to integer" methods. So maybe I need some more syntax: "as rounded int" or "as floored hex". Maybe I need to have integer length options too: "as floored dword hex". You can see it's growing more complicated. :-\
Several calculator apps have display option settings (checkboxes or radio buttons) for this stuff, which is fine when you can only see one result at a time, but I want Flume to be more of a scratchpad, like a one-column spreadsheet. So I will probably bite the bullet and implement the "as ..." syntax. Most of the time, people won't need it and will get results more in keeping with what they expect, but the option will be there for the times they want to see results different ways. Hopefully, adding this syntax won't hurt too bad in terms of code size.
No promise on when I'll get to this. If Fluff does not generate too many bug reports, I may get back to Flume before the end of the year.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version