This is a multi-part message in MIME format.
--------------080108000605050608040308
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sam Mason wrote:
> On Wed, May 14, 2008 at 02:08:47PM -0400, Justin wrote:
>
>> Sam Mason wrote:
>>
>>> What does foxpro use for storing numbers? or is it just that you never
>>> pushed it hard enough for the abstractions to show through.
>>>
>> I know i pushed it. Foxpro for the most has only 4 basic data types
>> Numeric (similar to Posgresql numeric), Boolean, Date, Text aka
>> (string) The foxpro tables sup****ted far more data types but when
every
>> it was dumped to variable it acted like one of the 4.
>>
>
> I really meant how much did you check the results, or did you accept
> that they were correct?
>
>
>> Foxpro did not suffer floating point math errors. I normally used 8 to
>> 10 points precision. Foxpro was limited to 15 points of precision
>> period. No more and no less, once you hit that was it.
>>
>
> 15 places seems very similar to what a 64bit IEEE floating point number
> will give you, i.e. a double in C/C++.
>
>
>> My problem is we calculate resistance of parts in a Foxpro app that we
>> want to move because we want to bring all the custom apps into one
>> framework and single database.
>>
>> Take this calculation (0.05/30000* 1.0025) which is used to calculate
>> parts resistance and Tolerance. (its Ohms Law) The value returned
from
>> C++ = .0000016708 which is wrong
>> it should be .00000167418. We just shrank the tolerance on the part we
>> make
>>
>
> Why are you so sure about the FoxPro result? I've just checked a few
> calculators and get results consistent with your C++ version.
>
> Justin C: 0.0000016708
> J FoxPro: 0.00000167418
>
this 167418 came of my ti 89 calculator, going back i noticed that i
accident rounded it to .00000167 which gives a bad result.
So what i typed in after that point is wrong. OOPS.
But loosing the 3 will put out of the tolerance sense its the last
significant digit needed thats displayed on the measurement devices. So
if the 3 becomes a 4 your out of tolerance.
> My C: 0.000001670833
> bc[1]: 0.0000016708333333333333333333333333333332
> PG[2]: 0.0000016708333333333333336675
>
> Google[3]: 0.00000167083333 (actually gives 1.67083333e-6)
>
Foxpro Agrees with what you have 0.00000167083333
the code looks like this
SET DECIMALS TO 15
? ((0.05/30000)* 1.0025)
When i wrote the application like 10 years ago I spent allot time making
sure the numbers where correct even doing some by hand.
If I gotten it wrong there's allot National labs, Universities, Big
companies that are generating allot bad results in their QC departments.
Chced
> Both bc and Postgres use their own code (i.e. not the CPU's FPU) to do
> the math, and as they all agree I'm thinking FoxPro is incorrect!
Here is the foxpro Do***entation
Integers or decimal numbers
For example, the quantity of items ordered
8 bytes in memory; 1 to 20 bytes in table
- .9999999999E+19 to .9999999999E+20
> Next
> I tried doing it accurately (in Haskell if it makes any difference) and
> get an answer of 401/240000000 out, which would agree with everything
> but FoxPro. If I calculate the ratio back out for FoxPro I get
> 401/239520242 which is a little way out.
>
>
>> The Do***entation from MS says 15 points of precision but the result
say
>> otherwise.
>>
>
> The docs for what? FoxPro or their C compiler?
>
From the MS Do***ent here is Copied text
*Microsoft Specific --->*
The double type contains 64 bits: 1 for sign, 11 for the exponent, and
52 for the mantissa. Its range is +/--1.7E308 with at least 15 digits of
precision.
*END Microsoft Specific*
> If you mean FoxPro, I think this is another case of MS screwing up.
>
Foxpro normally did not suffer form other MS screw ups.
>
>> I'm glad You and others are taking the time to explain to me
>> the odd results before i get into redoing that application.
>>
>
> Welcome to the PG community, lots of people to get interested in lots of
> things!
>
>
>> Why oh Why did MS kill Foxpro. :'( I understood it, knew its quirks
>> and it worked very well with Postgresql
>>
>
> Are you sure you want to stay with it if its answers are wrong?
>
>
> Sam
>
> [1] http://www.gnu.org/software/bc/manual/html_mono/bc.html
> [2]
http://doxygen.postgresql.org/backend_2utils_2adt_2numeric_8c-source.html
> [3] http://www.google.com/search?q=0.05/30000*1.0025
>
>
--------------080108000605050608040308
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
Sam Mason wrote:
<blockquote
cite="mid:20080514192719.GJ1657@[EMAIL PROTECTED]
"
type="cite">
<pre wrap="">On Wed, May 14, 2008 at 02:08:47PM -0400, Justin wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Sam Mason wrote:
</pre>
<blockquote type="cite">
<pre wrap="">What does foxpro use for storing numbers? or is it just
that you never
pushed it hard enough for the abstractions to show through.
</pre>
</blockquote>
<pre wrap="">I know i pushed it. Foxpro for the most has only 4
basic data types
Numeric (similar to Posgresql numeric), Boolean, Date, Text aka
(string) The foxpro tables sup****ted far more data types but when every
it was dumped to variable it acted like one of the 4.
</pre>
</blockquote>
<pre wrap=""><!---->
I really meant how much did you check the results, or did you accept
that they were correct?
</pre>
<blockquote type="cite">
<pre wrap="">Foxpro did not suffer floating point math errors. I
normally used 8 to
10 points precision. Foxpro was limited to 15 points of precision
period. No more and no less, once you hit that was it.
</pre>
</blockquote>
<pre wrap=""><!---->
15 places seems very similar to what a 64bit IEEE floating point number
will give you, i.e. a double in C/C++.
</pre>
<blockquote type="cite">
<pre wrap="">My problem is we calculate resistance of parts in a
Foxpro app that we
want to move because we want to bring all the custom apps into one
framework and single database.
Take this calculation (0.05/30000* 1.0025) which is used to calculate
parts resistance and Tolerance. (its Ohms Law) The value returned from
C++ = .0000016708 which is wrong
it should be .00000167418. We just shrank the tolerance on the part we
make
</pre>
</blockquote>
<pre wrap=""><!---->
Why are you so sure about the FoxPro result? I've just checked a few
calculators and get results consistent with your C++ version.
Justin C: 0.0000016708
J FoxPro: 0.00000167418
</pre>
</blockquote>
this 167418 came of my ti 89 calculator, going back i noticed that i
accident rounded it to .00000167 which gives a bad result.<br>
<br>
So what i typed in after that point is wrong. OOPS. <br>
<br>
But loosing the 3 will put out of the tolerance sense its the last
significant digit needed thats displayed on the measurement devices.
So if the 3 becomes a 4 your out of tolerance.<br>
<blockquote
cite="mid:20080514192719.GJ1657@[EMAIL PROTECTED]
"
type="cite">
<pre wrap=""> My C: 0.000001670833
bc[1]: 0.0000016708333333333333333333333333333332
PG[2]: 0.0000016708333333333333336675
</pre>
</blockquote>
<blockquote
cite="mid:20080514192719.GJ1657@[EMAIL PROTECTED]
"
type="cite">
<pre wrap=""> Google[3]: 0.00000167083333 (actually gives 1.67083333e-6)
</pre>
</blockquote>
Foxpro Agrees with what you have 0.00000167083333
<br>
the code looks like this<br>
<br>
SET DECIMALS TO 15<br>
? ((0.05/30000)* 1.0025)<br>
<br>
When i wrote the application like 10 years ago I spent allot time
making sure the numbers where correct even doing some by hand. <br>
<br>
If I gotten it wrong there's allot National labs, Universities, Big
companies that are generating allot bad results in their QC
departments. <br>
<br>
Chced<br>
<blockquote
cite="mid:20080514192719.GJ1657@[EMAIL PROTECTED]
"
type="cite">
<pre wrap="">
Both bc and Postgres use their own code (i.e. not the CPU's FPU) to do
the math, and as they all agree I'm thinking FoxPro is incorrect!</pre>
</blockquote>
<br>
Here is the foxpro Do***entation <br>
<table cellpadding="5" cellspacing="2" height="94" width="613">
<tbody>
<tr>
<td>
<p>Integers or decimal numbers</p>
<p>For example, the quantity of items ordered</p>
</td>
<td>
<p>8 bytes in memory; 1 to 20 bytes in table</p>
</td>
<td>
<p>- .9999999999E+19 to .9999999999E+20</p>
</td>
</tr>
</tbody>
</table>
<br>
<blockquote
cite="mid:20080514192719.GJ1657@[EMAIL PROTECTED]
"
type="cite">
<pre wrap=""> Next
I tried doing it accurately (in Haskell if it makes any difference) and
get an answer of 401/240000000 out, which would agree with everything
but FoxPro. If I calculate the ratio back out for FoxPro I get
401/239520242 which is a little way out.
</pre>
</blockquote>
<blockquote
cite="mid:20080514192719.GJ1657@[EMAIL PROTECTED]
"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">The Do***entation from MS says 15 points of precision but
the result say
otherwise.
</pre>
</blockquote>
<pre wrap=""><!---->
The docs for what? FoxPro or their C compiler?
</pre>
</blockquote>
From the MS Do***ent here is Copied text<br>
<br>
<p><b>Microsoft Specific —></b></p>
<p>The double type contains 64 bits: 1 for sign, 11 for the exponent,
and 52 for the mantissa. Its range is +/–1.7E308 with at least 15
digits of precision. </p>
<p><b>END Microsoft Specific</b></p>
<!--Footer Start--><br>
<blockquote
cite="mid:20080514192719.GJ1657@[EMAIL PROTECTED]
"
type="cite">
<pre wrap="">
If you mean FoxPro, I think this is another case of MS screwing up.
</pre>
</blockquote>
Foxpro normally did not suffer form other MS screw ups. <br>
<blockquote
cite="mid:20080514192719.GJ1657@[EMAIL PROTECTED]
"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">I'm glad You and others are taking the time to explain to
me
the odd results before i get into redoing that application.
</pre>
</blockquote>
<pre wrap=""><!---->
Welcome to the PG community, lots of people to get interested in lots of
things!
</pre>
<blockquote type="cite">
<pre wrap="">Why oh Why did MS kill Foxpro. :'( I understood it,
knew its quirks
and it worked very well with Postgresql
</pre>
</blockquote>
<pre wrap=""><!---->
Are you sure you want to stay with it if its answers are wrong?
Sam
[1] <a class="moz-txt-link-freetext"
href="http://www.gnu.org/software/bc/manual/html_mono/bc.html">http://www.gnu.org/software/bc/manual/html_mono/bc.html</a>
[2] <a class="moz-txt-link-freetext"
href="http://doxygen.postgresql.org/backend_2utils_2adt_2numeric_8c-source.html">http://doxygen.postgresql.org/backend_2utils_2adt_2numeric_8c-source.html</a>
[3] <a class="moz-txt-link-freetext"
href="http://www.google.com/search?q=0.05/30000*1.0025">http://www.google.com/search?q=0.05/30000*1.0025</a>
</pre>
</blockquote>
</body>
</html>
--------------080108000605050608040308--
|
