Talk:Sum of squares: Difference between revisions

From Rosetta Code
Content added Content deleted
(Function composition is but one way to approach the task.)
No edit summary
Line 5: Line 5:
:::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 [http://en.wikipedia.org/wiki/Function_composition_%28computer_science%29 function composition] as a starting point. --[[User:TBH|TBH]] 11:32, 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 [http://en.wikipedia.org/wiki/Function_composition_%28computer_science%29 function composition] as a starting point. --[[User:TBH|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. --[[User:Mwn3d|Mwn3d]] 12:54, 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. --[[User:Mwn3d|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. --[[User:TBH|TBH]] 14:48, 28 January 2008 (MST)
::Function composition may be too broad a topic for a single task. Consider the following:
::Function composition may be too broad a topic for a single task. Consider the following:



Revision as of 21:48, 28 January 2008

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)
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)
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)