For JohanWiltink, RealKenshiro and Unnamed, a new condition has been temporarily added: divisor % 2 == 1. When testing even cases, in the process, there were always some duplicates in the answer, by the approach used by myself, Unnamed and towc. I'm still researching on this to find a general solution for these cases. Thanks for pointing these issues.
I'm not sure if n % divisor != 0 is possible without more complicated stuff with high-precision fractions, but I have a version of the solution that seems to work for all other input.
n < 100000, divisor < n.
In order to make the outputs exact, n % divisor == 0 condition holds for every test.
These conditions are less general than possible, and seem arbitrary ( though they may enable additional performance if and when the reference solution starts giving correct answers ).
0 <= n and 1 <= d <= triangular(n) ( or even slightly larger for small n ) would make sense, and you can put any arbitrary upper limit on n ( and thus d ) for performance reasons.
I'd suggest including tests with n = 0, with d = 1, with d >= n, and with n, d coprime.
And the reference solution is wrong for many other cases: (9, 9) -> expected 60, (15, 15) -> expected 2192. I sumbitted this version to see what should be done to generalize it and wasn't really expecting it to pass all the tests.
i love how all of us have the same solution except the variety is on characters
(not like there was any other way to solve this god forsaken puzzle)
sorry, bro, okey
Use spoiler flag next time, please, your posts here are visible on the homepage's discourse.
This comment is hidden because it contains spoiler information about the solution
This comment is hidden because it contains spoiler information about the solution
but wasn't the question about immutable param?
(const std::string& str)?
For
JohanWiltink
,RealKenshiro
andUnnamed
, a new condition has been temporarily added:divisor % 2 == 1
. When testing even cases, in the process, there were always some duplicates in the answer, by the approach used by myself, Unnamed and towc. I'm still researching on this to find a general solution for these cases. Thanks for pointing these issues.I'm not sure if
n % divisor != 0
is possible without more complicated stuff with high-precision fractions, but I have a version of the solution that seems to work for all other input.These conditions are less general than possible, and seem arbitrary ( though they may enable additional performance if and when the reference solution starts giving correct answers ).
0 <= n
and1 <= d <= triangular(n)
( or even slightly larger for smalln
) would make sense, and you can put any arbitrary upper limit onn
( and thusd
) for performance reasons.I'd suggest including tests with
n = 0
, withd = 1
, withd >= n
, and withn, d coprime
.exactly my results
Seems like they do.
I worry. I also worry you're going to need a lot of
if
s.It's not just cases where
d == n
either. See above for(8,4)
.Why
test.assert_equals(subset_sum(8, 4), 67)
when the answer is apparently64
?Lots of expected answers ( half of 'em, to be exact, even excluding the removed (2,2) ) in the example tests are still wrong according to my solution.
And the reference solution is wrong for many other cases: (9, 9) -> expected 60, (15, 15) -> expected 2192. I sumbitted this version to see what should be done to generalize it and wasn't really expecting it to pass all the tests.
Loading more items...