Tiny Core Linux
General TC => Programming & Scripting - Unofficial => Topic started by: MikeLockmoore on November 07, 2010, 12:21:15 PM
-
I have bumped the version number up to 0.9.0 and re-releasing it as BETA software. If approved by the TinyCore repository maintainer, this version may be soon available in binary form. For now, you can still build it from source if you are sufficiently motivated. ;)
Until it appears on the official repository, you can post bug reports and suggestions to this thread. Later on, perhaps we can start a thread in the TCE subforums. I'll post the user help info below. Hope you like it.
--
Mike Lockmoore
-
Flume
BETA Version 0.9.0, November 2010
Flume is a fast, light utilitarian math environment. It can be used from the command-line for simple calculations, or in GUI form as a desktop calculator or a one-column spreadsheet. Calculations are performed with your CPU's floating point hardware, so the range and precision of numbers are somewhat limited, but suitable for most uses. Flume uses the FLTK user interface library, which makes it is especially efficient on TinyCore Linux. The source code of Flume is released under the GNU license. See http://www.gnu.org/licenses/ for more details.
CAUTION: Flume 0.9.0 is BETA SOFTWARE. While due care was taken during development, it has not been tested exhaustively. Mathematical calculations in Flume are done within the precision and limitations of IEEE-standardized floating-point computations. Flume does NOT have arbitrarily high precision (like some math packages), and is subject to round-off errors and other issues. DO NOT use Flume BETA as your sole mathematics tool for your P.h. D dissertation, preparing tax filings, or unlocking the secrets of an ancient script. Even when Flume BETA is used in more mundane applications, it is likely at some point to produce an inaccurate result, lose your work, steal your dog, tell an embarrassing story at your wedding, or otherwise do something that disappoints you. Please help make Flume better by reporting bugs and offering suggestions. Suggestions are especially welcome that come with specific test cases that reproduce errors or code changes that can be easily integrated. Thanks!
Command-Line Options
--f filename load content of file "filename" into work area upon startup
--d angles expressed as degrees
--r angles expressed as radians (default)
--t N "terseness", with N = 0(very verbose) to 5 (very terse)
--v print name and version on command-line
Command-Line Mode
If you invoke Flume from the command line and provide it a mathematical expression after any command-line options, Flume will immediately try to calculate and print the result and then exit without opening the graphical user interface (GUI). For example, if you enter:
$ flume 6*7[Enter]
you will see the result:
6 * 7 = 42
Command-line mode will only parse and calculate one result, so some features of Flume, such as references, will not work properly. If your expression contains any characters that are special for the command-line shell, such as parentheses, please enclose your expression in double-quotes:
$ flume "1.0+(2.0*2.0)"[Enter]
1.0 + (2.0 * 2.0) = 5.0
Flume supports the following number formats:
Decimal integer: 7
Real number: 7.0
Scientific notation: 7.0e0
Hexadecimal integer: 0x07 or 0X07
Binary integer: 0`111 or 0b111 or 0B111
Note the first form of binary notation uses a back-quote, not single-quote! Negative numbers should be prefaced with a - (dash) with no space before the numerals.
Flume will parse your entries and try to provide grouping parentheses to resolve any ambiguity in the order of operations. For example, if you enter the expression
2*3+4^2
You will see flume re-write the expression as:
(2 * 3) + (4 ^ 2)
If this grouping is not what you intended, please edit the expression with the exact grouping you need.
Comments may be added to the end of an expression a semi-colon:
sin(pi / 4.0) ; sine of 45 degrees
All expressions in the main workspace area are recalculated each time you press the Enter key, so you may easily edit and update multiple results as in spreadsheet applications. Comments will be preserved, but any text between the equal symbol and the first semi-colon will be replaced by new results.
It is acceptable to enter a single number by itself as an expression, which is simply evaluated as the entered value (identity principle). This form is useful for changeable input values used in a later calculation. For example:
5.0 = 5.0 ; width, inches
7.0 = 7.0 ; length, inches
3.0 = 3.0 ; height, inches
p[3] * p[2] * p[1] = 105.0 ; volume, cubic inches
Operators, Functions, and Constants
The spelling of operators, functions, and constants is generally case-insensitive with exceptions noted below.
The following infix operators are used between two numbers or sub-expressions:
+ add
- subtract
* multiply
x or X multiply, or part of hex number if directly preceded by zero
of multiply (e.g. "1/2 of 732")
/ divide
^ raise to a power
MOD integer modulus
& or AND bit-wise integer AND
| or OR bit-wise integer OR
XOR bit-wise integer exclusive-OR
The following prefix operator should be used before its operand:
~ bit-wise integer NOT (invert)
The following postfix operators should be used after their operand:
% divide by 100.0
! factorial (non-neg. integers only)
Flume can compute the following functions:
sqrt() square root
sin() sine of an angle
cos() cosine of an angle
tan() tangent of an angle
arcsin() arcsine (inverse sine) of an angle
arccos() arccosine (inverse cosine) of an angle
arctan() arctangent (inverse tangent) of an angle
remainder() real-number remainder after division
deg2rad() multiply by PI/180.0
rad2deg() multiply by 180.0/PI
Note: for trigonometric functions, the default angle encoding is radians. From the GUI or command-line, the encoding can be switched to degrees.
Flume will provide the following constant values:
PI 3.141592...
e 2.7182818... (lower-case only!)
Referring to Prior Results
You may reuse prior results in an expression using absolute or relative references.
Absolute references specify an expression row (or "result") number in the form of r[n], where n is the row number from 0 (the first row number) up to the maximum. No matter where the absolute reference shows up, it refers to the same expression row. Warning: referring to a higher-number row will recall the old calculation result for that row, which may change during the subsequent calculations.
Relative references specify an expression row a specified number of rows displaced from the row containing the reference. The form of relative references is p[n], where n is the number of rows offset in the prior direction. For example, p[1] refers to the immediately prior row and p[2] refers to an expression two rows back. Negative values for the row offset will make forward-references, which may produce inconsistent results.
When Flume parses expressions, the single-quote character (') will be automatically expanded into p[1], while the double-quote character (") will be automatically expanded into p[2], making it a little more convenient to chain calculations together as you type them in.
Files
Flume may open and insert the contents of a text file into the main work area. This can be done by specifying a file on the command-line or by pressing the "Open" button in the GUI and selecting a file. The file selection dialog defaults to browsing files with the ".flume" filename extension, but ".ume", ".txt" or all files may be browsed by changing the filter field.
If the file contents are successfully retrieved, Flume will attempt to evaluate each line of the file. If any line is not a valid expression, Flume will report an error and place the editing cursor at the end of that expression. The name the retrieved file is displayed in the GUI main window title. If the content has been modified, the filename in the title will show an asterisk (*) prefix.
You may save your current workspace content as long as there has been at least one valid expression. The entire workspace content is saved to the file, even if some of that content has not been parsed and calculated yet. After Flume successfully writes the current workspace content to the file, the file modification flag and title asterisk is cleared.
If the file modification flag is currently set when try to quit or open a new file, you will be notified that quitting will cause the modifications to be discarded. You may either choose to discard and quit anyway or chose to cancel the quit request so you may save the modified content.
Quirks and Tricks
Flume doesn't (yet?) handle imaginary numbers, so sqrt(-1) returns "-nan" (not a number).
Multiple sequential "raise to the power" operators will expand into a strange looking expression, but will calculated OK. For example, 3^2^2 will expand to (3 ^ (2) ^ 2), but will still equal 81. Use parentheses if an exponent is a complicated expression.
Flume keeps track of the format of a number (integer, hexadecimal, etc.), and most results will "inherit" the format of the last number entered. You can exploit this behavior with the Multiplicative Identity (multiply by one), using the form of the number one you want to convert the first number or expression to. For example, to convert 192 into hexadecimal:
$ flume 192 x 0x01[enter]
192 x 0x01 = 0xC0
To convert 1/1000 into scientific notation:
$ flume "(1.0/1000) * 1e0"
(1.0 / 1000) * 1e0 = 1.000000e-03
-
Minor typo in "!" popup: ARITHMETIC ;)
While scrolling in help browser there is error output, not of any obvious functional essence though.
-
@tinypoodle: Thanks! Typo fixed for the next release. Can you give me any more info on the help browser error message you see? Where do you see it? I don't think I've ever seen something like that.
-
Output in aterm, when flume is started from CLI.
X_ChangeGC: BadMatch (invalid parameter attributes) 0x3000186
X_ChangeGC: BadPixmap (invalid Pixmap parameter) 0x2e00100
X_ChangeGC: BadPixmap (invalid Pixmap parameter) 0x2e000ff
etc...
On further testing this seems only to appear while scrolling at the very top of the document.
(FWIW, running TC 2.10 here)
-
I'm currently developing on TC 3.1 and 3.0. I don't know of any reason it should not compile and run OK on TC 2.10, but maybe the version does have some impact. Is there anything else unconventional about your setup (WM, XOrg instead of VESA, etc)? Unless I find a posting by someone else who ran into a similar FLTK problem, I don't know if I can duplicate and fix it. :-\
UPDATE: A bit of searching did not lead to any specific causes or fixes. This kind of error seems to pop up in many different situations with many different applications. My only thought after looking at these is to think about whether you have the proper XOrg development headers installed for your setup, especially if you are using XOrg as your display server.
--
Mike
-
Using jwm-snapshot and the Xvesa.tcz extension (as opposed to Xvesa included in base).
I wouldn't really label this as a problem, as there appears to be no impact whatsoever in functionality.
-
FWIW, I have actually Xorg-7.4-dev.tcz (as a dependency of some app) installed, without having Xorg installed.
-
@tinypoodle: Maybe the headers have nothing to do with it. I wonder if the Xvesa.tcz has a slight incompatibility with FLTK's runtime API lib. If I can ask, why install Xvesa.tcz?
-
There are some rather minor differences in behaviour in some aspects, couldn't recall all at the moment; but I have observed "leaking" of memory to a big extent with Xvesa in base, e.g. last time I had reached a res mem usage of 230MB - Right now is around 100 MB (couldn't say exactly as I am using swap) with Xvesa extension after 29 d uptime.
-
Everyone: Flume is now available on the official TCE repository for TC 3.x. ;D
-
flume has an unusual behaviour under jwm-snapshot.
As I couldn't see a way to resize it, I tried Maximize-x & Maximize-y.
Consequence is that flume would "snap" to the left resp. top edge of screen, and when being dragged elsewhere it would instantly snap back upon release of mouse button.
Note: the builtin help browser can be resized as expected.
-
@tinypoodle: thanks for documenting that. Maybe I will allow full resizing the next time I work on it. For the shorter term, maybe I can come up with a way to ignore the resize events from the WM.
-
3.99 - 3 = 0
-
3.99 - 3 = 0
3.99 - 3.0 = 0.99
-
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.
-
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]
-
@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. ;)
-
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.
-
@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.
-
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.
-
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 :P) 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"
-
@ 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. ;)
-
@ 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