Availability: git@github.com:MetaCommunity/igneous-math.git
Dependencies:
Supported Implementations
This program system is being developed primarily with Steel Bank Common Lisp (SBCL). Though some effort is made to ensure portability with other Common Lisp implementations, however SBCL is effectively the reference platform in development of this program system.
Although this sytem endeavors to implement ANSI Common Lisp, as for purpose of portability, however in regards to extensions of the Metobject Protocol, some implemetation-specific features might vary.
Pending further development of Igneous-Math onto the specified reference platform, the Igneous-Math codebase may be revised for portability onto other Common Lisp implementations.
License: Eclipse Public License 1.0
This system has been designed initially as an academic exercise. It is hoped that this system may be developed towards a level of application quality, such that this system may be considered for commercial applications. To this time, the Igneous-Math software system has been designed towards a concept of a manner of semantic normalcy, although not as if to make a sacrifice of mathematical accuracy, in defining the semantics of the implementation.
- Object model for measurements. Extending of the Common Lisp Object System (CLOS), Igneous-Math defines a model for measurement domains, measurement classes, and expressions of measurement units.
- Mathematical operations. Igneous-Math defines a set of generic functions and methods as interfaces onto the set of numeric functions defined in CLtL2. These generic functions and methods are specialized for monadic, diadic, and variadic application -- in extension of the Common Lisp metaobject system -- moreover specialized onto individual classes of numeric field as defined in CLtL2.
- _Rational coercion for floating-point values. On input, a floating point value may be converted into a rational value, comprised of an integer and an exponent, such that would represent a value scaled of the original input value. Subsequent mathematical operations may then be applied as onto the rational equivalent of the input value, namely as to minimize inaccuracies attendant with point numeric implementations, in individual floating point errors and in feedback errors (see also: Hamming, Richard W. Numerical Methods for Scientists and Engineers. 2 ed. Dover. 1973)
The implementation of rational coercion is effectively integrated with the measurements model in Ig1m
- Implementation of forms for vector methamtics and linear analysis
- Scalar value type, corresponding with the measurements module
- Vector value type, with corresponding numerical operations
- Matrix values and corresponding mathematical operations
- Implementation of an object model for coordinate systems and
coordinate syntaxes, independent of the Common Lisp Interface
Manager (CLIM)
- Euclidean Coordinate Plane
- Extensionally, an implementation of a complex coordinate plane, graphically analogous to the Euclidean coordinate plane
- Polar Coordinate Plane
- Euclidean Coordinate Plane
- Presentation of phasor diagrams, in applying the modules for vector mathematics and for polar coordinate planes
- Implementation of spatial object systems
- 3 Space (Euclidean)
- Spherical Space
- Object model for vector mathematics in spatial object systems
- Graph model for visual coordinate system presentation, integrating with CLIM (see also: McCLIM Scigraph application)
- Comprehensive integration with standard systems of measurement, referencing the Systeme Inernationale (BIPM) and NIST guidelines
- Automatic adjustment of measurement values onto the decimal prefix system, for standard measurement units
- Automatic adjustment of measurement values onto the binary+decimal (2^10) prefix system, for quantities of digital information [][#jedec:jesd-100b.01][][#wikipedia:byte] preferring the JEDEC convention for prefixes "K", "M", and "G" for units of bits, "b", and bytes, "B" with user option for selection of a consistent IEC prefix system [][#wikipedia:byte]
- Implementation of an object model for formulas in CLOS -- referencing the KR system in the Garnet codebase
- Integration with machine-specific numeric operations (e.g SSE2)
- Applications towards modeling and analysis of principles developed in the electrical sciences, separately onto domains of alternating current and direct current, and onto a frequency domain for analysis of signal-processing applications -- ideally, to be integrated wth a system for schematic capture and block-level circuit modeling, onto McCLIM.
- Integration with formal reference texts, in eBook and print editions
Ig2m is the second major version of [igneous-math]. Essentially, Ig2m represents a restructuring and partial refactoring of the Ig1m source tree, with corresponding development of individual modules begun originally in development of Ig1m.
Development in Ig2m will be focused about the following concepts:
- Extension of the base measurements module, for geometric units of measurement and compound units of measurement
- Normalization and conversion of measurement units, within overloaded mathematical operations
- Definition of seperate reader macros for each of unit expresions
and measurement values containing unit expressions, e.g.
#{3.0E+08 <m <s -1>>}
The sections of this outline, immediately following, are developed for application about the design of the first of those three modules.
In Ig1m, each of the seven fundamental base
units of the Systeme International was impelemented such as with the
following example: The class METER
would have as its metaclass, the
class LENGTH
. The class LENGTH
would itself represent a
measurement domain, while likewise being defined as a metaclass.
During the development of classes for dervied units in Ig2m, that feature of the design of Ig1m has been reconsidered.
In Ig2m, the following additional classes are defined, as for differentiation of measurement syntaxes defined to specific types of measurement unit:
LINEAR-MEASUREMENT-CLASS
GEOMETRIC-MEASUREMENT-CLASS
COMPOUND-MEASUREMENT-CLASS
Furthremore, the following two classes are defined as for differentiation between derived units and base units
DERIVED-MEASUREMENT-CLASS
BASE-MEASUREMENT-CLASS
Effectively, every BASE-MEASUREMENT-CLASS
is likewise a
LINEAR-MEASUREMENT-CLASS
, though certainly not every
LINEAR-MEASUREMENT-CLASS
is likewise a
BASE-MEASUREMENT-CLASS
. Semantically, however, the concepts of
Derived units and base units is orthogonal to the concept of linear
and other types of measurement class as developed in
Ig2m.
As a further feature of the design of Ig1m, originally: Considering that a measurement unit would have a measurement domain as its metaclass, then the measurement domain of a measurement unit may be calculated by computing the class of the measurement unit's representative class. To retain this feature onto the design of Ig2m, however, there must be a differention made somewhere semantically between a measurement domain and a measurement class, as to differentiate the measurement class for whether it is a base measurement unit or a derived measurement unit.
During development of Ig2m, a prototype was defined wherein a measurement domain would be extended (by way of subclass) by two additional measurement domains, one solely representative of a base or fundamental unit of measure for the domain, and the other for representing all types of derived measurement deriving from the base or fundamental measure of the associated measurement domain. Although this seemed to present a novel and convenient solution to the concern denoted of the previous paragraph, but it effectively "breaks" the procedures developed in Ig1m for indexing of measurement domains. Therefore, this prototype must be reconsidered for its essential meaning and relevance, in its own regards and as it may serve as a reflection of the design of Ig1m.
Continuing with the previous example:
- Semantically, Meter is a measurement of Length
- Programmatically, in Ig1m, the class
METER
has as its metaclass, the classLENGTH
. The classLENGTH
has as its metaclass, the classMEASUREMENT-DOMAIN
. Therefore, theMETER
class is aLENGTH
class, andLENGTH
is aMEASUREMENT-DOMAIN
. Furthermore, an instance of typeMETER
would be an object of typeMEASUREMENT
. - In Ig2m, initially it was considered that the
class
METER
must be redefined such that it would also be bot of aBASE-MEASUREMENT-CLASS
and aLINEAR-MEASUREMENT-CLASS
, itself. Both classes being orthogonal to the metaclass ofMETER
--
i.eLENGTH
-- it would pose some difficulty to apply those classes in the exiting Ig1m measurement model, as if to extend ontoLENGTH
During the development of Ig2m, a certain issue of code alignment was observed, with regards to the following three functions, such that were developed originally in Ig1m.
- Function
SCALAR-MAGNITUDE
- Function
BASE-MAGNITUDE
- Function
MESAUREMENT-MAGNITUDE
Correspondingly, this represents an issue of an essential concern of conceptual alignment as to the naming, meaning, and application of each of those respective functions.
In a computational sense, the magnitude of a value would be calculated seperate to the exponential degree of the value - such as, with or without an overlayed measurement prefix model.
As in how these functions have been developed in Ig1m: Perhaps the term "magnitde" has ben applied too broadly, within Ig1m, as if the term was synonymous with "numeric value".
Ed. Note: In an orthogonal sense, there may seem to be a further conceputal ambiguity of these concepts as implemented, but in an ambiguity towards concepts of 'magnitude' and 'degree' within vector arithmetic. Presently, that ambiguity will not be developed of this documentation.
Concerning the relevance of concepts "Magnitude" and "Degree", as in how those concepts have been developed and applied in the design of the measurements model in Ig1m -- as in order to endeavor to disambiguate the concepts as intended and the concepts as implemented of the design of each of those three functions denoted in the previous outline:
The measurement prefix model developed of Ig1m represents one of the primary concepts underlying the development of Ig1m. Essentially, the mesaurement prefix model was to the origins of the measurements design in Ig1m -- in which, a measurement may be evaluated seperately as either numeric value or as a scalar value of distinct magnitude and degree.
Simply, the numeric value of a measurement would be drived from its scalar properties of scalar magnitude and scalar degree, as for example:
Magnitude: 5 Degree: 2 Base: 10 => numeric value: 5 * 10^2 = 500
Although in this model, there are essentially three fields required for recording each numeric value, and so it may seem to be either redundant or excessively complex, but there may be some computational advantages developed of such an elemental encoding for a numeric value. For instance:
-
The base value need not be encoded into the numeric value itself, but rather may be derived of a metaclass of the numeric value. Thus, only the magnitude and degree would need to be recorded for each respective numeric value.
-
If a prefix measurement system would be applied onto the numeric value, then it would be a relatively straightforard process to compute a nearest prefix for the numeric value, as based on the encoded degree of the numeric value.
-
With regards to rational scaling of decimal numeric values, this manner of rational, elemental encoding for numeric values effectively serves to allow for computations to be completed all with rational intermediary values, even for decimal input values. Thus, this design may effectively serve to minimize the numer of instances of possible feedback errors as may occur due to floating point contagion during calculatin of intermediary values within the computational system.
In a sense of the design of Igneous-Math as a mathematical system, the concept of a magnitude -- namely, in which a magnitude would represent a scalar property of a numeric value, as a magnitude being a rational value that would be distinct to but not altogether seperate from an integer scalar decimal exponent property i.e scalar degree property for the numeric value -- essentially, that was thought to be one of the stronger conceputal "selling points" for the design of Igneous-Math - although it may be difficult to document, in any ways succinctly.
Notably, in the design of Ig1m, the concept of magnitude -- as in sense developed of the previous paragraph -- the concept, in its applications, had become essentially confounded with a broader concept of numeric value -- thus, becoming to something of a sense of ambiguity, as in how the concept is applied in the definition of each of the functions
SCALAR-MAGNITUDE
BASE-MAGNITUDE
MEASUREMENT-MAGNITUDE
...and in the concept is applied in those functions' respective applications, within Igneous-Math (Ig1m)
The same conceptual ambiguity may become apparent, when the system for measurement conversion -- as develoepd of Ig1m -- would be analyzed, as to consider both of the following concerns:
-
How the measurement conversion features of Igneous-Math were designed in Ig1m. Notably, this feature has not been well documented of the design of Ig1m, but insofar as the mechanics of this feature are apparent of the source code, then it may be discovered of the design of Ig1m -- albeit, not until after some relatively time consuming analysis.
-
How the design of Ig1m may be refactored, in any regards, as ideally to introduce some more of a computational efficiency in measurement conversions, within the Igneous-Math system -- such as, specifically, towards making a further application of a particular computational "short cut" for conversion of a measurement values onto the base measure of a measurement's measurement domain -- such that the "short cut" would need not apply the broader, linear measuremnt conversion framework, as also developed in Ig1m ...and also not presently well documented of this computational system, with the author's sinceremost apology.
Considering those as being two issues of analytical concern, the second of those two issues may serve to lend way towards an actual refactoring of the design of the same system.
With limited further apology, the author will not endeavor to comment at great length, towards any broader view of how the same computational system is evolving in its development in Ig2m.
If the author may denote a second bunch of concerns, succinctly: In the development of Ig2m, there have also been some concerns observed, as with regards to the system for measurement conversion -- such as developed in Ig1m -- as when that system is applied across the disjunction of the definitions of the measurement units kilogram and gram. This issue has been observed within functional testing, during the development of Ig2m.
Simply, whereas the measurement unit, kilogram, is defined as the base unit of measure for quantities of mass, then the measurement unit, gram may be denoted as a derived unit. Though it is the unit of zero degree within the base measure for mass, but it is not the standard base unit of measure for quantities of mass, such as standardized in the Systeme International and such as would be applied in any number of formulas entailing of quantities of mass, as within calculations onto the classical mechanics.
Although there was an implementation of a measurement unit kilogram, in computational system comprised of Ig1m, but the corresponding measurement unit, gram, had not been implemented in the same system. Certainly, Ig1m did not represent a complete implementation of measurement units -- as measurement units being of definitions standardized in Systeme International and as addressed in other institutional publications.
Ig1m was designed, essentially, as an initial prototype for a mathematical system. That prototype now being further developed, in Ig2m, the discussion will return to continue discussing the issues of the ambiguity of magnitude and numeric value, in Ig1m.
As regarding how a_numeric value_ may be encoded of seperate magnitude, exponent base and exponent degree values, there may seem to be some generic similarities towards implementations of floating point numeric systems. Excepting that the magnitude and the degree would both be iplemented as rational values -- as within Ig1m -- respectively, those concepts are analogous toe the concepts of mantissa and exponent, as represnted in IEEE standard floating point arithmetic.
Presently, that analogy will not be further developed of this article of documentaiton. If it may serve towards a development of a numeric system for a microprocessor, but considering the braoder industry adoption of IEEE floating point arithmetic, any further thesis as such should well be accompanied with a substantial proof of concept.
In one further divergence from the IEEE standard model for floating point arithmetic: Essentially, this system of numeric values represents not a floating point numeric implementation -- though it may naturally apply a floating point numeric implementation, insfoar as applications of standard implementations of numeric functions developed in CLtL2, typically implemented onto LibC.
Rather, the details of the design of this numeric system may be more characteristic of a decimal, "fixed point" numeric implementation, but in which each decimal value would be represented with a rational encoding -- such that the rational encoding of a decimal numeric value may serve to permit for mathematical operations mostly, if not entirely on rational numbers -- ideally, as to minimize errors that may result of floating point contagion and furthermore, of feedback within computational implementations of numeric systems.
In the development of Ig2m, a further distinction must be developed between concepts of numeric value and of rational magnitude. This may entail a substantial revision to the design of Ig1m, insofar as towards specific functional forms developed originally in Ig1m.
Insofar as towards an offhand analysis of possible side effects of such revisions: Ig1m was not widely publicized for its development. If it may be believed that any additional developers may have located the source code of Ig1m, in the source repository for igneous-math, at Github -- such that, hypothetically, in a functional manner, would be possible to anyone with Internet access, though it may seem likewise an unlikely possibility, in any offhand estimation -- then perhaps it may also be believed that any developer having located the same source code repository, at Github, may be of an understanding that Ig1m was by no means anything but a prototype, and should by no means be placed into any broad adoption. Likewise, it is a prototype to which Ig2m may not demonstrate any absolute backwards compatibility.
As the design of Ig2m continues to evolve, this article in documentation should be furthermore extended, as to illustrate the conceptual frameworks developed in Igneous-math, and to describe their intended applications within distinct usage case scenarios.
Candidly, this system was not designed to be a "Cheat Sheet" for the homework assigments at any single academic institution, and neither a "Short circuit" for any informal studies of disciplines in mathematics and the sciences of mechanical engineering.
It is hoped that this system may serve to assist in development of a single reference implementation for numeric calculations applying scalar values, in a comprehensive numeric system. Although there may not be any single, formal project denoting a development of such a reference implementation, however -- insofar as with regards to numeric systems developed in Common Lisp -- clearly, at least one proof of concept may already exist, such that could be considered towards development of a unified mathematical model for numeric applications, such as developed in Common Lisp.
Certainly this project, in itself, could only serve towards any such reference implementation, if only insofar as that this project has developed any complete solutions to any issues as may be presented to such reference implementation. Towards discovery of such issues, and towards their further documentation, firstly the developer accepts that the development of this system represent a substantial divergence from applications of existing tools in numerical computation. As Igenous-Math being essentially a software project, this system may not diverge from existing methods in development and application of mathematical methods in computational systems.
Though it might be remarked of as something of a "Horse of a different color," in regards to existing tools, and though the conceptual model presented of this project may not be obviously in alignment with any single institutional model -- the developer of this project being, moreover, not a student of any single thesis program, academically, though the developer is formally a student of a postsecondary academic institution, presently -- but insofar as that the development of this project may present an opportunity for reevaluation of existing methods in mathematical computation, and - in a manner of extension - an opportunity for an evaluation of alternate approaches for development of computational systems applying of decimal values, but the developer accepts likewise that it may not result in any too glaringly brilliant thesis topics.
If the reader may be hunting for a brilliant thesis topic, presently, the developer would kindly advise that a visit to a history museum may afford anyone a great opportunity to take a break from hunting. If the history museum be overcrowded, then, but so much is there to say of the natural history of society and the arts, as well as the artifacts of a museum's curation.
Thus, a discrete character of logic.
In a synopsis of the semantics of the design of the Ig1m measurements module: A measurement domain, in viewed in terms of SI, represents a type of quantity (e.g. temperature or inductance), whereas a measurement class represents an SI measurement type (e.g. degrees kelvin or henries) for quantities of a specific type.
In Ig1m, a measurement is essentially a scalar object that is an instance of a measurement class. Corrspondingly, a measurement class is an instance of a measurment domain. In Ig1m, measurement domains are implemented as metaclasses.
Correspnding with the semantic model for measurement domains,
measurement classes, and measurement objects,
Ig1m implements some qualities of a
presentational model for measurements. See also:
pretty-printable-object
[mci-cltl-utils]
- Class:
MEASUREMENT-CLASS
- Protocol class
- See also:
REGISTER-MEASUREMENT-CLASS
- See also:
MEASUREMENT-DOMAIN
- See also:
LENGTH
;MASS
;TIME
;ELECTRICAL-CURRENT
;TEMPERATURE
;AMOUNT-SUBSTANCE
;LUMINOUS-INTENSITY
;
- Class:
BASE-MEASUREMENT-CLASS
MEASUREMENT-CLASS
for SI base units- See also:
BASE-LENGTH
;BASE-MASS
;BASE-TIME
;BASE-ELECTRICAL-CURRENT
;BASE-TEMPERATURE
;BASE-AMOUNT-SUBSTANCE
;BASE-LUMINOUS-INTENSITY
;
- Class:
DERIVED-MEASUREMENT-CLASS
BASE-MEASUREMENT-CLASS
andDERIVED-MEASUREMENT-CLASS
form an exhaustive set of types ofMEASUREMENT-CLASS
- In application as a metaclass: Essentially, applied for definition of measurement units for which there is a single linear converstion ratio, for conversions to/from a base measurement unit or to/from another derived measurement unit
- Analous to existing
MEASUREMENT-CLASS
for (linear) derived units - See also:
CONVERSION-FACTOR
;FIND-CONVERSION-FACTOR
;MEASUREMENT-DOMAIN
- Class:
LINEAR-MEASUREMENT-CLASS
- Direct superclasses:
DERIVED-MEASUREMENT-CLASS
- Semantically correlated with
LINEAR-UNIT-EXPR
- Direct superclasses:
- Class:
GEOMETRIC-MEASUREMENT-CLASS
- Direct superclasses:
DERIVED-MEASUREMENT-CLASS
- Semantically correlated with
GEOMETRIC-UNIT-EXPR
- Direct superclasses:
- Class:
COMPOUND-MEASUREMENT-CLASS
- Direct superclasses:
DERIVED-MEASUREMENT-CLASS
- Semantically correlated with
COMPOUND-UNIT-EXPR
- Direct superclasses:
- Class:
UNIT-EXPR
- A unit expresion represents an expression of a measurement unit.
- Essentially, this concept pertains to presentation of measurement units. See also: McCLIM (MCi fork)
- An implementation of the concept unit expression may be
implemented as orthogonal to the Ig1m
MEASUREMENT-CLASS
-- eachMEASUREMENT-CLASS
, orthogonally, being an instance ofMEASUREMENT-DOMAIN
(which itself is a class). - In Ig1m, seven primary
MEASUREMENT-CLASS
classes are defined, each corresponding to a singleMEASUREMENT-DOMAIN
. - The class
UNIT-EXPR
may be implemented towards aUNIT-EXPR
representing a syntactic expression of a measurement class - Three essential types of unit expression
- Linear unit expression, e.g. as denoted with
m
orW
- The corresponding measurement class for each linear
unit expression may be indexed according to a symbol
representing the name assigned to the measurement
class (e.g
:|m|
) and correspondingly, to the unit expression
- The corresponding measurement class for each linear
unit expression may be indexed according to a symbol
representing the name assigned to the measurement
class (e.g
- Geometric unit expressions, e.g. as denoted with
m^2
- The corresponding measurement class for each geometric unit expression may be indexed according to the linear unit expression represented of the geometric unit expression and correspondingly, the degree of the geometric unit expression
- Semantically, a unit expression
m^2
represents a measure of surface area, whereas a unit expressionm^3
represents a measure of space. As in this trivial example: Although the respective concepts of surface area and space, may not be numerically relevant -- such as for formulas either applying or producing measurement values of those respective measurement units -- but infoar as to represent a semantic significance of the respective measurement units, it may be appropriate to define a measurement domain corresponding to each -- respectively, a domain for measures of surface area and a domain for measures of cubic space or volume. - "Special Note": [[BIPM][#BIPM]] defines the
measurement unit for the domain, frequency in terms
of SI base units as
s^-1
(e.g table 3, Eng. p. 118, PDF p. 26)
- Compound unit expressions e.g. as denoted with
m^2 kg s^-3
- The corresponding measurement class for each compound
unit expression may be indexed as a sequence of
elements [
simple-vector
]#(U D)
whereU
represents a measurement unit andD
represents a degree of that measurement unit. For example:#2A((m 2) (kg 1) (s -3))
as a normalized compound unit expression. corresonding toW
i.e.watts
- Alternatley, each element of the measurement elements sequence for a compound unit expression may be stored as a geometric unit expression.
- Orthogonally, towards a presentation model for compound unit expressions -- pending a design for superscript and subscript typesetting in McCLIM -- the presentation may be focused mostly about representing the syntactic qualities of a unit expressions, homologous with unit expressions in igneous-math. Where possible, measurement units should be presented in their derived forms (contrasted to normalized form)
- "Special Note": [[BIPM][#BIPM]] defines the
measurement unit for the domains, plane angle and
solid angle, when in terms of SI base units as
respectively,
m m^-1
andm^2 m^-2
. These two derivations may represent the only instances in which the base unit expression of an SI measurement unit is defined in a form not reduced for its exponents. Orthogonally, those expressions each provide a base measurement unit derivation for, respectively, radian and steradian - Concept: Normalized compound unit expression
- For a unit expression
A_1
, the normalized compound unit expression ofA_1
shall be a compound unit expression representing the measurement unit elements ofA_1
all converted and reduced to SI base units
- For a unit expression
- Concept: Partially normalized compound unit
expression
* Example: The derived unit, volt (
V
) may be represented of a compound unit expressionW A^-1
* Internal to the measurements module of [igneous-math], a prtially normalized compount unit expression may be converted to a fully normalized unit expression simply by normalizing each compound unit in the unit expression to any compound expression of SI base units - For purpose of normal ordering within index search and
retrieval algorithms, the order of elements in a
normalized compound unit expression should not be
arbitrary. This system will specify that the order of
elements of a normalized compound unit expression
will be in accord with the sequence of SI base unit
names denoted in section 2.1.2 of [[BIPM][#BIPM]]
(in English language, p. 116, PDF p. 24) See also:
+SI-BASE-MEASUREMENTS+
- The corresponding measurement class for each compound
unit expression may be indexed as a sequence of
elements [
- Linear unit expression, e.g. as denoted with
- Class:
LINEAR-UNIT-EXPR
- Concept: A syntactic container for a single measurement unit
expression, e.g
m
- Concern: The definition of this class would serve to ensure that
the subclasses specified of
UNIT-EXPR
would represent an exhaustive set of types of unit expression. However, this class -- in its application -- might seem redundant ontoSYMBOL
, insofar as that a symbol may be applied as being syntactically representative of a measurement unit. Insofar as that -- conversely -- a symbol would be interpreted as being representative of a measurement unit, the classesSYMBOL
andLINEAR-UNIT-EXPR
are therefore functionally orthogonal. Effectively, aLINEAR-UNIT-EXPR
would represent an encapsulation of aMEASUREMENT-CLASS
, insofar as input and presentation of unit expressions. Transitively, aMEASUREMENT-CLASS
may be denoted with a symbol, as in the context of the measurement classes namespace
- Concept: A syntactic container for a single measurement unit
expression, e.g
- Class:
GEOMETRIC-UNIT-EXPR
- Concept: A syntactic container for both of a single measuremnt unit expression and a numeric (fixnum) degree of the measurement unit
- Class:
COMPOUND-UNIT-EXPR
- Function:
SIMPLIFY-UNIT
- Syntax and arguments:
SIMPLIFY-UNIT EXPR => EXPR
EXPR
: A unit expression
- Description (design): Provided a partially normalized unit expression, this function must produce a partially normalized unit expression in which -- insofar as possible -- any combinations of base units representative of a derived unit would be expressed as the corresponding derived unit
- Implementation Notes
- Indexing of measurement units
- Given a compound unit expression -- whether expressed
in derived units such as
W A^-1
, or expressed in base units such as ``m^2 kg s^-3 A^-1`, or in any combination of base units and derived units, and in any exponent prefix of those unit expression elements -- such that the compound unit expression would be representative of an SI derived unit(e.g. volt) each compound unit expression must be stored within a central compound unit expressions index. An interface must be defined onto the compound unit expressions index, such that a compound unit expression can be stored within the index and later retrieved
- Given a compound unit expression -- whether expressed
in derived units such as
- Indexing of measurement units
- Syntax and arguments:
- Function:
NORMALIZE-UNIT
- Syntax and arguments:
SIMPLIFY-UNIT EXPR => EXPR
EXPR
: A unit expression
- Description (design) : Recriprocal to
SIMPLIFY-UNIT
, essentially this function must produce a fully normalized unit expression for the providedEXPR
- Syntax and arguments:
- Define measurement domains for derived measurement units
- "Normalize" and document those measurement domains already defined within this software system
- Refer to [SI], [NIST], other resources
- e.g. towards units of amps, watts, ohms, newtons, radians, herz...
The Systeme International (SI), published by the Bureau International des Poids et Mesures (BIPM), defines seven base measurement units, of which any additional measurement units may be directly or indirectly derived[BIPM][#BIPM].
- length
- mass
- time, duration
- electric current
- thermodynamic temperature
- amount of substance
- luminous intensity
Each of the fundamental measurement domains is defined with a corresponding measurement base unit.
- Length: meter (alternately, metre)
- Mass: kilogram
- Time, Duration: second
- Electric Current: ampere
- Thermodynamic Temperature: kelvin
- Amount of Substance: mole
- Luminous Intensity: candela
This program system represents those respective measurement domains and their respective base measure units as follows:
- Domain
math:length
, basemath:meter
- Domain
math:mass
, basemath:kilogram
- Domain
math:time
, basemath:second
- Domain
math:electrical-current
, basemath:ampere
- Domain
math:temperature
, basemath:kelvin
- Domain
math:amount-substance
, basemath:mole
- Domain
math:luminous-intensity
, basemath:candela
In the object system defined of the
[Igneous-Math source tree][igneous-math, effectively a
math:measurement
class is an instance of a
math:measurement-class
, such as math:meter
. Each
math:measurement-class
, in turn -- such as math:length
-- is an
instance of a math:measurement-domain
class.
(use-package '#:math) => T
(defparameter m (make-measurement 1 :|m|)) => M
M => #<METER 1 m {10083AF7A3}>
(class-of m) => #<BASE-LENGTH METER>
(class-of (class-of M)) => #<MEASUREMENT-DOMAIN BASE-LENGTH>
Note: This system develops a concept of a measurement domain, in some regards independent of the referenced standards for measurement systems. Essentially, this system defines a measurement domain as an object effectively shared between measurement units having a same base measurement, though possibly having a differeing dimensionality onto the base measurement. In many regards, this definition is developed towards a sense of computational convenience.
For example: Units of length, of area, and of volume all derive from the same essential domain of length -- respectively, being of dimensionality 1, 2, and 3 onto the base measurement of length. In a mathematical operation in which any two values of length are multiplied, for example, the result is a measure of area -- essentially, a measurement of a dimensionality equivalent to the sum of the degrees of the dimensionalities of the provided values, in the geometrically expansive mathematical operation, multiplication.
Similarly, dimensions of duration and of frequency may both be derived from a base unit measurement of time and duration -- a duration measurement being of a dimensionality 1 onto time and duration and a_frequency_ measurement being of a dimensionality -1.
In standards published by the BIPM and in standards published by the NIST, standard base units are defined and subsequently extended with exacting formulas, each describing the mathematical nature of a conventional derived unit of mesurement. [BIPM][#BIPM][NIST][#NIST]
Axiom: Measurement units defined within an equivalent measurment domain and of an equivalent dimensionality may be scaled, linearly -- each, per a ratio defining how many units of the base measure exist within one unit of the derived measure, or reciprocally, how many units of the derived measure exist within the base mesaure.
See, for example, MATH:FOOT
and MATH:METER
Implementation Notes:
math::measurement-base-factor
math::measurement-base-factor-exponent
To do: Still developing the architecture for derived units
Concepts:
- Algebraic conversions between measurement units in non-linear derivations
- Caching and quering for known measurement unit conversion formulas
- Application of measurement unit conversion formulas, within mathematical operations onto measurement values
The measurement unit, ohm, as a standard unit for measurement of electrial resistance, is defined as a derived unit with formulas
1 ohm = 1 m^2 kg s^-3 A^-2 [1] p. 111
i.e. ((:|m| 2) :|kg| (:|s| -3) (:A -2))
1 ohm = 1 V / 1 A [1] p. 118
Similarly, the measurement unit, volt, as a standard unit for measurement of electromotive force or difference in electrical potential, is defined with formulas
1 volt = 1 m^2 kg s^-3 A^-1 [1] p. 118
1 volt = 1 W / 1 A [1] p. 118
and the measurement unit, watt, as a standard unit for measurement of power or radiant flux:
1 watt = 1 m^2 kg s^-3 [1] p. 118
1 watt = 1 J / 1 S [1] p. 118
and the measurement unit, joule, as a standard unit for measurement of work, energy, or amount of heat:
1 joule = 1 m^2 kg s^-2 [1] p. 118
1 joule = 1 N * 1 M [1] p. 118
and the measurement unit, newton, as a standard unit for force:
1 newton = 1 m kg s^-2 [1] p. 118
Thus, a definition of the derived measurement unit, ohm, effectively requires the definitions of the derived measurement units: newton, joule, watt, and volt.
[1] http://www.bipm.org/en/publications/si-brochure/
Issue: Towards a methodology for linear unit conversion
NIST SP 811[1] appendix B defines an effective table of conversion factors for standard measurement units recognized by the NIST. The table is defined with a format, effectively: (S,D,F,E) for
S: source measurement unit
D: destination measurement unit
F: factor for converstion
E: decimal exponent for factor of conversion
S and D do not appear uniquely in the table, but the set {S,D) is unique within the table.
In transposing that measurement conversions table into this software system, a number of matters may be considered, for example:
-
That a floating-point value 3.048 E-03 (imay be represented similarly as 3048 E-6, with the exponent value stored seperate to the integral magnitude -- thus, ensuring that a manner of integral arithmetic may be applied onto the integral magnitude and its integral decimal degree.
-
that for any measurement converstion path A..D in which the following measurement conversion paths are available:
- A..B
- B..C
- C..D ...the converstion from A to D may be accomplished directly by multiplying the factors for the conversions A..B, B..C, and C..D and summing their decimal degrees
NIST SP 811[1] clause B.9, furthermore, defines a set of individual measurement domains and subdomains.
[1] NIST. Guide for the Use of the International System of Units http://physics.nist.gov/cuu/pdf/sp811.pdf
Point of reference: http://www.hytime.org/materials/hi2mdhyt.sgm
Notation names and public identifiers, for 'standard measurement unit' (SMU) definitions,from the HyTime Granule Definition Notation module of "ISO/IEC 10744:1997", i.e. Hypermedia/Time-based Structuring Language (HyTime)
gQuantum "ISO/IEC 10744:1997//NOTATION Virtual Measurement Unit//EN"
SIsecond "ISO/IEC 10744:1997//NOTATION Systeme International second//EN"
SImeter "ISO/IEC 10744:1997//NOTATION Systeme International meter//EN"
virTime "ISO/IEC 10744:1997//NOTATION Virtual Measurement Unit//EN"
virSpace "ISO/IEC 10744:1997//NOTATION Virtual Measurement Unit//EN"
SIkg "ISO/IEC 10744:1997//NOTATION Systeme International kilogram//EN"
SIcd ""ISO/IEC 10744:1997//NOTATION Systeme International candela//EN"
SIampere "ISO/IEC 10744:1997//NOTATION Systeme International ampere//EN"
SImole "ISO/IEC 10744:1997//NOTATION Systeme International mole//EN"
SIradian "ISO/IEC 10744:1997//NOTATION Systeme International radian//EN"
SIsr "ISO/IEC 10744:1997//NOTATION Systeme International steradian//EN"
Issue: The gQuantum, virTime and virSpace notations share the same public idenifier, but may be differentiated by their respective notation names. Though practically useful, however those measurement units are not standardized onto SI
see also:
- http://crism.maden.org/consulting/pub/hytime/meas.html (1992)
- http://www.is-thought.co.uk/schedule.htm
- http://www.hytime.org/materials/hi2mdhyt.sgm
- cf. %hygrand
Previous Documentation (2) :
Referring to [BIPM][#BIPM], p. 118 (English Edition PDF p. 26) a number of additional measurement domains are defined within a single table, each denotedper an essential type of quantity. Within a domain of applications of electrical systems, the folloiwng units are denoted of that table:
- Volt (V)
- Domain: Electrical power difference, electromotive force
- Relation in terms of SI derived units:
W/A
- Relation in terms of SI base units:
- Common Applications include Ohm's Law -- in a classic form,
I=V/R
- ....
Previous Documentation (1) :
The measurement unit, ohm, as a standard unit for measurement of quantity of electrical resistance, is defined as a derived unit with formulas:
1 ohm = 1 m^2 kg s^-3 A^-2 [1] p. 111
1 ohm = 1 V / 1 A [1] p. 118
Sidebar: Ideally, a mathematical system should be able to determine what units of measurement have resulted from a single formula. For instance, if a unit of length is multiplied by a unit of length, then intuitively, the unit of the resulting multiple is a unit of area. If the resultimg unit of area would be multiplied, then, by another unit of length, then the resulting unit would be a unit of cubic volume, intuitively. Alternatley, if a unit of area would be divided by a unit of length, then the resulting unit would be a unit of length.
Essentially, this describes a manner of unit algebra, specifically as with regards to measurement units as objects having some qualities like real numbers.
In a prototypical regards, assuming a symbolic representation of unit names in Common Lisp:
(unit :|ohm|) = (unit (:|m| 2) :|kg| (:|s| -3) (:A -2))
= (unit :V (:A -1))
Similarly, the measurement unit, volt, as a standard unit for measurement of quantity of electromotive force or difference in electrical potential, is defined with formulas
1 volt = 1 m^2 kg s^-3 A^-1 [1] p. 118
1 volt = 1 W / 1 A [1] p. 118
The measurement unit, watt, as a standard unit for measurement of quantity of power or radiant flux:
1 watt = 1 m^2 kg s^-3 [1] p. 118
1 watt = 1 J / 1 S [1] p. 118
The measurement unit, joule, as a standard unit for measurement of quantity of work, energy, or amount of heat:
1 joule = 1 m^2 kg s^-2 [1] p. 118
1 joule = 1 N * 1 M [1] p. 118
The measurement unit, newton, as a standard unit for measurement of quantity of force:
1 newton = 1 m kg s^-2 [1] p. 118
[1]
http://www.bipm.org/en/publications/si-brochure/
The Igenous-Math system defines a set of overloaded mathematical
operations, such that extend of an implementation's own optmized
mathematical operations. (xref: MATH::DEFOP
)
For extending so much as the simple, "+"
, "-"
, "*"
, and "/"
operations onto measurement objects, some consideration must be made
as to how those respective operations would affect units of
measurement on input measurement values.
In a diadic mathematical operation, onto two values of the same mesaurement domain:
-
For linear mathematical operations
"+"
and"-"
, then each respective value may be scaled effectively to the base measurement of the measurment domain and the effective magnitudes resulting of the scale then effectively summed or differenced, to a resulting object of the same base measurement as the measurement domain, of a scalar degree appropriate to the input values and the mathematical operation -
For a geometrically expansive mathematical operation, such as
"*"
, then ... -
For a geometrically reductive mathematical operation, such as
"/"
, then ...
Each type of measurement base quantity corresponds to exactly one measurement base unit. Each base unit is denoted with a unit name -- for instance, "second" -- and one or more symbols denoting of the measurement unit -- for instance "s".
This program system defines the following values for each type of measurement unit:
-
name of base quantity, e.g "time, duration"
- for a measurement M,
(object-print-name (class-of (class-of *M*)))
- for a measurement M,
-
a singular, verbose, printable name for the measurement unit, without symbolic characters e.g. "second", "kilogram"
- for a measurement M,
(object-print-name (class-of *M*))
- for a measurement M,
-
a singular, printable label for symbolic representation of the measurement unit in conventional syntax -- in which instance, this system assumes that the lisp implementation implements the Unicode code set -- e.g. "m", "°", "ω", or "lᵥ".
- for a measurement M,
(object-print-label (class-of *M*))
- for a measurement M,
-
A Lisp symbolic name, interned within the keyword package, for application within the source code of Lisp programs -- e.g.
:m
,:deg
, (angular),:ohm
, and:lux
.- for a measurement M,
(measurement-symbol (class-of *M*))
- for a measurement M,
Example:
(use-package '#:math) => T
(defparameter m (make-measurement 1 :|m|)) => M
M => #<METER 1 m {10083AF7A3}>
(object-print-name (class-of (class-of m))) => "length"
(object-print-name (class-of m)) => "meter"
(object-print-label (class-of m)) => "m"
(measurement-symbol (class-of m)) => :|m|
Regarding selection of measurement symbols, a number of standard practices will be defined of this system:
-
ASCII characters shall be represented as ASCII characters to be interpreted in "readtable case"
e.g
"m" => :m
,"mol" => :mol
,"K" => :k
-
Superscirpt characters shall be prefixed with a caret "^" and represented without typesetting
e.g.
"cubic meter" = :m^3
FIXME: This may be effectively outdated together with the definition of reader macros for measurement unit expressions
-
For measurement units defined by SI[BIPM][#BIPM] with subscript characters, a corresponding symbolic name shall be sought of the NIST specification[NIST][#NIST]
e.g symbolic name
"Lᵥ"
in SI[BIPM][#BIPM], interpreted rather as"lx"
in NIST[NIST][#NIST] and therefore=> :lx
-
For measurement units whose conventional symbolic name denotes a ratio among measurement units, the character denoting the ratio shall be retained
e.g
"kg/mÂł" => :kg/m^3
_FIXME: This is effectively outdated with the addition of compound
measurement unit expressions_
-
For measurement units whose conventional symbolic name includes a subscript character, the character shall be prefixed by an underscore "_" and rendered without typesetting
e.g.
"mâ‚‘" => :m_e
-
For the special instance of the radian or steradian, this program system shall retain the respective, conventional symbolic name -- respectively
"rad"
or"sr"
i.e.:rad
or:sr
in Lisp symbolic syntax. This decision is correlated with a note: That in a conventional shorthand practice for mathematical equations, namely the symbolic name of the radian may be omitted from mathematical equations; radians, as a measurement unit, may contextually be differentiated from degrees, as a measurement unit, in that a measurement denoting a degree measure would be suffixed with the printed name"°"
-
For the special instance of
"rad"
as a ratio of Grays, this program system shall use the symbolic name"rd"
i.e:rd
-
For each of the special instances of a measure in units of "degree" (angular measure) or "degree Celsius" (thermodynamic temperature). the non-ASCII character
"°"
shall be transposed to a short hand letter form - respectively,:deg
,:deg-c
-
For the non-SI unit of measurement "degree Fahrenheit", similarly the shorthand form
:deg-f
shall be applied -
For the SI unit of measurement "degree Kelvin", the shorthand form
:k
shall be applied, as transposing the symbolic unit identity "K" -
For measures of plane angle in units of minutes or of seconds, this system shall use the letter forms respectively
:|'|
and:|"|
, with printed representation respectively"'"
and'"'
-
For the special instance of the measurement unit, angstrom
"Ă…"
, this system shall use the conventional name of the measurement unit, without diacritic marks, i.e.:angstrom
In defining those policies for Lisp symbolic names for measurement units, this system endeavors to present a convenient balance between needs for symbolic uniqueness and expressive clarity.
In denoting formal printable labels for measurement units, this system shall defer firstly to to the SI brochure[BIPM][#BIPM] (noting, namely, Tables 1 through 4, table 6, etc) excepting those centimeter-gram-second (CGS) units of measure as denoted "Unacceptable" by the NIST guide[NIST][#NIST] sections 5.3.1 and 5.3.2
For printed names utilizing special typographic characters in superscript or subscript notations, this system will apply the Unicode character equivalent of the respective superscript or subscript, when available.
It should be noted that an alternate syntax may be developed in extending of MathML syntax, such that may be integrated with electronic publishing systems. However, until if this system may have reached an extent of development as to provide an integration for MathML with a corresponding desktop interface and office document publishing system, this system shall instead apply a typographic shorthand of those letters' special typographic forms, so far as available within the Unicode code set.
A short illustration:
(use-package '#:math) => T
(use-package #:utils) => T
(defparameter m (make-measurement 1 :|m|)) => M
M => #<METER 1 m {10083AF7A3}>
(object-print-label m) => "1 m"
See also: utils:object-print-name
, utils:object-print-label
The following text represents a body of notes developed during initial prototyping of the Igneous Math system.
Section subsequently moved into reference documentation, previous
The Systeme International defines a standard set of symbolic names for decimal exponents of measurement values, in a range from -24 to 24 degrees. Those decimal prefixes allow for succinct representation of magnitudes of measurement values, within limits of significant digits.
(To Do: Computation of significant digits within input values, with corresponding limits onto significant digits for printed values)
See Also: Garcia-Santamarina, Sareta, et. al. Significant decimals and rounding
In addition to the SI base units, this system may endeavor to define a set of additional measurement domains, such as inspired by the HyTime standard[HyTime][#HyTime] -- specifically, such an abstract virtual measurement domain -- as well as a measurement domain for quantities of digital information.
The virtual measurement domain is extended with base units, namely, virtual time and virtual space -- applicable as for purpose of a representation of measurable quantities within a software system respectively, such as PAL frame rate and pixel coordinates[MBryan][#MBryan]
This program system will endeavor to adopt a consistent syntax for measurement names, within the context of this program system.
Section subsequently moved into reference documentation, previous
This system is being developed for a purpose of defining a consistent measurement model for application in analytic geometry. In order to ensure that this system would provide a model consistent onto standards for conventional practice in measurement modeling, and would implement a mathematically reliable methodology for conversion of metric values, this system's development effectively must be informed of standards for "best practice."
In extending of the measurement model implemented of this program system, a further set of components may be defined for representation of properties of trigonometric systems as well as known practices in analytic geometry. within the Common Lisp programming environment.
For representation of measurement values, this system defines a single class, SCALAR, namely for representation of quantities of known measurement units. The class, SCALAR, is then extended with the class, VECTOR, in a programmatic model implemented, internally, onto the polar coordinate plane.
For purpose of ensuring compatibility with mathematical methods utilizing of qualities of the Cartesian/Euclidean and rectangular coordinate planes, this system furthermore defines an object model for representation of geometric forms, specifically within a Common Lisp programming environment.
- Define an ASDF system for this source file [DONE]
X) Define a reader macro syntax for measurement units also cf. Jakub Higersberger's unit-formula system
Y) Extend MEASUREMENT-CLASS with a new class, DERIVED-MEASUREMENT-CLASS, such that would publish an accessor for calculating a formula for measurement unit conversions
-
Implement YouTrack and TeamCity onto AWS (cf. Nr 4)
-
Move DEFCLASS* into the mci-cltl-utils source tree
-
Define, within YouTrack and TeamCity, such TO DO items as are denoted within the commentary in the DEFCLASS* macro definition
-
Define a convenient syntax for extension of this measurement protocol in definition of custom measurement units
-
Continue with definition of the geometry component of this system, toward DEFCLASS VECTOR etc.
-
"Back track" to the TO DO items defined then in YouTrack/TeamCity
-
At some point, refine the comments in this file into a form of normative documentation for this program system
-
Define a desktop interface for this system
FIXME: The following documentation items were transposed from measurement.lisp and should be edited for presentation in this markdown file
- IUPAC 'Gold Book' esp. http://goldbook.iupac.org/list_goldbook_quantities_defs_A.html
- NASA SWEET Ontologies
- http://physics.nist.gov/cuu/units/
- http://physics.nist.gov/pubs/sp811/appenb.html
- ^ esp. for conversions regarding foot, mile, yard , ...
- Sidebar; Measurement tools (e.g. oscilloscope; digital multimeter; thermometer; barometer; soil moisture sensor; solar intensity ...)
- Sidebar: Experimental data (e.g. spectrographs; astrometry data)
- A primary concern: "Rigorous metadata recording," i.e insofar as to record the source of a calculation or a measurement, as "measurement metadata," for purpose of reference - cf. LoC MODS RDF, LoC PREMIS
- If a numeric value is a result of a calculation, it should be annotated as a calculation, and annotated for the methodology in which the calculation was derived
- If a numeric value is a result of a measurement, it should be annoted with the identity of the device by which the measurement was obtained, as well as the configuration of the measurement system in which the device was applied.
- In effect, this requires a development of an object model for measurement devices. See also: [EDIF], [ISO-10303], [STEP]; JEDEC; About STEP, but not as if to neglect the derivation of parts of the STEP standard from EDIF;
- For interactive/manual calculations and measurements, an applicaiton may request user input for establishing the respective source of calculation or measurement
- For automated calculations or measurements with multiple heterogenous data sources, a data model may be developed such that would effectively "tag" each measured value with the identity of the measurement system from which the value was "read"
(TO DO - look for NASA best practice guidelines, regarding? i.e. "Lab work")
- Graph
- Bezier curves ?
- Sample data ?
[#wikipedia:byte]: Wikipedia. Byte
[#jedec:jesd-100b.01]: JEDEC. JESD-100B.01. Terms, Definitions, and Letter Symbols for Microcomputers, Microprocessors, and Memory Integrated Circuits
[#BIPM]: BIPM. SI Brochure: The International System of Units (SI). 8th edition, 2006; updated in 2014.
[#NIST]: NIST. Guide for the Use of the International System of Units (SI)
[#EToolbox]: [The Engineering Toolbox. Standard Form, Scientific, and Engineering Notation)(http://www.engineeringtoolbox.com/standard-form-scientific-engineering-notation-d_1801.html)
[#HyTime]: HyTime Granule Definition Notation
[#MBryan]: Martin Bryan. Using HyTime for Scheduling Events