Rational Numbers: Add error test case to expreal property #2213
Conversation
|
Hello. Thanks for opening a PR on Exercism. We are currently in a phase of our journey where we have paused community contributions to allow us to take a breather and redesign our community model. You can learn more in this blog post. As such, all issues and PRs in this repository are being automatically closed. That doesn't mean we're not interested in your ideas, or that if you're stuck on something we don't want to help. The best place to discuss things is with our community on the Exercism Community Forum. You can use this link to copy this into a new topic there. Note: If this PR has been pre-approved, please link back to this PR on the forum thread and a maintainer or staff member will reopen it. |
natanaelsirqueira
force-pushed
the
rational-numbers-add-test-case
branch
from
ccb7364
to
9a2b1cb
Compare
| "property": "expreal", | ||
| "input": { | ||
| "x": -1, | ||
| "r": [1, 1] |
There was a problem hiding this comment.
This is kind of an edge case because a [1, 1] exponent is the same as doing nothing, and also the power -1 is not so interesting. If we want to test an actual case, maybe -8 ^ [1, 3] == -2 might be a better choice.
Same for the non-reduded case, it could be [2, 6] instead.
There was a problem hiding this comment.
Hey! I tried using that example in my Gleam implementation but stumbled on this. This behaviour is the same in Elixir/Erlang. Any thoughts?
There was a problem hiding this comment.
Yeah, that's a sensible choice. What I would do is check if the base is negative and the denominator odd, then take the power of the absolute value and negate it.
There is also the option of backing out of these strange cases altogether, although I kid of like them :)
There was a problem hiding this comment.
Yeah... I'm up for dropping all of this tbh. It's starting to feel like we are overcomplicating the exercise and not adding much value. Plus, the initial motivation was to add an error case to our Gleam implementation because the function returns a result. Maybe we could just make that same check that float.power/2 does and have that be our error case?
|
Is this good to go? :) |
|
@lpil Thank you for the reminder. In the interest of time, I believe it's reasonable to back out of this change to unblock the PR in the Gleam track. In hindsight, adding an error case to the problem spec solely because the Gleam function returns a Result may not be necessary. I'm open to being challenged on this, but if you agree with this approach, please feel free to leave your review/approval on that PR, and I'll proceed with closing this one. |
|
Thank you. What do you think @jiegillet ? |
As suggested by @jiegillet in gleam!248, we would like to add a failure edge case when doing the exponentiation of a real number to a rational number.