Val() Statement Not Acting As Expected?

[(PeteCresswell)]

Can anybody offer up a clue?

--------------------------------
?Val(!SumOfAmount & "")
222

?(Val(Me.txtParValue & "") * Val(Me.txtShares & ""))
222

?Val(!SumOfAmount & "") <> (Val(Me.txtParValue & "") * Val(Me.txtShares & ""))
True

 

[aaron.kempf]

it's because .MDB has no .VALue

-Aaron

 

[Dirk Goldgar]

Can anybody offer up a clue?

--------------------------------
?Val(!SumOfAmount & "")
222

?(Val(Me.txtParValue & "") * Val(Me.txtShares & ""))
222

?Val(!SumOfAmount & "") <> (Val(Me.txtParValue & "") *
Val(Me.txtShares & "")) True
--------------------------------

I'd assume it's a result of floating-point imprecision. Consider:

?221.9999999999999
222
?222.0000000000001
222
?(221.9999999999999 = 222.0000000000001)
False

 

[Vladimír Cvajniga]

Pls, check out operators priorities.
Last expression seems to act as follows ;-) :
Val(!SumOfAmount & "") <> ((Val(Me.txtParValue & "") * Val(Me.txtShares &
"")))

HTH

Vladimír

 

[(PeteCresswell)]

Per Dirk Goldgar:

I'd assume it's a result of floating-point imprecision. Consider:

?221.9999999999999
222
?222.0000000000001
222
?(221.9999999999999 = 222.0000000000001)
False

That's kind of what I was thinking.

If that's true, then I'd guess that most applications that do comparisons should
have some sort of Round() function coded and only compare the results of that
function.

 

[Dirk Goldgar]

Per Dirk Goldgar:

That's kind of what I was thinking.

If that's true, then I'd guess that most applications that do
comparisons should have some sort of Round() function coded and only
compare the results of that function.

It depends what you're comparing, of course, but when comparing
floating-point numbers, you do have to allow for the imprecision. What
people usually do is subtract one value from the other and see if the
absolute value of the difference is greater than some value "epsilon".
If so, the values are considered equal; if not, they're the same for
all practical purposes. It's up to you to pick a suitable epsilon.

If you're dealing with numbers that represent currency, it's best to use
the Currency data type, rather than any floating-point type, and perform
rounding when you multiply or divide so as to ensure proper results. Be
aware that the built-in Round function uses "banker's rounding" to
minimize rounding bias. That may not always give you the result you
expect, if you're used to always rounding a terminal digit of 5 upward.

 

[Jamie Collins]

I'd assume it's a result of floating-point imprecision.

Correct, IMO. The Val() function casts the result as Double (Float),
even in Jet 4.0 SQL code, where DECIMAL has a higher precedence (within
range) than IEEEDOUBLE e.g.

SELECT TYPENAME(CDBL(1.8) / 1.2)

returns Decimal. Even so, the VAL() function will always cast as
IEEEDOUBLE e.g.

SELECT TYPENAME(VAL(CDBL(1.8) / 1.2))

returns 'Double'.

Jamie.

--