gum-128.png

GUM Calculator

Updated 2019-05-25

Overview: What Is GumCalc?

GUM Calculator, aka GumCalc, is an automated measurement-modeling and calculation tool. The most important feature, which makes it different from most other calculation tools, is its ability to propagate measurement uncertainty automatically. A second unusual feature is its ability to propagate the dimensions of measurable quantities. These two features together provide my rationale for calling it a measurement-modeling tool rather than a calculator program. Since I wrote GumCalc to be a tool for my own use at a radiochemistry laboratory, it also has many features that are intended to make it particularly useful in that environment.

GumCalc runs under Microsoft Windows. I have tested it with Windows XP, Windows 7, and Windows 10.

Note: Although GumCalc lets you create measurement models, you can use it every day for calculations and unit conversions without ever creating a model at all. You just type an expression in the Evaluation window and click a button to evaluate it, as shown below. There is an option to specify the unit of measurement for the result.

with-uncertainty.png

In this example the user has typed an expression to multiply the mass of the electron (m.e) by the square of the speed of light (c) and asked for the result expressed in kiloelectron volts (keV).

The program allows you to specify a measurement model as a collection of definitions of variables and functions. Each model may be saved in an electronic file and reopened and edited later. GumCalc also provides a capability to run a model on imported sets of data, with the values of specified variables being obtained from import files in CSV format. When the model runs, it can also export results to CSV files, which presumably can then be uploaded to other software systems or even a LIMS. (This export feature needs to be beefed up in the future to be more useful.)

Model variables come in four types:

  • imported variables (whose values are obtained from CSV import files)
  • text variables
  • input quantities (or input estimates)
  • output quantities (output estimates)

Measurement uncertainty is introduced into a model via the input quantities. The user specifies the value and uncertainty of an input quantity by specifying a type of probability distribution and the values of the parameters of the distribution. When other results (output quantities) are calculated from input quantities, they acquire uncertainty, too. The uncertainty of an output quantity (combined standard uncertainty) is automatically determined by uncertainty propagation.

The creator of a model can define variables and functions in any order, without worrying about the order of evaluation. The application itself determines the evaluation order that is needed to obtain meaningful results. It is possible for the model creator to create circular definitions, but GumCalc will detect any circularity without entering an infinite recursion, which would crash the program.

Dimensions in GumCalc are built up from the seven base dimensions of the International System of Units (SI). The seven base units of the SI are hard-coded in the program, while all other units are defined in XML setup files. The unit prefixes of the SI are also hard-coded in the program, and the unit setup files specify which units can be used with prefixes.

Downloads

The links below allow you to download an installer package, which will install GumCalc and required files on your Windows-based computer. Downloads, which include all the available version 1 features, are free.

The current builds include some version 2 features, which are hidden unless you have a key to unlock them. Friends who wish to try them out should contact me.

Other builds are still available if you find that those above simply do not work for you: 2011-05, 2012-01, 2012-02. Note that all of these are version 1.0 or pre-1.0. Later builds have more complete 1.0 features and, I hope, fewer bugs.

Please provide feedback if you find bugs. GumCalc has grown into a large, complicated project, and thorough testing has become more than one person can easily handle. I wish I could do a full test of the program after each modification, but I can’t. There are many features large and small, and I am occasionally surprised by a bug in a feature I seldom use or a bug that occurs only in an unusual situation. The cause may be nothing more than a typo or an overlooked line of code, but the effect may be a program crash.

You may find bugs that I wouldn’t, because you will use the program in ways that I don’t.

Change History
0.99.10
  • Implement the 2019 revision of the International System of Units and the CODATA 2018 adjustment of the fundamental constants, both of which were effective May 20, 2019.
  • Provide the Rydberg constant, R, as one of the primary experimental constants on which the values of others are based. Revise the definitions of other constants accordingly.
  • Revise the symbols for several constants, using the period implemented in 0.99.9 instead of the underscore to denote a subscript. If the symbol for a constant has a subscript, do not italicize the subscript when printing. For example, the symbol for the electron’s mass will be m.e, not m_e as in earlier versions, and it will be printed as me.
  • Make the lists of editable constants, units, and distributions sortable on all columns.
  • Correct a bug that led to crashes after deleting a constant on which the values of other constants depended.
  • Prohibit the use of all units except SI base units and their multiples and submultiples in expressions for user-defined constants. This limitation was previously assumed but not enforced.
  • Correct a problem with how the program wrote, read, and interpreted the file of nuclide data, failing to obtain the correct uncertainty for m(12C).
  • Allow more kinds of characters in identifiers, including Unicode subscript digits (e.g., a₁). Provide user-reversible auto-correction to generate subscript digits when the user types an ordinary digit after an underscore.
  • Provide a new version 2 function to calculate the density of air-free water at a specified Celsius temperature using the Tanaka equation.
  • Make several cosmetic changes.
0.99.9
  • Update the constant library with new values from CODATA 2014. Update the definitions of the astronomical unit (au) and parsec (pc).
  • Correct a bug that makes it impossible to use the correlation coefficient for one pair of constants or variables in the definition of the correlation coefficient for another pair of variables. Previous versions treat this as a circular definition, even when it is not. Worse, they leave the r(x,y) library function flagged as unusable until the program closes.
  • Change the implementation of the file Save As dialog, updating its appearance and changing how it provides default file extensions (with a new workaround for some deficiencies in the Microsoft API).
  • Allow many of the windows to be resized.
  • Reverse the order of updates listed when a user checks for updates and clicks the Details… button, showing the most recent update first.
  • Make several enhancements of the program’s icons and bitmap images, including those on the toolbar.
  • Let the user choose the font for displaying special Unicode characters.
  • Correct a minor bug in the implementation of auto-completion lists. The bug, which was introduced in 0.99.8, causes the up and down arrow keys to work incorrectly with the list of suggestions.
  • Make the printing of uncertainty budgets optional in each user-defined report.
  • Enhance the XML import feature (version 2), allowing the user to specify the XML tree structure by selecting an existing XML data file as an example. Modify the XML import logic slightly to implement a different trigger condition for generating output. Provide more error-checking and some enhancements in the user interface (e.g., more drag-and-drop operations and new buttons for editing import units and date format strings). Expand the explanation of XML import formats in the Help system.
  • Provide a new (version 2) function for the natural isotopic abundance of a nuclide.
  • Provide the symbol (U+212F) for Euler’s number with (U+2147) as a synonym, instead of the lower-case Latin e (U+0065). Will define e instead to mean the elementary charge (charge of a proton). The symbol for Euler’s number will still be printed—correctly—as an upright small Latin letter e.
  • Provide keyboard sequences for several Unicode combining diacritical marks, including accents grave, acute, circumflex, tilde, umlaut/​diaeresis, cedilla, macron, breve, ring, caron/​háček, and a few others. Allow these accents to be used in identifiers.
  • Eliminate the auto-correct sequences \| and \& for Boolean and , retaining the sequences || and &&.
  • Test a new design that uses a period to introduce a subscript in a variable or function identifier (e.g., c.A to represent activity concentration, cA).
  • Improve the formatting of identifiers in printouts, implementing subscripts as described above and ensuring that non-alphabetic characters are not italicized. (For now, there is still no way for the user to override the rules for use of italics.)
  • Automatically wrap long printed equations.
  • Implement the Ctrl+Up arrow and Ctrl+Down arrow key combinations to change the case of selected text, with support for basic Latin, Greek, and Cyrillic letters and also many accented Latin letters.
  • Provide auto-correction of &-sequences inside quoted strings, leaving the user the option to press Ctrl+Z to undo the auto-correction if necessary.
  • Allow the use of the backslash character (\) inside a quoted string as a prefix for a literal character, as in “William F. \“Bull\” Halsey, Jr.”
  • Implement the Alt+X key combination to toggle Unicode representations of selected text.
  • Revise the 0.99.3 implementations of Ctrl+Right arrow, Ctrl+Left arrow, and double-click, which were never satisfactory.
  • Correct a few errors in the nuclide database, and add information.
  • Implement a new version 2 feature for exporting results to XML files.
0.99.8
  • Corrects an obscure bug that revealed itself only if you ran the program with a unit library that omitted the becquerel (Bq).
  • Corrects a bug that caused the program to omit the parentheses in an expression like Ar(O) in a printed uncertainty budget. In version 0.99.7 this expression appeared incorrectly as ArO, although the relative atomic mass of a nuclide, such as Ar(3H), was printed correctly.
  • Provides an option to have GumCalc check for available updates automatically at start-up, on a user-specified schedule.
  • No longer displays an annoying auto-completion list when the user types the e in a floating-point number using scientific notation (e.g., 1.57e-4).
  • Makes it easier to find components in the tree view of a large model. It allows the user to right-click a reference to a model variable or function and have the program find and highlight its definition in the model tree. It also provides an option to list components alphabetically under each node. And it provides an option to group model variable definitions by type (import, text, input, output).
  • Includes several other changes in the implementation of the tree view and tabbed view of a model. These changes are intended to correct oversights, make the interface more user-friendly, and simplify the code that coordinates the updating of each view. The method for renaming a function has been simplified, eliminating the dialog box used in earlier versions. Although the tabbed view is still provided, the tree view is fully functional.
  • Fixes a previously unrecognized bug that may have caused occasional invisible program crashes when the user tried to exit while a document was still open. The only apparent symptom would be the loss of unsaved changes, where the program failed to prompt the user to save a modified document. I still consider this bug to be an error in the Microsoft framework itself, which would sometimes delete an object and then try to reference it via a dangling pointer.
  • Corrects an almost completely inconsequential bug in the implementation of auto-correction for the dialog box that is used to create and edit functions.
  • If the column labels in a CSV import file match the expected labels of the current import format only partially, the program gives the user the option of updating the import format to match the labels in the file (exactly).
  • Provides configuration options for showing or hiding various windows at startup. All versions to date have automatically displayed the “Evaluation” window, which may prevent inexperienced users from exploring other features.
  • Makes slight changes in the format of printed reports.
  • Implements the menu items Help | Library constants, Help | Library functions, and Help | Library units using MDI child windows instead of modeless dialog boxes. The MDI windows do not force themselves to the front of other child windows.
Unfortunately, 0.99.8 also introduces a new bug in the implementation of auto-completion lists. The bug will be corrected in 0.99.9.
0.99.7
  • Corrects a bug that was triggered in the tabbed view of a model when a user attempted to switch tabs while still editing the label for an item (i.e., when renaming a variable). This may be the same bug that I first thought might be related to reopening and editing a new report, since I discovered it while trying to do just that. The most obvious symptom was an immediate program crash, but other symptoms may also have been possible.
  • The implementation of pop-up prompts for function arguments in 0.99.6 created a bug that affected the dialog box for editing a CSV export format, sometimes causing the program to display incorrect pop-up lists. Version 0.99.7 corrects the bug.
  • Removes minor glitches in the autocorrection features in some of the edit controls.
  • Corrects a bug that would trigger the message DEBUG: Unexpected situation. Programmer error? when the user entered an invalid unit expression in the Evaluation window and pressed ENTER. (It was indeed a programmer error.)
  • Provides an option to duplicate a model component, creating a new unnamed copy, which the user can either edit and save or discard.
  • Re-implements the operators ∂(y,x), @ui(y,x), and @ui2(y,x) in a way that allows them to accept an arbitrary expression as the second operand x as long as the value of x depends on just one input quantity. The old implementations required x to be the symbol for an input quantity. The new implementations allow one to evaluate an expression like ∂(decay(“Cs-137”, 180{d}), HalfLife(“Cs-137”)) or even ∂(decay(“Cs-137”, 180{d}), lambda(“Cs-137”)).
  • Makes auto-completion listboxes (auto-lists) optional. They are still enabled by default. To disable one or more of them, see Tools | Options | Preferences.
  • No longer supports the syntax @sum(i,a,b)(e) and @prod(i,a,b)(e), as mentioned under 0.99.3 below. Use ∑(i=a:b)(e) and ∏(i=a:b)(e) instead. I expect to continue supporting the alternative syntax ∑(i=a,b)(e) and ∏(i=a,b)(e), too.
  • Provides better, more specific user error messages for invalid operations.
  • Improves the data grid used for editing CSV export formats and the data grid used for editing unit definitions.
  • Version 2 features now include a function chi2tail(x,n) for calculating the tail probability of a χ2 distribution with n degrees of freedom and also a function chi2(q,n) for the inverse operation χ21−q(n). Note that chi2tail(x,n) = Q(n/2,x/2) and the function Q(a,x) was already available as a Version 1 feature.
0.99.6
  • Corrects a bug that would crash the program when the user opened or created a model containing a correlation definition, evaluated an expression, deleted the correlation definition, and then tried to evaluate any expression that required that correlation coefficient.
  • Corrects an oversight that would leave the image of an open folder displayed for a component group in the tree view of a model even after the user deleted the last item from the group.
  • Provides automatic syntax upgrades for old function definitions that use < and > as angle brackets. (I think I had provided them for every other type of model component but had forgotten to provide them for function definitions.)
  • Provides some missing functionality in the edit control used to specify the preferred unit for an output quantity.
  • Allows reporting of a model variable using an appropriate unit of measurement even when the user’s preferred unit has the wrong dimension for the quantity.
  • Provides more contextual information with many of the user error messages to help users debug their models.
  • Improves the export feature with a few tweaks, although it needs much more than tweaks.
  • Implements a pop-up window to prompt the user for arguments when typing a function invocation.
  • Includes a few previously missing &-entities (e.g., &xi; = ξ, &mdash; = , and &ndash; = ) and the corresponding TeX control words (\xi, \mdash, and \ndash).
0.99.5
  • Corrects errors in the user interface for creating and editing correlations between library constants (Tools | Edit constants…).
0.99.4
  • Disables TeX-style control words and control symbols in edit controls used for the names of files and folders.
  • Improves accuracy of the last (15th or 16th) digit when numerical results are formatted for display without uncertainty.
  • Allows a model to continue running after a CSV data-import error and improves the presentation of the error message in the printed output.
  • Produces more specific user error messages for CSV import failures.
  • Improves the operation of auto-completion listboxes, making better use of the context to choose the highlighted item and replacing more text when the selected item is accepted.
  • Autocorrects &ohm; to Ω (U+03A9), not Ω (U+2126), so that &ohm; really is equivalent to &Omega;, as previously advertised.
  • In the form used to edit a CSV import format, provides a workaround to keep the OK button from canceling an active edit operation. (This perverse behavior had been a problem for years, but I never noticed it until I was testing another feature with a very small import format.)
0.99.3
  • Corrects a bug in the Tools | Edit constants… feature that could cause some constants not to appear in the list or cause the program to crash when displaying the list.
  • Corrects an oversight that prevented evaluation of the average (@avg) of a list of dates or a list of temperatures.
  • Corrects an oversight in the implementation of the ration function (version 2) that prevented the calculation of atom ratios for long-lived progeny.
  • Corrects a minor bug that affected the appearance of Euler’s number e in printed reports.
  • Detects overflows in rational arithmetic and switches to floating-point arithmetic when necessary.
  • When renaming variables, provides warnings for conflicts between new variable symbols and other identifiers (function parameters and the iterators in n-ary sums and products).
  • Provides more warnings for attempts to perform invalid calculations with dates or temperatures.
  • Provides TeX-like control words for typing non-ASCII Unicode characters. HTML-like &-entities were already provided for the same purpose.
  • Emulates certain TeX control symbols for adding Western European accents to letters (e.g, \'e to produce é).
  • Tries to provide better feedback for user syntax errors.
  • Provides a sign function to tell the sign (−1, 0, or +1) of a scalar quantity, ignoring its unit of measurement.
  • Provides Boolean constants true and false, relational operators (e.g., and ), and logical operators (e.g., , , ¬) for constructing Boolean expressions. Provides keyboard sequences for typing the new symbols using auto-correction (e.g., <= for , <> for , \& for , \| for , ~ for ¬).
  • Makes another small change in the syntax for n-ary sums and products. The preferred syntax is now ∑(i=a:b)(e) for sums and ∏(i=a:b)(e) for products, although ∑(i=a,b)(e) and ∏(i=a,b)(e) will still be accepted, probably in perpetuity, since I am still in the habit of using them, and since parsing them is easy. The original forms @sum(i,a,b)(e) and @prod(i,a,b)(e) are deprecated and will soon be unsupported. My code for parsing those forms has always been inelegant and I want to deep-six them.
  • Replaces the symbols < and > previously used as angle brackets with actual angle brackets and , allowing < and > to be used as relational operators. Provides keyboard sequences \< and \> for typing the angle brackets using auto-correction. For compatibility with Windows and Arial Unicode MS, the keyboard sequences generate the deprecated characters U+2329 and U+232A instead of the preferred characters U+27E8 and U+27E9, but the parser considers U+2329 ≡ U+27E8 ≡ U+3008 and U+232A ≡ U+27E9 ≡ U+3009.
  • Provides better spell-check suggestions for identifiers that contain accented letters, ligatures (e.g., æ and œ), or certain foreign letters that may be transliterated as two English-Latin letters (e.g., Ch for Č).
  • In version 2, provides C-style conditional evaluation operators (e.g., m ≤ R ? 1 − m / (2 × R) : R / (2 × m)). Note that version 2 features are accessible only with a user-specific key code.
  • Provides a new version 2 function to calculate the theoretical maximum relative mass yield of a chemical product from a chemical reactant; e.g, yield(“KIO3”,“PdI2”) or yield(“KIO3”,“PdI2”,“I”). Use the 2-parameter version if the reactant and product have only one element in common. Otherwise, use the 3-parameter version to specify a shared element on which to base the calculation.
  • Provides a Details... button for obtaining additional information about available software updates.
  • Makes it slightly easier to create a new component in the tree view of a model by enabling the New operation whenever an existing component is selected.
  • Provides new event handlers for Ctrl+Right arrow, Ctrl+Left arrow, and double-click in edit controls. I found the old ones annoying, especially Ctrl+Right arrow and Ctrl+Left arrow.
  • Makes several significant changes in the expression-parsing algorithm, primarily to remove old kludges and simplify the code.
0.99.2
  • Version 0.99.2 was an incomplete implementation of 0.99.3. I gave it to only one person and then incremented the version number.
0.99.1
  • Avoids crashes caused by certain mouse-over tooltips
  • Removes a bug that caused incorrect selection of preferred units for radionuclide half-lives (due to an embarrassingly obvious mistake in the code, which I discovered when I added the ampere-hour to my unit library)
  • Avoids errors triggered when a user renamed any constant upon which another constant’s definition depended
  • Correctly propagates uncertainty for the expm1 function
  • Corrects errors and omissions in the history of US daylight saving time
  • Provides menu icons (still subject to change)
  • Allows user to check for software updates
  • Provides autocompletion lists for unit symbols
  • Provides more complete implementation of autocompletion and autocorrection features throughout the program (e.g., in combo boxes, list controls, and tree controls)
  • Labels columns in uncertainty budgets more appropriately
  • Provides header sort buttons for the tables of constants, library functions, and units under the Help menu
  • Provides a more compact context menu for inserting special characters into edit controls
  • Includes additions and corrections in the help system
  • Provides a Help Favorites tab
  • Implements the log1p function (because I found the standard C/C++ version of log1p useful when implementing some of the decay/ingrowth functions)
  • Uses a new algorithm for dealing with certain sets of correlated input estimates (e.g., decay branching factors whose sum is 1)
Future changes
  • Provide capability to import from and export to Microsoft Excel workbooks.
  • Provide features for editing tabular import data files (CSV or Excel).
  • Provide a function to calculate a zeta (ζ) score for one argument or for the difference of two arguments.
  • Provide options to use pipes (|) or semicolons (;) instead of commas as delimiters in CSV import and export files.
  • Bring the help system up to date.
  • Provide more sophisticated report formats.
  • May provide a small collection of pre-defined models as examples for new users.
  • Should provide an option to find all references to a selected variable or function.
  • May provide a feature to search for arbitrary text strings in a model—e.g., in the descriptions of variables and functions.
  • Should provide pop-up auto-completion lists and prompts for @ keywords and operators such as @now, @user, @avg(…), and @stdev(…).
  • May enhance the nuclide browser to show the parents and daughters of the currently selected nuclide and to allow navigation forward and backward along the decay paths. If so, the enhancement should be a version 2 feature.
  • Should provide a capability for users to build their own function libraries (version 2).

If you encounter an error, please report it, especially if you can tell me how to reproduce the symptoms so that I can find the cause and correct it.

Features

GumCalc has all the main features envisioned for version 1.0, including:

  • automatic uncertainty propagation
  • automatic propagation of dimensions of quantities and easy conversion of units
  • extensible library of predefined mathematical and physical constants (XML)
  • built-in SI base units
  • extensible library of SI derived units and off-system units (XML)
  • experimentally determined units (with uncertainty), such as the electronvolt and the unified atomic mass unit (XML)
  • handling of correlations between model variables and also between the predefined constants and experimentally determined units
  • built-in library of standard mathematical functions
  • dates and times, with parsing functions
  • special functions for the radiochemistry laboratory
    • half-life — e.g., HalfLife("Co-60")
    • decay constant — e.g., lambda("Co-60")
    • decay factor — e.g., decay("Co-60", 160 {d}) or decay("Co-60", date("2008-07-15 12:00 CDT"))
    • specific activity — e.g., a("Co-60")
    • atomic mass — e.g., m("U-238") or m("U")
    • molecular mass — e.g., m("Sr(NO3)2")
  • extensible set of probability distributions for defining input quantities (XML)
  • a nuclide database, with half-lives, isotopic abundances (not yet used), and atomic masses
  • an element database, with atomic numbers and relative atomic masses (XML)
  • vector and matrix operations
  • data import and export (via CSV files)
  • formatting options for results with uncertainty:
    • either standard uncertainty or expanded uncertainty
    • user’s choice of coverage factor (k) for expanded uncertainties
    • parenthetical format for standard uncertainties; ± format for expanded uncertainties
    • automatic rounding of uncertain results, per recommendations of the GUM, MARLAP, ANSI N42.23, etc., with choice of the number of figures in the uncertainty
  • uncertainty budgets
  • automatic backups of model-definition files
  • an online help system (never quite up-to-date or complete—sorry—but it’s > 95 %)
  • labeled CSV formats for import (with named columns)
  • ability to print each model in an attractive format
  • time zone and format options for dates and times
  • propagation of time zones through date-time calculations
  • an implementation of preferred units for calculated quantities, and propagation of preferred units through many calculations
  • Celsius and Fahrenheit temperatures – not just temperature differences
  • atomic weight data from IUPAC (2005, 2007)
  • an XML version of the nuclide database, allowing users to update data and recompile

Ideas for GumCalc version 2 include:

  1. a slicker user interface, perhaps taking inspiration from the user interface of Visual Studio
  2. a more sophisticated nuclide database with parent-child relationships, allowing built-in functions for calculating ingrowth factors (in progress)
  3. default values for missing import variables
  4. Monte Carlo methods for propagating distributions
  5. effective degrees of freedom for combined uncertainties
  6. XML formats for importing and exporting data (Both of these are underway.)
  7. more reporting options
  8. least-squares regression
  9. use of the concept of the type of a measurable quantity, not just its dimension
  10. more special functions in the function library

I really want a better user interface (item 1), and I have some ideas for the design. Items 3–5 would also be nice to have. I’ve partially implemented XML import formats (item 6). In January and February 2013 I more or less completed my implementation of the functions for decay and ingrowth (item 2). These functions, called decayn and decaya, calculate decay/​ingrowth factors based on probability (or atoms) and activity, respectively. There are overloaded versions for average decay and ingrowth factors during a counting interval. Note that a function for calculating simple decay factors (decay) was already included in version 1.0, since it did not require a new database. After starting work on decayn and decaya, I realized how easy it would be to calculate equilibrium ratios (in GumCalc, the daughter-parent activity or atom ratios in a state of radioactive equilibrium). So, two other new functions called eqrn and eqra are included among the version 2 features. As of March 2013 there are also version 2 functions for calculating the age of a sample based on its current daughter/​parent ratio.

Friends who like GumCalc and want to test the version 2 features that are hidden in the most recent builds can contact me personally to obtain a key value to unlock those features. Note that keys cannot be shared.

I will add a few other user-friendly interface features. For example, there will be a tool to search a model for occurrences of specified identifiers or text strings. The current version already implements mouse-over tooltips for components of mathematical expressions. It also matches parentheses and other grouping symbols automatically as you type (by color-highlighting both of the paired symbols) and by request (by selecting the matching symbol when you select one of a matched pair and type Ctrl+]). It provides visual and auditory feedback for unmatched grouping symbols.

I also intend to update many of the nuclide half-lives. You can wait for me to do it, or you can do it yourself. I downloaded a large file of nuclide data from the National Nuclear Data Center years ago and did not update it again. Only recently have I started manually updating half-lives using data from Laboratoire National Henri Becquerel (www.lnhb.fr/en/).

It is tempting to keep adding features to version 1.0, but at some point I have to stop. I’m now calling the feature set closed, but I’m still trying to make sure all those features perform as expected. When I think it has been evaluated and tested enough, version 1.0 will be finalized, and I will continue work on new versions.

The feature set may be closed, but it’s not hermetically sealed, because I still yield to temptation now and then, as evidenced by the addition of TeX-style control words. Small improvements in the version 1 user interface are still possible.

I intend to maintain GumCalc version 1 as freeware. Updates will be limited to bug fixes and other small improvements. If I revamp the user interface and add major features, I will use new version numbers starting at 2.0, but versions 1.x will still be available for free.

Quirks

GumCalc has some aspects that may seem odd on first encounter. Many of us are accustomed to performing a series of calculations with numbers, using mathematical functions such as exp, log, or sin, without worrying about the units of measurement until the final result is obtained. Since GumCalc propagates the dimensions of quantities step by step as it calculates the results of these functions, it must enforce some restrictions on the values of the arguments.

Since the dimension of a quantity is a product of powers of the seven base dimensions, it makes sense to raise a quantity x to a power or take its square root, but it makes no metrological sense to say exp(x), log(x), or sin(x) unless x is dimensionless. This does not mean that x cannot be expressed in some unit of measurement, but the unit must be a dimensionless unit, such as the radian, degree, or percent.

Similar observations can be made about raising a quantity y to the power x. The expression yx makes no sense unless x is dimensionless.

One may encounter expressions of this sort in the literature, but they make sense only if the unit of measurement is specified. When an equation is written in terms of the numerical values of quantities relative to specified units, all the variables in the equation become dimensionless and anything goes. GumCalc on the other hand allows one to write equations in terms of the values of the quantities, not just the numerical values, and this fact requires one to be more careful. It also helps the software detect logical errors in the user’s work.

Looking at it another way, writing yx where x is the mass of the residue in milligrams is equivalent to writing yx/(1 mg) where x is the mass of the residue. The latter version makes it clear that the exponent is a dimensionless ratio. It would be nonsensical to say yx where x is the mass of the residue without specifying the unit of measurement for x.

A second issue is the fact that GumCalc cannot distinguish between different types of quantities unless they have different dimensions. For example, activity, count rate, and frequency are three different types of quantities and are usually expressed in different units. However, since all three have the dimension of reciprocal time, T−1, GumCalc cannot distinguish one type from the other, and it allows you to express any of these quantities in any unit of measurement that has the dimension of reciprocal time. For example, you can convert a frequency from hertz (Hz) to becquerels (Bq), and GumCalc won’t detect the error. Of course GumCalc will not let you use a unit with the wrong dimension for the quantity being expressed.

One other quirk exists because of the software’s need to compare dimensional exponents without rounding error when adding or subtracting quantities. To eliminate rounding error, GumCalc requires that dimensional exponents be rational numbers, not floating-point numbers. So, a quantity that is not dimensionless cannot be raised to a power that isn’t rational. Therefore, if the dimension of x is not unity, you can evaluate x3/5 but not x0.6, because GumCalc obtains a rational value for the expression 3/5 and a floating-point value for the expression 0.6. With an enhanced numeric parsing function, this limitation might be partially eliminated, so that the program would recognize 0.6 as equivalent to 3/5, but the requirement that dimensional exponents be rational is likely to remain.

The versions of GumCalc produced since 2010 provide the ability to include arbitrary positive numerical factors in a unit expression, allowing expressions like pCi/100 cm2. At first I wasn’t sure how kosher this was, but it is a common practice when reporting swipe measurement results in the U.S., and it makes perfect sense if we consider the number itself to be a unit, as GumCalc does. The factor must not appear after a unit symbol or a complete subexpression, since a number in that position is parsed as an exponent. Nevertheless, even with that restriction this feature raises new questions about the semantics of unit expressions, since an expression of the form a2/3 b could reasonably be interpreted as either a2/3 b or a2 / (3 b). The other possible interpretation, (a2 / 3) b, is ruled out by the fact that in GumCalc the multiplication implied by juxtaposition of symbols has a higher operator precedence than explicit multiplication or division. The parser currently uses the first of these interpretations, but I am starting to question the logic of that choice, given that juxtaposition generally has a higher precedence than division. From the start I have recommended that you use parentheses to eliminate any possible ambiguity (a(2/3) b, a2/(3 b), or ((a2)/3) b), and I recommend it now more strongly. Note that the BIPM makes a similar and more general recommendation for the use of all SI unit symbols that involve multiplication and division (www1.bipm.org/en/si/si_brochure/).

Sometimes you may see that the numerical value of a quantity displayed by GumCalc is slightly different from the value that you entered. This quirk occurs because GumCalc represents all quantities internally in SI units but may display them for you in any valid units that you choose. The conversions back and forth between SI and other units may cause very small rounding errors. I have also seen a case where a value is calculated as 4.963 {pCi}/{L} and then displayed as 4.962 999 999 999 999 pCi/L. If the value is calculated instead as 4.963 {pCi/L}, the result is displayed as 4.963 pCi/L. Again, the difference is due to machine rounding. There is no guarantee that a floating-point processor will obtain exactly the same result for (x × y) / z and x × (y / z).

The nuclide library provides the uncertainty of each half-life and atomic mass, but it has no information about the correlations that exist among these values, and it currently has no capability to use such information even if it becomes available. This lack of capability is a known weakness rather than a quirk.

Another weakness in the nuclide library and the decay-and-ingrowth functions is their inability to account for spontaneous fission as a possible mode of decay.

Temperature Functions

In 2011, I implemented absolute temperatures in the program with a choice of temperature scales. (Note that I have not implemented either Celsius temperature or Fahrenheit temperature as a new type of quantity.) To specify an absolute temperature, you can use any of the functions celsius, fahrenheit, kelvin, or rankine. Since these functions return absolute temperatures, some arithmetic operations are undefined on the results. The only operations currently guaranteed to be provided are certain types of addition and subtraction. Although it makes sense to multiply or divide a temperature by a numerical factor, it may be confusing to many users. For example what result do you expect if you type the expression celsius(4) * 2? Since celsius(4) is equivalent to kelvin(277.15), the correct result is 554.3 K, or 281.15 °C, not 8 °C. I may decide that to avoid confusion, multiplication and division of these temperatures should not be allowed.

I’m also reconsidering the decision to have the celsius and fahrenheit functions return absolute temperatures instead of Celsius and Fahrenheit temperatures (relative to 0 °C and 0 °F, respectively). The rationale for the original design is that it makes the results from all the new temperature functions comparable, so that subtraction is easy and unit conversions make sense. The downside is that there is a small but noticeable loss of precision when expressing the results relative to 0 °C or 0 °F. Because of this loss of precision, the implementation may change.

Units and Uncertainty

Combining automatic uncertainty propagation with unit propagation reveals relationships between the two that may not be obvious. In particular, the uncertainty of the result of a measurement depends on the unit of measurement. It should be clear that the numerical value of the uncertainty depends on the unit of measurement, but in fact the actual value of the uncertainty depends on it, too.

Why does the uncertainty depend on the unit of measurement? Because measuring a quantity really means determining the ratio of that quantity to another specified quantity — the unit of measurement — and the uncertainty of that ratio depends on both quantities, including the unit. The value of the ratio may be known better for some units than others. For example, if you want the uncertainty of the mass of an atom of 12C, it matters whether the value is expressed in kilograms or unified atomic mass units. If the unit is the unified atomic mass unit, the uncertainty is exactly zero. If the unit is the kilogram, the uncertainty is positive.

Although the uncertainty of a measurement result depends on the unit, the interface that GumCalc presents does not make this fact obvious, because it provides a function u(x) that returns the standard uncertainty of the argument x, and the unit of measurement is not specified. GumCalc can do this only because it implicitly bases all quantities on the International System of Units (SI), which provides a frame of reference in which the concept of the uncertainty is unambiguous.

In GumCalc the expression u(x) returns u({x}) × [x], where [x] is the appropriate SI unit for x (base unit or coherent derived unit) and {x} is the numerical value of x with respect to that unit. When you evaluate the expression x in the Evaluation window, you can specify any appropriate unit for the result, and GumCalc will evaluate the uncertainty properly for the chosen unit. Note: The uncertainty you get may differ from what you would get by evaluating the expression u(x) with the same unit.

About the Icon gum-32.png
The GumCalc icon (a red, green, and blue Δ) has no significance. It was designed only to be easily recognizable on the desktop.