Talk:Unicode polynomial equation: Difference between revisions
→Format of the task
(→Format of the task: OK) |
|||
| (9 intermediate revisions by 3 users not shown) | |||
Line 16:
::*re:∑ (1+xⁿ)xⁱ - true.. if n and the bounds of the ∑ are known, then it could be a polynomial. But again, let us avoid symbolic manipulation. A simple array of real coefficients is what is required.
::ThanX for the feedback. [[User:NevilleDNZ|NevilleDNZ]] 05:46, 19 November 2011 (UTC)
:::The use of negative exponents introduces several difficulties. One of which is that the notation allows for continued fractions (2x^3/4x^5/6x^7). Another difficulties is the treatment of discontinuities. Another one is that we do not know what precedence rules to use (1/2*3). And if we are not dealing with polynomials then that introduces other complexities (one of which is "what is the scope of this task? (x^x, 4^½, ...)" ). Also, you have left the treatment of parenthesis ambiguous and your "unicode characters which must be supported" list did not include the digit 0 -- even though it's a unicode character. --[[User:Rdm|Rdm]]
: I find this task objectionable, if for no other reason than promoting bad typography. The unicode super-/subscripts are only good for when you don't have a way to mark up text. They are generally too small, inflexible, and unpleasant to look at. And, I don't see any practical merit in parsing such strings: I don't see why a human would carefully type out those difficult symbols as input data to a program, and if it's generated by machines, you might as well tell the machine to do a better job by writing structured/properly marked up data. --[[User:Ledrug|Ledrug]] 03:00, 19 November 2011 (UTC)
Line 28 ⟶ 29:
|Unicode || x⁵ - 2x⁴ + 42x³ + 40x + 1 || x⁵ - 2x⁴ + 42x³ + 40x + 1 || x⁵ - 2x⁴ + 42x³ + 40x + 1
|-
|MediaWiki || x<sup>5</sup> - 2x<sup>4</sup> + 42x<sup>3</sup> + 40x + 1|| <nowiki>x<sup>5</sup> - 2x<sup>4</sup> + 42x<sup>3</sup> + 40x + 1</nowiki>|| x5 -
|}
Line 42 ⟶ 43:
:Hi NevilleDNZ, I guess we take different views on what would make an interesting task. That's OK. --[[User:Paddy3118|Paddy3118]] 09:15, 19 November 2011 (UTC)
Cheers for that. Thank Zeus that we are all different. <!-- removed comment as it was too ambiguous, my apologies to all. --> [[User:NevilleDNZ|NevilleDNZ]] 09:33, 19 November 2011 (UTC)
The problem with removing commas is that the input string might have some numbers inside it whether the comma is used as a decimal point (common in continental european number formatting, whereas the UK and US use a period for that). This is very nasty, and wikipedia [[wp:Decimal mark|goes to some length]] on the subject's background. I recommend dropping that part of the task (though removing spaces between digit sequences ''is'' fine; it's not ambiguous except in situations which aren't polynomials at all). –[[User:Dkf|Donal Fellows]] 21:16, 14 January 2012 (UTC)
: That is not strictly true, though it could well be true for the definition of this task: J will represent polynomials as a space separated list of numeric coefficients (with constant being the first number). --[[User:Rdm|Rdm]] 23:44, 14 January 2012 (UTC)
:: 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)
| |||