"Robert Crandal" wrote:
"joeu2004" wrote
y = -(x<=0) - (x0)*WorksheetFunction.Roundup(x,0)

Hmm, but doesn't this code involve a little bit of if-else
logic because it's comparing X with 0, and returns True or
False depending on the value of X?

Yes. So does the use of WorksheetFunction.Max internally.


"Robert Crandal" wrote:
doesn't this get converted to if-else instructions at the
assembly language level?

Yes. And it may or may not be more efficient than using
WorksheetFunction.Max. I was not suggesting it. I was just trying to get a
sense for what you meant by a "simple math formula that does not use if-else
logic".

In fact, if-then-else logic of some form is inescapable in your case because
of the need to handle x<=0 as a special case. It is simply a matter of how
explicit that logic appears in the program.


"Robert Crandal" wrote:
["joeu2004" wrote]
If x0 Then y = WorksheetFunction.Roundup(x,0) Else y = 1

So, the last example of code is the most efficient solution?
Even more efficient than the code that I chose to use:
y = WorksheetFunction.Max(1, WorksheetFunction.RoundUp(x, 0)) ??

Probably.

I don't know the internal design of VBA. But the explicit If-Then-Else
statement has the opportunity for some efficiencies, especially if it is
compiled or pseudo-compiled.

The WorksheetFunction.Max expression probably calls a general-purpose
assembly-language function that must be capable of processing a variable
number of parameters and selecting the largest one. And there is overhead
of evaluating and setting up the parameter list before the call.

If Max were a VBA function, it might be optimized and implemented exactly as
the explicit If-Then-Else. I doubt that is the case with
WorksheetFunction.Max. But if it were, at best, the two forms are simply
two ways of expressing exactly the same behavior in VBA.