Anonymous user
Talk:Formal power series: Difference between revisions
m
moved Talk:Formal Power Series to Talk:Formal power series
m (moved Talk:Formal Power Series to Talk:Formal power series) |
|||
| (3 intermediate revisions by 3 users not shown) | |||
Line 16:
: I hope multiplication of the Ada solution is correct. As for division, it is impossible to implement because the result can infinite (example: 1-''x'') or non-existent (example: ''x''). --[[User:Dmitry-kazakov|Dmitry-kazakov]] 15:14, 10 March 2009 (UTC)
:: Division introduces two problems. One problem has to do with remainders (as in the 1/(1-x) or 1/x cases suggested by [[User:Dmitry-kazakov|Dmitry-kazakov]]), and the task specification did not specify how they should be treated. A related but deeper problem is that the quotient is not knowable unless every element can be inspected (or treated in some symbolic fashion). In other words, the Kth element of the result depends on the Jth element of the divisor and the (J+K)th element of the numerator for arbitrary K and J. In the general case, significant examples of both J and J+K can be infinite for any finite K. This problem becomes tractable when we deal with finite sequences (which, in essence, is what lazy evaluation gives us, though without the tractability). --[[User:Rdm|Rdm]] 19:32, 22 January 2010 (UTC)
It is like normal multiplication of polynomials, but done on (potentially) infinite elements (we shall truncate the series anyway at some point...) It is enough to do the right grouping according to the ''power'', so say you have (a<sub>0</sub> + a<sub>1</sub>x + ...) and (b<sub>0</sub> + b<sub>1</sub>x + ...) then you do what you would normally do: a<sub>0</sub> with all the b<sub>i</sub>x<sup>i</sup> and so on; but of course you must group equal powers. You could write it shortly as
Line 94 ⟶ 96:
Summarizing: is the task accomplished even if the goals are (partially) missed? --[[User:ShinTakezou|ShinTakezou]] 17:30, 9 March 2009 (UTC)
== Java and generics ==
It was my understanding that generics had been added to Java recently, yet the Java example indicates that they're not available. A generic implementation would be far better than using the "swap out the type for the one you want" implementation it currently uses. --[[User:Short Circuit|Short Circuit]] 17:31, 17 May 2009 (UTC)
: Alas, <tt>java.lang.Number</tt> is not a very useful base-class in this regard, nor are its standard subclasses any better. In particular, there's no built in methods for performing arithmetic; those operations are only defined on the atomic numeric types, which can't participate in the generic type system. This means that the example would have to build its own type framework, and suddenly that's looking like real work and not elegant examples. (FWIW, the reason why the atomic types don't participate in the generics system is that they are treated specially by the JVM spec; addition on integers is completely different to addition on doubles. This would have forced recompilation for handling generic atomics, which was rejected as being silly and expensive. By contrast, swapping one object type for another is pretty straight-forward.) —[[User:Dkf|Dkf]] 21:40, 22 May 2009 (UTC)
| |||