> On Wed, May 14, 2008 at 02:08:47PM -0400, Justin wrote:
>> 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.
>
> 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
> 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 thinking FoxPro is 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
> but FoxPro. If I calculate the ratio back out for FoxPro I get
> 401/239520242 which is a little way out.

I'll add my Casio scientific calculator to the list, which also gives
the non-FoxPro result.

We can also write this "exactly" as:

(0.05 * 1.0025 / 3) * 10^-5
= (5 * 10025 / 3) * 10^-11
= (50,125 / 3) * 0.00000000001
= (16,708 + 1/3) * 0.00000000001

which you can verify in your head, so the correct answer is clear.

Is it possible that the FoxPro calculation isn't what you describe?
If you use the tolerance 1.0045, a single digit off, then you get
0.00000167417, very close to your result.

-- Andy


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

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 supported 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 Documentation

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 Documentation from MS says 15 points of precision but the result say
>> otherwise.
>>
>
> The docs for what? FoxPro or their C compiler?
>
From the MS Document 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/backen...8c-source.html
> [3] http://www.google.com/search?q=0.05/30000*1.0025
>
>

> Sam Mason wrote:
>>
>> If you mean FoxPro, I think this is another case of MS screwing up.
On May 14, 2008, at 4:08 PM, Justin wrote:
> Foxpro normally did not suffer form other MS screw ups.
>>
That's because MS bought it from a third-party developer.
(And so, of course, they couldn't allow that to stand, and had to
develop their own product, Access. What a hunk of junk that was for
the first couple of years. :-(
-- Andy

Andy Anderson wrote:
>> Sam Mason wrote:
>>> If you mean FoxPro, I think this is another case of MS screwing up.
> On May 14, 2008, at 4:08 PM, Justin wrote:
>> Foxpro normally did not suffer form other MS screw ups.
> That's because MS bought it from a third-party developer.
> (And so, of course, they couldn't allow that to stand, and had to develop their own product, Access. What a hunk of junk that was for the first couple of years. :-(
> -- Andy
>
I loved foxpro its the best Xbase language. MS killed because they did
not want to move it to 64 bit. Which would have made all the
limitations that it suffered from due to 32 integer go away.

What annoys me everyone told me how crappy xbase languages were/are but
today most of the popular programming languages are now just getting
tools that we Xbases developers have had forever.

Don't get me started on the Access Jet Engine blue or red. They both
suck and prone to failure. I still have a hard time believing MS uses
Jet Engine Blue for Exchange and AD. I have spent allot time
recovering from corrupt databases. And the way MS shoe horned Exchange
into that flawed database design is amazing.

On May 14, 3:27 pm, s...@samason.me.uk (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 supported 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 Documentation 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"

Anybody tried to reckon this math
the way we used to do it with a Slide-Rule ???
(In VFP of course)

glene77is

glene77is wrote:
> On May 14, 3:27 pm, s...@samason.me.uk (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 supported 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 Documentation 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
documentation 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
>