6 Jan
2019
6 Jan
'19
10:59 a.m.
On Sat, 2019-01-05 at 12:00 -0600, cctalk-request at classiccmp.org wrote:
Re: Microcode, which is a no-go for modern designs
I was a tech in the 90's when the original Pentium FDIV bug was
storming. The issue was confined to the integrated floating point
portion of the processor and was therefore rarely an issue as the vast
majority of software did not use the mathco portion of the chip. Only
a handful of applications and relative handful of users were affected.
This became Intel's position on the matter and they hoped the issue
would just die down to those handful whom they would provide new chips.
The issue did not die down and the bad press forced the decision to
replace ALL pentiums affected. Only a relative few were actually
replaced in the home and small business arena. A software patch was a
common solution to the problem. It masssaged input to the FDIV
instruction to produce a corrected result and worked pretty well as I
recall.
At the time of the storm, the Pentium was still pretty new and very
expensive. Most folks were getting along with AMD k5 and k6
processors. I WAS. I went from k6 to Celeron.
Best
Jeff
6 Jan
6 Jan
11:08 a.m.
On Sun, Jan 6, 2019 at 10:59 AM Jeffrey S. Worley via cctalk <
cctalk at classiccmp.org> wrote:
On Sat, 2019-01-05 at 12:00 -0600, cctalk-request at
classiccmp.org wrote:
That's a good trick, given that the K5 came out in 1996 and the K6 in 1997,
the FDIV issue blew up in late 1994.
- Josh
Re: Microcode, which is a no-go for modern
designs
I was a tech in the 90's when the original Pentium FDIV bug was
storming. The issue was confined to the integrated floating point
portion of the processor and was therefore rarely an issue as the vast
majority of software did not use the mathco portion of the chip. Only
a handful of applications and relative handful of users were affected.
This became Intel's position on the matter and they hoped the issue
would just die down to those handful whom they would provide new chips.
The issue did not die down and the bad press forced the decision to
replace ALL pentiums affected. Only a relative few were actually
replaced in the home and small business arena. A software patch was a
common solution to the problem. It masssaged input to the FDIV
instruction to produce a corrected result and worked pretty well as I
recall.
At the time of the storm, the Pentium was still pretty new and very
expensive. Most folks were getting along with AMD k5 and k6
processors. I WAS. I went from k6 to Celeron.
Best
Jeff
11:18 a.m.
On Sun, 2019-01-06 at 11:08 -0800, Josh Dersch wrote:
That's a good trick, given that the K5 came out in
1996 and the K6 in
1997, the FDIV issue blew up in late 1994.
Memory is like that. The FDIV bug didn't go away because it was
announced, the chips stayed on desktops and our diagnostic software
frequently contained the FDIV patch to deal with such, for the rest of
the decade.
I went from a 486dlc-40 to a 4x86 dx2 80 to a k5 133 to a k6 to a k6 to
a k6 to a celeron. Amd kept releasing faster k6's. My last, in the
late 90's, was IIRC a 333mhz model.
I was a tech in Miami at the time FDIV happened, working for Victors
DataSouth and it's Novell networks. My servers ran 486's but we sold
Pentiums and it was a real hassle to have to field all those beefs from
customers whose EXPENSIVE processors couldn't divide accurately.
In 95' I went to work in Asheville, NC for Uptime Computer Services and
saw a bunch of machines cross my desk which needed the software patch.
In 2000 I was working with Bits and Bytes computer services.
Best,
Jeff
1 p.m.
Pentiums and it was a real hassle to have to field all
those beefs from
customers whose EXPENSIVE processors couldn't divide accurately.
no
It was a real hassle to have to field all those beefs from customers who
had a PERCEPTION that their expensive processors Wouldn't divide
accurately.
There was a serious problem with public perception, and further fueled by
talk show comedians, that all bank statements would be wrong, that
missiles would hit the wrong cities, that airplanes couldn't find the
right airport, . . . AND that all arithmetic in all computers is done
with floating point.
Few people (but most are right here) can recite PI to enough digits to
reach the level of inaccuracy. And those who believe that PI is exactly
22/7 are unaffected by FDIV. (YES, some schools do still teach that!)
Intel needed to do much better on their PR. There was a public perception
that Intel said that they would only replace them for people who could
PROVE that their work was directly affected.
Instead, Intel needed to make it CLEAR that "ALL will be replaced, at no
charge. But, we need a little time to make a few more, SO, we will start
by replacing those for which the work is directly affected, and replace
ALL of them as quickly as more are made."
MOST owners would not hit the error during the life of the machine. Most
power lUsers would have already upgraded to a newer machine (those who
were screaming the loudest, "upgrade" to a newer machine several times
a year, even though they don't replace their car EVERY year).
--
Grumpy Ol' Fred cisin at xenosoft.com
3.14159265358979
8 Jan
8 Jan
9:46 a.m.
New subject: Approximations (was Re: Microcode, which is a no-go for modern designs)
On Sun, Jan 6, 2019 at 1:00 PM Fred Cisin via cctalk <cctalk at classiccmp.org>
wrote:
Few people (but most are right here) can recite PI to
enough digits to
reach the level of inaccuracy. And those who believe that PI is exactly
22/7 are unaffected by FDIV. (YES, some schools do still teach that!)
Really? I find it hard to believe any schools taught that as anything
other than
an approximation. And as an approximation it's not good for much unless
you are
multiplying PI in your head by a factors of 7 a lot (i.e 21*PI ~ 66).
Personally, I use the
PI^2 ~ 10 approximation far more often when doing math in my head. But
since I'm
almost always sitting at a screen, approximations are less useful than they
used to be.
If I need PI to 600 places, "scale=600;a(1)*4" is always there for the
asking.
The exception is the approximations that provide physical scale. For
example, 1 km/s ~
1 parsec/million years, or v=4.74 PM/parallax, which provides the
conversion from proper
motion to parallax, 5 magnitudes is a factor of 100. And of course, "c" in
whatever units
you need. They are just easier to remember than to look up.
--
Eric Korpela
korpela at ssl.berkeley.edu
AST:7731^29u18e3
1:31 p.m.
New subject: Teaching Approximations (was Re: Microcode, which is a no-go for
> Few people (but most are right here) can recite PI
to enough digits to
> reach the level of inaccuracy. And those who believe that PI is
> exactly 22/7 are unaffected by FDIV. (YES, some schools do still teach
> that!)
On Tue, 8 Jan 2019, Eric Korpela wrote:
Really? I find it hard to believe any schools taught
that as anything
other than an approximation.
I first encountered it about 60 years ago, in fifth grade. Our textbook
said, "PI is about 3.1416 or 22/7." Our teacher insisted that that
sentence meant "PI is about 3.1416, or exactly 22/7." I argued it. I
pointed out that 22/7 was about 3.1429, and "why would they say 'about
3.1416' instead of 'about 3.1429' if it were actually 22/7?" I got sent
to the principal's office. My father, who COULD recite a dozen digits of
PI gave me a hard time about "staying out of trouble".
I thought that that was the last of 22/7, other than that my classmates
had been subjected to "lies told to children".
In 1983 - 2013, I taught in the community college. One of my courses was
[BEGINNING] "Computer Math". The students were mostly high school
graduates 18-25 years old, adults seeking career change or enhancement,
and a rare few there for recreational education.
About every other semester, I would have a student who had been taught
"exactly 22/7"! One guy admitted that he had just never bothered to
divide it out. Once he did, he understood the concept of
"approximation", did his homework, and found better ones, like 355/113.
A silly little exercise to get across the concept of approximation was to
get them to divide 1 by 3, write down the result, then clear, and multiply
that result times 3. "What is WRONG with that calculator?" :-) Once they
grasped a comparison to "rounding", "approximation" wasn't so
alien.
They all thought that they knew binary, but many were unaware of octal or
hexadecimal! Hardly any had any idea about NEGATIVE numbers! - "don't you
just use a minus sign?", which I easily changed into the concept of a sign
bit, followed by deriving one's complement and then two's complement by
pointing out that it would be useful to have a bit pattern that we could
add to a number to get zero. "The overflow?? WHAT HAPPENS when the
odometer of your car gets to all 9's? If you add one, you have a new car?
Only way that I ever have 0 on MY odometer! Trivial homework assignment:
how many more miles do you need to drive to get zero on your odometer?"
Virtually NONE of them had any clue about how to represent non-integers,
or even that non-integers COULD be represented in binary!
THAT is further exacerbated by the WINDOZE Calculator that switches to
INTEGERS-ONLY in "Programmer" mode!
I put my usual grid of 8 boxes on the board, then a dot and another grid.
"It is NOT a 'decimal point'! You can call it a 'period', but
it's really
a 'binary point' or more generally, a 'radix point'"
We did a whole bunch of simple fractions, such as 3.5, 1.375, etc.
Then I talked about ridiculously large or small numbers, and reminded them
of "scientific notation", and we launched into floating point
representation. One of my homework assignments was the IEE single
precision floating point bit pattern for PI.
And, why bother to memorize a dozen digits of PI, when you could just
memorize a few hundred characters of a macro that will produce it?
Or wait for a infinite series to converge.
--
Grumpy Ol' Fred cisin at xenosoft.com
2:28 p.m.
New subject: Teaching Approximations (was Re: Microcode, which is a no-go for
On 1/8/19 1:31 PM, Fred Cisin via cctalk wrote:
I first encountered it about 60 years ago, in fifth grade.? Our textbook
said, "PI is about 3.1416 or 22/7."? Our teacher insisted that that
sentence meant "PI is about 3.1416, or exactly 22/7."? I argued it.? I
pointed out that 22/7 was about 3.1429, and "why would they say 'about
3.1416' instead of 'about 3.1429' if it were actually 22/7?"? I got
sent
to the principal's office.? My father, who COULD recite a dozen digits
of PI gave me a hard time about "staying out of trouble".
3.142 was good enough for Edward Elgar.
--Chuck
3:04 p.m.
New subject: Teaching Approximations (was Re: Microcode, which is a no-go for
On Tue, 8 Jan 2019, Chuck Guzis via cctalk wrote:
3.142 was good enough for Edward Elgar.
Approximations are what is needed for real world use.
How much accuracy do I need for making a patio table base for a RAMAC
[CRASHED!] platter, using a handheld circular saw, and a guess of the kerf
width?
I have just always found it offensive that 22/7 wasn't properly identified
as being an approximation!
But, using a crude code of 'A' = 1, 'B' = 2, 'C' = 3, etc.
"ELGAR" appears in PI at decimal digits 7608455
4:21 p.m.
New subject: Teaching Approximations (was Re: Microcode, which is a no-go for
On 1/8/19 3:04 PM, Fred Cisin via cctalk wrote:
But, using a crude code of 'A' = 1,
'B' = 2, 'C' = 3, etc.
"ELGAR" appears in PI at decimal digits 7608455
I suspect that Pi, to a sufficient number of places could decode
anyone's surname.
No, I'm thinking of "Nimrod"...
--Chuck
5:24 p.m.
New subject: Teaching Approximations (was Re: Microcode, which is a no-go for
There is an algorithm to calculate any digit of PI as long as it is in HEX ( or base 16 ).
So far no one has been able to do this in a decimal system. It would seem that out binary
computers were close to right in the first place.
Dwight
________________________________
From: cctalk <cctalk-bounces at classiccmp.org> on behalf of Chuck Guzis via cctalk
<cctalk at classiccmp.org>
Sent: Tuesday, January 8, 2019 4:21 PM
To: Fred Cisin via cctalk
Subject: Re: Teaching Approximations (was Re: Microcode, which is a no-go for
On 1/8/19 3:04 PM, Fred Cisin via cctalk wrote:
But, using a crude code of 'A' = 1,
'B' = 2, 'C' = 3, etc.
"ELGAR" appears in PI at decimal digits 7608455
I suspect that Pi, to a sufficient number of places could decode
anyone's surname.
No, I'm thinking of "Nimrod"...
--Chuck
5:50 p.m.
New subject: Teaching Approximations (was Re: Microcode, which is a no-go for
On 1/8/2019 6:24 PM, dwight via cctalk wrote:
There is an algorithm to calculate any digit of PI as
long as it is in HEX ( or base 16 ). So far no one has been able to do this in a decimal
system. It would seem that out binary computers were close to right in the first place.
Dwight
What is the value of PI when you pound a SQUARE peg in a ROUND HOLE?
+-+
| |
+-+
Ben.
6:07 p.m.
New subject: Teaching Approximations (was Re: Microcode, which is a no-go for
On 2019-01-08 8:50 PM, ben via cctalk wrote:
On 1/8/2019 6:24 PM, dwight via cctalk wrote:
You're definitely asking in the right place.
There is an algorithm to calculate any digit of
PI as long as it is in
HEX ( or base 16 ). So far no one has been able to do this in a
decimal system. It would seem that out binary computers were close to
right in the first place.
Dwight
What is the value of PI when you pound a SQUARE peg in a ROUND HOLE? ?+-+
|? |
?+-+
Ben.
9 Jan
9 Jan
9:36 a.m.
New subject: Teaching Approximations (was Re: Microcode, which is a no-go for
On 1/8/2019 7:21 PM, Chuck Guzis via cctalk wrote:
On 1/8/19 3:04 PM, Fred Cisin via cctalk wrote:
I always wondered how do people know that those computed digits of pi,
out to millions and millions of digits, are correct?
Do different algorithms or methods give the same answer?
Doug
But, using a crude code of 'A' = 1,
'B' = 2, 'C' = 3, etc.
"ELGAR" appears in PI at decimal digits 7608455
I suspect that Pi, to a
sufficient number of places could decode
anyone's surname.
No, I'm thinking of "Nimrod"...
--Chuck
10:30 a.m.
New subject: Teaching Approximations (was Re: Microcode, which is a no-go for
On 1/9/19 9:36 AM, Douglas Taylor via cctalk wrote:
I always wondered how do people know that those
computed digits of pi,
out to millions and millions of digits, are correct?
Do different algorithms or methods give the same answer?
That's basically the idea. For example, you can start with the series
approximation of arctangent(1) which is basically
1-1/3+1/5-1/7...
and multiply by 4, and it will converge (slowly) to pi. Using any of
the other methods enumerated on Wolfram:
http://mathworld.wolfram.com/PiFormulas.html
yield the same converging-to-pi result..
Wolfram also has some interesting "approximations" to pi that I had
never encountered:
http://mathworld.wolfram.com/PiApproximations.html
The point is that pi figures deeply into mathematics and so can be
"discovered" by a variety of methods.
--Chuck
10:41 a.m.
New subject: Teaching Approximations (was Re: Microcode, which is a no-go for
For those musically uninitiated, my reference to Elgar was the
interesting discovery by an amateur musician that the "enigma" of the
"Nimrod" variation, which has been debated by musicologists for the last
century or so, is very likely pi.
Consider that by assigning a number to the degrees of the scale, you
have 3.142 =
mi do fa re, or the opening notes that Elgar referred to in his letters
for his "small circle of friends".
Here's a YT performance of Nimrod so you can see how often this theme
occurs:
https://www.youtube.com/watch?v=sUgoBb8m1eE
Musicologists generally don't like the proposed solution, but bear in
mind that the "Enigma Variations" were composed at nearly the same time
that the Indiana Pi Bill was being ridiculed by the literate world.
https://rationalwiki.org/wiki/Indiana_Pi_Bill
Politicians!
--Chuck
8 Jan
8 Jan
8:58 p.m.
New subject: Teaching Approximations (was Re: Microcode, which is a no-go for
On Tue, Jan 8, 2019 at 9:31 PM Fred Cisin via cctalk
<cctalk at classiccmp.org> wrote:
I first encountered it about 60 years ago, in fifth
grade. Our textbook
said, "PI is about 3.1416 or 22/7." Our teacher insisted that that
sentence meant "PI is about 3.1416, or exactly 22/7." I argued it. I
pointed out that 22/7 was about 3.1429, and "why would they say 'about
3.1416' instead of 'about 3.1429' if it were actually 22/7?" I got
sent
to the principal's office. My father, who COULD recite a dozen digits of
PI gave me a hard time about "staying out of trouble".
Nice to know that clueless schoolteachers are not limited to the UK. I had
my fair share of them <mumble> years ago...
About every other semester, I would have a student who
had been taught
"exactly 22/7"! One guy admitted that he had just never bothered to
divide it out. Once he did, he understood the concept of
"approximation", did his homework, and found better ones, like 355/113.
As an aside, I find the 355/113 approximation useful if I need $\pi$ when
doing metalwork and don't have a scientific calculator to hand (e.g. I've
just got the HP16C that lives on my workbench). That approximation is
good to 6 figures I think, which is way more accurate than I can machine
metal to.
A silly little exercise to get across the concept of approximation was to
get them to divide 1 by 3, write down the result, then clear, and multiply
that result times 3. "What is WRONG with that calculator?" :-) Once they
grasped a comparison to "rounding", "approximation" wasn't so
alien.
IIRC one of the manuals for the HP15C had a chapter on 'Why this
calculator gives the wrong answers'. It covered things like rounding
errors.
-tony
9 Jan
9 Jan
5:49 a.m.
New subject: Teaching Approximations (was Re: Microcode, which is a no-go for
On Jan 8, 2019, at 11:58 PM, Tony Duell via cctalk
<cctalk at classiccmp.org> wrote:
...
IIRC one of the manuals for the HP15C had a chapter on 'Why this
calculator gives the wrong answers'. It covered things like rounding
errors.
-tony
That reminds me of a nice old quote.
"An electronic pocket calculator when used by a person unconversant with it will most
probably give a wrong answer in 9 decimal places" -- Dr. Anand Prakash, 9 May 1975
Understanding rounding errors is perhaps the most significant part of "numerical
methods", a subdivision of computer science not as widely known as it should be. I
remember learning of the work of a scientist at DEC whose work was all about this: making
the DEC math libraries not only efficient but accurate to the last bit. Apparently this
isn't anywhere near as common as it should be. And I wonder how many computer models
are used for answering important questions where the answers are significantly affected by
numerical errors. Do the authors of those models know about these considerations? Maybe.
Do the users of those models know? Probably not.
paul
6:27 a.m.
New subject: Teaching Approximations (was Re: Microcode, which is a no-go for
Recently, in the calculator group, a fellow has an older calculator and was using the
power function. You know x^y. He'd put in 2^2 and got 3.99998 or something where the
last digit was 2 off. He was worried that the calculator was bad. I explained to him that
the calculator was fine. It was simply a rounding error. I explained that the calculator
was not doing 2*2 and that it used some series or such to calculate the general case. Most
calculators today have about 2 extra bits not shown to hide most rounding errors. Early
calculators didn't have any extra digits.
The Intel case was actually worse as its errors were often large and not just in the last
digits, when they happened. The errors tended to cluster around odd integer values as
well. When looking at all the possible numbers, the odds were small. When looking at
integer values the odds were a lot larger and the errors were also larger.
Dwight
________________________________
From: cctalk <cctalk-bounces at classiccmp.org> on behalf of Paul Koning via cctalk
<cctalk at classiccmp.org>
Sent: Wednesday, January 9, 2019 5:49 AM
To: Tony Duell; General Discussion: On-Topic and Off-Topic Posts
Subject: Re: Teaching Approximations (was Re: Microcode, which is a no-go for
On Jan 8, 2019, at 11:58 PM, Tony Duell via cctalk
<cctalk at classiccmp.org> wrote:
...
IIRC one of the manuals for the HP15C had a chapter on 'Why this
calculator gives the wrong answers'. It covered things like rounding
errors.
-tony
That reminds me of a nice old quote.
"An electronic pocket calculator when used by a person unconversant with it will most
probably give a wrong answer in 9 decimal places" -- Dr. Anand Prakash, 9 May 1975
Understanding rounding errors is perhaps the most significant part of "numerical
methods", a subdivision of computer science not as widely known as it should be. I
remember learning of the work of a scientist at DEC whose work was all about this: making
the DEC math libraries not only efficient but accurate to the last bit. Apparently this
isn't anywhere near as common as it should be. And I wonder how many computer models
are used for answering important questions where the answers are significantly affected by
numerical errors. Do the authors of those models know about these considerations? Maybe.
Do the users of those models know? Probably not.
paul
9:43 a.m.
New subject: Teaching Approximations (was Re: Microcode, which is a no-go for
On 01/09/2019 07:49 AM, Paul Koning via cctalk wrote:
Understanding rounding errors is perhaps the most
significant part of "numerical methods", a subdivision of
computer science not as widely known as it should be. I
remember learning of the work of a scientist at DEC whose
work was all about this: making the DEC math libraries not
only efficient but accurate to the last bit. Apparently
this isn't anywhere near as common as it should be. And I
wonder how many computer models are used for answering
important questions where the answers are significantly
affected by numerical errors. Do the authors of those
models know about these considerations? Maybe. Do the
users of those models know? Probably not. paul
A real problem on the IBM 360 and
370 was their floating
point scheme. They saved exponent bits by making the
exponent a power of 16, instead of 2. This meant that the
result of any calculation could end up normalized with up to
3 most-significant zeros. That would reduce the precision
of the number by up to 3 bits, or a factor of 8. Some
iterative solutions compared small differences in successive
calculations to decide when they had converged sufficiently
to stop.
These could either stop early, or run on for a long time
trying to reach convergence.
IBM eventually had to offer IEEE floating point format on
later machines.
Jon
10:17 a.m.
New subject: Teaching Approximations (was Re: Microcode, which is a no-go for
On Wed, 9 Jan 2019, Jon Elson via cctalk wrote:
A real problem on the IBM 360 and 370 was their
floating point scheme.
I think that another serious problem was erroneous nomenclature, such as
FORTRAN using binary approximations (using a special subset of "RATIONAL
numbers"), and calling them "REAL" numbers!
10:40 a.m.
New subject: Teaching Approximations (was Re: Microcode, which is a no-go for
-----Original Message-----
From: cctalk <cctalk-bounces at classiccmp.org> On Behalf Of Jon Elson via
cctalk
Sent: 09 January 2019 17:43
To: Paul Koning <paulkoning at comcast.net>; General at ezwind.net;
Discussion at ezwind.net:On-Topic and Off-Topic Posts
<cctalk at classiccmp.org>
Subject: Re: Teaching Approximations (was Re: Microcode, which is a no-go
for
On 01/09/2019 07:49 AM, Paul Koning via cctalk wrote:
They
Understanding rounding errors is perhaps the most significant part of
"numerical methods", a subdivision of computer science not as widely
known as it should be. I remember learning of the work of a scientist
at DEC whose work was all about this: making the DEC math libraries
not only efficient but accurate to the last bit. Apparently this isn't
anywhere near as common as it should be. And I wonder how many
computer models are used for answering important questions where the
answers are significantly affected by numerical errors. Do the authors
of those models know about these considerations? Maybe. Do the users
of those models know? Probably not. paul
A real problem on the IBM 360 and 370 was
their floating point scheme. saved exponent bits by making the exponent a power of
16, instead of 2.
This meant that the result of any calculation could end up normalized with
up
to
3 most-significant zeros. That would reduce the precision of the number
by
up to 3 bits, or a factor of 8. Some iterative
solutions compared small
differences in successive calculations to decide when they had converged
sufficiently to stop.
These could either stop early, or run on for a long time trying to reach
convergence.
Early machines had to have the floating point units re-worked as IBM found
they had to add guard bits to the calculations to get any thing like decent
accuracy. In general you needed to use double for decent results.
IBM eventually had to offer IEEE floating point format
on later machines.
Jon
Dave
10:12 a.m.
New subject: Teaching Approximations (was Re: Microcode, which is a no-go for
> I first encountered it about 60 years ago, in
fifth grade. Our textbook
> said, "PI is about 3.1416 or 22/7." Our teacher insisted that that
> sentence meant "PI is about 3.1416, or exactly 22/7." I argued it. I
> pointed out that 22/7 was about 3.1429, and "why would they say 'about
> 3.1416' instead of 'about 3.1429' if it were actually 22/7?" I got
sent
> to the principal's office. My father, who COULD recite a dozen digits of
> PI gave me a hard time about "staying out of trouble".
On Wed, 9 Jan
2019, Tony Duell wrote:
Nice to know that clueless schoolteachers are not
limited to the UK. I had
my fair share of them <mumble> years ago...
They have not been limited to the UK for more than half aa millenium.
USA caught up many hundreds of years ago.
11:36 a.m.
New subject: Teaching Approximations (was Re: Microcode, which is a no-go for
Good evening.
I used to post here a lot; now I mainly lurk, but this subject is one I
feel strongly about...
About every other semester, I would have a student who
had been taught
"exactly 22/7"!? One guy admitted that he had just never bothered to
divide it out.? Once he did, he understood the concept of
"approximation", did his homework, and found better ones, like 355/113.
For me, the one that bugs me is sqr(3), which comes up in electrical
engineering a lot in 3-phase circuits.
What bugs me is seeing people type "1.73" into their calculator when
they mean sqr(3). I know other people disagree with me on this - some
say it doesn't matter, others say it shows the person is thinking about
the problem rather than just using a textbook formula - but here is my take.
Firstly, I don't know about many modern calculators, but on the
calculators I grew up with, and on my HP-48, sqr(3) takes _fewer_
keypresses than 1.73, so why would anyone want to type that?
Secondly, how accurate is 1.73? I am willing to bet these people don't
know. A more precise figure is 1.73205... so 1.73 is about 0.12% too small.
In other words, in most applications the difference is negligible. But
when they are calibrating (for example) the tarriff metering system,
where the system is expected to be accurate to 0.1%, using current and
voltage transformers of nominally 0.1% precision (you need to measure
the error under various conditions and program a correction into the
meter), the error in the figure they are using for sqr(3) will swamp the
errors they are measuring.
My worry is that these people will go on using 1.73, and getting away
with it, until they calibrate the metering CTs, and then will have no
ideas why everything is so far out of spec. If they are lucky, the
error will show a new piece of kit to be out of spec when it is actually
fine but marginal, and the supplier will gently correct them...
And all because, as people here have been saying, people don't know the
validity of the approximations they are using.
For sqr(3) without a calculator, "7/4 less 1%" is actually pretty good.
It comes out at 1.7325, or 0.026% high. If I just need a rough figure,
7/4 is fine. And most importantly, I know how much precision I need for
most applications.
Philip.
PS for pi, I once saw 710/226 in a slide rule manual. This is the same
as 355/113, of course, but owing to the discontinuous nature of the
scale precision, it is easier to set up. On that slide rule, anyway -
others may have the discontinuities in different places...
2:54 p.m.
New subject: Teaching Approximations (was Re: Microcode, which is a no-go for
On Wed, 9 Jan 2019, Philip Belben via cctalk wrote:
For me, the one that bugs me is sqr(3), which comes up
in electrical
engineering a lot in 3-phase circuits.
What bugs me is seeing people type "1.73" into their calculator when they
mean sqr(3). I know other people disagree with me on this - some say it
doesn't matter, others say it shows the person is thinking about the problem
rather than just using a textbook formula - but here is my take.
Firstly, I don't know about many modern calculators, but on the calculators I
grew up with, and on my HP-48, sqr(3) takes _fewer_ keypresses than 1.73, so
why would anyone want to type that?
except that not all calculators have sqrt key in same place, so sometimes
it's quicker to just type the number.
Secondly, how accurate is 1.73? I am willing to bet
these people don't know.
A more precise figure is 1.73205... so 1.73 is about 0.12% too small.
I have ALWAYS used 1.732 It is accuraate enough for any of my needs.
"But, how do you remember it?"
"Easy. the year that George Washington was born."
"But how do you remember THAT?"
"Extremely easy! Square root of 3 !"
6 Jan
6 Jan
11:09 a.m.
On 1/6/19 11:59 AM, Jeffrey S. Worley via cctalk wrote:
I was a tech in the 90's when the original Pentium
FDIV bug was storming.
The issue was confined to the integrated floating point portion of the
processor and was therefore rarely an issue as the vast majority of
software did not use the mathco portion of the chip. Only a handful of
applications and relative handful of users were affected. This became
Intel's position on the matter and they hoped the issue would just die
down to those handful whom they would provide new chips.
The issue did not die down and the bad press forced the decision to
replace ALL pentiums affected. Only a relative few were actually replaced
in the home and small business arena. A software patch was a common
solution to the problem. It masssaged input to the FDIV instruction to
produce a corrected result and worked pretty well as I recall.
I suspect that Intel is longing for the Pentium FDIV bug days after the
speculative execution issues that have surfaced (and gained traction) in
2018.
--
Grant. . . .
unix || die
1955
days inactive
1958
days old
24 comments
15 participants
participants (15)
-
ard.p850ug1＠gmail.com -
bfranchuk＠jetnet.ab.ca -
cclist＠sydex.com -
cctalk＠gtaylor.tnetconsulting.net -
cisin＠xenosoft.com -
dave.g4ugm＠gmail.com -
derschjo＠gmail.com -
dj.taylor4＠comcast.net -
dkelvey＠hotmail.com -
elson＠pico-systems.com -
korpela＠ssl.berkeley.edu -
paulkoning＠comcast.net -
philip＠axeside.co.uk -
technoid6502＠gmail.com -
toby＠telegraphics.com.au