1
\$\begingroup\$

This question is about the rules of One OEIS After Another.

A comment was made about hard-coding the values of a particularly difficult sequence, for the sake of keeping the challenge going. Peter Taylor claimed that a hard-coded answer must account for at least 1000 terms or else be invalid. This interpretation of the rules would invalidate a previous answer, forcing the deletion of it and six subsequent answers.

However, the rules also say that you may assume that the required output will not be outside your language's numerical range. I, and others, thought that meant that if required outputs were above, for example, 232-1 in a language with 32-bit unsigned ints, then they could be safely ignored. The other view, as I see it, is that it means that your program should assume it has the required memory and not worry about overflow, outputting in this example the correct answer mod 32.

To be fair, the answer at the center of this is mine, so I'm biased, but I think that this should have a consensus before any action (such as deleting seven answers) is taken.

The rules in question are:

  • You can assume that neither the input nor the required output will be outside your languages numerical range, but please don't abuse this by choosing a language that can only use the number 1, for example.
  • n will never be larger than 1000, or be out of bounds for the sequence, simply to prevent accuracy discrepancies from stopping a language from competing.
\$\endgroup\$
  • 1
    \$\begingroup\$ This is a standard loophole... I'd say Peter was wrong, but erring on the side of being lenient. The loopholes page states that it shouldn't really be allowed at all. \$\endgroup\$ – Rɪᴋᴇʀ Sep 15 '17 at 15:21
  • 1
    \$\begingroup\$ I hope that "a particularly difficult sequence" doesn't refer to A000173, which is rather easy. \$\endgroup\$ – Peter Taylor Sep 15 '17 at 15:22
  • \$\begingroup\$ Since some OEIS sequences are not computable you must be able to hard code \$\endgroup\$ – Sriotchilism O'Zaic Sep 15 '17 at 15:24
  • \$\begingroup\$ @FunkyComputerMan A000173 is easily computable though. \$\endgroup\$ – Rɪᴋᴇʀ Sep 15 '17 at 15:24
  • 1
    \$\begingroup\$ Also, with respect to "forcing the deletion of it and six subsequent answers, I'm working on an answer in a different language which can be padded to the same length to "save" the subsequent answers. \$\endgroup\$ – Peter Taylor Sep 15 '17 at 15:24
  • \$\begingroup\$ @PeterTaylor The question came up about A000083. It was just later pointed out that it also applied to mine. \$\endgroup\$ – KSmarts Sep 15 '17 at 15:24
  • \$\begingroup\$ @Riker I'm just saying in general it must be allowed to hard code, otherwise it is impossible to do some sequences. \$\endgroup\$ – Sriotchilism O'Zaic Sep 15 '17 at 15:25
  • \$\begingroup\$ @FunkyComputerMan you can always just not do some sequences, there are plenty. \$\endgroup\$ – Rɪᴋᴇʀ Sep 15 '17 at 15:26
  • 1
    \$\begingroup\$ @Riker If all hard-coding is banned in that challenge, then over 100 answers are invalid, thanks to this. \$\endgroup\$ – KSmarts Sep 15 '17 at 15:27
  • 1
    \$\begingroup\$ See here. I think using intercal and hard-coding falls under standard loopholes, as it's using the 32 bit integer to not give all the numbesr. However, I don't think that blame falls on you. The challenge is pretty badly worded there. \$\endgroup\$ – Rɪᴋᴇʀ Sep 15 '17 at 15:27
  • 3
    \$\begingroup\$ @KSmarts yeah, I think the blame is on the challenge OP there. \$\endgroup\$ – Rɪᴋᴇʀ Sep 15 '17 at 15:28
  • \$\begingroup\$ @Riker Which is why I'm seeking clarification. This was asked in the comments the day after it was posted but didn't get a clear answer. ["Is assuming, say, 32-bit ints and hard-coding for that "abusing" this rule? (I think it's a banned common loophole, but this sounds a little like you're excepting it!)"] \$\endgroup\$ – KSmarts Sep 15 '17 at 15:32
  • \$\begingroup\$ "Uncomputable" I had an almost ready answer that actually computed the sequence. It just needed testing \$\endgroup\$ – NieDzejkob Sep 15 '17 at 15:33
  • \$\begingroup\$ @NieDzejkob I am not speaking about that sequence I am just saying that some sequences are strictly not computable. \$\endgroup\$ – Sriotchilism O'Zaic Sep 15 '17 at 15:38
  • \$\begingroup\$ @FunkyComputerMan, although the sequence is not computable, it's possible that the first 1000 terms are. I believe the current lowest index of the busy beaver function which is known to be independent of ZFC is around 1900, so it's not impossible that a program which enumerates all proofs in ZFC looking for one that proves the value of the busy beaver function for lower indices would work, and I think it would be reasonable to accept it as an answer should the situation arise. \$\endgroup\$ – Peter Taylor Sep 15 '17 at 15:52
4
\$\begingroup\$

I believe the background to

n will never be larger than 1000, or be out of bounds for the sequence, simply to prevent accuracy discrepancies from stopping a language from competing.

was a comment of mine in the sandbox which raised issues about sequences which depend on high-precision values of real numbers. I believe the specific example I gave was a low-numbered sequence which uses π. In my opinion, using that rule as an excuse for hard-coding values up to 1000 is technically legal but bad sportsmanship, and I presume that other people concur because one high-profile answer linked in comments above which does it is currently at +7/-7.

However, in the case of e.g. A000017 hard-coding the sequence is the only option because it is essentially defined as a hard-coded list of values.

The issue of uncomputable sequences is also raised in comments and is an interesting one, but I think it would be getting off-topic for this question to discuss it in detail.

I don't think this rule is relevant to the answer which is the subject of this meta question, since it neither hard-codes 1000 values nor hard-codes a full finite sequence.

You can assume that neither the input nor the required output will be outside your languages numerical range, but please don't abuse this by choosing a language that can only use the number 1, for example.

As Riker has mentioned in a comment, there is a standard loophole:

Abusing native number types to trivialize a problem

It is common practice to restrict challenges to cases where input, output and/or intermediate values of the algorithm of choice fit into the language's native number type. At least for input and output, this is generally assumed even if not stated in the challenge specification.

...

As a rule of thumb, I'd say an answer abuses the native number type if the code would require non-trivial modifications for larger number type.

The OEIS question doesn't directly specify whether it uses the same rule of thumb to define abuse, but the intention behind the rule seems to be the same as the intention behind the meta-answer which defines the loophole, and I don't see a good argument against assuming that the same rule of thumb applies. On that basis, hard-coding all of the values which fit inside a language's native integer size is abuse and such answers are not valid.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .