Talk:IBM hexadecimal floating-point

message: 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)
replies: text: 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)

text: 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)
thread_title: IBM 360 vs IBM 370 and zSeries

message: 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)
thread_title: Algorithm instead of code

message: 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)
replies: text: 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)
thread_title: Name

message: 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)
thread_title: Comparison to 754

message: 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)
thread_title: 360 FP

message: 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)
replies: text: 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)
replies: text: 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)
thread_title:  Representation of zero 

message: 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)
replies: text: This format dates to about 1962.  A little late to change now. Gah4 (talk) 01:34, 9 March 2019 (UTC)
thread_title:  i think it is terrible  

message: 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)
replies: text: 10011001 rounded to 4 binary digits is 1010, since 1001 > 1000. --Macrakis (talk) 14:10, 21 October 2014 (UTC)

text: 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)
thread_title: Representation of 0.1

message: 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)
replies: text: Thanks for making the change.  Gah4 (talk) 19:08, 12 July 2018 (UTC)
thread_title:  rename  to ''IBM Hexadecimal Floating Point''? 

message: 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)
thread_title:  fraction 

message: 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)
replies: text: 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)
thread_title:  Special uses 

message: 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)
replies: text: 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)
thread_title:  TI-990