stacks-network
Negative Power of a Number in Clarity
Describe the bug Inconsistent power function behavior.
Steps To Reproduce Open the clarinet console and type
(pow 0 -2)
and
(pow 5 -1)
Expected behavior
(pow 0 -2) should return error since it is infinity number and (pow 5 -1) should return zero...
Environment (please complete the following information):
- OS: MacOs
- Clarinet Console 0.33
Additional context
Similar to (pow 0 -2)
(log2 0) is an infinity number, and throws an error...
Echoing my Discord comments here for record:
The code handling pow looks like this, which explains those cases:
if base == 0 && power == 0 {
// Note that 0⁰ (pow(0, 0)) returns 1. Mathematically this is undefined (https://docs.rs/num-traits/0.2.10/num_traits/pow/fn.pow.html)
return Self::make_value(1);
}
if base == 1 {
return Self::make_value(1);
}
if base == 0 {
return Self::make_value(0);
}
if power == 1 {
return Self::make_value(base);
}
if power < 0 || power > (u32::MAX as $type) {
return Err(RuntimeErrorType::Arithmetic(
"Power argument to (pow ...) must be a u32 integer".to_string(),
)
.into());
}
I think the behavior is reasonable, even though it is different, so the cleanest solution for now will be to update the documentation to make this behavior clear.
More test data; I have done these tests yesterday, just forgot to post it here.
| Base | Power | Clarity | Javascript | Result |
|---|---|---|---|---|
| -5 | -5 | error | 0 | X |
| -5 | -3 | error | 0 | X |
| -5 | -1 | error | 0 | X |
| -5 | 0 | 1 | 1 | |
| -5 | 1 | -5 | -5 | |
| -5 | 3 | -125 | -125 | |
| -5 | 5 | -3125 | -3125 | |
| -3 | -5 | error | 0 | X |
| -3 | -3 | error | 0 | X |
| -3 | -1 | error | 0 | X |
| -3 | 0 | 1 | 1 | |
| -3 | 1 | -3 | -3 | |
| -3 | 3 | -27 | -27 | |
| -3 | 5 | -243 | -243 | |
| -1 | -5 | error | -1 | X |
| -1 | -3 | error | -1 | X |
| -1 | -1 | error | -1 | X |
| -1 | 0 | 1 | 1 | |
| -1 | 1 | -1 | -1 | |
| -1 | 3 | -1 | -1 | |
| -1 | 5 | -1 | -1 | |
| 0 | -5 | 0 | Infinity | X |
| 0 | -3 | 0 | Infinity | X |
| 0 | -1 | 0 | Infinity | X |
| 0 | 0 | 1 | 1 | |
| 0 | 1 | 0 | 0 | |
| 0 | 3 | 0 | 0 | |
| 0 | 5 | 0 | 0 | |
| 1 | -5 | 1 | 1 | |
| 1 | -3 | 1 | 1 | |
| 1 | -1 | 1 | 1 | |
| 1 | 0 | 1 | 1 | |
| 1 | 1 | 1 | 1 | |
| 1 | 3 | 1 | 1 | |
| 1 | 5 | 1 | 1 | |
| 3 | -5 | error | 0 | X |
| 3 | -3 | error | 0 | X |
| 3 | -1 | error | 0 | X |
| 3 | 0 | 1 | 1 | |
| 3 | 1 | 3 | 3 | |
| 3 | 3 | 27 | 27 | |
| 3 | 5 | 243 | 243 | |
| 5 | -5 | error | 0 | X |
| 5 | -3 | error | 0 | X |
| 5 | -1 | error | 0 | X |
| 5 | 0 | 1 | 1 | |
| 5 | 1 | 5 | 5 | |
| 5 | 3 | 125 | 125 | |
| 5 | 5 | 3125 | 3125 |
The consensus at the blockchain meeting is that pow exhibits well-defined behavior as-is. The issue is that it was not properly documented. @obycode will address the documentation.
