Support Board
Date/Time: Sun, 29 Dec 2024 15:50:35 +0000
Spreadsheet-Rare bug in Greater than or Equal?
View Count: 1152
| [2016-05-13 18:32:27] |
| User791263 - Posts: 151 |
|
As in prior recent issue post,I've been doing intensive backtest audit for months, often slow motion, and rarely see what appear 3 or 4 rare bugs. (worked with SC a year,& others before that) I've studied all your back-testing, management, etc documentation. This is not just valid "ignored" orders, etc. My settings work great 99.9% of the time: Fill Blanks with Last Value Reset Condition on New Bar, etc. (See last post for other settings) One bug I did not report was a pending exit from 1 contract long, position +1 showing, and a -1 working exit order that would not fill for several bars (not the same as a never-off/on True which might be ignored). There was no ignored order message in Trade message log,either (like last post). Today I see an error in a >= test a condition that SC reports false, while it computes true in the same condition-equation, testing for (E3-E4)>= 0.75. At first I thought maybe getting rid of no leading zero on .75 might help, but no. That is, the difference IS .75, the test is for .75. but >= returns False. The test & condition are simple, it's past end of bars, unlike the prior intrabar or at change of bar bug(s). I've attached a screenshot. It's rare, becaused I've viewed thousands of these (many days) with nothing like this before in a simple operator-function. My system is large & complex, has cascading charts, and I can't send the entire system. I'm sure you've done it, but I urge you to someday have someone spend a few days doing what I've done, looking for these 3 or 4 bugs and others, slowing it down, testing an assortement of operators. |
 GreaterOrEqualBug-Spreadsheet-01.jpg / V - Attached On 2016-05-13 18:30:59 UTC - Size: 212.64 KB - 278 views |
| [2016-05-13 18:56:53] |
| |
|
This is almost certainly not a bug. This is merely a floating-point error comparison issue. Refer to: https://www.sierrachart.com/index.php?page=doc/doc_StudiesSystemsAlerts.php#ImprecisionOfFloatingPointNumbers To confirm this is the case, change the formula to: (E3-E4)>= 0.74 I'm sure you've done it, but I urge you to someday have someone spend a few days doing what I've done, looking for these 3 or 4 bugs and others, slowing it down, testing an assortement of operators. Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing |
| [2016-05-13 19:26:53] |
| Sawtooth - Posts: 4143 |
|
This is what I do to correct floating point errors: http://www.sawtoothtrade.com/example-3.html |
| [2016-05-13 20:33:02] |
| User791263 - Posts: 151 |
|
I had forgotten about that, since the problem is seldom seen. I'm surprised it is not seen more often, but it must be happening more than I've noticed. That means a lot of review, caution and refinements. We should all study that link more: https://www.sierrachart.com/index.php?page=doc/doc_StudiesSystemsAlerts.php#ImprecisionOfFloatingPointNumbers I've tried to carefully match decimal places all along, but that is not sufficient. Both solutions you all offer work well. Apparently a near-but-lower or higher decimal and range for the comparison test solves the issue. Thanks much. |
To post a message in this thread, you need to log in with your Sierra Chart account: