Talk:Character codes: Difference between revisions

Content added Content deleted

Inline

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)

@@ Line 1: / Line 1: @@
-== J solution ==
+== 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 =.  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 <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^1 11 17 e.~2^.3!:0)</code>, rather than the two-liners above.
-:PPS:  Thinking about it more, it might be best to present both the current <code>::</code>-based solution and a <code>^:</code>-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.