• from math import prod

  • You don't need to turn that generator expression into a list, you could replace the [] with () to theoretically improve performance.
    Or you could just not do any i for i in stuff and just make the second argument the list itself.
    You could also pass a 1 as a third argument to functools.reduce to simplify this a little.
    Instead of using a lambda, you could import from operator.
    Finally, instead of a reduce, you can just use a certain built-in to get the product of the list.

  • Just realized my solutions based on base conversion don't work because they don't pad left. I've done enough Kumite for today, will deal with it tomorrow.

  • An interesting edgecase that a fork of this should take care of is the case of coinciding segments, the current solution fails with a division-by-zero.

  • Didn't realize that was the case, thanks for telling me about it.

  • The declaration of max should be long max(long, long)

  • You could save some occurances of std::list<int>::iterator::operator++ if you take it out of the for header, remove the assignment to the return value of std::list<int>::insert, and add and else, but this preserves the ideas of the forked Python solution better.

  • The point of this was mostly just an excuse for me to have some fun golfing with no fear of undefined behaviour, sorry for not making that very clear.

  • It wasn't completely clear what the order of the arrays should be for case multiple solutions, so I just did what was easiest. It's probably based on order of first element though.

  • This is not a difficult problem by itself, but you can make it more interesting for yourself by giving yourself an extra challenge (like code golf) or solving it in a unique way. Of course it is easy to take a piece of code and add some lines that never do anything to the end. The only thing that can prevent you from doing that is ennui and your own desire for a challenge. so I suggest you try actually improving on the previous solution. There's a very nice way to both shorten this code and make it more efficient. Try reading up on the third argument of Python range to see what I'm getting at.

  • Very good solution. Don't think there's anywhere to go from here other than f="{:,}".format. I really should have read up on the Python str documentation.

  • You can save one byte by using an operator different from the !=, but it's not well defined whether or not that's the desired behaviour, and I don't want to take any steps towards turning this into a solution remotely resembling lambda*_:532. If you make a fork that changes something other than that and improve the rules in a way that allows a shorter operator to be used, it might be a good thing to copmare against a hypothetical one byte shorter version of this that utilizes the < operator.

  • After some basic searching to see whether this idea was original, I found https://juliapackages.com/p/polynomials. I won't unpublish this or anything because this was good practice, but I probably won't add to this.

  • That does work and is quite a bit nicer, but the original problem statement said to create a copy of the array. That's a pretty pointless condition that doesn't even get tested though, so the default arguments should probably be used in a slightly tweaked better version of this Kumite.

  • Loading more items...