Jump to content

DECIMAL PLACES V3 / V3 Beta


Recommended Posts

I was using actual beta and recompiled some of my Autoit programs with the new W3.2 version.

I was surprised to see that my displayed numbers had an incredible number of decimals.....

I do not want to stringformat all my numbers to have the correct number of decimals.

So for the moment I will go on with the current beta.

But may-be there is a simple way to correct this problem.

Regards,

AL,

Link to comment
Share on other sites

I was using actual beta and recompiled some of my Autoit programs with the new W3.2 version.

I was surprised to see that my displayed numbers had an incredible number of decimals.....

I do not want to stringformat all my numbers to have the correct number of decimals.

So for the moment I will go on with the current beta.

But may-be there is a simple way to correct this problem.

Regards,

AL,

Given that you didn't state what version of beta you were using, I can only assume that you are using one of the older releases (in the 120s) which is severely bugged with regards to floating point display. The behavior you see in 3.2 is "correct". It's the same behavior that was in AutoIt since the dawn of time. There is no easy fix for the problem as evidenced by the fact that we quickly reverted the changes. If you are using a version of AutoIt which negates the need for StringFormat(), you are using a version that is significantly flawed.

Edit: Disclaimer: I'm making a lot of assumptions in my response. You didn't provide any useful information, quite honestly. You didn't state which version of the beta you are running nor did you show a sample script with both the output you receive and the output you expect. So, theoretically, there may be an issue with the display of floating point numbers in 3.2 but as of right now I'm merely speculating that 3.2 is right and your expectations are wrong.

Edited by Valik
Link to comment
Share on other sites

Given that you didn't state what version of beta you were using, I can only assume that you are using one of the older releases (in the 120s) which is severely bugged with regards to floating point display. The behavior you see in 3.2 is "correct". It's the same behavior that was in AutoIt since the dawn of time. There is no easy fix for the problem as evidenced by the fact that we quickly reverted the changes. If you are using a version of AutoIt which negates the need for StringFormat(), you are using a version that is significantly flawed.

Edit: Disclaimer: I'm making a lot of assumptions in my response. You didn't provide any useful information, quite honestly. You didn't state which version of the beta you are running nor did you show a sample script with both the output you receive and the output you expect. So, theoretically, there may be an issue with the display of floating point numbers in 3.2 but as of right now I'm merely speculating that 3.2 is right and your expectations are wrong.

I am sorry I was not precise enough. I am using V3.1.1.123 (beta)

I download V3.2.0.1 and recompiled my programs and I noticed my numbers had a lot of decimals.

I was doing calculations like these :

$profit=GUICtrlRead($close)-(GUICtrlRead($iprof)*$multiply)

$stop2=GUICtrlRead($close)+(GUICtrlRead($istop)*$multiply)

GUICtrlSetData($iprof2,$profit)

GUICtrlSetData($istop2,$stop2)

where $multiply can be from : 1 to 0.0001

and I displayed numbers like : 1.2800000000001245

to fix the problem I had 2 choices :

1 - add :

GUICtrlSetData($iprof2,stringformat("%.4f",$profit))

GUICtrlSetData($istop2,stringformat("%.4f",$stop2))

or

GUICtrlSetData($iprof2,stringformat("%.2f",$profit))

GUICtrlSetData($istop2,stringformat("%.2f",$stop2))

depending on the number of decimals I wanted

2 - Return to V3.1.1.123 (beta) which I did and have the correct decimal numbers I had since several months.

Thanks for your help and sorry for my lack of precisions.

Regards,

AL,

Link to comment
Share on other sites

Right, like I said, during that time period, I broke some stuff trying to fix the very "issue" you describe. The changes I tried ended up doing more harm than good. The behavior that you see in 3.2.0.1 is the correct behavior. The behavior you see in 3.1.1.123 was an attempt to make things more user friendly - it didn't work, it broke stuff. You're going to have to use StringFormat() and 3.2.0.1. I do not recommend using 3.1.1.123. As I've mentioned several times, floating point representation was broken during that time. The behavior of the current version is the behavior we are going to be stuck with for awhile.

Link to comment
Share on other sites

$profit=GUICtrlRead($close)-(GUICtrlRead($iprof)*$multiply)

Can you send all the fractional profits my way?

Seriously, you should account for all the decimal places when doing financial calculations as they tend to accumulate, and not always in your favor!

Link to comment
Share on other sites

Actually, that's not even the worst part. The worst part is storing data in the display. I can alter the data to say anything I want just by altering the display of the data (From a 3rd-party program). Never, ever store the data in the display, always display the stored data. Keep your data internally in it's full floating point representation and only display it using StringFormat(). That will reduce errors and prevent outside tampering.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...