Problem-specifications: Almost identical exercises: binary, trinary, octal, hexadecimal

[rbasso]

In an unrelated discussion, it came to my attention that, just looking at the .md files, these 4 exercises are almost the same:

• binary
• trinary
• octal
• hexadecimal

At least in xhaskell, the implementations for both, tests and solutions, are mostly the same, and it's boring to solve the same problem multiple times.

Are there some subtle differences among them that I'm missing?

Are they that similar _by design_, or is it an historical accident?

(Possibly related to #223)

[NobbZ]

Yeah, the differences are very subtle: All are converting from different bases…

But yeah, I think you are right, these exercises are similar enough to do one of these:

• Deprecate 3, keep one, add another one which has a parametrized converter convert(from, to, number)
• Deprecate all and have the parametrized version
• Deprecate 3 and keep only one, don't add anything else

Across all tracks I have implemented this, the major difference between these four are the way how I bitshift and which input I consider valid. The logic/recursing part is the same.

[ErikSchierboom]

I'm in favor of combining these four exercises into a single exercise. The exercise should thus focus on being able to convert from different bases, with tests for at least two or three of the current bases.

[kytrinyx]

Definitely related to #223.

I would favor collapsing all of this into two exercises:

• binary, which remains as it is, except that we would encourage people to solve it using the standard library or usual tools.
• trinary, using alternate symbols so that people can't use a trivial conversion (e.g. in Ruby: 120.to_i(3)`.

I really would like people to have a basic understanding of how numbers actually work.

[NobbZ]

So you suggest making trinary more of a crypto-kind with a fixed key? Sorry, but I really don't like it.

It is a numeric conversion, fullstop. In ruby it is ease as input.tr("abc", "210").to_i(3), in most other languages you have similar mechanisms, in the worst case, it is a lookup in a map while folding the input.

Having something else than plain arabic digits adds obfuscation and not value into the exercise, I think.

I will write something to #223 as well later this day.

[kytrinyx]

That's fair. How would you design an exercise that encourages people to actually understand the underlying numbers?

[NobbZ]

I wish I had an idea, but to be honest, as long as we don't monkeypatch #to_i away (and we can't even do that in most languages), the only way to encourage it, is to write it out LOUD and bold and _italic_ in the README :(

But I think, that asking for the following function/method might help: string convert(string input, int from_base = 2, int to_base = 10) (pseudo typesignature, but should be clear).

This can only work by converting from the input into an intermediate integer and then back into a string having the correct base.

Most languages I am aware of, have very easy stuff to convert a string represantation of an integer with base X into base 10, but not the other way round.

[rbasso]

I think the exercise is more educative when it fuses the two problems:

• Composition / Decomposition
• Representation

The composition/decomposition - certainly the main problem as noted by @NobbZ - is just about conversions between a number and a list of numbers:

compose :: Integral a => [a] -> a
decompose :: Integral a => a -> [a]

It's a good starter problem!

The representation problem involves two functions:

encode :: Integral a => a -> Something
decode :: Integral a => Something -> a

What makes it interesting, IMHO, it that, when you combine those two problems, the student is forced to see that the two lists of symbols are equivalent by same underlying number, especially if they don't use common numeric symbols:

colorsToAlpha :: [Color] -> [Letter]

If one of the representations is numeric, it could wrongly think that there is a _natural representation_ of a number, probably decimal. So I think there is some merit in having a encoded version of the problem too.

[NobbZ]

I really like the idea of having a more generic conversion exercise as suggested by @rbasso, but as @kytrinyx stated, this family of exercises was meant to teach numeric conversion.

And for numeric conversion there is probably only that one way of intermediate representation: the languages native integer type. We do not even know for sure, how it looks like internaly, all we know is, that values of this type are _printed_ in their decimal representation in most languages or at least string-converted.

[rbasso]

If these problems are just about composing/decomposing in digits, so there are still three distinct types of exercise possible:

• construction (from a list of numbers to a number)
• deconstruction (from a number to a list of number)
• conversion (from a list of numbers to a list of number)

Those types has nothing to do with character conversions, but - from what I remember - the exercises are specified to work with strings of characters. This is inconvenient in Haskell, but maybe it's irrelevant in some languages.

[NobbZ]

Yeah, currently they are as a string/list of chars/array of chars/whatchamacallit.

Perhaps a list of digits could in fact make it harder to use the stdlib, since most stdlibs are working on strings. But making it a string in the right format again is just a join away…

[rbasso]

So, instead of the current problem descriptions,

Write a program that will convert a binary number, represented as a string (e.g. '101010'), to its decimal equivalent...

What do you think about...

Write a program that will convert a sequence of numbers, in base a, in another sequence of numbers in base b.

I believe this is in the spirit of what @ErikSchierboom proposed and still compatible with the signature you provided earlier.

This way we completely avoid mixing the base conversion problem with encoding in the descriptions, and each language can implement it in the most idiomatic way.

[ErikSchierboom]

@rbasso correct, that is indeed what I was proposing.

[kytrinyx]

@rbasso @ErikSchierboom I'm all for this approach!

[yurrriq]

:+1: to base a -> base b (to replace all four existing exercises?) and for discussing here.

[rbasso]

So... what would be the new exercise's name?

[kytrinyx]

So... what would be the new exercise's name?

Good question. all-your-base? Too cheeky? How about base-to-base? Or numeric-conversion?

[yurrriq]

base-conversion? Naming things is hard...

[rbasso]

+1 for all-your-base. We have to use that!

[yurrriq]

Into it.

[NobbZ]

Definitively a :+1: for all-your-base or all-your-bases! I like the pun…

But if it has to stay more pragmatic and punfree I'd go for base-conversion.

[Cohen-Carlisle]

I like the consensus around converting from an arbitrary base to another arbitrary base that seems to have formed here. I and also strongly support naming the exercise all-your-base.

[rbasso]

So, if I'm counting right, all-your-base it is.

Now, what?

I think we need a all-your-base.yml and all-your-base.md, right? Anything else?

I have a PR ready here, just waiting for confirmation... :smile:

[kytrinyx]

Yepp, we need the yml and the md, and let's also start with a json file where we define the test cases. That will let us discuss and work out all the details, and it will be easier to create the various track implementations based on that.

[kytrinyx]

I've posted a new issue that is about deprecating the old issues. Once the PR for all-your-base is merged we can close this one.

[rbasso]

Working on that json file!

[kytrinyx]

@NobbZ @ErikSchierboom @yurrriq @Cohen-Carlisle @petertseng if you have time to review https://github.com/exercism/x-common/pull/280 that would be great!

[kytrinyx]

Now that all-your-base is merged, I'm going to close this issue in favor of https://github.com/exercism/x-common/issues/279