Copyright © by Daniel Kian Mc Kiernan
NumericsDisplay converts amongst various representations of floating-point numbers and integers. More specifically: It converts between IEEE 754-1985 and various Java representations; and amongst various Java representations, decimal, octal, and hexadecimal representations of integers.
NumericsDisplay is a small but useful tool developed as part of the PraxioLogic Class File Editor (presently in progress). NumericsDisplay is or will be provided both as a separate application, and integrated into the Editor.
Aside from those working with JVM class files, NumericsDisplay may prove useful to programmers working in or with Java, and to those working in related languages such as C.
NumericsDisplay is copyrighted freeware. See its license (which this document in no way supersedes) for the binding details, but the gist is that possessors may redistribute it only if they redistribute it unaltered, include all documentation, and bind recipients to respect the terms of its license.
This version of NumericDisplay is distributed
as an executable .jar file,
NumericsDisplay.jar.
This .jar file may be saved to whatever directory
(folder) that the user/administrator finds convenient.
[The term ‘octet’ is used through-out this document to refer to sets of eight bits. The term ‘byte’ has sometimes referred to different numbers of bits, and in the context of Java also refers to a particular type.]
The command-line invocation is
In various versions of MS Windows, one may alternately usejava -jar NumericsDisplay.jar
javaw -jar NumericsDisplay.jar
NumericsDisplay may be closed
by clicking the close button on its frame
or by selecting the Close item
of its File menu.
(If NumericsDisplay is operating as a stand-alone application,
then the application will terminate.
If NumericsDisplay is integrated into another program,
then its objects may be discarded,
or may merely be made invisible to the user,
depending upon the choice of the programmer of the application.)
Numeric data is entered and displayed in a set of text fields. Entry is regarded as complete with a carriage return is hit, or when one of the integral Type buttons is selected. Further, the functionality of a programmer's calculator is available by way of a virtual keypad.
The top-most text field is for the entry and display
of floating point numbers encoded as per the IEEE 754-1985 standard
(which is used internally by the JVM and by other machines).
This standard provides for the representation
of floating point data as a sign bit,
followed by exponent bits,
followed by mantissa bits.
The sign bit is 0 for positive numbers,
and 1 for negative numbers.
When the number is encoded with four octets (32 bits),
8 bits are used for the exponent,
to which a bias of 126 is typically added.
When the number is encoded with eight octets (64 bits),
11 bits are used for the exponent,
to which a bias of 1023 is typically added.
Extra precision is squeezed out of the representation
by normalizing almost all numbers such that their initial bit
would be 1
and thus need not be explicitly represented.
Numbers are displayed and entered in the field
as eight or 16 hexadecimal digits.
Entry of anything else will constitute an error.
If a entry is completed in the IEEE 754-1985 field with the Enter key,
then the result will be displayed
in the JAVA field.
The JAVA field will display
“ERROR”
if an invalid entry is made in the IEEE 754-1985 field.
The IEEE 754-1985 field may also display “ERROR”
if an invalid entry is made in the JAVA field.
(“ERROR” is not a valid entry
in the IEEE 754-1985 field,
and will cause the display of
“ERROR”
in the JAVA field.)
If the IEEE 754-1985 field was the last text field in use before the selection of an integral Type button, then its text will be processed, and if the entry is valid then it will be cast to a integer will the same number of octets (four or eight).
The second text field is for the display and entry of Java expressions for numbers. The expressions will be of one of two forms.
The first form is built around numeric literals as defined in the Java language standard. Valid entries of the first type are numeric literals optionally prefixed with casting operators, with signing operators, or with bitwise complementation operators, and optionally nested in parentheses.
The second form accepted and displayed
in the JAVA field is
of a selection of the predefined constants of wrapper classes
(Character,
Byte, Short, Integer,
Long, Float, Double),
optionally prefixed with a ‘-’.
(Other operators are not accepted, nor are parentheses.)
The relevant constants are
MAX_VALUE, MIN_VALUE,
POSITIVE_INFINITY, NEGATIVE_INFINITY,
and NaN
(the last three being defined only for the floating point wrappers).
If an invalid entry is made
by way of any other field,
then the JAVA field will display “ERROR”.
Any invalid entry from the JAVA field will cause
all other fields to display “ERROR”.
“ERROR” is not a valid entry
from any field.
If an acceptable floating-point expression is entered by way of the JAVA field using the Enter key, then an equivalent IEEE 754-1985 representation will be displayed in the IEEE 754-1985 field. The text of the JAVA field itself may also be simplified, reducing casting operators, and replacing finite predefined constants with corresponding literals.
If an acceptable integer expression is entered
by way of the JAVA field using the Enter key,
then equivalent representations will be displayed
in each of the INTEGER fields.
The text of the JAVA field itself may also be altered,
reducing casting operators,
replacing finite predefined constants
with corresponding literals,
and replacing ordinary or escaped char literals
with literals containing Java Unicode escape sequences.
If the JAVA field was the last text field in use before the selection of an integral Type button, then its text will be processed. If the entry is valid for a floating-point number, then it will be cast to a integer of the selected type; if the inferred Type button is selected, then the integer will the same number of octets (four or eight) as is the floating-point number. If, instead, the entry was valid as a integer, then if any button other than that for the inferred type is selected, then the entry will then be cast to the selected type; if the button for the inferred type was selected, then the entry will be processed without casting.
The remaining three text fields are for the entry and display of integers in decimal, in octal, or in hexadecimal form. Their effect data is largely governed by the integral Type buttons.
Valid entries into the INTEGER fields are strings of digits, optionally prefixed with unary sign operators (‘+’ or ‘-’).
If an invalid entry is made
by way of any one of the INTEGER fields,
by way of the JAVA field,
or otherwise by way of one
of the integral Type buttons,
then each INTEGER field that was not the source of the unacceptable data
will display “ERROR”.
“ERROR” is not a valid entry
from any INTEGER field,
and will cause
the other INTEGER fields and the JAVA field
to display “ERROR”.
The type of an entry from an INTEGER field is
determined by the selected Type button.
Selection of Type button will complete an entry
if it is not otherwise completed.
High bytes will be discarded as needed
to fit results to type.
When the inferred button is selected,
an entry from the Decimal field
will be presumed to be of type long,
and entries
from the Octal field
or from the Hexadecimal field
will have their types inferred
from their representations
(roughly speaking,
from the number of digits used).
(The inferred type will always be signed.)
The displays in the Octal Field and in the Hexadecimal Field will be left-padded with ‘0’ as necessary the give them that number of digits required to display each of the possible values associated with the selected type. (In the case of the Hexadecimal Field, the number of digits will be twice the number of octets associated with the type.)
[Discussion of the Decimal field reïterates what has been said in the more general discussion of INTEGER Fields.]
The Decimal field is for the entry and display of integers in decimal notation. Its effect is largely governed by the integral Type buttons.
Valid entries into the Decimal field are strings of decimal digits (‘0’ through ‘9’) optionally prefixed with unary sign operators (‘+’ or ‘-’).
If an invalid entry is made
by way of any one of the other INTEGER fields,
by way of the JAVA field,
or otherwise by way of one
of the integral Type buttons,
then the Decimal field will display “ERROR”.
“ERROR” is not a valid entry
from the Decimal field,
and will cause
the other INTEGER fields
and the JAVA field
to display “ERROR”.
The type of an entry from a the Decimal field is
determined by the selected Type button.
Selection of Type button will complete an entry
if it is not otherwise completed.
High bytes will be discarded as needed
to fit results to type.
When the inferred button is selected,
an entry from the Decimal field
will be presumed to be of type long.
[Discussion of the Octal field largely reïterates what has been said in the more general discussion of INTEGER Fields.]
The Octal field is for the entry and display of integers in octal notation. Its effect is largely governed by the integral Type buttons.
Valid entries into the Octal field
are strings of decimal digits
(‘0’ through ‘7’)
optionally prefixed with unary sign operators
(‘+’ or ‘-’).
(This field is for the entry and display of ordinary octal,
and an initial ‘0’ is not required
in this field
for purpose of signalling that the number is octal,
nor will one be display for that purpose.
If the contents of this field are copied
into a program in Java, in C, or in some similar language,
then it may be necessary to prefix
with an initial ‘0’.)
If an invalid entry is made
by way of any one of the other INTEGER fields,
by way of the JAVA field,
or otherwise by way of one
of the integral Type buttons,
then the Octal field will display “ERROR”.
“ERROR” is not a valid entry
from the Octal field,
and will cause
the other INTEGER fields
and the JAVA field
to display “ERROR”.
The type of an entry from a the Octal field is
determined by the selected Type button.
Selection of Type button will complete an entry
if it is not otherwise completed.
High bytes will be discarded as needed
to fit results to type.
When the inferred button is selected,
an entry from the Octal field
will have its type inferred
from its representation;
left-padding with ‘0’ may be used
to increase the size of the inferred type,
unless the inferred type is long.
(The inferred type will always be signed.)
The display in the Octal Field will be left-padded with ‘0’ as necessary the give it that number of digits required to display each of the possible values associated with the selected type.
[Discussion of the Hexadecimal field largely reïterates what has been said in the more general discussion of INTEGER Fields.]
The Hexadecimal field is for the entry and display of integers in hexadecimal notation. Its effect is largely governed by the integral Type buttons.
Valid entries into the Hexadecimal field
are strings of decimal digits
(‘0’ through ‘9’,
‘A’ through ‘F’,
‘a’ through ‘f’),
optionally prefixed with unary sign operators
(‘+’ or ‘-’).
(This field is for the entry and display of ordinary hexadecimal,
and an initial “0x” is not required or permitted
in this field
for purpose of signalling that the number is hexadecimal,
nor will one be display for that purpose.
If the contents of this field are copied
into a program in Java, in C, or in some similar language,
then it may be necessary to prefix
with an initial “0x”.)
If an invalid entry is made
by way of any one of the other INTEGER fields,
by way of the JAVA field,
or otherwise by way of one
of the integral Type buttons,
then the Hexadecimal field will display “ERROR”.
“ERROR” is not a valid entry
from the Hexadecimal field,
and will cause
the other INTEGER fields
and the JAVA field
to display “ERROR”.
The type of an entry from a the Hexadecimal field is
determined by the selected Type button.
Selection of Type button will complete an entry
if it is not otherwise completed.
High bytes will be discarded as needed
to fit results to type.
When the inferred button is selected,
an entry from the Hexadecimal field
will have its type inferred
from its representation;
left-padding with ‘0’ may be used
to increase the size of the inferred type,
unless the inferred type is long.
(The inferred type will always be signed.)
The display in the Hexadecimal Field will be left-padded with ‘0’ as necessary the give it that number of digits required to display each of the possible values associated with the selected type.
The Type buttons perform three functions.
As per the Java standard,
The
inferred button directs the program
to infer the type of the entry.
When the entry is
from the IEEE 754-1985 field
or is a floating-point number
from the JAVA field,
the number will be cast to an integer of the same number of octets.
When the entry is an integer
from the JAVA field,
its type will be as per the Java standard.
When the entry is from the Decimal field,
the type will be long.
When the entry is from the Octal field,
the type will be inferred from the number of digits
and, when necessary to resolve ambiguity, from the initial digit;
the inferred type will be the smallest type
containing a number of bits three times the number of digits
in the representation,
with an initial digit
of ‘0’ or of ‘1’ being take to be a single bit,
of ‘2’ or of ‘3’ being take to be two bits.
(Left-pad with a ‘0’
to increase the inference by one or two bits.)
When the entry is from the Hexadecimal field,
the inferred type will be the smallest type
containing a number of bits four times the number of digits
in the representation.
The calculator functionality is accessed
by way of a virtual key pad presented
by the Calculator item on the Tools menu.
Should an entry into any one of the text fields have been underway when any key is clicked, that entry is completed before the distinctive action of the key is effected.
| >> | REVB | % |
÷ |
RCL |
>>> |
^ |
CLR | × |
STO |
| ROTR | | |
-- |
- |
ROLLUP |
| ROTL | & |
++ |
+ |
ROLLDN |
<< |
~ |
+/- |
ENTER | X↔Y |
The calculator maintains a queue of operands,
at the head of which is the most recently entered number.
The queue grows as needed (unless available memory is exhausted).
In keeping with established calculator metaphor,
the queue is conceptualized as an inverted stack,
with entries pushed onto and popped off its bottom.
(This is relevant exactly and only to understanding the naming
of the ROLLUP
and ROLLDN keys.)
CLR (CLeaR)
Clears the stack and any error state.ENTER
Inserts a copy of number at the head of the queue between it
and the subsequent operands.X↔Y (X-Y exchange)
Exchanges the number at the head of the queue
with the very next number.ROLLUP (ROLL UP)
Moves the item at the tail of the queue to its head.ROLLDN (ROLL DowN)
Moves the item at the head of the queue to its tail.The calculator has one “memory”.
STO (STOre)
Copies the head of the queue into the memory.RCL (ReCaLl) key.
Copies the contents of the memory to the head of the queue
(overwriting any existent contents at the head).Five keys act on the number at the head of the queue:
+/-
Changes the sign of signed numbers.
For signed integer types,
this amounts to performing a two's complement.)
NB: This operation does not promote;
and (by implication) does not affect chars.
(To get the two's complement of a char,
take the bitwise complement and then increment,
or cast to a short, change sign, and then cast back to a char.)~
Takes the bitwise complement (the one's complement).++
Increments by 1.--
Decrements by 1.REVB (REVerse Byte order)
Reverses the byte order of the number at the head of the queue.
(Potentially useful when wrestling with endians.)The calculator supports something like the basic four functions of arithmetic and modular division. However, note that the type of the result is determined by that of the more distant operand, so that (for example)
'e' ENTER 3L +'\u0068' (a char),
while3L ENTER 'e' +104L (a long).
(It is expected that this behavior is here more useful than simple promotion
according to the rules of the Java language spec.)
If no operand has been been pushed to the further position, and a previous result resided on the stack, then this previous result will be used as the further operand. Thus
3 ENTER 6 + 4 *36.+ (addition)- (subtraction)× (multiplication)÷ (division)
NB: Causes the second element in the queue
to be divided by the head of the queue.
Thus (for example)
6 ENTER 2 ÷results in 3.% (remainder after division)
NB: Causes the second element in the queue
to be divided by the head of the queue,
and the remainder to be stored as the result.
Thus (for example)
(int)24 ENTER 5 ÷results
in 4.The calculator supports some bitwise dyadic logical opertions. (See also the unary bitwise complementation key.) However, note that the type of the result is determined by that of the more distant operand (as with the Arithmetic keys), so that (for example)
'e' ENTER 0xFF01F0 |'\u01f5' (a char),
while 0xFF01F0 ENTER 'e' |16712181 (0x00FF01F5).
(It is expected that this behavior is here more useful than simple promotion
according to the rules of the Java language spec.)
If no operand has been been pushed to the further position, and a previous result resided on the stack, then this previous result will be used as the further operand. Thus
3 ENTER 6 & 4 |6.& (“AND”)
Performs bitwise conjunction.|
(“OR”)
Performs bitwise disjunction^
(“XOR”)
Performs bitwise exclusive disjunction.The calculator supports bit-shift operations whereby a more distant operand has its bits shifted by a count established by an operand at the head of the queue. For example
1L ENTER 3 <<8L.
If no operand has been been pushed to the further position, and a previous result resided on the stack, then this previous result will be used as the further operand. Thus
3 ENTER 6 << 4 ROTR12.<<
(left shift)
Shifts bits up in significance,
filling least-significant spaces with zeros.>>
(left shift with sign-carry)
Shifts bits down in significance,
filling most-significant spaces with ones if the number is negative,
or with zeros otherwise.>>>
(left shift without sign-carry)
Shifts bits down in significance,
filling most-significant spaces with zeros.ROTL (ROTate Left)
Shifts bits up in significance,
placing spilt-off most significant bits
into positions of least significance.ROTR (ROTate Right)
Shifts bits down in significance,
placing spilt-off least significant bits
into positions of most significance.