8
\$\begingroup\$

When writing challenges involving integer I/O, I always find myself having to type the same thing: You may assume that the input and output will not exceed the maximum representable range in your language. I think it would be useful if we had a default for integer ranges in challenges, to avoid needing the same text in every challenge (and if chat stars are anything to go by, I'm not alone in this).

Should we have a default integer range? If so, what should it be?

\$\endgroup\$
  • \$\begingroup\$ I'm having a lot of trouble putting this into a concrete answer, but I think the solution shouldn't be assumptions on the input/output, but something more like "the answer is valid as long as the algorithm works in theory". But that opens another can of worms with arbitrary precision floats. \$\endgroup\$ – Sp3000 Feb 17 '16 at 5:04
  • 2
    \$\begingroup\$ I personally would never allow people that much flexibility, because there are languages in which the maximum representable range is 1 bit. \$\endgroup\$ – Peter Taylor Feb 17 '16 at 8:22
  • 3
    \$\begingroup\$ @PeterTaylor which is covered by this loophole iir \$\endgroup\$ – Downgoat Feb 17 '16 at 15:09
  • \$\begingroup\$ This is not one particular problem that regard input output: It is a general one that regard each function has at last one arg... \$\endgroup\$ – RosLuP Jan 19 '18 at 9:25
4
\$\begingroup\$

Any intermediary value should not exceed...

... as long as the author does not purposely minimize the valid input range by performing otherwise unnecessary calculations to bump against a limit.

If we only put limits on I/O, the following trivial challenge will be almost impossible:

Write a function or program that returns its argument plus one.

\$\endgroup\$
3
\$\begingroup\$

I think this is a good idea.

For one, it saves challenge authors a lot of work. Not only that, but it potentially lowers the barrier to entry for newer challenge authors would wouldn't have thought to consider that.

We have a standard loophole that would help to guard against abuse of this default.

I would propose that the default upper and lower bounds be the bounds on what's representable in a single signed numeric value (integer or float) in the given language.

\$\endgroup\$
  • \$\begingroup\$ What if the language doesn't have an integer type? JavaScript, for example, only has double precision floats. \$\endgroup\$ – Dennis Feb 17 '16 at 4:56
  • \$\begingroup\$ @Dennis That's a good point. Clarified a tad. Still run into the issue with potential overflow just from a simple calculation on a big input though. \$\endgroup\$ – Alex A. Feb 17 '16 at 5:11
  • \$\begingroup\$ This can severely handicap c answers. The largest integer type is typically something like u?int64_t, but to use this you must #include <stdint.h>, as well as use 7 or 8 character type name. Plain old int is much nicer to golf in, especially as its the default type for globals. \$\endgroup\$ – Digital Trauma Feb 19 '16 at 1:19
  • \$\begingroup\$ @DigitalTrauma I think having the default be something like You may assume that the inputs and outputs will be no greater than the maximum representable integer in your language or 2^64 - 1, whichever is less (from OP's recent challenge) but using a more reasonable default (2^32-1?) could be a solution to this. \$\endgroup\$ – user81655 Feb 19 '16 at 4:40
  • 1
    \$\begingroup\$ @DigitalTrauma For C I assumed this would apply to int, not int64_t or anything fancy. \$\endgroup\$ – Alex A. Feb 19 '16 at 5:10
1
\$\begingroup\$

The I/O should not result in a value exceeding the language's representable number range

(What you stated)

Keep this loophole in mind.

"Number" is defined as the most "basic" (or default) numeric "type" the language uses (e.g. JavaScript's floats, C's int)

If the default numeric type has no limit then there is no limit to the I/O integers until the system runs out of memory. (e.g. Python's numbers).

Also, as @Nbz stated in his answer. Unnecessary or purposeful code to minimize the range of valid inputs should be prohibited

\$\endgroup\$
  • \$\begingroup\$ The only issue I can see is with languages such as Python, where there is a seamless, invisible transition into a bignum type outside of a certain range. \$\endgroup\$ – Mego Feb 17 '16 at 4:48
  • 3
    \$\begingroup\$ What if the language doesn't have an integer type? (JavaScript, for example, only has double precision floats.) What if input and output can be represented, but the intermediate values of my calculations cannot? \$\endgroup\$ – Dennis Feb 17 '16 at 5:02
  • \$\begingroup\$ @Dennis I was thinking on how to phrase that. I guess I'll clarify \$\endgroup\$ – Downgoat Feb 17 '16 at 5:03
  • \$\begingroup\$ This doesn't address languages which have no maximum/minimum representable value (like I mentioned in an earlier comment). \$\endgroup\$ – Mego Feb 19 '16 at 4:48
  • \$\begingroup\$ @Mego specifically addressed that, I hope I make sense in the edit \$\endgroup\$ – Downgoat Feb 19 '16 at 4:52
  • 2
    \$\begingroup\$ @Downgoat Works for me :) \$\endgroup\$ – Mego Feb 19 '16 at 4:52
  • \$\begingroup\$ What's a "default" number type? Sure, C has int but that only goes up to 2^32 or 2^64, and C also has double which is insanely huge. \$\endgroup\$ – cat Mar 2 '16 at 0:26
  • 1
    \$\begingroup\$ @tac that's difficult to define but the most "basic" integer type is the way I could. Considering the broad range of ways languages store numbers, there is some subjectivity when defining a "default" number type \$\endgroup\$ – Downgoat Mar 2 '16 at 0:43
  • \$\begingroup\$ @Downgoat (excuse my pretend-daftness to prove my point, but) Golang has integer types down to int8, and I'm very certain it's not a chore to find a language with support for 4 bit numbers. 4 or 8 bits seems pretty "basic"; far more "basic" than int. int is indeed ubiquitous, but that's not very objective :( \$\endgroup\$ – cat Mar 2 '16 at 0:46
-1
\$\begingroup\$

The range for the arg of function return right result must be in the answers code

The note negative for the 99% answers, that down quality of them: The absence of a range in the code for a valid argument for function that return a right result.

There would be a range limit for the arg of the function; something as 1..20000 and each answer would indicate its kind of range the argument has to be for to be safe to pass to the function (without one seg fault in the code, without one memory insufficient for the program, without one incorrect value return as result ).

So it is not the question that specify the general range of validity for the answers (perhaps a minimum range) but it is the answer specific it, based of restrictions: language, mean PC power computation, algorithm etc.

\$\endgroup\$

You must log in to answer this question.

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