IFS evaluates all elements

%3CLINGO-SUB%20id%3D%22lingo-sub-3200131%22%20slang%3D%22en-US%22%3EIFS%20evaluates%20all%20elements%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-3200131%22%20slang%3D%22en-US%22%3E%3CP%3ESo%20I%20like%20the%20IFS%20statement%20to%20avoid%20nested%20IF()%20with%20all%20those%20((())).%26nbsp%3B%20But%20I%20just%20ran%20into%20a%20problem%20using%20IFS%20inside%20a%20recursive%20Lambda%20function.%26nbsp%3B%20Basically%20it%20appears%20the%20IFS%20statement%20evaluates%20ALL%20its%20terms%20before%20evaluating%20the%20IF%20part%20which%20means%20a%20MyFunc%3DLAMBDA(in%2C%20IFS(0%2CMyFunc(in)%2C%201%2C%20in))%26nbsp%3B%20failed%20because%20it%20recursively%20evaluated%20that%20Lambda%20function%20until%20it%20hits%20the%20limit%20even%20though%20it%20should%20NEVER%20even%20look%20at%20that%20part%20of%20the%20IFS.%26nbsp%3B%20Anyone%20else%20find%20this%20issue%3F%26nbsp%3B%20Or%20am%20I%20just%20missing%20something%3F%26nbsp%3B%20It%20seems%20like%20a%20very%20inefficient%20problem%20with%20IFS%20in%20general%20to%20calculate%20parts%20that%20don't%20need%20to%20be%20calculated.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-3200131%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EExcel%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EFormulas%20and%20Functions%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-3200386%22%20slang%3D%22en-US%22%3ERe%3A%20IFS%20evaluates%20all%20elements%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-3200386%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F570951%22%20target%3D%22_blank%22%3E%40mtarler%3C%2FA%3E%26nbsp%3B%20wrote%3A%20%60%60it%20appears%20the%20IFS%20statement%20evaluates%20ALL%20its%20terms%20before%20evaluating%26nbsp%3Bthe%20IF%20part%20%5B....%5D%20am%20I%20just%20missing%20something%3F%20It%20seems%20like%20a%20very%20inefficient%20problem%60%60%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EYou%20are%20not%20missing%20something%3B%20not%20at%20all.%26nbsp%3B%20And%20as%20you%20point%20out%2C%20the%20greater%20problem%20is%20the%20potentially%20incorrect%20evaluation%20caused%20by%20evaluating%20parts%20that%20should%20be%20avoided%20because%20the%20condition%20is%20false.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EIn%20other%20words%2C%20it%20behaves%20like%20a%20normal%20function%2C%20with%20one%20exception%3A%26nbsp%3B%20if%20an%20evaluated%20part%20results%20in%20an%20Excel%20error%20(%23VALUE%2C%20%23NUM%2C%20etc)%2C%20that%20does%20not%20cause%20the%20IFS%20function%20to%20fail%20unless%20the%20condition%20for%20that%20part%20is%20true%20--%20unlike%20the%20evaluation%20of%20bona%20fide%20functions.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ETechnically%2C%20there%20is%20nothing%20wrong%20with%20that%2C%20except%20that....%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EIn%20contrast%2C%20the%20IF%20%22function%22%20is%20really%20an%20%3CU%3E%3CEM%3Eoperator%3C%2FEM%3E%3C%2FU%3E%20whose%20syntax%20has%20the%20%3CU%3E%3CEM%3Eform%3C%2FEM%3E%3C%2FU%3E%20of%20a%20function.%26nbsp%3B%20And%20we%20have%20come%20to%20expect%20that%20for%20Excel%20conditional%20%22functions%22%3B%20for%20example%2C%20CHOOSE.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20noticed%20that%20as%20soon%20as%20I%20learned%20about%20the%20IFS%20function.%26nbsp%3B%20And%20that%20is%20why%20I%20deprecate%20its%20use.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EIn%20form%2C%20it%20is%20merely%20a%20shorthand%20for%20nested%20IF's.%26nbsp%3B%20There%20is%20no%20other%20benefit%20of%20IFS.%26nbsp%3B%20And%20as%20you%20discovered%2C%20there%20are%20some%20disadvantages%3B%20mostly%20performance-related%2C%20but%20you%20discovered%20a%20correctness%20issue%20as%20well.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-3201426%22%20slang%3D%22en-US%22%3ERe%3A%20IFS%20evaluates%20all%20elements%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-3201426%22%20slang%3D%22en-US%22%3EOK%20let%20me%20take%20that%20back%20but%20add%20another%20factor%20to%20be%20considered.%20CHOOSE(1%2C%20...)%20does%20act%20like%20an%20operator%20as%20noted%20above.%20BUT%20if%20you%20use%20an%20array%20as%20the%20operator%20it%20will%20then%20calculate%20all%20parameters%20and%20this%20is%20true%20for%20BOTH%20CHOOSE%20and%20IF.%20For%20example%3CBR%20%2F%3EIF(%20%7B1%2C1%7D%2C%20%22easy%22%2C%20%5Bsome%20really%20complicated%20formula%5D%20)%3CBR%20%2F%3EEven%20though%20it%20should%20just%20output%20%22easy%22%20%22easy%22%20it%20fully%20calculates%20that%20complicated%20formula.%20So%20the%20advantage%20of%20the%20'operator'%20is%20lost%20and%20it%20acts%20as%20a%20'function'%3C%2FLINGO-BODY%3E
Trusted Contributor

So I like the IFS statement to avoid nested IF() with all those ((())).  But I just ran into a problem using IFS inside a recursive Lambda function.  Basically it appears the IFS statement evaluates ALL its terms before evaluating the IF part which means a MyFunc=LAMBDA(in, IFS(0,MyFunc(in), 1, in))  failed because it recursively evaluated that Lambda function until it hits the limit even though it should NEVER even look at that part of the IFS.  Anyone else find this issue?  Or am I just missing something?  It seems like a very inefficient problem with IFS in general to calculate parts that don't need to be calculated.

3 Replies

@mtarler  wrote: ``it appears the IFS statement evaluates ALL its terms before evaluating the IF part [....] am I just missing something? It seems like a very inefficient problem``

 

 

You are not missing something; not at all.  And as you point out, the greater problem is the potentially incorrect evaluation caused by evaluating parts that should be avoided because the condition is false.

 

In other words, it behaves like a normal function, with one exception:  if an evaluated part results in an Excel error (#VALUE, #NUM, etc), that does not cause the IFS function to fail unless the condition for that part is true -- unlike the evaluation of bona fide functions.

 

Technically, there is nothing wrong with that, except that....

 

In contrast, the IF "function" is really an operator whose syntax has the form of a function.  And we have come to expect that for Excel conditional "functions"; for example, CHOOSE.

 

I noticed that as soon as I learned about the IFS function.  And that is why I deprecate its use.

 

In form, it is merely a shorthand for nested IF's.  There is no other benefit of IFS.  And as you discovered, there are some disadvantages; mostly performance-related, but you discovered a correctness issue as well.

You gave the example of CHOOSE as being like IF as an 'operator' in the form of a function, but I just tested that out and CHOOSE appears to be calculating unused parameters also.
OK let me take that back but add another factor to be considered. CHOOSE(1, ...) does act like an operator as noted above. BUT if you use an array as the operator it will then calculate all parameters and this is true for BOTH CHOOSE and IF. For example
IF( {1,1}, "easy", [some really complicated formula] )
Even though it should just output "easy" "easy" it fully calculates that complicated formula. So the advantage of the 'operator' is lost and it acts as a 'function'