|
|
|
| Authored by: Anonymous on Friday, March 29 2013 @ 01:18 PM EDT |
Ah, yes, all that you say is true (and obvious to anyone who's ever done
assembly-language floating-point arithmetic.)
All the machines that I have any information about, have floating-point
registers that are as long or longer than the in-memory representation. With the
IEEE standard, this practice is
Which means -- in real practice, NOBODY builds a machine that PRACTICES or
INFRINGES this patent. And, since software simply uses the machine instructions,
it's not possible for software to infringe the patent (unless, of course,
someone was idiotic enough to implement this algorithm in slow software rather
than using the hardware...)
And finally, this algorithm is brain-dead from the beginning. Some legal-weasel
doofus may say it's an "improvement" over IEEE-standard arithmetic to
round the operands first -- but some legal-weevil legislator could just as
accurately, just as usefully, just as intelligently, propose a law saying that
the value of pi should be 3 for all future ages.
There's no reason at all to round the operands first, and many good reasons not
to.
But what would I know? I'm not a patent lawyer, just a graduate of
BS/mathematics, MS/computer science university programs.[ Reply to This | Parent | # ]
|
| |
| Authored by: jesse on Saturday, March 30 2013 @ 05:53 AM EDT |
In my case, the multiply by 100 was necessary to force the conversion to the
correct resolution - as I recall it was a truncate conversion. This was a
business simulation application, and converted from IBM 360/370 Fortran to run
on a Dec System 10. So there was also a required floating point format
differences got involved.
You also get normalized/unnormalized results when using IEEE floating point
causing additional uncertainty. As I recall, the internal register formats were
allowed to be unnormalized - which improves speed, but can introduce more errors
when used in certain operations/other values. This was the original intent to
have up to 80 bits of precision inside the FPU to reduce these errors.[ Reply to This | Parent | # ]
|
|
|
|
|
