Anonymous user
Talk:Formal power series: Difference between revisions
m
moved Talk:Formal Power Series to Talk:Formal power series
(→Multiplication and division: What is the task about?) |
m (moved Talk:Formal Power Series to Talk:Formal power series) |
||
| (4 intermediate revisions by 4 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 50 ⟶ 52:
:::Yep, the task name is misleading. When it says "formal series" that gives an impression of some generalized framework for dealing with more or less '''any''' series, Fourier, Chebyshev, not just Taylor ones. Laurent series is yet another story. It goes in direction of approximations by rational polynomials, Padé etc. So what is the task about? The example of a definition of cos-sin has almost nothing to do with either series or approximations and how they are dealt with in real world. (I addressed this issue in a subthread.) --[[User:Dmitry-kazakov|Dmitry-kazakov]] 09:44, 12 March 2009 (UTC)
:::: I am trying to understand better, and it's why I still haven't added code: to me one thing is to "handle" a formal power series (big but still finite array for a computer language?), another thing is to ''generate'' a formal power series. The first can be accomplished without caring too much, we need only to put constraints over some coefficient for operations like / (maybe, not sure, enough the constant is not zero for the division? ... anyway still problems, since we indeed manipulate "finite" series, can arise, but maybe the task asks to disregard these details). I admit I've not taken a deep look to posted codes yet. --[[User:ShinTakezou|ShinTakezou]] 13:37, 13 March 2009 (UTC)
==About solving equations==
Line 92 ⟶ 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)
| |||