What I can to do with old PL/1 code? - Programming Languages

glen herrmannsfeldt wrote:[color=blue]
> In comp.lang.pl1 Binyamin Dissen <postingid@dissensoftware.com> wrote:
>[color=green]
>>On Mon, 10 Apr 2006 06:34:38 -0700 "Tom Linden" <tom@kednos.com> wrote:[/color]
>
>
>[color=green]
>>:>When I went to school, Mantissa was the fractional part of the
>>:>logarithm. It has been widely misused to mean the fractional part of
>>:>a normalized floating point representation of a number, googling I
>>:>even found one definition as the fractional part of a real number.
>>:>Now let's end it there please.[/color]
>
>
>[color=green]
>>That is how it is used in S/360 as well.[/color]
>
>
>[color=green]
>>The fractional part is not base 10, true, but there is no such requirement.[/color]
>
>
> It is a fractional part, but it isn't (most of the time)
> a logarithm.[/color]

This is not so. It is a fraction, but not a fractional part. There is a big
difference between the two and that's why it is so unfortunate that back in the
fifties some ill informed or unthinking person used the word mantissa for the
significand or fraction of a floating point number. Once it got into the wild,
the usage stuck and there is probably no undoing it now, although we can but try.

The important difference is that in the case of a logarithm, the characteristic
is the integer part and the mantissa is the fractional part of a mixed number
which is the (theoretically exact)logarithm of the (theoretically exact) value
under consideration. In other words, the characteristic and the mantissa are
ADDED together (or juxtaposed, separated by the radix point, which amounts to
the same thing provided they are represented in the same base) to obtain the
logarithm of the value being considered. In fact the logarithm function is a
group isomorphism mapping the uncountably infinite group of non negative real
numbers under multiplication onto the group of all real numbers under addition.
On the other hand, in the case of scientific notation or floating point
representation, the significand or fraction as the case may be is MULTIPLIED by
the base raised to the power given by the true exponent to obtain the
(approximate) value represented. Ordinary notation and scientific notation or
floating point are mappings only in the sense of being alternative
representations of the same values. All of the operations on the underlying
abstract values can be carried out on either of the representations, and there
is no question of one operation being mapped onto another. Moreover, floating
point notation as implemented in computers applies only to a finite subset of
representable numbers.

My 370 manuals use the terms fraction (for significand) and characteristic (for
biased exponent). I think there was an earlier time when IBM did use the term
mantissa for the fraction but they later repented of this. Fraction works for
the 360/370 line but fails for the IEEE format.

In my opinion, the best practice is to use the terms significand and exponent
and avoid the misleading use or mantissa and characteristic, but it is
impossible to undo history so we will no doubt continue to see the misuse of
mantissa and characteristic.

In the case of the return value from the LOG[color=blue]
> function it would be a mantissa. (Though that would make more
> sense if it was a base 16 log for the S/360 case. Last I knew,
> PL/I had a LOG, LOG10, and LOG2 function but no LOG16.)
>
>
> -- glen
>[/color]

"James J. Weinkam" <jjw@cs.sfu.ca> wrote in message
news:wGB_f.18876$4S.10053@edtnps82...[color=blue]
> glen herrmannsfeldt wrote:[color=green]
> > In comp.lang.pl1 Binyamin Dissen <postingid@dissensoftware.com> wrote:
> >[color=darkred]
> >>On Mon, 10 Apr 2006 06:34:38 -0700 "Tom Linden" <tom@kednos.com> wrote:
> >>:>When I went to school, Mantissa was the fractional part of the
> >>:>logarithm. It has been widely misused to mean the fractional part of
> >>:>a normalized floating point representation of a number, googling I
> >>:>even found one definition as the fractional part of a real number.[/color][/color][/color]

Except that the mantissa (of a FPN) can be a fraction,
an integer, and /or a number, or whatever the designer
wants it to be.
[color=blue][color=green][color=darkred]
> >>That is how it is used in S/360 as well.
> >>The fractional part is not base 10, true, but there is no such requirement.[/color]
> > It is a fractional part, but it isn't (most of the time)
> > a logarithm.[/color]
>
> This is not so. It is a fraction, but not a fractional part. There is a big
> difference between the two and that's why it is so unfortunate that back in
> the fifties[/color]

Probably the forties, because that's when
floating-point algorithms were being written.
[color=blue]
> some ill informed or unthinking person used the word mantissa for the[/color]

I think that you will find that the persons weren't "ill-informed" at all.
They were competent numerical mathematicians.
[color=blue]
> significand or fraction of a floating point number.[/color]

There's nothing wrong with 'mantissa' to mean part of a FPN.

"glen herrmannsfeldt" <gah@barf.ugcs.caltech.edu> wrote in message
news:e1e5q6$47e$2@naig.caltech.edu...
[color=blue]
> It is a fractional part, but it isn't (most of the time)
> a logarithm. In the case of the return value from the LOG
> function it would be a mantissa. (Though that would make more
> sense if it was a base 16 log for the S/360 case. Last I knew,
> PL/I had a LOG, LOG10, and LOG2 function[/color]

It still has.
[color=blue]
> but no LOG16.)[/color]

IIRC log16(a) = log2(a)/4

robin wrote:

(snip)
[color=blue][color=green]
>>but no LOG16.)[/color][/color]
[color=blue]
> IIRC log16(a) = log2(a)/4[/color]

Well, that is true of all logs, though the coefficient isn't so easy
to remember. I don't believe that is a sufficient reason, especially on
hex float machines. (Where /4 can lose two bits of precision.)

-- glen

James J. Weinkam wrote:

(snip regarding mantissa)
[color=blue]
> In my opinion, the best practice is to use the terms significand and
> exponent and avoid the misleading use or mantissa and characteristic,
> but it is impossible to undo history so we will no doubt continue to see
> the misuse of mantissa and characteristic.[/color]

I have read discussions about logarithmic systems where instead of
fraction (or significand) and exponent the mantissa and characteristic
of the log of the desired value are stored. This makes multiply easy
and add hard, though, but in that case mantissa does describe the stored
value.

-- glen

glen herrmannsfeldt wrote:[color=blue]
> James J. Weinkam wrote:
>
> (snip regarding mantissa)
>[color=green]
>> In my opinion, the best practice is to use the terms significand and
>> exponent and avoid the misleading use or mantissa and characteristic,
>> but it is impossible to undo history so we will no doubt continue to
>> see the misuse of mantissa and characteristic.[/color]
>
>
> I have read discussions about logarithmic systems where instead of
> fraction (or significand) and exponent the mantissa and characteristic
> of the log of the desired value are stored. This makes multiply easy
> and add hard, though, but in that case mantissa does describe the stored
> value.
>
> -- glen
>[/color]
Well, if it really is a logarithmic system, I suppose the terms characteristic
and mantissa are appropriate, but can you give a reference?

The question I have is why anyone would want to do this. In Napier's time,
logarithms were used to reduce multiplication to addition when there were no
mechanical or electronic calculators. Now that we have them, what's the point
for that purpose?

Of course the logarithm and exponential functions have numerous other useful
applications, but that's another story.

In article <4dRdg.27449$zn1.10846@clgrps13>,
James J. Weinkam <jjw@cs.sfu.ca> wrote:
[color=blue]
> Well, if it really is a logarithmic system, I suppose the terms characteristic
> and mantissa are appropriate, but can you give a reference?[/color]

"FOCUS Microcomputer Number System"
Albert D. Edgar and Samuel C. Lee
_Communications of the ACM_ Vol 22 #3, pp 166-177, March 1979.
----------------------------------------------------------------------

Abstract: FOCUS is a number system and supporting computational
algorithms especially useful for microcomputer control and other signal
processing applications. FOCUS has the wide-ranging character of
floating-point numbers with a uniformity of state distributions that
give FOCUS better than a twofold accuracy advantage over an equal word
length floating-point system. FOCUS computations are typically five
times faster than single precision fixed-point or integer arithmetic
for a mixture of operations, comparable in speed with hardware
arithmetic for many applications. Algorithms for 8-bit and 16-bit
implementations of FOCUS are included.

FOCUS actually stored the log of (1+x) to represent x.
[color=blue]
> The question I have is why anyone would want to do this.[/color]

It effectively saves a bit of precision; more, if you are comparing to a
hex FPS such as the IBM/360, or one that wastes a bit to carry the
(always-on for nonzero numbers) leading bit of the fractional part.
[color=blue]
> In Napier's time, logarithms were used to reduce multiplication to
> addition when there were no mechanical or electronic calculators.
> Now that we have them, what's the point for that purpose?[/color]

Harware multiply is not ubiquitous, and used to be absent from inexpensive
CPUs. Even now, hardware multiply is often slower than hardware add, and
hardware divide nearly alweays is. If the numbers being stored will be used
for division or multiplication far more often than for addition,
subtraction, or display, then logarithmic representation allows faster
programs.

--
Randy Hudson

"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:rsadnaGA26jKhevZRVn-ug@comcast.com...[color=blue]
> robin wrote:[color=green][color=darkred]
> >>but no LOG16.)[/color][/color]
>[color=green]
> > IIRC log16(a) = log2(a)/4[/color]
>
> Well, that is true of all logs, though the coefficient isn't so easy
> to remember. I don't believe that is a sufficient reason, especially on
> hex float machines. (Where /4 can lose two bits of precision.)[/color]

The precision of S/390 is 21 bits or 53 bits.
You don't lose this precision on division by 4.

robin wrote:

(snip)
[color=blue]
> The precision of S/390 is 21 bits or 53 bits.
> You don't lose this precision on division by 4.[/color]

The precision is between 21 and 24 for short, and between
56 and 53 for long. The algorithms for the most libraries
were designed not to lose precision unnecessarily.

0.9 has 24 bits of precision in short float. Divide it by
four and it loses two bits. Multiply or divide the result by four
and you don't gain them back again, though the bits are again
available. That is precision loss.

-- glen