On 2/3/26 11:48 AM, Harald Anlauf wrote:
Hi Jerry!
On 2/2/26 22:42, Jerry D wrote:
On 2/2/26 12:28 PM, Harald Anlauf wrote:
Hi Jerry!
--- snip ---
Let's see:
13.7.2.3.6 EX editing
The EXw.d and EXw.dEe edit descriptors indicate that the external field
occupies w positions, except when w is zero in which case the processor
selects the field width. The fractional part of the field contains d
hexadecimal digits, except when d is zero in which case the processor
selects the number of hexadecimal digits to be the minimum required so
that the output field is equal to the internal value; ...
But -0XF.FFFFFP+124 is shorter than -0X1.FFFFFEP+127, so I think
you should recheck. Sorry for the extra work ;-)
I am very aware of this. My interpretation is "in which case the processor
selects" the number of hexadecimal digits to be what ever minimum it chooses
to produce. Keep in mind this is using the built-in C functions to generate
the hex string so we do not have a bit string to deal with. The value is
correct and it is the minimum the processor produces.
Anyone else one to way in on this? I sure don't want to create custom code bit
shift this.
Not sure if C is really a good reference.
printf takes a double when one wants to pass a float.
With 53 bits for a double with the leading one implicitly set
one could be biased towards a leading 1 before the decimal point.
#include <stdio.h>
#include <values.h>
int
main()
{
printf ("%A\n", -FLT_MAX);
printf ("%A\n",-0X1.FFFFFEP+127);
printf ("%A\n", -0XF.FFFFFP+124);
}
-0X1.FFFFFEP+127
-0X1.FFFFFEP+127
-0X1.FFFFFEP+127
And Fortran does it better (shorter)... ;-)
Harald
Hi Harald, as we know, I got sidetracked on the push for the shared coarray
efforts. I am getting back to looking at this and have some thoughts on how to
mae this better.
One thought that hit me is that I can work the needed bit manipulations if I
assume IEEE 754 format. I think we support platforms that are not IEEE 754.
I presume we ignore those.
Any thoughts on this?
Jerry
