Talk:Unicode polynomial equation: Difference between revisions
→Format of the task
| (One intermediate revision by one other user not shown) | |||
Line 51:
:: That sounds more like an internal representation (and is actually similar to the rep I'd use in Tcl). –[[User:Dkf|Donal Fellows]] 13:46, 2 March 2012 (UTC)
::: It might be an internal format for TCL -- in TCL, I think everything is a string. In J, though, it the simplest parseable representation of a polynomial and could also be used as a serialized format. --[[User:Rdm|Rdm]] 14:19, 2 March 2012 (UTC)
:::: While it's somewhat inaccurate to say everything is a string (“all values are ''serializable''” would be closer to the truth as implemented, though Tcl practitioners tend to say “everything is a string” as a way to teach noobs) when it comes to rendering formats then while it is possible to do it that way, it isn't something that you'd want to expose to a non-programmer friend. Serializing as a “human-readable” format makes a bunch more sense given the general thrust of this task. (I suppose it would also be reasonable to use XML or JSON but that would increase the “ewwww!” factor…) Unfortunately, there's no way to reconcile the space-separated list format with the way that other languages treat spaces in digit sequences as ignorable; there really are totally incompatible interpretations of the same byte sequence. (The disadvantage of an undecorated number list is that there's no way to know if it is “big-endian” or “little-endian”, i.e., if the first element represents the most significant or least significant term. It might be “obvious” which it is, but I bet some people will get it wrong anyway.) –[[User:Dkf|Donal Fellows]] 15:53, 2 March 2012 (UTC)
::::: Certainly. This was originally an illustration of an issue with this task, which is that instead of a precise specification it makes ambiguous use of existential operators. I just got sidetracked. --[[User:Rdm|Rdm]] 16:29, 2 March 2012 (UTC)
| |||