This is a multi-part message in MIME format.
--------------020904030503040302000306
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
glene77is wrote:
> On May 14, 3:27 pm, s...@[EMAIL PROTECTED]
(Sam Mason) wrote:
>
>> On Wed, May 14, 2008 at 02:08:47PM -0400, Justin wrote:
>>
>>> Sam Mason wrote:
>>>
>>>> What doesfoxprouse 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) Thefoxprotables 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?
>>
>>
>>> Foxprodid not suffer floating point math errors. I normally used 8 to
>>> 10 points precision. Foxprowas 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 aFoxproapp 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 theFoxProresult? I've just checked a few
>> calculators and get results consistent with your C++ version.
>>
>> Justin C: 0.0000016708
>> JFoxPro: 0.00000167418
>> My C: 0.000001670833
>> bc[1]: 0.0000016708333333333333333333333333333332
>> PG[2]: 0.0000016708333333333333336675
>> Google[3]: 0.00000167083333 (actually gives 1.67083333e-6)
>>
>> 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 thinkingFoxProis incorrect! 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
>> butFoxPro. If I calculate the ratio back out forFoxProI 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?FoxProor their C compiler?
>>
>> If you meanFoxPro, I think this is another case of MS screwing up.
>>
>>
>>> 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 killFoxpro. :'( 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
>>
>
>
*********************************************************************************
> This is fun, at 0400 AM. I enjoy reading Experts having serious fun!
>
> VFP 6.0, using my defaults
> ? (0.05/30000* 1.00250000000000000)
> displays "0l.000001670833333000"
>
> SET DECIMALS TO 15
> ? ((0.05/30000)* 1.0025)
> displays "0.000001670833333"
>
> and a frivolous example:
> SET DECIMALS TO 18
> ? ((0.050000/30000.00000000)* 1.0025000000000000)
> displays "0.000001670833333000"
>
Foxpro always stops at 15 decimals points, Even though some of the
do***entation says 20 and 22 points of precision depending on the
version. I have versions 5 to 9
> Anybody tried to reckon this math
> the way we used to do it with a Slide-Rule ???
> (In VFP of course)
>
A slide what??. I have never touched one or seen a slide rule in real
life, just pretty pictures :-)
> glene77is
>
--------------020904030503040302000306
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">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
glene77is wrote:
<blockquote
cite="mid:50a48f05-173a-42c6-88b8-00d6aadda1c4@[EMAIL PROTECTED]
"
type="cite">
<pre wrap="">On May 14, 3:27 pm, <a class="moz-txt-link-abbreviated"
href="mailto:s...@[EMAIL PROTECTED]
">s...@[EMAIL PROTECTED]
> (Sam Mason) wrote:
</pre>
<blockquote 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 doesfoxprouse for storing numbers? or is it just
that you never
pushed it hard enough for the abstractions to show through.
</pre>
</blockquote>
</blockquote>
<blockquote type="cite">
<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) Thefoxprotables 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="">Foxprodid not suffer floating point math errors. I
normally used 8 to
10 points precision. Foxprowas 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
aFoxproapp that we
want to move because we want to bring all the custom apps into one
framework and single database.
</pre>
</blockquote>
<blockquote type="cite">
<pre wrap="">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 theFoxProresult? I've just
checked a few
calculators and get results consistent with your C++ version.
Justin C: 0.0000016708
JFoxPro: 0.00000167418
My C: 0.000001670833
bc[1]: 0.0000016708333333333333333333333333333332
PG[2]: 0.0000016708333333333333336675
Google[3]: 0.00000167083333 (actually gives 1.67083333e-6)
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 thinkingFoxProis incorrect! 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
butFoxPro. If I calculate the ratio back out forFoxProI get
401/239520242 which is a little way out.
</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?FoxProor their C compiler?
If you meanFoxPro, I think this is another case of MS screwing up.
</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 killFoxpro. :'( 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
</pre>
</blockquote>
<pre wrap=""><!---->
*********************************************************************************
This is fun, at 0400 AM. I enjoy reading Experts having serious fun!
VFP 6.0, using my defaults
? (0.05/30000* 1.00250000000000000)
displays "0l.000001670833333000"
SET DECIMALS TO 15
? ((0.05/30000)* 1.0025)
displays "0.000001670833333"
and a frivolous example:
SET DECIMALS TO 18
? ((0.050000/30000.00000000)* 1.0025000000000000)
displays "0.000001670833333000"
</pre>
</blockquote>
Foxpro always stops at 15 decimals points, Even though some of the
do***entation says 20 and 22 points of precision depending on the
version. I have versions 5 to 9<br>
<blockquote
cite="mid:50a48f05-173a-42c6-88b8-00d6aadda1c4@[EMAIL PROTECTED]
"
type="cite">
<pre wrap="">
Anybody tried to reckon this math
the way we used to do it with a Slide-Rule ???
(In VFP of course)
</pre>
</blockquote>
A slide what??. I have never touched one or seen a slide rule in
real
life, just pretty pictures :-) <br>
<blockquote
cite="mid:50a48f05-173a-42c6-88b8-00d6aadda1c4@[EMAIL PROTECTED]
"
type="cite">
<pre wrap="">
glene77is
</pre>
</blockquote>
<br>
<br>
<br>
<br>
</body>
</html>
--------------020904030503040302000306--
|
