ok, well i can just be a bit lazier.
exec(__import__("marshal").loads(__import__("codecs").decode("63000000000000000000000000000000000200000040000000730c00000065006400830101006401530029027a476f72206a757374206265206c617a69657220616e6420637265617465206d79206f776e2070726f6772616d207468617420646f65732062797465636f646528696d206c617a79294e2901da057072696e74a90072010000007201000000fa083c737472696e673eda083c6d6f64756c653e0100000073020000000c01","hex")))

p.s. this is for logging to console

sth i made on my own (i dont think ill reveal it? if youre interested u can read up here and try to implement one yourself, or perform it by hand)

what program

the goal is to make it short, not make it long

I did NOT improve from @thatbirdguythatuknownot's answer, I modified the test cases. So its still 96 characters.

I did NOT improve from @thatbirdguythatuknownot's answer, I modified the test cases.

nice

thats so much shorter

nice! I see that big improvement!

Updated:

# ORDER TYPE COUPONS
f'10% off order' : lambda x: x // 10,
f'10$ off 20$ or larger order' : lambda x: 1000 if x >= 2000 else 0,

# Reward points is a special order type coupon that gives $1 discount per 1000 points.
f'Reward points: {0 <= n <= 100000}' : lambda x: 100 * x // 1000

order type coupons should each be processed exactly once if they exist.

Let me know if that's a clear enough description for the rewards coupons.

It matters from the standpoint of de-duplicating coupons: de-duplicating by the entire coupon name rather than reward coupons will fail tests where multiple reward coupons of different values exist. This isn't ruled out by the description, so there are no reasons to arbitrarily remove some of the possible inputs.

I see your point now. My appologies for not understanding.

If you recieve two or more rewards coupons, while, yes they all have the same number currently, it doesn't matter

It matters from the standpoint of de-duplicating coupons: de-duplicating by the entire coupon name rather than reward coupons will fail tests where multiple reward coupons of different values exist.

This isn't ruled out by the description, so there are no reasons to arbitrarily remove some of the possible inputs. Lack of test coverage (testing the possible kind of scenarios fully) is a serious testing issue: you can't just say "I don't need to test it because the rules explained this pretty clearly". Code doesn't care about your description; it only cares about your tests.

Speaking of which, where are the explanations of reward points coupons? It used to be in the description but now it's gone, so the meaning of it is unclear.

I have changed tests to use strict equals.

Hello mortonfox, The discrepancy is due to assert_approx_equals accidentally being left in after converting all the floats to use ints. Let me know if this solves your problem.

I chose the puzzles tag because I don't know what other category this falls under. I figured a vague over-used tag would be better than no tag. If there's one that's more applicable, or if no tag is actually better, I'd be happy to change it.

I understand your frustration, but yes. To the best of my ability, I have tested that this works the way it was intended. I see the issue you're describing now, and I'm not sure if it matters. If given a coupon array of one reward points coupon, you'll get a random number that should be given to the coupon for the discount amount. If you recieve two or more rewards coupons, while, yes they all have the same number currently, it doesn't matter. That coupon should only be processed one time anyway. If it's that important to add the appearance of randomness, I will happily do this. I just don't see the reason given that the rules were pretty explicit about how to process duplicate coupons.

Ja