Alternate to If statement

[jduplessis]

One of the consultants we work with loves using an alternate to an if statement. Where typically we might want to check if something is equal to 0. For instance where we might want to use:

Code: Select all

['Element X'] = IF( ['Element A'] <> 0, ['Element B'], 0 );

The consultant will use:

Code: Select all

['Element X'] = ABS( SIGN( ['Element A'] ) ) * ['Element B'];

This is a simple example. The way it works is that sign returns -1, 1 or 0 if 'Element A' is positive or negative or 0/empty, and abs will convert it to a 1 if it has a value or a 0 if it's empty. This is then multiplied by the value in 'Element B' returning a 0 or the value in 'Element B'.

The claim is that the second approach is faster than an if statement because it only has to check the sign bit on the value in Element A. But I wanted to get others opinions on this. My concern is that this approach is actually slower since the true statement in the above example is always calculated even if it returns 0 using the consultants approach. Not a major issue in this simple example but it gets worse as you add complexity and possible nesting. Is anyone able to validate that this is actually faster? Or is it only faster in certain circumstances?

My other concern is that the second approach is just plain confusing and hard to read for anyone not familiar with the model.

[tomok]

I don't care if it's faster or not. All it does is add confusion to the business purpose behind the rule and for that reason I'm out (with due respect to the Sharks ) Translation: I would never use it in a model.

[jduplessis]

I don't care if it's faster or not. All it does is add confusion to the business purpose behind the rule and for that reason I'm out (with due respect to the Sharks ) Translation: I would never use it in a model.

Agreed, assuming I had control over what goes into the models. I think it destroys readability, but I am more curious whether it is actually faster (or only faster in specific circumstances). If it is not faster and it destroys readability then it will be easier to stop the practice. Is there an easy way to test the speed of a calculation like that or is it just theoretical?

[tomok]

Is there an easy way to test the speed of a calculation like that or is it just theoretical?

Write both rules in the same cube and time how long it takes to retrieve the results. Of course, you'll need a sterile environment so that contention with other users is not an issue. You'll also need to invalidate the cache after each test (by writing to the cube) because the results of the calculation will be cached and return a misleading timing.

[tomok]

Is there an easy way to test the speed of a calculation like that or is it just theoretical?

Write both rules in the same cube and time how long it takes to retrieve the results. Of course, you'll need a sterile environment so that contention with other users is not an issue. You'll also need to invalidate the cache after each test (by writing to the cube) because the results of the calculation will be cached and return a misleading timing.

[Alan Kirk]

If I had to guess I'd say that somebody just has their mind stuck in the mode of "avoid evaluating the second expression at all costs! At!!! All!!! Costs!!!! I say!!!! And that includes the cost of running a couple of extra functions and the associated overhead."

I agree with Tomok in both posts. If you really want to test it then follow the advice in his second post, note the results carefully, then tear them up and throw them away because it's bad coding. Not "bad" in the "doesn't work" sense (indeed it's quite clever in an abstract way) but bad in the maintainability sense, and possibly the performance sense as well.

I really couldn't be bothered doing it with Rules (as Tomok notes there's a lot of work involved in that) but just out of curiosity I generated a data file of about a million rows (a full Excel 2007 worksheet exported to a .csv in other words) and had two T.I. processes to run the equivalent expressions on that data source. There was no code in either process aside from that line on the data tab, a variable assignment in Prolog to get the start time, and an AsciiOutput to write the elapsed time in the Epilog. (Identical in both processes save for the file name which had a timestamp.)

Consistently the If() function process took either 1 or 2 seconds to complete. The clever but harder to read syntax's process took 3.

If you decide to do the tests with rules then I'm sure many would be curious about the outcome but based on the above I wouldn't hold out a lot of hope that it'll show a barnstorming performance improvement.

[rmackenzie]

...

Code: Select all

['Element X'] = IF( ['Element A'] <> 0, ['Element B'], 0 );

...

Is it necessary for 'Element X' to evaluate to 0 if the condition is FALSE? Had you considered using STET instead? I realise that the rule presented is probably not a real-life example but the consultant's substitute code arrives at the same outcome, so I thought it may be worth mentioning. Storing a lot of calculated zeroes seems in itself a bit inefficient irrespective of the coding technique.

[jduplessis]

...

Code: Select all

['Element X'] = IF( ['Element A'] <> 0, ['Element B'], 0 );

...

Is it necessary for 'Element X' to evaluate to 0 if the condition is FALSE? Had you considered using STET instead? I realise that the rule presented is probably not a real-life example but the consultant's substitute code arrives at the same outcome, so I thought it may be worth mentioning. Storing a lot of calculated zeroes seems in itself a bit inefficient irrespective of the coding technique.

I think the reason 0 was returned was to prevent accidentally writing a value to that cell, which STET would allow. But you bring up a good point, even if someone entered a value, subsequent calculations would not be impacted so do we care that whether a value exists in that cell or not...

[lotsaram]

One of the consultants we work with loves using an alternate to an if statement. Where typically we might want to check if something is equal to 0. For instance where we might want to use:

Code: Select all

['Element X'] = IF( ['Element A'] <> 0, ['Element B'], 0 );

The consultant will use:

Code: Select all

['Element X'] = ABS( SIGN( ['Element A'] ) ) * ['Element B'];

I've heard the statement a bit that evaluating a boolean condition is more expensive in terms of performance overhead than a numeric operation and so should be used in preference. I've never actually bothered to do a speed test though. Unless there was a significant difference in performance like 50% or more (that is a reason to do it) then I would also always go with the more readable/understandable/maintainable calculation. For this pretty simple example it would seem from Alan's practical experiment that the overhead of performing 3 mathematical operations vs. a single level boolean evaluation and assignment is actually greater. Therefore no reason at all to do it.