Reading over an embarrasingly obtuse description that I had written, one day in another place, about a software system that I was referring to as igneous-math, I would like to denote henceforward that the article was much of an effort to describe a simple sense of novelty about the 'ratio' type as implemented in Common Lisp. Without immediately producing a study of IEEE standards for representing *floating point decimal *values in computing systems, and without any lengthy sidebar as to comment to a concept of *fixed point* arithmetic as developed in Forth, I recall that my initial thesis had centered on the very limits of finite *data registers* in computational machines.

In the following article, the author will endeavor again to circumnavigate any specific consideration with regards to computing, instead to focus about some concepts of commumications as developed with regards to CORBA.

Assuming a fixed-size data register, in any single numeric computation – whether of a 24 bit, 32 bit, 64 bit, or other bit length of numeric encoding – any *number* may be represented in a *precision* bounded by the size of the *data register* in which the *number* is *encoded*.

This article will not go at length to juxtapose different methods of discrete digital encoding of numeric values, as whether for encoding of natural numbers, signed integers, unsigned integers, fixed point decimal numeric values, floating point decimal values, numeric ratios, or complex numbers. Excepting the field of *ratios* and the field of *complex numbers*, each other of those topics may be referenced immediately onto the Common Data Representation (CDR) format as standardized in specifications about the Common Object Request Broker Architecture (CORBA). Though that may not serve as to describe such topics in any manner of a comprehensive detail, but as to reference these topics onto CDR encoding, perhaps it may at least serve as to provide a common point of reference – in regards to numeric computing – principally orthogonal to an implementation of any single programming language or programming architecture.

The CORBA specifications, as publicly described in core specifications documents and as extended in any number of supplemental specifications documents published by the Object Management Group (OMG), moreover as pragmatically *augmented* with domain-specific case studies described in any discrete number of documents in or outside of the OMG specifications set, moreover as implemented in any number of instances of *development tools*, then as applied in any singular set of software products – broadly, CORBA provides a platform-agnostc framework for applications, such as may be developed to extend of any number of fundamental CORBA object services – as in regards to developing software components such that may interact via CORBA object services, at an applications layer and – as on a TCP/IP network – may employ methodologies of *transport semantics* at *session* (cf. SECIOP) and *presentation* (cf. ZIOP) layers, as in regards to a view of networked applications projected onto a conventional seven layer model of TCP/IP networking.

In such a context, CORBA serves to provide a single, standardized, *baseline* object service architecture, such as may be augmented in applications of supplemental CORBA object service specifications.

In regards to applications utilizing CORBA IIOP – IIOP being the Internet Inter-ORB Protocol, principally an extension of the Generalized Inter-ORB Protocol (GIOP) – applications may apply the Common Data Representation (CDR) format for *stream encoding* of data values, such as may be reversibly *encoded* and subsequently *decoded* onto *protocol* *request* sockets and *protocol response* sockets in a context of CORBA IIOP.

Short of an orthogonal concern with regards to encoding of *object references*, the CDR encoding format provides for an encoding of atomic, primitive numeric values – an encoding standardized essentially onto stream objects, principally in a manner independent of any single microcontroller implementation, but however dependent on a streams-oriented communications media. Though perhaps the CORBA architecture may serve to encapsulate much of the nature of the *stream based* encoding of data values in IIOP, but inasmuch as that an IIOP application utilizes TCP sockets for its implementation, the IIOP implementation therefore utilizes a stream based encoding. Whether GIOP may be extended, alternately, as to develop any more *computationally limited* encoding – such as perhaps to develop an encoding for protocol data values onto an I²C bus, as may be for application within a light-duty parallel computing framework, or alternately, as to develop an encoding method for GIOP onto shared memory segments within a process model of any single operating system – the CDR encoding onto IIOP serves to provide a standard encoding for atomic data values, moreover CDR providing a basis for encoding of object references and any number of application-specific data values, in CORBA applications.

Thus, as towards developing a platform-agnostic view of applications of computing machines, it may be fortuitious to make reference to the CORBA architecture – even in so limited a regards as in reference to the CDR encoding for primitive numeric values.

Concerning the CDR encoding for any single data value onto a communication stream, the CDR encoding may be observed as being compatible with so many machine-specific encoding methods for encoding of data values onto finite memory registers, data values as may likewise transmitted across finite processor bus channels within any single computing machine. Certainly, the communications of a data value – as within a CORBA application framework – would not cease at the transmittal of the data value to or from an IIOP application socket.

Towards a perspective of an implementation of CORBA, the CORBA implementation's own concerns – with regards to communication services – might not extend much further than as to provide an interface for *encoding* and *decoding* of data values onto CORBA data channels, in a manner however orchestrated with CORBA object adapters. The *trope* as that CORBA is for application in regards to *middleware* services – aside to any suggestion, to which the author may take some exception, as if CORBA was *not* *trendy, any more* – it does not serve to say much, at all, as to how a computing machine may apply any single data value, once a data value is transmitted over a CORBA object services network. Naturally, CORBA is a feature of a communications domain. In a manner of a domain-oriented view, CORBA dovetails with a domain of computer operating systems and a domain of microcontroller design, furthermore – as inasmuch as that a microcontroller provides computing services to an operating system, and as that an operating system may be applied as to provide computing services to a CORBA application.

How, then, is UNIX not relevant to CORBA applications?

The author of this article being how immediately preoccupied of developing a thesis with regards to the Common Lisp programming language, the FreeBSD operating system, and the potential for applications of CORBA in networked computing, but perhaps it may seem as though the author is simply distracted of some few archaic trends in the social universe. The author would not propose to suggest any too narrowly deterministic model of such a thesis, whether or not is may be easily proved to be of a computationally sound and comprehensive architecture for computing in any arbitrary networked systems environment. Common Lisp has perhaps not been a great favorite for applications programming, however it may momentarily serves an academic end, as in a manner of thesis development. It might be estimated, moreover, that most theses developed about Common Lisp would be developed, likewise, as theses about concepts of *artificial intelligence* – logically, with regards to theses describing of applications of logic in mathematics and in computing systems. Perhaps it has not been since the 1970s and 1980s that Common Lisp development was shaped of microprocessor development. Across the popular *AI Winter* of the era, but perhaps the *old scrolls* have not all been lost to the shifting ice of the populist glacier.

As though lost in the library of historic record – but AI Memo 514 is certainly no manner of a *Cardiff giant*. If it may be a memo of an academia in which the plain logic of microprocessor design was paramount – but perhaps the contemporary computing market may seem all preoccupied of so many novel products of contemporary microprocessor manufacture, if not of applications of the newest high-speed microcontrollers and software designs in all the novel, new commercial systems. In regards to how so many novel, new toys are applied to present any manner of noise to contemporary engineering trades, but if it may be simply a manifestation of a lot of marketing fluff atop a lot of repetitive iterations in social development, how novel is a simple endeavor to disembark of the sollubrious consumerism and recover whatever remains of the sciences aside the grand industrial merry-go-round?

It might seem as if it was only a metaphor of a brass ring, a token, a trinket grabbed in a singular merry-go-round's long spin? Is it to a metaphor of a trophy, then, ere it is returned to the vendor's brass ring dispensor? If there is not a metaphysics of such a commercial mechanics, perhaps Whitehead's thesis really ever was disproved? May the circus resume, fortwith, if there is no more of a meaning beyond so many singular objects of materialism.

Before returning to this thesis, the author denotes a concept of *pi* in which *pi* is calculated as a *ratio.*

Though perhaps not all definitions of *number* would include *ratio* as a *type of number*, but as for that a *ratio* may be defined as a type of *rational number*, it may be a *type of number* of some relevance for application in computations onto other types of *rational number*. Sure, then, between concerns of *computation* and of *measurement*, some variance in *measurment* may entail some of a variance in *computation*. In regards to variance of physical measurements in physical systems, and considering as that a discrete measurement – a *measurement* of any estimable *precision* – may be applied in a computational model, applied as towards calculating any *intermediate numeric values* as may be, lastly, applied in a physical analysis or physical design of a system, and though it may seem practically naive to assume a *perfect measurement* may be provided to any computational system, but insomuch as that a computational system may produce a predictable set of consequent computations, as given a known set of initial measurements and a discrete formula for calculations, a computational system should not itself be assumed to operate at variance of any set of initial measurment values.

If there may seem to be a commercial novelty of the Common Lisp functions, 'rational' and 'rationalize', those two functions alone may be applird as a computational entry point – of each, seperately so – to perform all intermediate calculations within a computing machine as in calculations with rational numbers. There may be, in that, likewise a *toss of the hat *with regards to fixed-point numeric calculations in Forth. Perhaps it may be said as to "Go further," moreover, that any immediately fixed-point numeric value may be converted to a ratio numeric value, as to conduct any subsequent calculations wholly onto rational numbers, whether or not producing a decimal number for numeric denotation as a consequent value.

It is not unprecedented: That a computing machine may usefully produce calculations deriving of rational numbers. In an immediate manner, a computer of a finite memory may not actually contain an irrational number, except that an irrational number is encoded of rational quantities. A concept of *irrational number* should not be removed from numbee theory, of course! It is *simply not* a concept occurring in computations within finine memory spaces.

It is not to merely make a drab show, therefore, if a rational number may be calculated as *estimating* a built-in *decimal* value of *pi* to a rational numeric constant. Such a constant, rational value may be applied intermediate computations wholly onto rational numbers. The rational numbers computer may only need convert any decimal input values into a ratio format, then to produce a decimal representation – to any single consequent precision – of any numbers calculated finally of the rational computation.

Of course, this does not indicate any trivial methodology for rational numeric computations onto transcendental functions. So far as that the triginometric transcendental functions may be derived of a rational estimate of pi, as on a *unit circle*, there may be a channel for computations with rational numbers in those transndental functions. The author, regrettably, is not as immediately familiar with calculations of Euler's constant.

Towards a representation of *ratio* numeric values and *complex* numeric values – no mere *propaganda,* the Common Lisp type system providing definitions of such numeric types, in computing – of course, it may be a trivial affair, to define an IDL module, an IDL interface, and finally an IDL data type in which a platform-agnostic definition of each of the *ratio* or of *complex number* numeric types may be provided, in a computing system. That being denoted as towards a consideration of a *transport level encoding* of numeric values, but it may not seem to say an immediate bunch as towards an algorithmic, if not functional view of computing

This article, presently, returns to a thesis about CORBA.

Of course, CORBA IDL itself is not the *computing* element of a *CORBA system*. Inasmuch as that an implementation of a CORBA IDL *module* may be developed in an application programming language, then applied within an *object adapters* system, CORBA IDL may serve something of a complete, modular role in regards to communications among computing systems. This article has denoted, albeit somewhat obliquely, the CDR encoding for data values in an IIOP framework. Likewise, as in regards to the subclauses of the CORBA core specifications as in which CDR and IIOP are described, it may be said to amount to a much of a description of a *platform-agnostic communications model*, such as is defined in a manner for application within a broader, platform-agnostic object services framework as may be denoted, broadly: CORBA.

May it be, then, as if to limit the potential applications of CORBA frameworks, if the computational features of CORBA systems may not often be found as described in so much of specific detail as of the CORBA communications model itself? One may wish to speculate as to how the platform-agnostic nature of CORBA specifications may seem to effectively obfuscate any single CORBA implementations from immediate duplication without limits of immediate licensing agreements. In some regards, such a coincidence could be quite fortuitous, overall. Inasmuch as CORBA may find an application in defense systems, such applications should probably not be danced out for any idle opportunism, however any CORBA applications may be momentarily denoted of a popular discourse. However analogously, if CORBA may be estimated as to find applications in some of social infrastructure systems – such that may seem however estimably *possible,* as in consideration of specifications defining platform-agnostic applications of CORBA in telecommunications systems – but this says almost nothing with regards to any manner of actual computing systems. Not to offend the reader with the author's own simple obtuseness: A *communications specification* is not a *microprocessor,* just as much as a pie plate is not a peach pie.

Sure, a discrete number of peaches may be applied in preparing any discrete number of peach pies, at any estimable formula of efficiency and other results. Analogously, the CORBA specifications are not either like recipes for microcontroller applications. (** Ed. note: **There should be a cute metaphor to Hexbugs(R), here. Though it might seem to startle a reader, if juxtaposed to the fantastic, fictional

*Replicators*of the Stagate SG-1 universe, in science fiction literature, but the metaphor of a microchip-sized automoton of a bounding character, outside of any too far Arachnid-like species of science fiction creature, the simple ant-like Hexbug Nano(R), as a metaphor, could be apropos.)

So, a student of computing might feel in some ways stymied of the communications-oriented CORBA specifications. The proverbial magic of CORBA may not be insomuch in the proverbial network chatter of a CORBA object system.