Communities

The Great Outdoors

Photography & Video

Scientific Speculation

Electrical Engineering

Languages & Linguistics

Software Development

Community Proposals

tag:snake search within a tag

answers:0 unanswered questions

user:xxxx search by author id

score:0.5 posts with 0.5+ score

"snake oil" exact phrase

votes:4 posts with 4+ votes

created:<1w created < 1 week ago

post_type:xxxx type of post

Notifications

Mark all as read See all your notifications »

Challenges Q&A Sandbox Meta

Meta

Posts Tags Edits

Comments on Using environment variables in code golf

Post

Using environment variables in code golf

+0

−0

I wrote a code golf answer which depends on setting an environment variable before running the code. I've assumed that the bytes used to define the environment variable should be added to the score, but I'm not sure if this is covered by existing default rules.

Should setting environment variables:

Be forbidden?
Be allowed as competition in the same language, with the additional bytes added to the score?
Be considered a different language, with the additional bytes added to the score?
Be considered a different language, with the additional bytes not added to the score?

Similar cases

In Default Rules: Libraries the consensus is that competing in "language + library" (for any library other than the language's standard libraries) is considered a different language. The bytes required to import the library are added to the score.
In Default Rules: Flags and Other Compile-Time Options the consensus is that changing the language's behaviour causes it to be considered a different language. The bytes required to set a flag or compile-time option are not added to the score.

Specific details for my example

In my answer, the environment variable is set before running the program:

PYTHONHASHSEED=764

This has 2 independent effects:

Defining a seed causes the hash function to be consistent between runs of the program (which it wouldn't normally be for security reasons).
Choosing the specific value 764 makes the particular hashes used in my answer unique in the final 3 bytes, allowing me to save bytes by hard coding only the final 3 bytes of each relevant hash.

The first of these is like switching on an optional feature. The second is fine tuning the language's behaviour to suit the challenge. Are both acceptable? If I were setting a random seed within a program rather than before running it, I would consider that acceptable, but then those bytes would be included in the score. I mention it here in case it affects your opinion on whether the bytes used to set the environment variable should be added to the score.

The current consensus that the bytes for flags and compile-time options are not added to the score makes me feel that treating that default rule as applying to environment variables would be a loophole. I'm not sure if that's a reason to treat environment variables separately, or to change the flags and compile-time options rule to add the bytes to the score in general.

discussion

posted 2 days ago

CC BY-SA 4.0

2d ago

1215 reputation 99 23 156 505

Raw

Markdown

is a duplicate

This question has been asked before and has already been answered. It should be marked as a duplicate.

Please enter the URL of the proposed duplicate in the details field below.

not constructive

This question cannot be answered in a way that is helpful to anyone. It's not possible to learn something from possible answers, except for the solution for the specific problem of the asker.

1 comment thread

Avoiding meta cruft (4 comments)

WheatWizard‭ wrote 2 days ago

I don't have a nice answer, but I would argue against option 2. I think we should try to avoid adding special rules to the meta. I don't think it's fun when someone comes up with a shorter answer based on the evocation of an obscure meta post from years back. And unless this is collated into another meta post it will likely become obscure rather quickly.

In theory, option 3 avoids this since users that know about the obscure meta will be in their own category. However, I think it's an open secret that many users find it difficult to not compare between different languages (esp. when those languages are similar). Further golflang designers are playing the meta game of optimizing between languages. I'm less worried about this option though, since these concerns are weak.

trichoplax‭ wrote 1 day ago

That's a good point about obscure rules.

I added the hash function to my answer, and then realised it wouldn't work without setting an environment variable, and then assumed that the correct course of action would be to add the bytes to the score, but that felt unfair on the other Python answer, which uses clever tricks rather than sidestepping the problem by manipulating the language. So option 2 is also my least favoured.

trichoplax‭ wrote 1 day ago

Option 4 is effectively treating environment variables the same way as flags and compiler options, but I'm not entirely comfortable with that existing default rule either. Flags and compile-time options can also be used to fine tune the language to the challenge.

I might be convinced by an answer arguing for option 1 (forbidding), but I can't see how that would be fair without also forbidding flags and compile-time options.

For now I've edited my answer to show the language as "Python 3 + PYTHONHASHSEED=764" and added those bytes to the score (following option 3), so at least the "real" Python answer shows as first place for Python 3 again.