Talk:Character codes

J solution

The concept behind the current J solution ({&a. :: (a.&i.)) is innovative, and a creative use of adverse ("decode, but if the codes are invalid then the user must've meant encode").

However, it might be considered slightly inelegant (or, rather, imprecise), because it is imposing a meaning upon an error condition, which that condition does not necessarily carry. For example, 256 is in invalid ASCII character code, and so adverse is invoked, but it doesn't make sense to encode 256 either (as evidenced by the result of {&a. :: (a.&i.) 256). This foible is manifest in the verb's asymmetry (i.e. you couldn't write the solution as a.&i. :: ({&a.)).

In addition, the current solution might be considered slightly redundant, as {&a. is implicit within a.&i. (and vice versa). Though this is a subjective and stylistic judgement.

We can address both these concerns by leveraging J's functional calculus, with a slight change to the code. We can apply {&a. or its inverse dynamically, depending on the nature of its input. That is, if we have the right predicate, then {&a.^:predicate will apply {&a.^:1 or {&a.^:_1 (i.e. a.&i.) as appropriate to the input.

One such predicate might be "is the input literal?", and so the full solution might look like:

   isLiteral =.  2=3!:0
   cc        =:  {&a.^:(_1^isLiteral)f.

But this, too, has its limitations. For example, it still doesn't address Unicode. While I don't know enough about Unicode to be confident that it covers every case, we might make this more general (and longer), with:

  isLiteral =.  1 11 17 e.~2^.3!:0
  cc        =:  (8 u:4 u:])^:(_1^isLiteral)f.

But since the task doesn't require handling Unicode, either verb will suffice. Both are symmetric, and both have the satisfying property of being self-inverse (obviously), so that cc^:2 is the identity, and -: cc^:2 a tautology.

--DanBron 21:31, 5 January 2009 (UTC)

PS: If we make this change, my personal preference is that we give the solution(s) succinctly, as {&a.^:(_1^2=3!:0) or (8 u:4 u:])^:(_1^1 11 17 e.~2^.3!:0), rather than the two-liners above.

PPS: Thinking about it more, it might be best to present both the current ::-based solution and a ^:-based solution, describing how they work, and differ, and why the facilities underlying each are interesting. If we do so, I suggest we lead with the current, shorter, verb.

Python

well, I suggest adding which libraries need imported (eg Python) for the examples as applicable--Billymac00 19:19, 6 December 2010 (UTC)

For the Python examples, no libraries need to be imported. All of those are built-in functions. --75.36.163.171 10:34, 7 December 2010 (UTC)