resistor-color-duo: Fix wording in description, add test case #1605

sshine · 2019-10-13T16:51:17Z

TL;DR:

Add ["black", "brown"] test case.
Clarify "numerical value".
Remove "even if the input is more than two colors!"
Add conditional before and clarify "ignoring the third color."
Change formatting of the last two bullets (there were none).

Bumping the canonical version in exercism/haskell#865, I encountered some problems that I'd like to address.

Each band has a position and a numeric value.

Since the first bands of a resistor denote the numeric value, perhaps it should read "a numeric and a positional value" in that order. After all, the positional value serves only as thematic context when looking at this exercise in isolation, which the student does regardless of whether the track implements resistor-color-trio in succession or not: addressing the positional value either happens at a later point in time, or not at all.

For example, if they printed a brown band (value 1) followed by a green band (value 5), it would translate to the number 15.

Since this interpretation of colored bands only applies to the numeric value, perhaps it should say "numeric value 15", since one brown band followed by one green band in the context of the exercise does not address the positional value or the full resistance value of the resistor.

An additional didactic point of concern: It may also say "numeric value 10 + 5 = 15, as if the colors were digits", to signify how the example is derived. (I saw a guy live code this exercise on twitch, and this part is not obvious.)

The program will take color names as input and output a two digit number,

As resistor-color-duo is implemented on 12 tracks, here is how they interpret "black, brown" (0, 1):

bash: 01 -- according to specification.
javascript / ecmascript: 1
nim: 1
dart: 1
crystal: 1
haskell: 1
java: 1
d: 1
c: 1
python: 1
ruby: 1

The only language that follows the specification is the only one where integers are represented as strings and so concatenate prefix zeroes easily. Unfortunately there is no test case that starts with "black" to demonstrate which interpretation is correct.

Given that the README speaks of the output as a numeric value, and given that canonical-tests.json has "expected": 10 for "colors": ["brown", "black"] rather than "expected": "10", it would make sense to regard prefix zeroes as redundant, and as such, the formulation should be changed to "a numeric value of at most two digits" to be true, and to clarify that the function does not address the positional value.

And it would make sense to add the following test:

+    {
+      "description": "Black and brown",
+      "property": "value",
+      "input": {
+        "colors": ["black", "brown"]
+      },
+      "expected": 1
+    },

For the last and most problematic case:

even if the input is more than two colors!

brown-green-violet should return 15 too, ignoring the third color.

    {
      description: Ignore additional colors,
      property: value,
      input: {
        colors: [green, brown, orange]
      },
      expected: 51
    }

The following two formulations and test case were added in #1569 that "aims to fix a basic implementation bug whereby any additional colors are also used in the calculation". The way many dynamic languages implement this function is with an input array capable of holding 0, 1, 2, 3 or more colors.

This third-band test case (and formulations) have made the function explicitly more ambiguous: Unlike 0 or 1 bands, which is undefined, the third band should be ignored, and >3 bands are undefined. Presumably they should be ignored as well, but following this logic, should 0 or 1 bands also be ignored, giving the result 0?

Before #1569, the Haskell track originally chose in exercism/haskell#808 to go with the same dynamic and error-prone approach, whereby the following sufficed:

value :: [Color] -> Int
value [a, b] = 10 * value1 a + value1 b

value1 :: Color -> Int
value1 = ...

Since this function may easily be modelled as a pure, total function instead, alternative implementations might have one of the following type signatures

value :: (Color, Color) -> Int
value :: [Color] -> Maybe Int
value :: [Color] -> Either String Int
value :: [Color] -> Either ColorError Int

depending on the aim of the exercise. Since error handling was initially argued against in exercism/haskell#808, the only pure, total alternative is value :: (Color, Color) -> Int. Fortunately, track maintainers get to decide how an exercise is best implemented for a given language, but unfortunately, this choice is not compatible with the wording of the problem description on two accounts:

It is not true that the numeric value is two digits. Fortunately, this is not true on 11 of 12 tracks, so changing it to "of at most two digits" can safely be regarded as a bugfix at the expense of @exercism/bash maintainers, who may still choose to keep the exercise as-is if they so prefer, since "of at most two digits" correctly describes an output of 01.
There can be no third color in value :: (Color, Color) -> Int, and indeed, should there be, it would be an error. Due to Haskell's type system, such errors are promoted to compile-time type errors, rather than run-time errors. Since most tracks that implement this exercise use a variable-length input list/array, the wording of a third color may apply here, and so removing these formulations would affect most other implementing tracks negatively.

A compromise would be to remove the sentence "even if the input is more than two colors!" and change the last formulation to "If your language track enables more than two colors as input, such as brown, green and violet, this should return 15, too, ignoring additional colors beyond the first two."

This preserves the (justifiable but unsafe) ambiguity of 0 and 1 color for those tracks that prefer run-time errors, and it removes the additional ambiguity of differentiating 3 colors but not >3.

And it gives preference to the majority of tracks at the slight expense of one track.

TL;DR: - Add `["black", "brown"]` test case. - Clarify "numerical value". - Remove "even if the input is more than two colors!" - Add conditional before and clarify "ignoring the third color." - Change formatting of the last two bullets (there were none). Bumping the canonical version in exercism/haskell#865, I encountered some problems that I'd like to address. > Each band has a position and a numeric value. Since the first bands of a resistor denote the numeric value, perhaps it should read "a numeric and a positional value" in that order. After all, the positional value serves only as thematic context when looking at this exercise in isolation, which the student does regardless of whether the track implements resistor-color-trio in succession or not: addressing the positional value either happens at a later point in time, or not at all. > For example, if they printed a brown band (value 1) followed by a green band (value 5), it would translate to the number 15. Since this interpretation of colored bands only applies to the numeric value, perhaps it should say "numeric value 15", since one brown band followed by one green band in the context of the exercise does not address the positional value or the full resistance value of the resistor. An additional didactic point of concern: It may also say "numeric value 10 + 5 = 15, as if the colors were digits", to signify how the example is derived. (I saw a guy live code this exercise on twitch, and this part is not obvious.) > The program will take color names as input and output *a two digit number*, As resistor-color-duo is implemented on 12 tracks, here is how they interpret "black, brown" (0, 1): - bash: `01` -- according to specification. - javascript / ecmascript: `1` - nim: `1` - dart: `1` - crystal: `1` - haskell: `1` - java: `1` - d: `1` - c: `1` - python: `1` - ruby: `1` The only language that follows the specification is the only one where integers are represented as strings and so concatenate prefix zeroes easily. Unfortunately there is no test case that starts with "black" to demonstrate which interpretation is correct. Given that the README speaks of the output as a numeric value, and given that canonical-tests.json has `"expected": 10` for `"colors": ["brown", "black"]` rather than `"expected": "10"`, it would make sense to regard prefix zeroes as redundant, and as such, the formulation should be changed to "a numeric value of at most two digits" to be true, and to clarify that the function does not address the positional value. And it would make sense to add the following test: ```diff + { + "description": "Black and brown", + "property": "value", + "input": { + "colors": ["black", "brown"] + }, + "expected": 1 + }, ``` For the last and most problematic case: > even if the input is more than two colors! > brown-green-violet should return 15 too, ignoring the third color. > ``` > { > description: Ignore additional colors, > property: value, > input: { > colors: [green, brown, orange] > }, > expected: 51 > } > ``` The following two formulations and test case were added in #1569 that "aims to fix a basic implementation bug whereby any additional colors are also used in the calculation". The way many dynamic languages implement this function is with an input array capable of holding 0, 1, 2, 3 or more colors. This third-band test case (and formulations) have made the function explicitly more ambiguous: Unlike 0 or 1 bands, which is undefined, the third band should be ignored, and >3 bands are undefined. Presumably they should be ignored as well, but following this logic, should 0 or 1 bands also be ignored, giving the result `0`? Before #1569, the Haskell track originally chose in exercism/haskell#808 to go with the same dynamic and error-prone approach, whereby the following sufficed: ```haskell value :: [Color] -> Int value [a, b] = 10 * value1 a + value1 b value1 :: Color -> Int value1 = ... ``` Since this function may easily be modelled as a [pure](https://en.wikipedia.org/wiki/Pure_function), [total](https://en.wikipedia.org/wiki/Total_functional_programming) function instead, alternative implementations might have one of the following type signatures ```haskell value :: (Color, Color) -> Int value :: [Color] -> Maybe Int value :: [Color] -> Either String Int value :: [Color] -> Either ColorError Int ``` depending on the aim of the exercise. Since error handling was initially argued against in exercism/haskell#808, the only pure, total alternative is `value :: (Color, Color) -> Int`. Fortunately, track maintainers get to decide how an exercise is best implemented for a given language, but unfortunately, this choice is not compatible with the wording of the problem description on two accounts: 1. It is not true that the numeric value is two digits. Fortunately, this is not true on 11 of 12 tracks, so changing it to "of at most two digits" can safely be regarded as a bugfix at the expense of @exercism/bash maintainers, who may still choose to keep the exercise as-is if they so prefer, since "of at most two digits" correctly describes an output of `01`. 2. There can be no third color in `value :: (Color, Color) -> Int`, and indeed, should there be, it would be an error. Due to Haskell's type system, such errors are promoted to compile-time type errors, rather than run-time errors. Since most tracks that implement this exercise use a variable-length input list/array, the wording of a third color may apply here, and so removing these formulations would affect most other implementing tracks negatively. A compromise would be to remove the sentence "even if the input is more than two colors!" and change the last formulation to "If your language track enables more than two colors as input, such as brown, green and violet, this should return 15, too, ignoring additional colors beyond the first two." This preserves the (justifiable but unsafe) ambiguity of 0 and 1 color for those tracks that prefer run-time errors, and it removes the additional ambiguity of differentiating 3 colors but not >3. And it gives preference to the majority of tracks at the slight expense of one track.

SleeplessByte · 2019-10-13T21:48:07Z

I don't quite understand the issue, please help me understand it given the following:

01 is as correct as 1. A numeric value of 01 is, in _in any base using 0 and 1 as "first two values" the same value. A resistor value with leading zeros is not special. It doesn't need a special interpretation. There is no ambiguity with leading zeros. The resistor value is a "composition of numerical values", which we'll see in resistor-color-trio and quartet (and perhaps quintet).

One of the multiple reasons we opted to have a "third band" input is because:

Often students on exercism just solve it "the quickest way", without carefully reading the instructions. They come up with solutions that pass the test, but always NEED mentoring because they aren't the idiomatic way.
Arguing that they should optimise for 2 values is hard without a test case.
Adding a test case and explicitly denoting only the first two colors should be processed, solves that.

I would actually argue that a solution such as

value [a, b] = 10 * value1 a + value1 b

is perfect. I think it's exactly what we would like to see. To this end, I think that Haskell doesn't require to implement this test case (I wanted it to be optional in the first place).

I personally also wanted "numerical value", but I believe Katrina is against that wording (perhaps because it's very scolarly?).

sshine · 2019-10-13T22:43:16Z

01 is as correct as 1. A numeric value of 01 is, in _in any base using 0 and 1 as "first two values" the same value. A resistor value with leading zeros is not special. It doesn't need a special interpretation. There is no ambiguity with leading zeros. The resistor value is a "composition of numerical values", which we'll see in resistor-color-trio and quartet (and perhaps quintet).

I'm not sure where this is going: I have not said that 01 is not as correct as 1. In fact, I've said that the bash track can continue to keep this leading zero if they like. (However, come to think of it, @thriqon submitted #1586 on behalf of the bash track because of concerns of leading zeroes being interpreted as octal, so perhaps this is not a good preference the bash track has picked in this exercise, according to its own standards, even though they're technically the only track that returns two of something.)

When you say "01 is as correct as 1", this requires context; for example, JSON does not allow one, and it allows the other, so they are not both correct ways to express the same value in canonical-data.json. When you say "There is no ambiguity with leading zeros.", this statement can not be made in general. For example, for (black, grey) = (0, 8), Perl would not accept the token 08.

One of the multiple reasons we opted to have a "third band" input [...]

Yes, I think I understand that -trio addresses the third band differently, and so -duo leaves the student without any definition of what it does, they generalise their data type, the variable-length list. So we're really asking people to half-solve an exercise, because the rest is coming. So the extra test is a hint that tells the student "don't make the wrong assumptions about the third band".

If you also notice, I did not propose that we remove this test. I've removed it on the Haskell track because the model of creating a partial function in a highly specific way, rather than make a total function, does not fit the implementation I seek to have in exercism/haskell#808.

If writing a value :: [Color] -> Int were on the way to write a total function, I think it might've made sense to encourage students submit a partial functions, but since this function will always be partial, since it is not defined for transistors of 0, 1 or >K bands, it simply never qualifies to be a good solution on the Haskell track.

I would actually argue that a solution such as
value [a, b] = 10 * value1 a + value1 b
is perfect. [...]

I believe the word you're looking for is partial.

I think it's exactly what we would like to see.

Yes, if we either would like students to submit half-solved problems because they will be fully-solved in the succeeding -trio exercise, or if we like to encourage students to write software that breaks at run-time when it could have been avoided. Now, both of these preferences are optional at the track-level: resistor-color-trio isn't yet on the Haskell track (but I've been wanting to add it), and neither is a preference for partial functions.

I think that Haskell doesn't require to implement this test case (I wanted it to be optional in the first place).

Whether or not it has the "optional": "???" flag or not, all tests are optional.

I personally also wanted "numerical value", but I believe Katrina is against that wording (perhaps because it's very scolarly?).

I didn't think about that. We can use "number"; the point was to differentiate between the precision and the exponent.

SleeplessByte · 2019-10-13T22:58:55Z

When you say "01 is as correct as 1", this requires context; for example, JSON does not allow one, and it allows the other, so they are not both correct ways to express the same value in canonical-data.json. When you say "There is no ambiguity with leading zeros.", this statement can not be made in general. For example, for (black, grey) = (0, 8), Perl would not accept the token 08.

In the context of the exercise, where the output is a representation of a numerical value. We can find side-case for almost anything and everything that makes any <statement> without <disclaimer or giant list of far fetched edge cases> technically incorrect, but anything you say here doesn't make me want to retract my statement.

The word I was looking for is perfect. To me that solution is perfect, not partial. I am not a Haskell-pro, but from a didactic standpoint, at the moment in the track, I think the solution is how it should be.

There is a lot of information in your initial post and I am failing to see why it's there. What needs to change and why does it need to change? Why do we need an entire paper on the matter when your change seems to be regarding three things (I literally lose track whilst reading the original comment and the response comment about what they are about).

Can we add a test case that results into the value 1, so that ...? We put in writing that it should be 1 and not 01?? I don't understand why we need this test case. I personally don't mind if it was added, but the details in your post don't make me understand why we need it.
Can we change the wording so that it's less ambiguous? I am in full agreement with you here, but there was a choice made from product why it was not called numerical value, significant digit or something like that. Perhaps in this PR we can come up with something that would fly? Or maybe word the sentence completely different so that it's no longer ambiguous at all, without using the aforementioned word(groups)?
Can we add a "if your track xxx" disclaimer? I personally don't care for this one. If a track only has tests for 2 inputs, there is nothing wrong with saying "three" shouldn't be accepted. The wording might be changed? I would like to see a student complain about the wording before we make changes like this.

I think tracks don't use TrackInserts (HINTS) enough, for track specific behaviour. This is semi-related to this PR. I don't think we need to sculpt each README.md so that it's exactly ambiguous enough so that it works with every track. I think we need to make it work with almost all of them, and fix it in those where it doesn't. But that's my opinion on it. I'm not an authority on this, just giving it because I know you care about my opinion.

sshine · 2019-10-14T01:51:51Z

Just a quick disclaimer for @tejasbubane who did the original port of the exercise: I just want to make sure you know that none of this criticism is directed towards you: I agreed with and approved the exercise you originally ported. This PR addresses when constraints between systems unalign, not one person's work.

As I tagged this PR "hold" upon creation, the purpose of this PR was to delay decision but not forget for when the repo gets unlocked. Since discussion has no consequence to merging, this is my last post in this PR until the "hold" tag can be removed again.

@SleeplessByte wrote:

The word I was looking for is perfect. To me that solution is perfect, not partial. I am not a Haskell-pro, but from a didactic standpoint, at the moment in the track, I think the solution is how it should be.

You'll have to accept that others may disagree with you on this.

There is not a "the track", there are many tracks, and they're run differently.

At no point in the Haskell track will it make sense to ask students to do things they should avoid to repeat, as much as possible, in their career as functional programmers. See e.g. Haskell Wiki on partial functions (my emphasis):

The opposite is a total function. You should strive to avoid partial functions and instead write total ones. This makes it much easier to reason about your code and makes "if your code compiles, it probably works" true for your code more often.

Usually if you have a partial function, it's because your types are incorrect and you should fix your types rather than writing partial functions which guarantee the impossible.

There are situations where partial functions are warranted. This is not one of them. If you'd like to know why, I'd love to elaborate, but it seems that you're a little annoyed at my verbosity without saying that directly.

There is a lot of information in your initial post and I am failing to see why it's there. What needs to change and why does it need to change? Why do we need an entire paper on the matter when your change seems to be regarding three things:

I did write a TL;DR summary at the top for those who were not interested in my reasons.

And yes, there is a lot of information.

I'm not asking if we can have a test for (black, ...). I'm saying that if we don't, the description lies on all tracks that assume "significant" in "two digits" or use some integer return type that truncates leading zeroes (all but bash). If I only said that it lied, I'd eventually have to elaborate, so I did that immediately.

If we don't assume "significant" in "two digits", and assume equivalence between prefix zero and truncated prefix zero, all numbers have ∞ digits.
I'm not advocating for less ambiguous wording. The wording, on the Haskell track in specific, is wrong to a point where the track-specific hint has to excuse for gibberish: "It's not really two digits, sometimes it's one, and that third color you're asked to ignore, it's not really a part of the exercise, so you should ignore ignoring that."

So I considered my options as (a) accept that the exercise is wrong, and that students get confused, (b) change readme and break CI configlet, (c) change readme and disable CI configlet and maintain README updates manually, (d) deprecate the exercise, (e) make up for it in the track-specific hint, and (f) submit a PR.

I've went with (e) and eventually (f).

So thanks for recommending that I formulate myself less verbosely.

I can try and provide less reason for my actions and wait for people to ask me.

I would like to see a student complain about the wording before we make changes like this.

Okay:

https://www.twitch.tv/videos/492890976##

Here are some highlights that suggest track improvement points:

01:08:56: Problem caused by superfluous Read type class instance (Fixed in Implement Resistor Colors exercise haskell#808.)
01:11:15: Deals with three-band test case (just as you would like, nothing wrong), starts dealing with problems wrt. totality of the function.
01:13:07: Says there are not enough tests. (This PR adds one more.)
01:13:57: Reiterates problem caused by Read type class instance.
01:18:40: Discovers alternative solution that highlights error vs. 0 choice point.
01:27:01 - revisits error vs. 0 choice point. says: "OK, let's think about this in a different way. This is the wrong data type to be passing to this function. Just, strictly. It should take a tuple of Colors. Right? If we're thinking about this critically, this is the wrong data type [...]"

(This is where I omit the specific biimplications that the data type has on wording.)

SleeplessByte · 2019-10-14T02:30:55Z

You'll have to accept that others may disagree with you on this.

I don't know why you think that I don't accept that. You're telling me that I was looking for a specific word when I wasn't. I just gave my opinion on the solution, that's all. I was commenting on the implementation of the algorithm, not the fact that it's a "partial function" if there is a test with 3 colours.

note: you dropped a solution without the exact explanation that partial functions are probably not what you want. This is what I mean with "verbosity but no connection with the points being made". Now that you've explained it, I get it 🥇

There are situations where partial functions are warranted. This is not one of them. If you'd like to know why, I'd love to elaborate, but it seems that you're a little annoyed at my verbosity without saying that directly.

It's very hard for me to "speak subtly" or "hide meaning between the lines", so most of what I say can be taken at face value. I'm not annoyed with verbosity, I just don't see the connection between the verbosity and the proposal, adding cognitive complexity. That said tho, your addition here ís helpful. Apparently the tests currently are designed in such a way that a Haskell student is likely to implement it in a non-idiomatic way, if I understand you correctly. I think that is a really good reason to change something, either here in the canonical data, or in the track itself. Regardless of where the change happens, I think it should.

I did write a TL;DR summary at the top for those who were not interested in my reasons.

But I am interested in the reasons; however the reasoning itself (in the original post) does, for me, not tie to the points mentioned in the TL;DR. My bigger issue with the bookwork(s) has nothing to do with you, or this PR in particular, and I have no problem discussion it with you privately, just let me know :)

starts dealing with problems wrt. totality of the function.

This is actually great, because it visualises what (I think?) you've been trying to say in words. Whereas in other tracks, adding the "3rd colour should be ignored" test removes students from implementing it complexly/lazily (reduce, map, etc -- or they add even more, slicing the input to 2 values), in Haskell it adds a lot of complexity to deal with, if I understand correctly.

For that exact reason, and its position in the Haskell track (which is what I meant before when I said "track" and not "tracks"), apart from (a subset of) these proposed changes, I did propose to not implement that test, as it seems not to fit in the natural progression lines of the track (the Haskell track). Now I understand that this is actually possible / considerable, and it's the non-clarity of the description that is causing havoc.

So thanks for recommending that I formulate myself less verbosely.

For what it's worth, your last comment made a lot of sense to me whilst still having quite a bit of information.

I can try and provide less reason for my actions and wait for people to ask me.

I don't think that's it. I think your points, now that they make sense to me, are valid to make. It just wasn't clear which points you were actually making and why you were making them. The information in the original post (even now that I understand you better), still feels disconnected from the points that you have elaborated. This can totally be a ME problem, for which I can only apologise, but if I didn't want to understand you, I wouldn't have asked (or commented at all 😄)

I'm not asking if we can have a test for (black, ...). I'm saying that if we don't, the description lies on all tracks that assume "significant" in "two digits" or use some integer return type that truncates

Agree to disagree? I don't see it like that. I think this is an overly pedantic interpretation (to say that it lies). I've always learned that you can always add leading zeroes (like you say in the second paragraph of point one), regardless of the presentation of said number, and that for me just makes it okay. Butttt I always don't care to add it so I'll support your change if this makes people happy 👍

The wording, on the Haskell track in specific, is wrong to a point where the track-specific hint has to excuse for gibberish: "It's not really two digits, sometimes it's one, and that third color you're asked to ignore, it's not really a part of the exercise, so you should ignore ignoring that."

Right. Okay. Let's try to change the canonical description so you don't need that!

Personally, I don't like this addition, as it's leading implementation:

it would translate to the numeric value 10 + 5 = 15, as if the colors were digits.

I am definitely in favour of adding the following, just because it "fixes" the issue you have with it "lying":

In this exercise you are going to create a helpful program so that you don't have to remember the numeric values of the bands. The program will take color names as input and output a numeric value of at most two digits.

And for the final part, I don't like the phrasing " If your language track enables more than two colors as input", but I think the overal content makes sense, especially if tracks like haskell are foregoing the implementation of that test!

petertseng · 2019-10-14T08:27:11Z

exercises/resistor-color-duo/description.md


-In this exercise you are going to create a helpful program so that you don't have to remember the values of the bands. The program will take color names as input and output a two digit number, even if the input is more than two colors!
+To get around this problem, manufacturers print color-coded bands onto the resistors to denote their resistance values. Each band has a numeric and a positional value. For example, if they printed a brown band (value 1) followed by a green band (value 5), it would translate to the numeric value.


I think "it would translate to the numeric value" would lead a reader to think "what numeric value?"

Yes, I felt the same way about "number". It should be more specific.

iHiD · 2019-10-14T09:50:44Z

[soft lock]

Let's come back to this when we've worked this repo out please and not comment any more for now. Thanks.

See PR discussion of #865 for full context. Among the options outlined, the following solution was chosen: Until exercism/problem-specifications#1605 is addressed, - README.md will contain information about a third band, which is amended by saying in .meta/hints.md that the task is to implement value :: (Color, Color) -> Int - test/Tests.hs will say -- Note: This test suite omits testing three-color bands, -- since they are not representable as (Color, Color). They -- are addressed in the exercise resistor-color-trio. This note is designed in such a way that both track maintainers and students can make use of it: The maintainer will know why not to add the missing test when bumping versions, and the student will know why the current README.md talks about an impossible third color band. The Read instance is removed from the stub as it isn't necessary.

ErikSchierboom · 2022-01-12T13:37:46Z

@sshine We now have a test case for black and brown: https://github.com/exercism/problem-specifications/blob/main/exercises/resistor-color-duo/canonical-data.json#L60 Can this PR be closed, or would you like to pursue the textual changes you'd suggested?

IsaacG · 2023-01-01T18:38:38Z

@sshine Is this PR still relevant or can it be closed out?

kytrinyx · 2023-01-03T08:11:19Z

Let's go ahead and close it, and instead reopen it if the original author responds with the desire to pursue the textual change.

IsaacG · 2023-01-03T19:46:36Z

Closing out for now. Feel free to reopen if you want to work on this further!

sshine added correctness hold labels Oct 13, 2019

sshine changed the title ~~resistor-color-duo: Fix wording in description~~ resistor-color-duo: Fix wording in description, add test case Oct 13, 2019

sshine added 2 commits October 13, 2019 18:58

resistor-color-duo: Bump version number from 2.1.0 to 2.2.0

f26b31e

sshine mentioned this pull request Oct 13, 2019

resistor-color-duo: Change to value :: (Color, Color) -> Int exercism/haskell#865

Merged

Revert 10 + 5 = 15 hint.

82467aa

petertseng reviewed Oct 14, 2019

View reviewed changes

sshine mentioned this pull request Nov 4, 2019

Pangram tests do not match exercise specification exercism/haskell#880

Open

Base automatically changed from master to main January 27, 2021 15:31

loziniak mentioned this pull request Sep 18, 2021

Resistor-color-duo: one-digit solution #1843

Merged

ErikSchierboom removed the hold label Oct 15, 2021

IsaacG closed this Jan 3, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

resistor-color-duo: Fix wording in description, add test case #1605

resistor-color-duo: Fix wording in description, add test case #1605

sshine commented Oct 13, 2019 •

edited

SleeplessByte commented Oct 13, 2019

sshine commented Oct 13, 2019 •

edited

SleeplessByte commented Oct 13, 2019 •

edited

sshine commented Oct 14, 2019

SleeplessByte commented Oct 14, 2019 •

edited

petertseng Oct 14, 2019

sshine Oct 14, 2019

iHiD commented Oct 14, 2019 •

edited

ErikSchierboom commented Jan 12, 2022

IsaacG commented Jan 1, 2023

kytrinyx commented Jan 3, 2023

IsaacG commented Jan 3, 2023


		In this exercise you are going to create a helpful program so that you don't have to remember the values of the bands. The program will take color names as input and output a two digit number, even if the input is more than two colors!
		To get around this problem, manufacturers print color-coded bands onto the resistors to denote their resistance values. Each band has a numeric and a positional value. For example, if they printed a brown band (value 1) followed by a green band (value 5), it would translate to the numeric value.

resistor-color-duo: Fix wording in description, add test case #1605

resistor-color-duo: Fix wording in description, add test case #1605

Conversation

sshine commented Oct 13, 2019 • edited

SleeplessByte commented Oct 13, 2019

sshine commented Oct 13, 2019 • edited

SleeplessByte commented Oct 13, 2019 • edited

sshine commented Oct 14, 2019

SleeplessByte commented Oct 14, 2019 • edited

petertseng Oct 14, 2019

Choose a reason for hiding this comment

sshine Oct 14, 2019

Choose a reason for hiding this comment

iHiD commented Oct 14, 2019 • edited

ErikSchierboom commented Jan 12, 2022

IsaacG commented Jan 1, 2023

kytrinyx commented Jan 3, 2023

IsaacG commented Jan 3, 2023

sshine commented Oct 13, 2019 •

edited

sshine commented Oct 13, 2019 •

edited

SleeplessByte commented Oct 13, 2019 •

edited

SleeplessByte commented Oct 14, 2019 •

edited

iHiD commented Oct 14, 2019 •

edited