Talk:IBM hexadecimal floating-point

IBM 360 vs IBM 370 and zSeries

This article describes in detail the Floating point format for IBM 360 platform. Regarding my edits from 15:54, 27 August 2013‎. Starting from the IBM370 Systems there are enhancements to the floating point format.

Should there be a section that describe the changes for newer hardware ? Or should there be a new article ? Wingsofcourage (talk) 13:50, 16 February 2017 (UTC)

The enhancements are IEEE754-2008 binary and decimal forms, described in the appropriate page. IBM might suggest that this page be called Hexadecimal Floating Point, as that is what the newer documentation calls it. Gah4 (talk) 21:12, 6 July 2018 (UTC)

Also, extended (quad) precision might be considered an enhancement, but that dates to the 360/85, so is still part of S/360. Gah4 (talk) 21:55, 28 October 2019 (UTC)

Misleading

This page, aside from being badly written, is misleading. As far as I can tell, what it is trying to describe is the floating-point format used by IBM's S/390 hardware, whose fp format dates back to the System/360 of the 1960s, and may also be similar to a 56-bit mantissa format used by some VAX machines. On the other hand, IBM POWER chips use the IEEE 754 format, and I can't find any reference to support the idea that the S/390 format is named the IBM Floating Point Standard. —Steven G. Johnson 21:25, 19 Mar 2004 (UTC)

Agreed. I have tidied it up a bit; the information down to the code section is useful and was basically correct, however. It should be renamed 'IBM Floating Point Architecture' .. is there an easy way to rename a Wikipedia page and all references to it? mfc 08:57, 20 Mar 2004 (UTC)

(Ah, rename is called 'move'. Done. mfc 08:15, 23 Mar 2004 (UTC))

The article by Gerwig et al. in the IBM Systems Journal 48(3) May/July 2004 refers to it as the "zSeries/trademark hexadecimal floating-point architecture (HFP)".

(Also, Wikipedia is not a code repository; the Java snippet is probably inappropriate, even if it is not a copyright infringement. Steven G. Johnson)

Agreed. Suggest commenting it out, or move it to here? mfc

Algorithm instead of code

One reason we still care about this format has been added. The code has been replaced with an algorithm, that I think could be valuable. --Tumb 22:01, 22 Mar 2004 (UTC)

Name

This article is specifically about IBM System/360 (et seq.) architecture floating-point, not about IBM in general. So the name should be changed. --Macrakis 17:44, 17 Apr 2005 (UTC)

This article should be renamed to reflect the name of the floating point format, which is I believe base-16 excess-64 floating point format, possibly in a different order 81.187.162.109 08:33, 15 July 2007 (UTC).

IBM calls it HFP, for Hexadecimal Floating Point. As IBM now supports binary and decimal IEEE formats, the name does seem a little wrong. Gah4 (talk) 20:50, 6 April 2018 (UTC)

Comparison to 754

Article says "hexadecimal floating-point uses a similar approach to IEEE 754 binary floating-point", but 360 FP is different from IEEE FP in almost every way that two FP formats can differ: different radix, different exponent range, different significand precision and range (360 is 1/16<=c<1, IEEE is 1<=c<2), no hidden bit, no special values (NaN, Inf, etc.), different rounding behavior. Also, didn't 360 also support single-precision FP (and quad?)? --Macrakis 17:44, 17 Apr 2005 (UTC)

360 FP

The 360 floating point is always normalized, so that the leftmost hex digit of the significand is nonzero. This gives each size (single, double, quad) a variable-precision behavior that can be annoying. The single-precision 360 FP, for example, can have as little as 21 bits precision in its significand, or as much as 24 bits. This is particularly vexing when one must account for all the bits while converting from 360 FP to IEEE 754 and vice versa.

It is not always normalized, as there are the AU and AW instructions for unnormalized add. (Also, SU and SW.) But yes the bit precision is variable. Note that the bit precision is also variable in the decimal representation commonly used by people (and also some computers). That is, one should be careful in calculating significant digits. Gah4 (talk) 20:48, 6 April 2018 (UTC)

Representation of zero

The standard representation of zero is missing. Probably it's 0x40000000, but I don't know. --84.150.204.140 02:04, 8 June 2006 (UTC)

After thinking about it, 0x00000000 makes more sense, and that's what I found in GRIB files. --84.150.204.140 02:14, 8 June 2006 (UTC)

Yes X'00000000'. (IBM assembler representation.) If you add zero with any other exponent value, you can lose significant digits. The Fortran AINT function is implemented by adding 0x47000000. For multiply, I think it doesn't matter, but I am not sure about that. Gah4 (talk) 20:46, 6 April 2018 (UTC)

i think it is terrible

The deferent format of data bings a great difficults in our daily works. it is time to do something to stop it . —Preceding unsigned comment added by 124.17.4.30 (talk) 09:31, 17 July 2008 (UTC)

This format dates to about 1962. A little late to change now. Gah4 (talk) 01:34, 9 March 2019 (UTC)

Bit Order or Endianness

The first two references (IBM System/360/370 Principles of Operation) state quite clearly that bit 0 is the sign. For example the 360 document says on page 12: "Bit position 0 in either [short or long] format is the sign (S) of the fraction". I suggest that this be corrected in the ASCII-Art diagrams. --130.75.243.201 (talk) 16:19, 25 April 2012 (UTC)

Unlike everyone else, IBM numbers bits from left to right, so what IBM calls "bit 0" is the leftmost (most significant) bit within a word. — Loadmaster (talk) 17:37, 10 February 2014 (UTC)

Yet the article has this self-contradictory note: "Note that IBM documentation numbers the bits from right to left, so that the most significant bit is designated as bit number 0."

I added that note, and I just corrected it; thanks for catching it. Hopefully it is clear that IBM names the bits the opposite way of what practically everyone else does, thus what IBM calls bit 0 is the most significant (left-most) bit of a word. — Loadmaster (talk) 19:55, 30 May 2014 (UTC)

Also, practically everyone else didn't exist at the time. But yes, IBM tends to do things their way. Note that the bit numbering is consistent with big-endian storage. Gah4 (talk) 01:36, 9 March 2019 (UTC)

Representation of 0.1

Is the representation of 0.1 given in the article correct? The article gives:

S Exp Fraction 0 100 0000 0001 1001 1001 1001 1001 1010

where the rightmost nybble is 1010 rather than the recurring 1001.

This could be a mistake or is the rounding up from 1001 to 1010 intentional and necessary? — Preceding unsigned comment added by 89.11.138.63 (talk) 10:43, 21 October 2014 (UTC)

10011001 rounded to 4 binary digits is 1010, since 1001 > 1000. --Macrakis (talk) 14:10, 21 October 2014 (UTC)

In many cases, they are defined as truncated. For example DER and DDR give the truncated quotient, not the rounded quotient. This was a documented incompatibility for the 360/91, which generates the rounded quotient. But as an arithmetic example, that isn't necessarily the answer. I am not sure what compilers and assemblers do if give 0.1. Gah4 (talk) 21:21, 6 July 2018 (UTC)

rename to IBM Hexadecimal Floating Point?

Any thought to renaming this IBM Hexadecimal Floating Point? That is what IBM now calls it, since the added BFP to ESA/390. Gah4 (talk) 21:23, 6 July 2018 (UTC)

Thanks for making the change. Gah4 (talk) 19:08, 12 July 2018 (UTC)

fraction

IBM calls the significand fraction as noted in the figures. The text mostly does that, too. I believe the remaining significand are describing formats in general, and not specifically HFP. Gah4 (talk) 01:39, 9 March 2019 (UTC)

Special uses

The bullet point about SEG Y is inaccurate but Philip Trueman objected to my correction by undoing it. SEG has supported IBM hexadecimal single precision in SEG Y since its original publication in 1975. Complementary standard SEG C supported IBM FP earlier, since 1972. My correction was altering the parenthesis to read (IEEE single-precision floating-point was added in 2002). I was indicating that IEEE was added in 2002 in revision 1, supplementing the existing IBM support. Citations for SEG documents should be updated, the base URL is https://seg.org/Publications/SEG-Technical-Standards/ Pete Forman (talk) 18:17, 28 October 2019 (UTC)

It seems to me that such a comment belongs on an IEEE format page, not this one. Removal of support for HFP could go here, I suppose. Gah4 (talk) 22:00, 28 October 2019 (UTC)

HFP

This article was (properly) renamed to include the hexadecimal part some time ago, and IBM supports HFP, BFP, and DFP on many current machines. The text of the article, though, still says IBM floating point throughout, suggesting that it is the only IBM format. As well as I know, HFP is not used for any other floating point formats, IBM or otherwise. Is it too strange to call it HFP throughout? Gah4 (talk) 04:07, 14 November 2020 (UTC)

I agree, the article should be updated. — Vincent Lefèvre (talk) 12:13, 14 November 2020 (UTC)

OK by me. I assume it’s “IBM floating point” because it was developed and used by IBM. As the article says, it was also used on other systems.Peter Flass (talk) 13:47, 14 November 2020 (UTC)

Yes, but IBM also had other floating point formats, such as the one used on the 704 and 7090 36 bit machines. DFP was, as well as I know, mostly developed by IBM but is now part of IEEE 754. If we identify it as HFP at the top, then we can call it that through the rest of the article. Gah4 (talk) 02:08, 15 November 2020 (UTC)

New name "IBM hexadecimal floating-point"

Comp.arch: I think that "IBM hexadecimal floating-point" is not OK because "floating-point" has a hyphen but is not followed by a noun. "IBM hexadecimal floating-point arithmetic" would probably be more meaningful. — Vincent Lefèvre (talk) 15:27, 14 December 2020 (UTC)

I don't think the article is up to arithmetic, but maybe only format. I am almost not sure about IEEE 754, but at least it describes rounding modes and lists the operations. This one does not include rounding modes (truncate), or operations, but only the bit formats. (HFP truncates on division, except for the 360/91 where it rounds. This is a documented difference, I don't know how often if cause problems.) Gah4 (talk) 17:24, 14 December 2020 (UTC)

The article is not just on the format, but also the arithmetic. See section Arithmetic operations, though it is currently very short; but I think that it should be expanded. — Vincent Lefèvre (talk) 17:33, 14 December 2020 (UTC)

OK, but I think that isn't enough to name the page with arithmetic. To me, IEEE 754 is barely enough. Gah4 (talk) 19:29, 14 December 2020 (UTC)

TI-990

The article mentions the TI-990 as using this format, but I can't find anything in TI-990 documentation about it. As far as I can tell, floating point is done in software for Fortran and BASIC. Gah4 (talk) 12:21, 25 June 2021 (UTC)

I don't know for this one, but IMHO, at least a source should be required for all the items of this list. — Vincent Lefèvre (talk) 16:44, 25 June 2021 (UTC)