• ###### 深紅心commented on "Factorial n!" kumite

from math import prod

• ###### 深紅心commented on "Factorial n!" kumite

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.

• ###### 深紅心commented on "Ben's task" kumite

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.

• ###### 深紅心commented on "LineIntersections3D" kumite

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.

• ###### 深紅心commented on "Value Added Tax (VAT) and Luxury tax" kumite

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

• ###### 深紅心commented on "NASM: Get Max of two integers" kumite

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

• ###### 深紅心commented on "Merge two sorted lists" kumite

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.

• ###### 深紅心commented on "ninjopiratis's Kumite #2" kumite

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.

• ###### 深紅心commented on "Game Of Cards" kumite

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.

• ###### 深紅心commented on "Make my numbers formatted" kumite

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.

• ###### 深紅心commented on "Make my numbers formatted" kumite

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.

• ###### 深紅心commented on "ASCII Number Jumble" kumite

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.

• ###### 深紅心commented on "Basic polynomial "literals" in Julia" kumite

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.

• ###### 深紅心commented on "Insertion sort" kumite

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.