##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) ...That was half my life ago! No I don't remember it specifically... nor do I remember using anything that might have had it, once windows 95 came out I went through several older computers before buying a new dell 10 years ago (P4 2.4ghz), and haven't programmed much since...jim mcnamara said:
I definitely do! I wrote a small x86 assembly program that checked your CPU to see if it was a Pentium, and, if so, used the FDIV instruction to do one of the division operations that was broken. It then compared the computed result against the correct answer to see if they were the same.jim mcnamara said:
There was a joke that Intel changed the name to Pentium because they used the first Pentium to add 100 to 486 and got the answer 585.9963427...Mark44 said:
That cracked me up!vela said:
It's not a problem with the standard, it's a limitation of how accurate you can represent arbitrary floating point numbers (no matter the representation). I believe that the common implementations can exactly represent powers of 2 correct?eltodesukane said: