== Suggested improvements ==

This proposal does not limit the syntax in any way. It does not mention parenthesis. Meanwhile, 1+1/x is not a polynomial (and neither is x^1/x), and limiting supported syntax to only that unicode which can represent polynomials would still allow for a variety of ambiguities, such as:

::cry

::c₁y¹+c₂y²

:: ∑ (1+xⁿ)xⁱ

I recommend explicitly listing the characters which should be supported, and eliminating the parts of the task description which refer to negative exponents. Another alternative would be to change the task name and explicitly document the syntax being supported. --[[User:Rdm|Rdm]] 19:12, 18 November 2011 (UTC) ::re: Openended - I've added a specific list of unicode that should be supported. e.g. {⁰ ¹ ² ³ ⁴ ⁵ ⁶ ⁷ ⁸ ⁹ ⁻ ⁺ · × ⁄ ↑ ⏨} (I hope I have not missed any interesting ones). ::*re: cry - The task is for polynomials of one variable, and "x" is the tradition "unknown". However I am inclined to think that the first lowercase letter (excluding "e") could be used as the "unknown", eg z, y etc. ::*re: c₁y¹+c₂y² - The examples in the text are with real coefficients. Allowing c₁ & c₂ would make the coefficients symbolic, and thus the task a whole lot harder. Similarly allowing complex numbers might stress some contributors: z⁵ - (1+2i)z⁴ + (405+4i)z³ + (403+4i)z + 5+2i ''or'' z⁵ - 1⊥2 z⁴ + 5⊥4 z³ + 3⊥4 z + 5⊥2. I have left manipulation of complex numbers to a future task. ::*re: negative exponents / misnamed? - it seemed a shame to restrict the exponent to just +ve Integers. And it is only as very minor code adjustment to allow -ve exponents in a "finite power series" and it does not detract from polynomials. Is there a better name for equations such as: x⁻⁵ - 2⁄x⁴ + 42x⁻³ + 40/x + 1x⁻⁰ + 40x + 42x³ - 2x⁴ + x⁵? Maybe "finite power series"? ::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/23). 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)

I'm sorry that you find this task objectionable, which languages have built in "mark up text"? I am using unicode because unicode is standardised, and widely supported. wikitext on the other hand is a non-standard e.g. {[[wp:AsciiDoc|AsciiDoc]], [[wp:BBCode|BBCode]], [[wp:Creole (markup)|Creole]], [[wp:deplate|deplate]], [[wp:Markdown|Markdown]], [[wp:MediaWiki|MediaWiki]], [[wp:Org-mode|Org-mode]], [[wp:PmWiki|PmWiki]], [[wp:Plain Old Documentation|POD]], [[wp:reStructuredText|reStructuredText]], [[wp:Setext|Setext]], [[wp:Textile (markup language)|Textile]], [[wp:Texy!|Texy!]], [[wp:txt2tags|txt2tags]], etc. etc. etc. also XML & HTML & Latex) and not built in to many languages.

The other problem with "markup" is that inevitably when a polynomial is cut and pasts it gets broken: {|class="wikitable" style="text-align: center; margin: 1em auto 1em auto;" |+Comparing cut and pasting of polynomials. !Method || Example || Markup || Paste result |- |Unicode || x⁵ - 2x⁴ + 42x³ + 40x + 1 || x⁵ - 2x⁴ + 42x³ + 40x + 1 || x⁵ - 2x⁴ + 42x³ + 40x + 1 |- |MediaWiki || x⁵ - 2x⁴ + 42x³ + 40x + 1|| x⁵ - 2x⁴ + 42x³ + 40x + 1|| x5 - 2x4 + 42x3 + 40x + 1 |}

I would agree that program should be agnostic of input and output formats. So providing a way (plugin, template or library) to read/write data from unicode and/or wikitext would be an effective way for supporting it. Do you suggest a task for every different kind of markup, or do you have a particular favourite wikitext? I am happy to suggests improvements if you create a task to which implements your favourite markup.

ThanX for the feedback. [[User:NevilleDNZ|NevilleDNZ]]

==Format of the task== :''"Given a string containing '''any''' untidy Unicode polynomial..."'' I think that mention of 'any' goes on to make this a difficult task. How about just limiting the task to parsing a very limited subset of the formats you mentioned that are more likely to be used in practice? Or how about chucking the emphasis on parsing and making the trask more about outputting an input polynomial in a normaized format? (That should address some of the issues that Ledrug pointed out above, and that I share). --[[User:Paddy3118|Paddy3118]] 05:02, 19 November 2011 (UTC)

I have added ''"Specific examples of Unicode and polynomial texts to be parsed as test cases"'' and removed the word ''"any"''. This should about cover the ugliest polynomials I can imagine. ThanX [[User:NevilleDNZ|NevilleDNZ]] 05:53, 19 November 2011 (UTC)

: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. [[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)