Possible duplicate of https://www.codewars.com/kata/reverse-polish-notation-calculator/

Julia translation

you are pushing strings on the stack instead of numbers ;-)

This is helpful, will be reviewing your code!

The main idea is that the number of digits in a decimal number is roughly equal to its base 10 logarithm. For example, 10^3 = 1000 (3 + 1 digits), 10^4 = 10000 (4 + 1 digits), and so on. This allows us to approximate the range of the "elegant" value (tens, hunderds, thousands, ...).

Hmm. Didn't think of using a logarithm. I just converted a number to a string and used it's length. Learned something new today.

You're right, my bad.

looks like you're returning a tuple at some point, tho

I get weird errors running tests, and I don't think my code is the culprit:

Traceback (most recent call last):
  File "/runner/frameworks/python/cw-2.py", line 111, in wrapper
    func()
  File "main.py", line 16, in sample2
    test_it('+ 3 5',8)
  File "main.py", line 4, in test_it
    test.assert_approx_equals(calculate(s),n,margin=1e-6)
  File "/runner/frameworks/python/cw-2.py", line 84, in assert_approx_equals
    div = max(abs(actual), abs(expected), 1)
TypeError: bad operand type for abs(): 'tuple'

My code runs fine locally with the same expressions. Am I wrong?

Why I am getting this error
Traceback (most recent call last):
File "/runner/frameworks/python/cw-2.py", line 111, in wrapper
func()
File "main.py", line 51, in fixed_set1
test_it('0',0)
File "main.py", line 45, in test_it
test.assert_approx_equals(calculate(s),n,margin=1e-6)
File "/runner/frameworks/python/cw-2.py", line 84, in assert_approx_equals
div = max(abs(actual), abs(expected), 1)
TypeError: bad operand type for abs(): 'str'

Here is my python code

def calculate(ex):
    stack = []

    for i in ex[::-1].split(' '):
        if i not in '+-*/':
            stack.append(i)
        else: 
            a, b = stack.pop(), stack.pop()
            stack.append(str(eval(a + i + b)))
    return stack[0]

I went ahead and added the following comment to the initial test setup as well: # for division, use true division, not floor division, so no room for ambiguity. :)

woops, I actually didn't even read that comment... x)

Could be enough. Tho, that means the user cannot have the info before he reaches the trainer. It's a bit suboptimal, even if nothing critical, I guess.

The initial solution setup includes the comment # should return a float. Coupled with the fact that the division operator used is / rather than //, shouldn't that suffice?

the description should be updated, saying expicitly that in python one should use true division, and not integer division (for now, the example of the description doesn't allow to be sure of it)