Logic bug

[Dazzerman]

Hi all,

Will someone please explain what is going on here, and how best to avoid this problem moving forwards?  I suspect that other Alteryx users will be exposed to this apparent bug without them realizing.

I have some logic in a live workflow that is incorrectly allocating some of our suppliers into a category based on a discount that we can obtain.  I have created a new workflow with raw data as examples to highlight what I am seeing, which is attached.

In short, there appears to be a problem with the way the Less Than (<) sign is working, both within a Formula tool and a Filter tool.   But this error is not happening consistently.

Here is a screenshot of two versions of the formula that I was using to calculate the categories :

This all looks pretty basic stuff, but for some reason the "[Agreed Discount] < 0.82" text was behaving as if I had typed "[Agreed Discount] <= 0.82".  So an Agreed Discount of 0.82 was being set the value of 0.235 instead of 0.22.

One of the strange things about this problem is that the 0.8 and 0.84 parts of the formula were working correctly.

The strangest thing that I observed was that if I changed 0.82 to 0.820000, then all worked as expected.  Both for the Formula tool as well as for the filter tool.

This has got to be a bug because, numerically, 0.82 is equal to 0.820000, and users should not need to specify the additional zeros, particularly when the zeros are not required for other numbers.

I have tried this on Designer versions 2020.4 and 2021.2 and get the same results.

Initially I thought it might be an issue with the version of IF THEN ELSEIF, and I experimented with Double, Fixed Decimal numbers, including FD 19.6 and FD 19.3.

I can work around this particular version of the problem by using 0.820000, but who knows what other numbers will behave in this strange way in other workflows?

Is this fixed in the latest version of Designer?

[Luke_C]

Hi @Dazzerman 

I've seen this before. Multiply your discount & percents by 100 and it should work (i.e. <82). Someone can probably provide a more elegant root cause, but if I remember correctly it has to do with how numbers are stored and used computationally. What might look fine to us is interpreted differently by the computer.

[Dazzerman]

Thank you Luke!

It is a good suggestion.  Hopefully there will be a bug fix too, as this is certainly behaviour that is not what most people would expect.