SHORT ANSWER: Exponentiation of any non-zero power of a negative base is a disallowed function.
LONG ANSWER: From a strictly theoretical viewpoint, this problem depends on exactly how the exponentiation operator is defined for VBA. There are three possible interpretations to having a negative base and a fractional exponent. (By the end of this examination, I'll tell you which one VBA uses based on the findings.) See also this linked article:
My teachers have gone over rules for dealing with fractional exponents. I was just wondering how someone would compute say: $$(-5)^{2/3}$$ I have tried a couple ways to simplify this and I am not s...
math.stackexchange.com
I'm going to summarize:
For
complex number exponentiation (involving
SQR(-1) or "
i" in math / "
j" in physics 'cause "
i" was already taken for
current), then the answer is likely to be multi-valued with simultaneous positive and negative components for the real and complex parts. FORTRAN is an example of a programming language that DOES handle complex numbers. But VBA doesn't directly support complex numbers (it has no complex data type) so that certainly wouldn't apply to this case.
For
discrete exponentiation, the subject situation is allowed in some cases, but the problem is that it is allowed only for specific values of the exponent, analogous if not identical in behavior to quantized entities in atomic and nuclear physics. I.e. only certain powers allow a solution and for other powers, there is no solution. This case is almost certainly not a discrete-exponentiation operation. One dead give-away is to look at the number of decimal places expressed in the exponent. Discrete, this is not. Which leaves us...
For
CONTINUOUS exponentiation, which is the most common case and the one I believe is used by VBA (though the language manual doesn't say so explicitly), a fractional power of a negative base is undefined. That condition is probably the source of the "invalid procedure call" error.
From the
VBA Language spec v04242014, section
5.6.9.3.7, ^ Operator,
If the left operand is 0 and the right operand is negative, runtime error 5 (Invalid procedure call or argument) is raised.
Here's how you get to that point:
First, it is a given fact purely based on observation that the exponent AND the negative base are both non-integers.
Second, considering the alternatives, it seems clear that this would have to be evaluated by the rules of continuous exponentiation. (This is a guess since Access is not OpenSource.)
Third, remember that no computer has a hardware exponentiation instruction. All computers perform exponentiation by software functions.
To software-evaluate this general expression:
x = -a^b
(where
a and
b are both real (but non-integer) numbers and in this case,
a is positive so
-a is negative), a computer will try to evaluate
x = EXP( b * LN( -a ) )
(where
EXP is exponentiation base
e and
LN is natural logarithm (also base
e), and
e is Euler's constant, equal to 2.718281828459045... (approximately).
The problem immediately crops up on the
LN function, for which there IS no logarithm for a negative number, integer or non-integer. The operation to derive the logarithm of a negative number is
undefined.
Since the operator is implemented by an internal function, it breaks it down to steps. The odds are that in either SQL or VBA, the step that attempts to resolve
LN( -a ) will return zero, which then leads directly to the stated error condition that occurs when raising zero to a fractional power.
Note, however, that there is an order of execution issue: Exponentiation occurs
before unary negation. Therefore, the fact that you can get an answer at all for the original expression implies that you are actually evaluating:
x = -( EXP( b * LN( a ) ) ) = - (a^b)
That is, because of operator precedence, that pesky minus-sign on
a is deferred until after the exponentiation occurs.
@AHeyne performed testing that showed that adding explicit parentheses, which overrides default math operator order, forces the unary negation to occur BEFORE the exponentiation, and that will not work. You will get an error 5, Invalid Procedure Call. I verified that myself using the immediate window, too, just to be sure the issue wasn't version-specific - and it isn't specific.
@sonic8 took a different approach and loaded the values to variables. But in so doing, he applied the unary negation to the variable BEFORE the exponentiation could occur, and so exhibited the same problem.
This is a round-about way of suggesting that VBA uses
continuous exponentiation, which is important in this context because it means that negative bases are not normally allowed. The same error will occur any time you write the expression in such a way that you apply the unary minus sign BEFORE you apply the exponentiation operator.
By the way, if you evaluate that expression in a way to avoid the error trap, you end up with a number that is roughly 2.
somethingE+23, or over 200 sextillion when using USA number-naming. That is a very large number. If that is a potential return on investment, sign me up, please.
