Re: One more oddity with gcc and vax floats...

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> Why couldn't hardware floating point do much of the work?
> Because if you want IEEE functionality, you need to use IEEE
> representation, and IEEE semantics on operations when/if they involve
> Inf or NaN.

I *think* that, for the numbers both formats can represent, F-float and
G-float are identical to IEEE single and double.

While I didn't write that "much of the work", I read it a referring to
"the work in the (common) cases where all values involved exist in both
formats".

>> [...]

> But I remember building Python many years ago.  It worked just fine,
> but the test suite to verify that it worked correctly always failed.

docs.python.org/3/reference/datamodel.html says that python
numbers.Real "represent machine-level double precision floating-point
numbers", going on to say "You are at the mercy of the underlying
[hardware/software implementation] for the accepted range and handling
of overflow".  If the test suite still fails on VAXen, I would say it's
broken to the point that filing a bug report against the test suite is
appropriate.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B