Talk:Character codes: Difference between revisions
Content added Content deleted
(in re J solution) |
(Removed "J Solution" section, since it does not relate to the current J implementation, and the treated issues were not related to the task requirements, and it was verbose) |
||
| (6 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
== |
== Python == |
||
well, I suggest adding which libraries need imported (eg Python) for the examples as applicable--[[User:Billymac00|Billymac00]] 19:19, 6 December 2010 (UTC) |
|||
The concept behind the current J solution (<code>{&a. :: (a.&i.)</code>) is innovative, and a creative use of adverse ("decode, but if the codes are invalid then the user must've meant encode"). |
|||
:For the Python examples, no libraries need to be imported. All of those are built-in functions. --[[Special:Contributions/75.36.163.171|75.36.163.171]] 10:34, 7 December 2010 (UTC) |
|||
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, <tt>256</tt> is in invalid ASCII character code, and so adverse is invoked, but it doesn't make sense to encode <tt>256</tt> either (as evidenced by the result of <code>{&a. :: (a.&i.) 256</code>). This foible is manifest in the verb's asymmetry (i.e. you couldn't write the solution as <code>a.&i. :: ({&a.)</code>). |
|||
In addition, the current solution might be considered slightly redundant, as <code>{&a.</code> is implicit within <code>a.&i.</code> (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 <code>{&a.</code> ''or its inverse'' dynamically, depending on the nature of its input. That is, if we have the right predicate, then <code>{&a.^:predicate</code> will apply <tt>{&a.^:1</tt> or <tt>{&a.^:_1</tt> (i.e. <code>a.&i.</code>) 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 =. 2 2048 131072 e.~ 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 <code>cc^:2</code> is the identity, and <code>-: cc^:2</code> a tautology. |
|||
--[[User:DanBron|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 <code>{&a.^:(_1^2=3!:0)</code> or <code>(8 u: 4 u: ])^:(_1 ^ 2 2048 131072 e.~ 3!:0)</code>, rather than the two-liners above. |
|||
Latest revision as of 15:48, 8 December 2010
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)