*when I was a young person, my family had "Gifted me" with an electronics kit, such that I've later learned was developed by Elenco. In fact, my family had "Gifted me" with a number of electronics kits -- an old 60-in-1 kit, later the Elenco*

**"Once upon a time,"***200-in-1*kit, and then a kit somewhat resembling the Elenco

*Snap Circuits*Kit, though the last of those was of a different design, as I recall -- something more designed for carrying an assembled circuit, really. My family had also gifted me with the opportunity to be wary of computer salespersons, but that's another thing.

In studying the manual of the Elenco

*200-in-1*kit, specifically, I was able to learn a few things about the simple novelty of electrical circuits. The manual for the Elenco

*200-in-1*kit contains a broad range of circuits, onto the

*domains*of each of

*solid-state*and

*digital electronics*. The circuit elements, in the kit, are all firmly fastened into a non-conductive base, each junction attached to a nice spring. The circuit elements, in the kit, may be "wired together" with the set of jumper wires contained in the kit, according to the numbered schematics within the manual. As I remember, today, I'd assembled the radio tuner circuit, the buzzer/oscillator, and something about the multi-segment LED, then separately, something about the step-up and step-down transformers. Of course, there's a novel analog meter, on the front of the Elenco

*200-in-1*kit's

*form factor*case.

Candidly, to my young point of view, the full manual of the Elenco

*200-in-1*kit had seemed a little overwhelming, to me. I remember, still, that I'd had a feeling for that I was looking at a broad lot of material when browsing the pages of the manual, but I wasn't particularly certain if I was able to understand the material I was reading. Of course, I could understand something about the circuit assembly instructions, in the manual -- it seemed, to me, much like the "Snap together" airplane models of the hobbyist domain -- but I was not able to

*analyze*the material of those circuits. Inasmuch, I wasn't able to interpret anything about my experiences, in studying of the manual. Certainly, I was able to set a wire between spring 30 and spring 14, to push a button, and to watch an LED glow, but -- beyond the simple, mechanical qualities of such circuit assembly and testing -- it didn't mean so much to me, then. It was a little bewildering to me, too -- there was such a nice manual, with the item, but I was unable to study the manual, beyond the simple circuit assembly instructions. I could not understand any much about it.

Candidly, It was the only electronics book that I knew of, in all of my young views. In that time of my life, I was not whatsoever cognizant about any sense of a relevance of digital circuits -- such as, of the digital logic gates with transistorized circuits, printed in the last pages of the manual. Sure, though, that was only a few

*germanium*[Computer History Museum]. I was a kid, when the decade was 1980, when the 32 bit processor was "New", and when the Nintendo Entertainment System was the hottest thing on the games market. Somehow, I still mark the chronology of my life by those relative metrics.

At that time in my life, I was not aware of there

*being*a

*digital domain*in electrical circuits, beside any concepts particularly of

*digital/analog interfaces*. I had received the Elenco

*200-in-1*kit as a gift, at a time before I had ever studied geometry, in school. It was a very novel thing, to me, but there wasn't so much I could do to understand the material of the manual provided with the thing. Candidly, it gathered some dust, and with some regrets, was delivered to a landfill, when I first left California. I wish I had held onto that item -- a reproduction would not be quite the same.

Certainly, the high school geometry class -- in a sense not focused towards any specific, practical or vocational regards -- the class did not present any notes with regards to any applications of geometry, in electrical circuit analysis, so far as I can recall of the primary material of the high school geometry course. There was nothing about the

*rectangular coordinate plane*, almost nothing about the unique,

*polar coordinate plane*, and there was not so much about

*complex numbers*, though certainly the course stayed its track along the standard curriculum.

Sure, though, the

*geometry*class had explained the natures of the

*unit circle,*the

*pythagorean theorem, and*the

*transcendental functions*as defined of a domain of trigonometry -- such as the

*sine*,

*cosine*, and

*tangent*functions, and their functional inverses,

*asin*,

*acos*, and

*atan.*Certainly, it had seemed novel to me that there are the relations of those functions onto objects within a unit circle

*,*but I could not conceive of any applications for such knowledge, beyond any of the no-doubt demanding domains of structural design -- such as of physical architecture or of automotive design, in any manner of mathematical refinement in structural design.

So, it was not until the 38th year of my life that I would learn that those trigonometric transcendental functions may be applied within a methodology of electrical circuit analysis -- and that conventionally, those are denoted as being among the

*transcendental functions*in mathematics. Without begging a discussion with regards to imperfections in measurement systems, personally I think it's a significant thing that there are applications of geometry in electrical circuit analysis, as well as in the broader physics. Candidly, I may only narrowly avoid regressing to a mindset like of a giddy child, to observe that there are more applications for trigonometry, under the nearby sun.

This week, I've begun to define something of an extensional model for application of mathematics, in Common Lisp -- that extending of the set of mathematically relevant functions, defined within the ANSI Common Lisp specification. Today, specifically, I've been developing a model for

*overloading*of mathematical operations in the Common Lisp Object System -- in a manner somewhat extending of a Common Lisp implementation's existing optimizations with regards to numeric computation. While I was endeavoring to make the next day's set of notes, for that "Sprint", I've now learned of a couple of functions defined in ANSI Common Lisp, such that effectively serve to "Obsolete" a page full of code that I had written and tested, earlier this week -- and in that, no doubt with further implementation-specific optimizations, in implementations of the ANSI Common Lisp

*rational*and

*rationalize*functions. The code that I had written, earlier this week, it was something implementing of a decimal-shifted encoding for floating-point numbers -- in a sense, developing a model for

*decimal shift*in measurement values, that onto the

*base-ten*or

*decimal base*measurement prefixes defined of the standard Systeme Internationale measurement system. Of course, there are also the

*base-eight*or

*octal*

*base*prefixes conventionally applied about quantities of digital information.

The code that I had written, earlier this week, it does not completely attain to a model for measurement for "Significant digits" within input values -- not in a sense as I had learned of, when I was a student of the science courses I'd attended in high school, in the mid 1990's. There was not so much about the

*floating point*numeric types, as defined in modern standards for computation -- and neither of so much of a sense of a

*mantissa,*as defined in those specifications -- in a course that described the molar weight of helium.

On discovering the the ANSI Common Lisp

*rational*and

*rationalize*functions, personally I may feel at least a small bit of good cheer that ANSI X3J13 [Franz Inc] had seen fit to develop such a set of functions as would serve to address some inevitable concerns in implementations of conventional models for floating-point arithmetic.

Personally, I think that this -- in a sense -- is the nicest line of code that I've ever written:

It follows, then, that one is also cheered to write:(rationalize=>pi)245850922/78256779

So, clearly, it is possible to define an accurate method for transformation of a measurement quantity from onto a unit of(defun=>rad-to-deg(r) (*r#.(/ 180 (rationalizepi))))RAD-TO-DEG(rad-to-deg=>pi)180.0D0

*radians,*then onto a unit of

*degrees*, without one having to go to any gross extent, to extend the ANSI Common Lisp specification.

That being simply the happiest thing that one has seen produced of a computer, of late, but of course one does not wish to make a

*laurel*of the discovery.

Of course, the simple transformation of

*pi radians*to

*180 degrees*is not so different if one does not firstly

*rationalize pi*in the equation. In a converse instance, however: What of a transformation of

*pi/2 radians*?

contrasted to:(/ (rationalize=>pi) 2)122925461/78256779

In the first instance of those two, when the implementation's value for(/=>pi2)1.5707963267948966D0

*pi*is firstly converted to a

*rational number*, then with the computation being made onto another

*rational number*, the real precision of the initial value of

*pi*is neither

*lost*nor

*folded.*In the second instance of those two, it might seem as though the application would simply be

*venturing along*in the implementations' system for floating point arithmetic -- that the application developer, then, must simply accept any matters of

*floating-point rounding,*and so on, as those being simply matters of the programmed environment. One might think that may not be sufficient, in all regards, though perhaps it might be common, as a matter of practice.

Notably, in applying a

*rationalized pi*value, the calculation of the number of

*degrees*represented of

*pi/2 radians*itself results in a rational number, exactly 90.

In a simple regards: That's both of a mathematical(defconstant *rpi* (rationalize=>pi))*RPI*(defun rad-to-deg (r)(*=>r#.(/ 180*rpi*)))RAD-TO-DEG(rad-to-deg (/=>*rpi*2))90

*precision*, and mathematical

*accuracy*, represented in a conversation of

*pi/2 radians*to

*90 degrees*.

I'm certain that it may be possible to emulate the CLHS

*rationalize*function, within other object-oriented programming languages -- such a Java, C++, Objective C, and so on. One would like to think that in such an instance, one may also emulate the Common Lisp numeric type,

*ratio*-- that being a subtype of

*rational*, in Common Lisp, disjunct to the numeric type,

*integer*-- then to

*overload*the respective numeric operations, for the new

*ratio*numeric type.

Personally, I would prefer to think of Common Lisp

*subsuming*other programming languages, however, rather than of other programming languages simply emulating Common Lisp. I know that there can be

*"More than one"*-- as far as programming languages, in the industry -- certainly. Personally, I think that it may be as well to address

*other programming languages*if from a

*Common Lisp*baseline, if simply as a matter of at-worst

*hypothetical*efficiency.

An ANSI Common Lisp implementation would already have defined the

*ratio*numeric type, as well as the mathematical operations denoted in the

*CLHS*Mathematics (

*Numbers*)

*Dictionary*, onto the whole set of numeric types defined in ANSI Common Lisp. Implementations might also extend on those functions and types, with any number of implementation-specific extensions such as may be defined for purpose of optimization within Common Lisp programs -- perhaps, towards a metric for

*deterministic timing*in mathematical procedures.

Sure, though, if one would endeavor to extend those numeric operations and types onto more types

*of mathematical object*than those defined in ANSI Common Lisp -- as onto a domain of

*vector mathematics*and

*scalar measurements*, such as the Igneous-Math project seeks to address, in all of a colloquial character of a

*source tree*(yet unpublished) -- then it would be necessary to extend the mathematical operations, themselves, and to define an object system for the types extension. That's something I was working on developing, today, before I noticed the simply sublime matter of

*rational*and

*rationalize*, as functions standardized in and of ANSI Common Lisp.

Presently, I'm not certain if I should wish to altogether discard the simple

*decimal-shift*code that I'd written, earlier this week -- essentially, that was for developing a rational numeric equivalent of a floating-point representation of a

*numeric input value*, such as

*pi --*but not only so. In that much, alone, it might be redundant onto the ANSI CL

*rationalize*function.

Also, it was for "Packing" numbers into their least significant digits -- in a sense, to derive value of

*magnitude*and a corresponding

*decimal scale*value, the latter essentially representing a

*decimal exponent*-- with a thought towards developing some

*optimized*mathematical operations onto

*rational*numeric values, throughout a mathematical system, in seeking to retain something of a sense of mathematical accuracy and precision, if but because it would seem to be appropriate to one's understanding, as such

The

*decimal shift*code, as implemented in Igneous-Math, of course it's nothing too complex, in any sense -- in a simple regards, the "decimal reduction" algorithm uses the Common Lisp

*truncate*function, and correspondingly, the "decimal expansion" algorithm uses the Common Lisp

*expt*function. It's been implemented as part of a system for encoding the Systeme Internationale decimal prefixes as Common Lisp objects, in a system essentially designed to ensure that -- excepting of such

*rational*numeric measurement values as would be input as of the type,

*ratio*-- that other real numeric values in the system would be stored in a manner derived to a

*base measurement unit*, before being applied within such conventional formulae as would be defined around

*base measurement units --*but allowing for operations onto arbitrary exponents of the base measurement units, in any single measurement system.

While designing so much of those features of the Igneous-Math system, candidly I was not then aware of the simple existence of the ANSI CL

*rationalize*function, as it being a feature available of an ANSI Common Lisp implementation. With some chagrin, I wonder if I would've designed the decimal-shift code any differently, had I been aware of that feature of ANSI Common Lisp, at any time earlier this week.

I think that, henceforward, I'll have to make some consideration about whether the

*rationalize*function should be applied throughout the Igneous-Math system. One matter that I would wish to emphasize about the design of the Igenous-Math system: That a number's printed representation need not be EQ to a number's representation in object storage, within a numeric system. So long as the

*printed value*and the

*stored value*are at least mathematically equivalent -- onto the ANSI Common Lisp '=' function, broadly -- then certainly, the system would have achieved its necessary requirements for storage and printing of numeric values.

That a mathematical system, moreover, may endeavor to apply the

*rationalize*function onto all numeric values input to the system, before applying those values within any mathematical operations -- such a feature would be developed as an extension of ANSI Common Lisp, also. It might seem redundant or simply frivolous, perhaps, but personally I think it's just as well.

Furthermore, I think it's a swell to encode any

*floating point*number as a set of two

*fixnum*type numbers -- assuming that the instances would be few, in which a floating point number would be expanded to a

*bignum*value on a decimal scale -- and only a matter of the nature of an application system, that one would

*scale*a

*floating point*number onto

*base ten*, instead of onto a

*base eight --*perhaps a matter of developer convenience, in developing a software program for applications of mathematics within a 64-bit Common Lisp implementation.

While beginning to develop a set of

*overloaded math*procedures in the Igneous-Math system, I've begun to wonder of how much work would be required if to optimize an individual mathematical operation onto a microcontroller's own specific hardware -- such as with regards to the Intel SSE extensions [Wikipedia] and the ARM architecture's

*hard float*design, with its corresponding ABI in the Linux application space [Debian Wiki]. The Igneous-Math system has been designed to rely on a Common Lisp implementation's own optimizations, in a portable regards.