10
\$\begingroup\$

When dealing with list input in C, as in this question, is it acceptable to add extra argument to indicate the length of the list?

It does give advantages because other language needs functions like len(M), but I cannot figure out a simple way to represent such a list in C.

\$\endgroup\$
  • 7
    \$\begingroup\$ If your language can't achieve something natively then you need to either implement a workaround or pick a different language for the challenge. Every language has its shortcomings that we all have to deal with and not every language will be suited to every challenge. Sidenote: This might be better as a tips question on main, asking how to get the length of a list in C. \$\endgroup\$ – Shaggy Jul 6 '17 at 8:33
  • \$\begingroup\$ this deleted answer to the Default input/output question proposed the same thing. It was down-voted, then deleted by the owner. \$\endgroup\$ – MegaTom Jul 10 '17 at 15:26
11
\$\begingroup\$

This is an interesting indication of the way PPCG has changed since the early days. I remember when a lot of questions included the length as a separate input and people commented with requests to make it optional because their high-level languages didn't need it.

In most high-level languages an array is effectively a struct with a pointer and a length. I don't see that there's any point to creating a standard struct template. However, it does seem perfectly reasonable to interpret "array" in a question as meaning "pointer and length, as encapsulated in your language". In the case of C the simplest "encapsulation"* is as two variables.

* Yes, I get the point that it's not really encapsulation if you can split them up, hence the scare quotes. But such pedanticism is not the point here.

\$\endgroup\$
  • \$\begingroup\$ Would you suggest that in higher level languages where Arrays have the length packaged that you should not be allowed to assume a separate length parameter (i.e. requirement to use natural I/O) \$\endgroup\$ – VisualMelon Jul 7 '17 at 18:19
  • \$\begingroup\$ @VisualMelon, I'd have to think about the implications of that. I mainly golf in a language which usually prefers not to receive the length as a separate argument, so I don't have a good intuition as to whether that's a good idea. My main aim here was to cast the question in a historical context. \$\endgroup\$ – Peter Taylor Jul 8 '17 at 8:54
  • 1
    \$\begingroup\$ I think the correct word is pedantry. Just sayin'. \$\endgroup\$ – Esolanging Fruit Jul 8 '17 at 9:04
  • 4
    \$\begingroup\$ @Challenger5, collinsdictionary.com/dictionary/english/pedanticism \$\endgroup\$ – Peter Taylor Jul 8 '17 at 10:03
  • 1
    \$\begingroup\$ @PeterTaylor Fine. \$\endgroup\$ – Esolanging Fruit Jul 8 '17 at 17:49
11
\$\begingroup\$

Not for all languages

I estimate 15% of my Python golfs with list input could be shortened by taking in its length, if that were allowed. Hundreds of golfs in mainstream languages could be improved by mechanically replacing "len(l)" or similar with an input parameter.

These submissions strongly suggest that golfers wouldn't guess this to be allowed without knowing the rule specifically. This is a hidden rule of the worst kind -- broadly useful, unexpected, and likely to make golfs more boring on average.

I'm sympathetic to the problems languages like C have with cumbersome input processing, especially as they already have many disadvantages. Golfing languages can be designed around such issues, but C is stuck with them.

But, I want to avoid the trend of giving all languages an easy extra workaround because one language really wants it. The result is a laundry list of liberties with input that go beyond taking it conveniently and naturally for the language, to doing parts of the golfing task in the input format, justified by citing obscure meta threads about other languages.

I'd rather say that this is a property of C that golfers need to deal with, or that a C-specific rule be made. Either one would be better than changing the rules for all languages.

\$\endgroup\$
  • 1
    \$\begingroup\$ A language-specific rule would essentially cause asking for different things from different languages as a default. That's undesirable. I don't think that this would negatively affect golfs - one could argue that allowing function submissions to be unnamed lambdas is a similar sort of "hidden rule" - many newcomers don't know about it until veterans specifically point it out to them. That rule isn't detrimental to golfing, so why would this rule? IMO allowing more options for golfing is usually a good thing. \$\endgroup\$ – Mego Jul 8 '17 at 9:10
  • 13
    \$\begingroup\$ This seems reasonable to me, actually. In languages where "array" is a first-class type, then you can't break it up into multiple pieces. However, in C, an array actually is represented by two distinct components: a pointer to the first element and the length. So there's no need for a new, language-specific rule. The existing rule is fine: take an array as an input. You just have to know what "array" means in C. It is 100% conventional to pass arrays to functions in C as a pointer and an integer. The darn main function does so! \$\endgroup\$ – Cody Gray Jul 9 '17 at 15:09
5
\$\begingroup\$

Yes, solutions may take the length of variable-length input as an additional input parameter

In non-golf C, taking the length of an array as a parameter alongside a pointer to the array is standard. Just look at the multitudes of functions in the standard library that do exactly that. So, a precedent exists for the language.

In general, it is impossible to determine the length of an array in C without special assumptions. sizeof only works if the array was statically allocated (no malloc), and the reference hasn't decayed to a pointer (like it does when you pass it as a function parameter). There is no hack that is 100% effective.

This means that C (and other languages like it) have a severe disadvantage when it comes to variable-length input. The only surefire way to do variable-length input in C is to read from STDIN into a buffer until EOF (and if there isn't a maximum number of elements, be prepared to have to realloc that buffer). Because of the severe restriction on input formats, solutions in C are forced to use a cumbersome input format, something which the community has decided is undesirable. C solutions are essentially solving a different challenge.

So yes, let's allow solutions to take the length of variable-length input as an additional input parameter. The only challenge this change could possibly trivialize is "Find the length of a list", and that challenge would already be trivialized by the preponderance of languages with built-in list length functionality. This change will do very little harm, and much more good.

\$\endgroup\$
  • \$\begingroup\$ let's allow solutions to take the length of variable-length input as an additional input parameter --> Just to clarify, you are expanding this to all languages, right? So I can take an extra input l in JavaScript arrow functions that is assumed to equal a.length? \$\endgroup\$ – Stephen Jul 7 '17 at 14:45
  • \$\begingroup\$ @StepHen Yes, I see no good reason to limit it to specific languages. \$\endgroup\$ – Mego Jul 7 '17 at 14:46
0
\$\begingroup\$

No

Not if the specifications do not explicitly allow it. There cannot be a clear line of what is allowed as extra input - sure, a list length seems reasonable, but this is really the user executing part of your algorithm. E.g., if the length of an array is allowed, why not a boolean array indicating which elements are prime? Saves a lot of effort implementing isprime if your algorithm needs it!

You are free to implement workarounds for features your language does not natively have - often, that's the part of the fun! Perhaps your language may not have a sizeof function, but why not scan the input until encountering a null byte, and calculate the length on the go?

If your language does not, in any imaginable way, perform the desired operation, you can always ask if your extra input is allowed by commenting on the OP - but do not be surprised to get a sound no - sometimes, your language is just not up for the task.

\$\endgroup\$
  • 4
    \$\begingroup\$ Your slippery slope argument doesn't make sense. The length of a list input is inherently part of the input - a boolean array indicating which elements are prime is not, and is clearly cheating if required as an input. \$\endgroup\$ – Mego Jul 7 '17 at 11:18
  • \$\begingroup\$ @Mego I've never been good for examples. But to me, the list length as somehow being an 'inherent part', and no other property of such a list, seems very arbitrary to me. \$\endgroup\$ – Sanchises Jul 7 '17 at 14:13
  • 4
    \$\begingroup\$ The list length is an inherent property. There are two inherent properties for a list: its length and its content. Allowing both of those properties to be taken as explicit input doesn't lead to a slippery slope. \$\endgroup\$ – Mego Jul 7 '17 at 14:15
0
\$\begingroup\$

We have a catalog for this already...

The Default Input/Output methods question is made to answer these sorts of questions. I have created an answer to that question*, for representing an array as a pointer and length. link.

I think the best way to settle this question is voting on that answer.

*As I commented above, an old answer proposed this, but was deleted, so I chose to propose my own version.

\$\endgroup\$
-2
\$\begingroup\$

No

Expanding on my comment slightly:

Every language has its shortcomings and every language will come up against challenges that expose those shortcomings. If your chosen language can't achieve something natively then your options are to:

  1. Implement a workaround. A well written "hack" to get your language to do something it was never intended to do will always impress, even it it comes at heavy byte cost. This can lead to higher upvotes and, on occasion, bounties.

  2. Accept that your chosen language can't accomplish the task at hand and use a different language instead.

If we were to allow C to take list length as a separate argument then that sets a precedent and, once it's set, where do we draw the line?

\$\endgroup\$
  • 3
    \$\begingroup\$ "If we were to allow C to take list length as a separate argument then that sets a precedent and, once it's set, where do we draw the line?" - We draw the line there. Your slippery slope argument doesn't make sense. \$\endgroup\$ – Mego Jul 7 '17 at 11:18
  • 1
    \$\begingroup\$ "Every language has its shortcomings" Ironic, considering that all your fancy golfing languages are basically abstractions on top of Python, which is itself an abstraction on top of C. This isn't a "shortcoming" of C; this is how arrays are represented in C: a pointer to the first element and a value indicating the length. It isn't at all true that C cannot "accomplish the task at hand", it's only true that the challenge was presented naively by someone who was unfamiliar with C. \$\endgroup\$ – Cody Gray Jul 9 '17 at 15:06

You must log in to answer this question.

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