Talk:Sum of squares
Is this too similar to Sum and product of array? --Mwn3d 22:42, 27 January 2008 (MST)
- I think not. The sum-and-product task lets us see how these functions are specified, but they don't let us see them in relationship with another function. The point of sum-of-squares, it seems to me, is to let us see how basic function composition occurs. It takes more than one function to show that. --TBH 10:01, 28 January 2008 (MST)
- If that is the goal, perhaps a function composition task would be appropriate. --IanOsgood 10:07, 28 January 2008 (MST)
- I don't think this counts as function composition. This is just accumulation, which is why I think it's similar to the sum and product. The capital sigma and capital pi symbols in math aren't really functions, and this task would use a capital sigma in its definition. --Mwn3d 10:39, 28 January 2008 (MST)
- If summation-of-series and product-of-series are not going to be considered functions within this site, what should they be called instead? They easily fall within a common meaning of the word. To see how, I recommend that we take the Wikipedia page on function composition as a starting point. --TBH 11:32, 28 January 2008 (MST)
- If they are considered functions, then they are always function compositions (their arguments are always functions) and the sum and product of an array should be considered that way too. --Mwn3d 12:54, 28 January 2008 (MST)
- If we broaden "function composition" to include anything that produces a function, the resulting category will swallow everything. All tasks would count in that category when approached at the function level. We want categories that provide focus and containment of complexities. --TBH 14:48, 28 January 2008 (MST)
- If they are considered functions, then they are always function compositions (their arguments are always functions) and the sum and product of an array should be considered that way too. --Mwn3d 12:54, 28 January 2008 (MST)
- If summation-of-series and product-of-series are not going to be considered functions within this site, what should they be called instead? They easily fall within a common meaning of the word. To see how, I recommend that we take the Wikipedia page on function composition as a starting point. --TBH 11:32, 28 January 2008 (MST)
- Function composition may be too broad a topic for a single task. Consider the following:
g (f y) g (x f y) (f x) g (f y) fi (g (f y)) fi ((f x) g (f y)) y g (f y) x g (f y) (f y) g (h y) (x f y) g (x h y)
- In the notation used above f, g, and h are functions, fi is the function inverse to f, and data arguments are indicated as x and y.
- These nine compostional structures are primary forms in the J programming language, so from the perspective of demonstrating J code nothing less than this set seems adequate. My intuition is that this set is too large to be demonstrated conveniently as a single task, for most other languages. Perhaps function composition should be a category, instead? --TBH 12:27, 28 January 2008 (MST)
- Just because it's complex in J doesn't mean it's too broad for everyone else. Forward difference seems pretty rough for Ada and Java, but it's simple in J. Maybe there's a language where function composition is significantly simpler than the nine structures in J. --Mwn3d 12:54, 28 January 2008 (MST)
- You misunderstood. Those nine structures are particularly straightforward in J, being supported by basic features of the language. I doubt we want to make a task that is not only biased toward one particular language, but composed of a sizeable list of subtasks. --TBH 17:26, 28 January 2008 (MST)
- Just because it's complex in J doesn't mean it's too broad for everyone else. Forward difference seems pretty rough for Ada and Java, but it's simple in J. Maybe there's a language where function composition is significantly simpler than the nine structures in J. --Mwn3d 12:54, 28 January 2008 (MST)
- Although I said before that the point of this task is to show function composition, I notice that does not actually fit with what has already been posted. The Java solution does not involve function composition, nor does the second J example. If this were restructured as a task to compose (g (f y)) these would have to go. --TBH 14:37, 28 January 2008 (MST)
- I'm going to assume for the moment that by "function composition", we're talking about taking arguments and computing a result, be it a value or state change. Even if it results in a huge task, it's not really inappropriate to create a task that explicitly seeks out to demonstrate function creation syntax.
- In fact, I think it's wholly appropriate for someone to create a Functions and Subroutines task to demonstrate this very common behavior, just as we have Loop Structures and Conditional Structures. If the goal is to demonstrate a language feature, then I believe an feature-type task ( Loop Structures, Conditional Structures, Compund Data Types, etc. ) is more appropriate than trying to define an operation-type task narrowly enough to force a specific style of implementation. Clarity is key; The more clear the role of a task, the easier it is for newbies and regulars alike to keep code accurate and pages maintained.
- And if we're talking about a different kind of function (It's possible; I don't have a strong mathematics background.), would someone link me to a good reference so I'd know what you guys are talking about? --Short Circuit 23:13, 28 January 2008 (MST)
- These nine compostional structures are primary forms in the J programming language, so from the perspective of demonstrating J code nothing less than this set seems adequate. My intuition is that this set is too large to be demonstrated conveniently as a single task, for most other languages. Perhaps function composition should be a category, instead? --TBH 12:27, 28 January 2008 (MST)