Problem-specifications: binary and/or trinary: use non-numeric symbols instead of digits?

[kytrinyx]

In a pull request on the Lisp track @wobh suggested that we switch from using 0 and 1 (and 2) for the binary/trinary exercises, which makes it much more obvious that the exercise is about parsing rather than figuring out how to use the standard library to do conversions from one format to another.

Another suggestion was to leave binary alone, and use non-numeric symbols for trinary, to make these more different from each other.

I like both ideas. I originally made the exercises because a group of students at a developer training program (a.k.a. bootcamp) didn't understand how numbers work, and I wanted to force them to think about it for a bit. Using non-standard symbols might actually make it easier to think about this without getting confused by existing misconceptions.

For binary I was thinking dots and dashes - for zero, . for one.

For trinary, we could either continue on the dots and dashes and add something else to replace 2 (pipe, maybe), or go with completely different symbols, so that it feels different.

[wobh]

I'll get my notes and code in a gist soon. There are a few different kind of exercises we could get out of this.

[wobh]

Briefly, positional numerations come in all kinds, each with a variety of challenges for the student. In addition to parsing a numeral, can they can write it? The numeration could be in least or greatest order, and then there's supporting different number types. Support negative numbers in binary with two's-complement (the complement method is interesting in itself), ternary negatives with balanced ternary. Bijective numeration! Don't let so many permutations of numerals go to waste!

I got some of this sketched out here:

https://github.com/wobh/cl-numerations/blob/master/src/oxxo.lisp

https://github.com/wobh/cl-numerations/blob/master/src/toivy.lisp

Where did all this yak wool come from?

[wobh]

(@kytrinyx, @verdammelt, @canweriotnow, @yurrriq on a serious note, due to some personal misfortunes, it seems unlikely that I'll be able to contribute as much as I would otherwise like this summer. I'll be taking a break. Carry on.)

[yurrriq]

Take care, @wobh.

[NobbZ]

I do not like the idea of having non-digits in the input. All these exercises (binary/trinary/octal/hexadecimal) are about converting numbers from a given fixed base into another fixed base which we are used to work with (decimal).

Changing the currently used well known digits into something else, would make it hard to argue about correctness during development, for a trinary number 10 I can tell at a glance that it is decimal 3, while for ._ I had to do some extra mindwork or even look into the README, to resolve . and _ into actual digits. Of course similar is true for other bases.

As a programmer there should be nearly no problem at all to convert from base X to base 10 as long as the numbers are positive and not much greater than 20 (where the exact value does also depend on the starting base).

Also as I have pointed out in #276, replacing digits with other symbols might be just coded away with a simple string replace or even a call on #tr. And in languages where you don't have such a thing in the stdlib, you will probably have no number conversion either.

So I do think, that adopting this would only add obfuscation and confusion.

[yurrriq]

IIRC, @wobh's take (discussion on some other issue) was that these exercises are about writing parsers generally. I can understand the argument on both sides, but lean slightly toward "arbitrary" symbols to illicit more focus on the parsing rather than the numeric values.

Edit: @kytrinyx linked to the discussion above.

[NobbZ]

As @kytrinyx stated on that other issue (#276) this is not about parsing, but about understanding numbers.

And to be honest, I feel like this too. I'm studying CS and I do see students in their second and third year not beeing able to do easiest transformations on the fly.

Exactly those are the people that would be totally confused when we add the additional layer of obfuscation.

[rbasso]

One kind of exercise doesn't exclude the other. Of course, the more cryptic one has to come later in the list. :smile:

[NobbZ]

Yupp. And I really think we should try to focus the discussion on only one of these issues or open a third umbrella one… And I do not really like adding just onother source of noise ;)

[kytrinyx]

One kind of exercise doesn't exclude the other.

Yeah, I think this is an important point. I think that #276 is converging on the conversion aspect in a really nice way. I don't feel any attachment to the idea of _converting numbers from a given fixed base into another fixed base which we are used to work with (decimal)_.

And I really think we should try to focus the discussion on only one of these issues

Agreed. Let's assume that #276 is about the conversion aspect. Or should we close this as a duplicate of #276? Or should we talk about whether there's an interesting exercise about parsing?

An interesting parser direction could use the first golang challenge for inspiration: http://golang-challenge.org/go-challenge1/).

[rbasso]

Unless there is the intention to reuse the names binary or trinary in another exercise, I think this issue should be closed. The _go-challenge_ looks interesting, but seems unrelated to this, right?

[kytrinyx]

The go challenge is about writing a parser. But yeah, I agree. Let's call this one quits!