DATETIME() vs INT() 1

[FoxAll]

Hi All of you,

I have strange problem in a very huge program.
I reproduce this problem in a small simple program exemple to be able to post it.

The question is, if c=60 then why INT(c/60) is equal to zero ?

I can't answer this one?

Thanks for your reply.

******************
* Program exemple
******************

CLEAR

a=datetime()
?"a=", a

b=a-60
?"b=", b

c=a-b
?"c=", c, type("c")

d=60
?"d=", d, type("d")


IF c=d
?"Yes 'c' and 'd' is equal", c, d
?
ELSE
?"No it's not!"
?
ENDIF


?"c/60=", c/60
?"d/60=", d/60

?"int(c/60)=", int(c/60)
?"int(d/60)=", int(d/60)

return
************

 

[JRB-Bldr]

Well when I followed your code above

Both C & D end up with the same values (60) and the same field type ('N')

And I get 1.0 for both n/60 expressions
and 1 for both the INT() expressions.

So if you are getting something else it must be due to something else.

Good Luck

 

[FoxAll]

Hi,

you get 1 on the line "INT(c/60)" ???

I try this on many computers and with all my friends with the same strange result.

Let me asking you the version of Foxpro you use and your OS, do you have any service pack installed?

Thanks

 

[Mike Lewis]

Hi FoxAll,

Looks weird, doesn't it. But in fact it's a simple rounding issue.

The point is that c is a floating point number. That means it's subject to minor round-off errors. When I ran your code, it was showing c as 1.00, which is what you would expect. But when I ran it again with DECIMALS set to 10, I could see its value as 0.9999999403. That's less than 1, so the INT() is zero.

The lesson is always to round floating point numbers to a reasonable number of decimal places.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[FoxAll]

What a lesson!!

Thanks Mike.

 

[mmerlinn]

[ ]

I don't see anything strange at all. You are getting the correct results within the limitations of the computers you are using.

For more information on this subject see these threads: thread184-1290417, thread184-1278669, thread184-531793, & thread182-1327346.




mmerlinn

http://mmerlinn.com

"We've found by experience that people who are careless and sloppy writers are usually also careless and sloppy at thinking and coding. Answering questions for careless and sloppy thinkers is not rewarding." - Eric Steven Raymond

 

[Mike Lewis]

Mmerlinn,

Excuse me, but it's not a limitation of the computer. It's just the way floating-point numbers work.

In VFP, floating-point numbers are held internally in 64 bits. They have a range of plus or minus 1.8 x 10^308. But you can't store every possible number in that range in 64 bits. There must inevitably be gaps -- that is, numbers that cannot be stored. That's why you get small round-off errors.

Because of this, you might think you're adding 1 and 1, but you get, say, 1.99999567, or perhaps 2.0000345. This can happen if the numbers in question are the result of divisions, as is the case in FoxAll's example.

It's not a bug, it's just the way things work. And it's certainly not the fault of the computer. If you used the most powerful computer available, you'd still see the same behaviour.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[FoxAll]

mmerlinn,

It's look strange to me because ...
if I show you this :


?int(c)
60

?int(c/60)
0


You find this clear? and normal?

 

[cricket]

I tried this and could not replicate your results using VFP8
c=60
?INT(c) result 60
?INT(c/60) results in 1

The value assigned to c is the key to your problem. Presumably it is the result of a complex calculation rather than a simple assignment as in my example. The INT(c/60) calculation falls through Mike Lewis's gap as explained above

 

[dbMark]

As I recall from years ago, the numeric data type is calculated going out to 18 digits, but comparisons are only done to 15 digits. That allows for 2-3 digits worth of accumulating minicule (invisible) errors before it would affect calculation results.

By the way, do not confuse the behavior of numeric memory variables with numeric fields in tables. As long as your numbers being written there are within the field's size, they are stored as that format displays (though rounding may still occur) and any miniscule computational discrepancies aren't saved.

INT(), ROUND(), FLOOR() and CEILING all deal with rounding goals, but be aware of how they work with positive numbers versus negative numbers or you could get unanticipated results.

 

[NasibKalsi]

To support Mike's idea run the following :

CLEAR
a=datetime()
?"a=", a

b=a-60.00000000
?"b=", b

c=a-b+0.00000000
?"c=", c, type("c")

d=60.00000000
?"d=", d, type("d")


IF c=d
    ?"Yes 'c' and 'd' is equal", c, d
    ?
ELSE
    ?"No it's not!", c, d  
    ?
ENDIF


?"c/60=", c/60
?"d/60=", d/60

?"int((C/60)=", int(c/60)    
?"int(d/60)=", int(d/60)

 

[mmerlinn]

[ ]

Mike

You are correct, it is NOT a limitation of the computer as ALL computers behave the same way. However, it IS a limitation of the chips in the computer as noted above - all chips do BINARY calculations - no one yet has come up with a chip with a 5-way switch so that chips could do DECIMAL calculations. As long as computers use BINARY chips you will have this behavior. So in that respect, using chips with limitations causes those same limitations to be transfered to the computer.

Floating point calculations are the WORK-AROUND for this chip limitation, not vice versa as your post implies. And, yes, as long as only BINARY chips are used, floating point calculations will ALWAYS work as designed giving incorrect results at the extremes of their respective ranges.



mmerlinn

http://mmerlinn.com

"We've found by experience that people who are careless and sloppy writers are usually also careless and sloppy at thinking and coding. Answering questions for careless and sloppy thinkers is not rewarding." - Eric Steven Raymond

 

[Mike Lewis]

MMerlinn,

Sorry, but I can't agree.

Really, the issue's got nothing to do with computers. Any time you try to store a large range of numbers, with a high degree of precision, in a relatively small number of bits, you must inevitably get gaps in the sequence.

In the floating point system we are talking about, we are trying to store numbers in the range +/- 1.8 * 10^308, to 14(?) decimal places, in 64 bits. The only way you can do that is to miss out some of the numbers. It's those gaps (typically in the 9th or 10th decimal place) that cause the round-off errors.

The best processors in the world won't change that.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk