Int type used in largest-series-product may be too small about go HOT 5 CLOSED

Mm hm, good catch. First, breaking code is never a worry, that's what testVersion is for. We could remove the test case, but I like it because the .yml cites Project Euler. PE does like to use 64 bits. Changing the result type sounds better. You know, I think we could even be devious here and use a type conversion. We'd move the test program to int64 but instead of comparing the solver's return value directly, convert the type inferred result to int64. That would let people be sloppy (like I was!) and possibly get nitpicked later.

Huh. Ideally we'd run CI on multiple architectures. I don't think Travis offers this. Their Go page states "Travis CI VMs are 64 bit..."

from go.

Yeah, I'm pretty sure Travis is linux/64-bit only.

from go.

I don't think the devious approach would work. The product would overflow during calculation in the user code and then extended to int64 upon return. So correct user code would still be unable to return a correct value.

I'll make a PR for a full conversion to int64 + TestVersion later today.

from go.

Aha. I got travis to test with 32bit ints: https://travis-ci.org/exercism/xgo/builds/57178825

It verifies that largest-series-product does indeed fail and also shows that prime-factors has a similar problem.

Update: Huh. And prime-factors is harder to fix in the way I've been arguing for largest-series-product. There, the big number is an argument rather than a return value. I'm not seeing an easy way to type-infer the argument with table driven tests. I can think of a few awkward ways, but I don't think it's worth it.

from go.

As of #161 and #162, these problems are int64, and as of #163 we have CI testing both 32 and 64 bit builds.

from go.