Support Board
Support Board
Search Board
Control Panel
View My Posts / Threads
Direct MessagesDate/Time: Fri, 27 Sep 2024 07:22:28 +0000
When comparing a FRACTIME to a TIMEVALUE, the >= operator ignores the =
View Count: 948
| [2021-08-08 18:18:54] |
| Sawtooth - Posts: 4092 |
|
In a spreadsheet study, when comparing a FRACTIME to a TIMEVALUE, the >= operator ignores the = However, When comparing the same FRACTIME to the same TIMEVALUE, the > operator is accurate. When comparing the same FRACTIME to the same TIMEVALUE, the = operator is accurate. Formula Details of the inaccurate >= operator: [ >= ] K94>=TIMEVALUE("17:00:00") = 0 (number, integer) [ K94 ] K94 = 0.7083333333333333 (number, double) [ TIMEVALUE ] TIMEVALUE("17:00:00") = 0.7083333333333334 (number, double) [ "17:00:00" ] "17:00:00" = "17:00:00" (text) K94 contains this formula: =MROUND(FRACTIME(A94),1/86400) M94 = 1 N94 should also be 1. See pic for reference. See .scss for more. Please advise. |
 GreaterThanOrEqualTo.scss - Attached On 2021-08-08 18:17:13 UTC - Size: 1.19 MB - 204 views  GreaterThanOrEqualTo.PNG / V - Attached On 2021-08-08 18:17:25 UTC - Size: 22.39 KB - 195 views |
| [2021-08-09 06:31:23] |
| |
|
There probably is just is a very small a difference related to floating-point error, resulting in this. So in effect there is no problem and you need to accommodate for that difference. We will have a look though. 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 Date Time Of Last Edit: 2021-08-09 06:31:32
|
| [2021-08-09 16:43:27] |
| Sawtooth - Posts: 4092 |
|
There probably is just is a very small a difference related to floating-point error, resulting in this.
If that were the case, then why does the = operator by itself return TRUE?:[ = ] K67=TIMEVALUE("17:00:00") = 1 (number, integer) [ K67 ] K67 = 0.7083333333333333 (number, double) [ TIMEVALUE ] TIMEVALUE("17:00:00") = 0.7083333333333334 (number, double) [ "17:00:00" ] "17:00:00" = "17:00:00" (text) |
| [2021-08-09 18:17:25] |
| Jeffrey - Posts: 2147 |
|
The equal operator (=) by itself is designed to allow some wiggle room if the numbers are slightly off. But the greater or equal operator (>=) enforces that if the left value is even the tiniest bit less than the right, then the operator returns FALSE. That's what's happening in this case. Here are a few alternative formulas you could consider: =K94>=TIMEVALUE("16:59:59.999") =K94>=TIMEVALUE("17:00:00")-1/86400000 =OR(K94>=TIMEVALUE("17:00:00"), ISSAMETIMETOMILLISECOND(K94, TIMEVALUE("17:00:00"))) More generally, only the equal (=) and not-equal (<>) operators have this extra provision to handle numbers that are slightly off. All of the other operators (<, <=, >=, >) are strict in their comparisons. This could potentially be changed if the minor impacts to performance and accuracy are considered worth it. |
| [2021-08-09 20:36:39] |
| Sawtooth - Posts: 4092 |
|
More generally, only the equal (=) and not-equal (<>) operators have this extra provision to handle numbers that are slightly off. All of the other operators (<, <=, >=, >) are strict in their comparisons. This could potentially be changed if the minor impacts to performance and accuracy are considered worth it.
Dealing with floating point imprecision is a continual problem, so this change would be welcomed.
Date Time Of Last Edit: 2021-08-09 20:38:13
|
To post a message in this thread, you need to log in with your Sierra Chart account: