PB9 and 10 give the same result.
Are you not allowed create an expression that gets evaluated with an IF statement with decimal variables?
#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
Can you explain the problem?
I do not understand whats the point here ...
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)
Working correctly with round (strange...)
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
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
I gave your example a try with ScriptBasic and it works as you expected.
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.
I expanded on your example to test precision comparing with an
IF.
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$
Quote from: piphilologyThe 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.
> 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.
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?
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 :-[
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.
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?
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
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.
> 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.
> 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.
QuoteIn 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.
I show a like example in SB that works and you say all I care about is bashing PB. That's easy for you to say seeing the HUGE investment you have in PB. I think your job of covering Bob's ass is over. There is only so much you can do with include files.
Your example is not equivalent. I guess that SB is using doubles and doing the math using double precission, so there is not a mix of different precisions. Does SB support extended floating point? Does it support currency and extended currency?
QuoteYour example is not equivalent.
Equivalent meaning not as fast or does PB have a new way of doing addition and subtraction?
These are better questions to ask Charles of OxygenBasic (apples vs apples) as SB is an interpreter and takes care of all the low level stuff giving the user a traditional BASIC experience.
ScriptBasic numbers documentation (http://www.scriptbasic.org/docs/ug/ug_9.3.html)
Quote from: John Spikowski on August 10, 2013, 09:34:50 PM
QuoteYour example is not equivalent.
Equivalent meaning not as fast or does PB have a new way of doing addition and subtraction?
These are better questions to ask Charles of OxygenBasic (apples vs apples) as SB is an interpreter and takes care of all the low level stuff giving the user a traditional BASIC experience.
ScriptBasic numbers documentation (http://www.scriptbasic.org/docs/ug/ug_9.3.html)
Not equivalent because you did not define your Variables in SB as Extended Currency. (Can You?)
See PB sample in post #1
DIM Test(3) AS STATIC CUX
You ask Charles.
You used ScriptBasic to prove a point.
You concluded that SB was working and PB was not.
Your
Scriptbasic sample does not use CUX or equivalent.
Therefore not same test. Probably using Double based on your SB doc link.
If you use DIM Test(3) AS STATIC DOUBLE or DIM Test(3) AS STATIC EXT it also works in PB as expected.as far as I'm concern Aslan's post an Jose's explanation made very clear to me.
The fact that a compiler does not interpret our instructions the way we thought it should, does not make the compiler wrong, it more than likely makes our interpretation of what it should be doing wrong.
Quote from: John Spikowski on August 10, 2013, 08:18:55 PM
Just another example of PowerBASIC as a high level language coming up short trying to be something it's not. IMHO
If your conclusion is based on this thread, and your Flawed comparison. Then your conclusion is wrong.
QuoteNot equivalent because you did not define your Variables in SB as Extended Currency.
ScriptBasic doesn't require the user to DIM or DECLARE the variables it uses. The language doesn't have type definitions only the data has type significance and is evaluated at the time it's being used.
Example:a = 1
b = "2"
PRINT a + b,"\n"
PRINT a & b,"\n"
Results3
12
If I have to declare and dimension everything, I might as well use C.
We should not start to compare Interpreters with real compilers.
Script Basic is an interpreter and as such has its advantages and disadvantages.
At the same time a compiler has otehr goals.
If you compile something your target is maximum speed, the result is possibly a datatype conversion to CPU internal datatypa - what we see here. If i write a script language i just stay within the highes precision, because nobody will expect best performance from an interpreting language. Just that it works in any way. Therefore we should not compare two diffrent kind of things.
Please keep the discussions on interpreting languages in the sub forum for that or else i need to make a cleanup of the postings.
Because we have already solved the problem here - Jose explained it - and there is no need to mix oil into the water here.
People may have to read the sollution for this prioblem, it should be easy to find. Academic discussions should be at other places.
@John: Open another post in the Scriptbasic forum IF you see a there a real topic/advantage.
Quote
If I have to declare and dimension everything, I might as well use C.
John, with PBCC you do not have to declare and dimension your variables and strings but only Arrays.
Just use DEFLNG A-Z and you can use anything you want anywhere you like.
A good point. And in earlier times, we had interpreters because a compiler needed 1 second per lin of code.
As PB "compiles with no significant delay", a script languages has ti have some special optimizations to make sense.
How about the Basic from Eros ....what was the name? Is it still developed?
I am sure he will also add optimizations that it can be used for special purposes.
>Just use DEFLNG A-Z and you can use anything you want anywhere you like.
Ok, where is the tree to hang people?
>:(
QuoteOk, where is the tree to hang people?
You are welcome to the stake I'm being roasted on when the friends of the forum are done with me if that helps.
From my standpoint, there are still places where script languages make sense.
We have now quite a lot of them around.
On the other side - as said- i do not see their use primarily for developing applications.
I also personally do not like JAVA Apps so much.
I see their use in daily automation-scripting. Compilers ... make applications.
Of course we can twist and move usages here around and find reasons.
If i develop a script language, it may make sense that at the same time, i show people what its good for.
For example in YouTube. How about you John?
How about a good video, that introduces people to your new born Scripting language?