Help - Have I overlooked something this basic for years?

[Carlo Pagani]

PB9 and 10 give the same result.

Are you not allowed create an expression that gets evaluated with an IF statement with decimal variables?

Code Select Expand

#Dim ALL

function PbMain()

  DIM Test(3) as STATIC CUX
 
  Test(1) = 22210.53
  Test(2) = 22210.53 - 61.14
  Test(3) = 61.14


  If ((Test(2)+Test(3))<>Test(1)) then 'Surely this is equal and should not get to next line
    MsgBox"WFT "+Format$(Test(2)+Test(3))+"<>"+Format$(Test(1))
  end if
 
  Test(0) = Test(2) + Test(3)
 
  If Test(0) = Test(1) then
    msgbox "Why does this work and not the one above?"
  end if
end function

 

[Theo Gottwald]

Can you explain the problem?
I do not understand whats the point here ...

[Carlo Pagani]

I get the WTF message box but i dont expect that because I expected the  <>  to fail since Test(2)+Test(3) is indeed equal to Test(1)

[Aslan Babakhanov]

Working correctly with round (strange...)

Code Select Expand

  IF ROUND(Test(2)+Test(3), 2) <> ROUND(Test(1),2) THEN 'Surely this is equal and should not get to next line
    MSGBOX"WFT "+FORMAT$(Test(2)+Test(3))+"<>"+FORMAT$(Test(1))
  END IF 

Also, working correctly with CCUX

Code Select Expand


  IF CCUX(Test(2)+Test(3)) <> CCUX(Test(1)) THEN 'Surely this is equal and should not get to next line
    MSGBOX"WFT "+FORMAT$(Test(2)+Test(3))+"<>"+FORMAT$(Test(1))
  END IF   


[John Spikowski]

I gave your example a try with ScriptBasic and it works as you expected.

Code Select Expand


Test[1] = 22210.53
Test[2] = 22210.53 - 61.14
Test[3] = 61.14


If ((Test[2]+Test[3])<>Test[1]) then
    print "WFT "&Test[2]+Test[3]&"<>"&Test[1],"\n"
end if
 
Test[0] = Test[2] + Test[3]
 
If Test[0] = Test[1] then
    print "Why does this work and not the one above?\n"
end if


jrs@laptop:~/sb/sb22/test$ scriba deccmp.sb
Why does this work and not the one above?
jrs@laptop:~/sb/sb22/test$

I guess compares in PB are only an approximation when using fractional values. That's an eye opener.

[John Spikowski]

I expanded on your example to test precision comparing with an IF.

Code Select Expand


Test[1] = PI
Test[2] = PI - .123
Test[3] = .123


If Test[2] + Test[3] <> Test[1] then
    print "WFT " & Test[2] + Test[3] & "<>" & Test[1],"\n"
end if
 
Test[0] = Test[2] + Test[3]
 
If Test[0] = Test[1] then
    print "Why does this work and not the one above?\n"
end if


jrs@laptop:~/sb/sb22/test$ scriba ifpi-123.sb
Why does this work and not the one above?
jrs@laptop:~/sb/sb22/test$

The record for memorizing digits of PI, certified by Guinness World Records, is 67,890 digits, recited in China by Lu Chao in 24 hours and 4 minutes on 20 November 2005.

[José Roca]

> Also, working correctly with CCUX

This is the way to do it; otherwise, the expression will be evaluated using extended precission floating-point instead of extended precission currency.

[John Spikowski]

It can be difficult to find the right balance between performance and making a profit on the end result. I remember when getting every last CPU cycle out of your code made the difference on a 386 PC. With the speed of today's processors does the extra code, restraints, a more skilled programmer and larger budget justify the difference in what the customer sees if he doesn't blink?

[Carlo Pagani]

Hmmm - I always thought
"Internally, Currency and Extended-currency numbers are stored as Quad-integers with an implied decimal point (at 4 places for Currency,
and at 2 places for Extended-currency).  This approach ensures that all of the digits of the variables can be represented exactly."

Bypassed the CCUX requirement. Oh well - Old dog has to learn new trix

[José Roca]

The values are stored correctly in the variables, but when evaluating the expression, the compiler has to create temporary values and PB does it using the FPU. Using CCUX you make sure that the temporary result is evaluated as extended currency instead of extended floating point.

[John Spikowski]

Please excuse my ignorance but are you saying that a copy of a stored floating point variable is not the same as the original? Is there a downside to using floating point values you would normally use in a graphics application and converting them to extended currency values? Is it better to define floating point variables as extended currency at the start if you have any plans on comparing their value? Has it always been this way in PB?

[Aslan Babakhanov]

Hi John,

Back in 90'th, I've made my own library to use currency like variable with QB4. I used LONG type variable and pseudo 2 digits after decimal point.
It was a mix of asm and basic code and I also faced with such bottlenecks.
No matter, what's better to define: floating point var's first or currency -- anyway, you have to convert them into FP variable in order to make a proper comparison.
Otherwise, you have to make a numerous micro-subroutines to compare pseudo variables types like currency.

Some facts from Delphi XE world on currency types:
http://synopse.info/forum/viewtopic.php?id=500

[John Spikowski]

Just another example of PowerBASIC as a high level language coming up short trying to be something it's not. IMHO

Bad workers always blame his tools. In your case it's even worse, because you don't even use PB. You're just looking for the slightest ocassion to bash it.  Really tedious.

[José Roca]

> Please excuse my ignorance but are you saying that a copy of a stored floating point variable is not the same as the original?

No, I'm not saying that at all. (Test[2]+Test[3]) is not a copy of any stored variable.

> Is it better to define floating point variables as extended currency at the start if you have any plans on comparing their value? Has it always been this way in PB?

What you have to do is to compare apples with apples. If the variables that you are going to compare have different precision, you have to cast them to the same precision. The CXXX functions exist for a reason: to use them when needed.

Ignoring this basic principle is your fault. C++ programmers are doing casting all the time, and nobody blames the compiler.

[José Roca]

> Just another example of PowerBASIC as a high level language coming up short trying to be something it's not. IMHO

Bad workers always blame his tools. In your case it's even worse, because you don't even use PB. You're just looking for the slightest ocassion to bash it.  Really tedious.