'Allergies': Vague instruction vis-à-vis final testset's case

[ANotFox]

For Exercise: Allergies
Link: https://exercism.org/tracks/julia/exercises/allergies

As per the instructions, components of 256, 512, etc ought to be ignored. Essentially, this is asking a student to only work with values modulus 256 (with sum of all allergens being 255). However, the wording is unclear and can be improved as it is difficult to understand what 'ignoring' means.

At first, I assumed that for any value >=256, 'eggs' would be returned, and had to rectify this error after learning from the community solutions.

The final testset's last case returns a Set with multiple allergens

@testset "testing for more allergies" begin
            @test allergy_list(3) == Set(["eggs", "peanuts"])
            @test allergy_list(5) == Set(["eggs", "shellfish"])
            @test allergy_list(248) == Set(["strawberries", "tomatoes", "chocolate", "pollen", "cats"])
            @test allergy_list(255) == Set(["eggs", "peanuts", "shellfish", "strawberries", "tomatoes", "chocolate", "pollen", "cats"])

# this            
@test allergy_list(509) == Set(["eggs", "shellfish", "strawberries", "tomatoes", "chocolate", "pollen", "cats"])
        end

Suggestion:

• Reword the line to make it clear that even if the allergen score is over 255, it can be scaled down (for example by a modulus).
• Add another example of a score > 255, increasing clarity on finding allergens

If this is not just me misreading the instructions (as a non-native speaker), I could do a pull request with another example and mild rewording in allergies/.docs/instructions.md. Thank you!

[depial]

Firstly, thanks for the suggestions!

I feel the wording in the instructions is appropriate since it is seems to be suggestive of using bitstrings or the binary representations of the number (example), and I think that is an implicit aim of the exercise (hence the powers of two). As an aside, I personally tend to enjoy leaving a bit of ambiguity in instructions because this mimics the imperfect information that we often have to deal with in the real world.

That being said, this is an "easy" exercise, so I could see room for a little more clarity. I would be open to possibly replacing the egg example with another example which is a bit more illustrative. For example, maybe we could reuse the given example for 34 by using the score 290. That way the list would be the same as 34 when 256 is ignored. In any case, I would like to avoid explicitly using the words modulo/modulus and to keep the level of ambiguity in line with the given example of 34. Maybe something like:

Note: a given score may include allergens not listed above (i.e. allergens that score 256, 512, 1024, etc.). Your program should ignore those components of the score. For example, if the allergy score is 290, your program should report the peanut (2) and chocolate (32) allergies since (256) is ignored.

I would also like to see if @colinleach has an opinion on this, but If you would like to open a PR along these lines, we could move ahead that way, or you can feel free to continue the conversation here.

[colinleach]

This isn't a Julia-specific issue. The instructions are synced to the problem-specifications repo that is shared by all tracks.

Improving these shared documents is important, and something that people spend a lot of time and effort on, but it also needs a lot of people to agree before anything can be merged. At a minimum, we need to take this away from the Julia repo and start a discussion on the forum where more people are likely to see it.

This is one of Exercism's oldest exercises (11 years!), and if I counted correctly it is implemented on 69 tracks so far. I expect there will be a willingness to fine-tune the wording, but be prepared for what could be a long discussion.

[ANotFox]

Thank you for the swift responses.

I could not find any issue regarding the wording for the exercise in the Julia track and thus, raised it. Closest forum question regarding the wording was on providing a hint.

I think it just might be misunderstanding on my end then. Rather than changing the wording, is replacing the example (reusing 34 with 290 as depial had said) or adding another one more viable?

If not, I am fine with closing this issue; appreciate the work done for the exercise.

[colinleach]

The examples used for testing are also common across tracks. It is possible to make track-specific changes, but this is normally done because of technical limitations of a language (such as having no integers larger than Int32). Again, if the exercise as it currently exists is unclear, I think it would be better to make the changes in problem-specifications where they benefit all tracks. Exercism has grown to have a large and complicated code base, so we try to share as much as possible. Starting discussions on the Exercism Forum helps to coordinate this.

Any thoughts, @depial?

[depial]

The examples used for testing are also common across tracks.

Rather than any testing examples, I believe ANotFox was referring to the change from the (rather terse) egg example at the end of instructions.md to a more descriptive one (like the example I offered), which seems like it would be a fairly minor change.

While I see the benefit of opening an issue at the problem_specifications level, if that is a no-go or gets bogged down, are we still tied to using what we may deem to be an inferior description? I would hope we could make minor modifications of this type without consulting the full organization. I guess this is partially due to having been fairly preoccupied with other things recently (I hope to have more time to contribute here come February!) and not really feeling up for opening a potential can of worms over such a simple issue.

Another point could be that someone who is new to contributing might balk at having to deal with opening an organization-wide issue or PR, while a track specific one may look much less daunting. I would like to avoid potentially disenfranchising new contributors in this way since their continued input is valuable even as the site matures.

On that note, thanks again @ANotFox for bringing this up!

[colinleach]

While I see the benefit of opening an issue at the problem_specifications level, if that is a no-go or gets bogged down, are we still tied to using what we may deem to be an inferior description?

Sorry, I still think that if it needs changing on the Julia track, it needs changing everywhere. These documents are synchronized for valid reasons (and past bad experiences when failing to sync them), Unless we put the changes in an instructions.append.md, the instructions.md will just be overwritten next time someone runs configlet sync.

I'm grateful to @ANotFox for raising this, but changing the instructions for standard Practice Exercises needs to be discussed first on the forum.