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.

[Frank]

I hope you appreciate this will require a fairly sophisticated approach.

The detailed examples make it clear that the matter is not trivial  Your postfix solution looks very promising.

Thank you for having seen my point, and for the pleasant conversation.

[TheNewbie]

Is this meant to go beyond arithmetic to equation solving? Because if you plan to add imaginary numbers, you'll have a system for handling variables as symbolic values. That's basically the only hurdle in adding features dealing with equations (quadratics, systems), isn't it...?

Also, is it feasible to have another FLTK app take advantage of Flume's CLI?

As for the issue of format conversion, you could have the "as" syntax, but separate various keywords into categories. You wouldn't want "as real hex". So far, the categories (off the top of *your* head ) are integer length (ex. dword), rounding (floor vs round), and format (ex. hex, real). You'd have to enforce a specific order (dword hex vs hex dword?) or specific signals as to what category a keyword is (L-dword F-hex R-floor)... The so-called category signals or enforced order are only necessary in a multiple keyword modifier, of course. Without any such order/signals, you could simply do a search for every keyword and keep a count in each keyword and category to check for multiple or invalid keywords, but that seems rather inefficient when taking into perspective typing "L-dword F-hex" vs "dword hex"

[MikeLockmoore]

@ TheNewbie: I'm not likely to implement equation solving anytime soon. But there are times that I want to do arithmetic with numbers in different formats and be able to see the results different ways.  I have not fully thought through the "as" syntax.  You raise issues I will need to think about.  I don't want the syntax to get too cumbersome to use or hard to implement, and I won't necessarily prevent the user from entering something bizarre. But I hope to handle the common and "natural" cases with minimum fuss or surprise to the user.  Maybe I will have something definitive to share by the New Year.  

[MikeLockmoore]

@ Frank, tinypoodle, TheNewbie: new version addresses many of your issues and suggestions.  Thanks for the feedback.  Feel free to try the new one and let me know what you think.  If you can't build it yourself from source, let me know and I will offer another option. 
--
Mike Lockmoore