Who ate all the PIES?

Uncle Gizmo

Nifty Access Guy
Staff member
Local time
Today, 04:31
Joined
Jul 9, 2003
Messages
16,675
Well this article was a bit of an eye opener for me because they state that 22 over 7 is not a good approximation of pi...

A better approximation is 355 over 113, but it's still an approximation even though it's more accurate than 22 over 7.

But they appear to have come up with a quantum way of handling pi which I thought was quite interesting you might want to read this article:-

 
I've always used the intrinsic DOUBLE constant used in Access, which is good enough most of the time since anything involved with PI in Access will also only be using DOUBLE numbers.

However, when we were working with satellite-based navigation, there was a time when the boss said I needed to compute PI to more than the 15 digits you can get with DOUBLE, because I was doing some work on a machine with IEEE/QUAD format, hardware 128-bit floating point = 33 to 36 digits. There, I used the formula PI/4 = arctan(1). There is a power series for arctangent, which I used to compute the value and store it as a constant for later use. Good thing I didn't have to recompute it every time because the power series is slow to converge.


If I recall correctly, the number I got that way was about 3.141592653589793238462643383279502884, and fortunately I only had to use it a couple of times before the boss realized that DOUBLE floating was really adequate for what we were doing and I could let that QUAD floating nightmare go back into oblivion.
 
I stick to the nmonic May I Have A Large Container Of Coffee Cream And Sugar. - 10 decimal places. I've never needed more than this, I 've normally never needed to use pi in code., but often on paper.
 
I've always used the intrinsic DOUBLE constant used in Access, which is good enough most of the time since anything involved with PI in Access will also only be using DOUBLE numbers.

However, when we were working with satellite-based navigation, there was a time when the boss said I needed to compute PI to more than the 15 digits you can get with DOUBLE, because I was doing some work on a machine with IEEE/QUAD format, hardware 128-bit floating point = 33 to 36 digits. There, I used the formula PI/4 = arctan(1). There is a power series for arctangent, which I used to compute the value and store it as a constant for later use. Good thing I didn't have to recompute it every time because the power series is slow to converge.


If I recall correctly, the number I got that way was about 3.141592653589793238462643383279502884, and fortunately I only had to use it a couple of times before the boss realized that DOUBLE floating was really adequate for what we were doing and I could let that QUAD floating nightmare go back into oblivion.

Interesting.
Choosing numeric datatypes in SQL Server is a big deal, and well worth studying the issue for days (or more) before deciding.
If there is one thing I would say as my rule of thumb, (not to be guilty of over-generalizing, but..) - it would be I avoid floats, as they're simply not accurate. And although I don't work in banking or scientific testing etc - I'd rather establish the best habits so that if I ever did, I'd be ready.
Decimal(19,6) is a common one I just grab when dealing with fractions and not wanting to think about it too much.
 
I avoid floats, as they're simply not accurate

For large amounts of money that is true, but for things that have statistical importance, floats are almost mandatory. In what I was doing with my dissertation research, not "almost" but "absolutely" mandatory. For money and finance, you do Currency and nobody will be surprised. For medical or chemical test results, floats are a sine qua non - and believe it or not, I use floats in my writing.

As it happens, my main fantasy series involves a world with four moons and, rather than treating them haphazardly, I decided to actually compute moonrise and moonfall. OK, I was having fun doing that, just sort of futzing around, and it turned up something that I turned into a plot point when I realized that I would have a four-moon conjunction during a specific part of the story where that event would have significance. Needed floats to make that astronomical computation work, but it had the desired effect.
 
For money and finance, you do Currency and nobody will be surprised
Actually there are major schools of thought that Currency is trash and should never be used in t-sql
 
As long as you're OK getting the wrong answer!

Me, get a wrong answer from a FLOAT? You forget that I am an old hardware guy who knows how to use DOUBLE to its proper precision. I understand and know how to minimize round-off errors. I know how to do error-sensitivity analysis that would tell me if I am losing significant digits. And don't forget that DATE is a TypeCast of DOUBLE, so you get reasonable dates when doing DATEADD, DATEDIFF, DATEPART, etc. No, Isaac, if you ever got consistently wrong answers from DOUBLE you probably used them incorrectly.
 
Me, get a wrong answer from a FLOAT? You forget that I am an old hardware guy who knows how to use DOUBLE to its proper precision. I understand and know how to minimize round-off errors. I know how to do error-sensitivity analysis that would tell me if I am losing significant digits. And don't forget that DATE is a TypeCast of DOUBLE, so you get reasonable dates when doing DATEADD, DATEDIFF, DATEPART, etc. No, Isaac, if you ever got consistently wrong answers from DOUBLE you probably used them incorrectly.
but I didn't refer to double - I referred to t-sql's float.
 
And although I don't work in banking or scientific testing etc - I'd rather establish the best habits so that if I ever did, I'd be ready.
Decimal(19,6) is a common one I just grab when dealing with fractions and not wanting to think about it too much.
Heartily agree: always been surprised that the decimal data type hasn't been incorporated into VBA as a native data type.. I was using decimal data type in PL/I forty years ago.
 
Last edited:

Users who are viewing this thread

Back
Top Bottom