The discussion revolves around the challenges and intricacies of computer arithmetic, particularly focusing on floating point representation and its implications in programming. Participants share insights, personal experiences, and technical details related to the limitations of floating point calculations, historical computing practices, and potential solutions.
Participants express a range of views on the effectiveness of floating point arithmetic and its historical context. While some agree on the challenges posed by floating point representation, there is no consensus on the best approaches or solutions, and multiple competing perspectives remain throughout the discussion.
Limitations include varying definitions of floating point precision, the historical context of computing hardware, and unresolved technical details regarding specific processors and their capabilities.
This discussion may be of interest to computer science students, programmers, and those interested in the history of computing and numerical analysis.
##6.022 × 10^{23}## right? I fixed it.BvU said:
The first programming class I took was in 1972, using a language named PL-C. I think the 'C' meant it was a compact subset of PL-1. Anyway, you wrote your program and then used a keypunch machine to punch holes in a Hollerith (AKA 'IBM') card for each line of code, and added a few extra cards for the job control language (JCL). Then you would drop your card deck in a box, and one of the computer techs would eventually put all the card decks into a card reader to be transcribed onto a tape that would then be mounted on the IBM mainframe computer. Turnaround was usually a day, and most of my programs came back (on 17" wide fanfold paper) with several pages of what to me was gibberish, a core dump, as my program didn't work right. With alll this rigamarole, programming didn't hold much interest for me.anorlunda said:
Thanks, Jim, glad you enjoyed it. Do you have any links to the Intel libraries, or a name? I'd like to look into that more.jim mcnamara said:
My first computer was so slow I would crunch the code for routines in machine code in my head and just type a data string of values to poke into memory through basic because even the compiler was slow and buggy... its the object oriented programming platforms that was when I really saw the "next level something" for programming.Mark44 said:
I don't think it had an Intel 8086 cpu. According to this wiki article, https://en.wikipedia.org/wiki/TRS-80_Color_Computer#Color_Computer_2_.281983.E2.80.931986.29, the Coco 2 had a Motorola MC6809 processor. I'm 99% sure it didn't have hardware support for floating point operations.jerromyjon said:
You must have had the optional Intel 80387 math processing unit or one of its competitors (Cyrix and another I can't remember). The 80386 didn't have any hardware floating point instructions.jerromyjon said:
That's what I thought at first 68B09E was the coco3 was the last one now that I remember, second guessed myself.Mark44 said:
It was a pentium whatever number I forget but I was only programming up to the 386 instruction set at that time... I printed out the instruction set on that same old fanfold paper stack and just started coding.Mark44 said:
The Pentium would have been 80586, but I guess the marketing people got involved and changed to Pentium. If it was the first model, that was the one that had the division problem where some divisions gave an incorrect answer out in the 6th or so decimal place. It cost Intel about $1 billion to recall and replace those bad chips. I think that was in '94, not sure.jerromyjon said:
I think that was about the same time, I think it was a pentium 1, 25 Mhz intel chip with no math co-pro but it had a spot on the board for it. Perhaps it was just a 80486... can't even remember the computer model!Mark44 said:
Found this on wikipedia: "The i486 does not have the usual 80-prefix because of a court ruling that prohibits trademarking numbers (such as 80486). Later, with the introduction of the Pentium brand, Intel began branding its chips with words rather than numbers."Mark44 said:
Thanks, jim, I'll take a look at this.jim mcnamara said:
I think you mean IEEE 754 - 2008 support.jim mcnamara said:
So, a compromise then? What you lack in accuracy, you make up for in speed.jim mcnamara said:
?).This isn't anything I've ever given a lot of thought to, but it wouldn't be difficult to compare two floating point numbers in memory (32 bits, 64 bits, or more), as their bit patterns would be identical if they were equal. I'm not including unusual cases like NAN, denormals, and such. The trick is in the step going from a literal such as 0.1, to its representation as a bit pattern.jim mcnamara said:
if (float_datatype_variable==double_datatype_variable)#include <stdlib.h>
#include <stdio.h>
#include <fenv.h>
// compile with gcc -std=c99 for fpclassify
inline int classify(double x) // filter out bad numbers correct for inexact, INT_MIN is the error return;
{
switch(fpclassify(x))
{
case FP_INFINITE:
errno=ERANGE;
return INT_MIN;
case FP_NAN:
errno=EINVAL;
return INT_MIN;
case FP_NORMAL:
return 2;
case FP_SUBNORMAL:
case FP_ZERO:
return 0;
}
return FP_NORMAL; //default
}
// doug gwyn's reldif function
// usage: if(reldif(a, b) <= TOLERANCE) ...
#define Abs(x) ((x) < 0 ? -(x) : (x))
#define Max(a, b) ((a) > (b) ? (a) : (b))
double maxulp=0; // tweek this into TOLERANCE
inline double reldif(double a, double b)
{
double c = Abs(a);
double d = Abs(b);
int rc=0;
d = Max(c, d);
d = (d == 0.0) ? 0.0 : Abs(a - b) / d;
rc=classify(d);
if(!rc) // correct almost zeroes to zero
d=0.;
if(rc == INT_MIN )
{ // error return
errno=ERANGE;
d=DBL_MAX;
perror("Error comparing values");
}
return d;
}
// usage: if(reldif(a, b) <= TOLERANCE) ...