Can i use the combine block this way ?
Expected result : 5 (1+1.666666666+2.333333333)
Apparently not. I'm not familiar with the inner workings of the COMBINE block, so I could't say exactly why not* - in general my advice would be to keep it simple.
What you can use is either:
... or:
... or (simplest solution):
*Update
I believe the definition of COMBINE's to be more or less equivalent to:
... but faster in execution. You can try it for yourself, it works fine with operations such as simple addition, MAX or JOIN, but if you are going to use multi-layered functions such as in your original post, it will report nonsense.
@bh: Since all primitive functions mentioned in the help text and Reference Manual have by now been adapted for variadic input, there's not much use for COMBINE anymore, or is there? Perhaps for associative user-defined operators, such as pythagorean addition (calculating the size of a hypotenusa in n-dimensional space)? A combination of MAP and SUM will usually suffice (well, with pythagorean addition, SQRT is needed too), so perhaps COMBINE is ready to be moved to a library. Either way it would be helpful it the workings of the function were better documented.
Your function is not associative. The computation goes like this:
3/3 + 5/3 = 8/3 = 2.6̅
2.6̅/3 + 7/3 = 3.2̅
You could say the same about MAP. One exception, I think, is when you nest calls to HOFs.
But in any case there's a pedagogic value to the (explicit) HOFs, because at some later point in their education, kids might be coerced into programming in one of those toy languages that don't have hyperprocedures. ;~)
By the way, your comment about the base case of COMBINE isn't quite right. If the list is empty and the function is a primitive, you get the identity element of that function:
So that only works for primitive functions. Well... not the greatest of features.
And not even consistently applied 
What's the point in mapping over the list if it doesn't change anything? If you're thinking the hyperblocks modify the original list, well, they don't. They create a completely new list.
This is a much better solution.
With the usual disclaimer about the potential uncertainty of the execution order, you can overcome this limitation with an initial value
"Any > 7"
"All > 2"
Kartesian distance (0,0,0) (10,10,10)
Non trivial examples
Bit array to value 
Octal array to value 
I’m impressed!
Interesting--I had no idea that would work, though now that I think about it, it does make sense.
Yeah, Dan Garcia loves those asymmetrical combining functions but I think it's much cleaner pedagogically if we make no promises about order of evaluation. I eventually convinced him to stop. :~) Your examples are very clever, but we try to teach our students not to write clever code!
The thing is, we don't know the identity element, if any, of a function you write. (In particular, functions have an identity only if their domain is the same as their range. So, for example, not most predicates.)
Yeah, well, APPEND wasn't a primitive at the time we added the identity feature to COMBINE. @jens
Teaching tip: Don't make your student make several leaps at once. A better way to make the point you're after, in this context, would be
Thanks for the tip. I'm still trying to figure out a good way to teach stuff to people.
Do you mean you didn't know you could do it with COMBINE, or you didn't know about that algorithm altogether? (I mean, repeatedly multiplying result-so-far by the base rather than computing (base) ^ (digit position) for each digit.)
More like I hadn't thought of using COMBINE to implement the algorithm.
Edit: I just made base-to-num using it and which supports up to base 36 using letters.
Ah. Thanks. I was curious because one of the arguments I emphatically lost in developing BJC for high school was that I wanted to use this algorithm, but with recursion rather than COMBINE, and all the EDC people told me that they'd had a lot of experience teaching place value algorithms to high school kids, and most of them were hopelessly confused by this algorithm, regardless of how expressed. In particular asking kids to do this by hand failed.
When I read this post, I thought to myself: oh, we can average in many ways with Snap. I tried several approaches in this project.
(i don't know why this quoted block is so big!)
I know. I've only been experimenting with the combine block...
Here's a picture of the block made with the Block Plugin syntax, that can textually represent any Snap! block (or almost any) - as explained at the https://en.scratch-wiki.info/wiki/Block_Plugin/Syntax#Snap! page.
[scratchblocks]
(sum((list[3][5][7]🞀 🞂 ::list ) / (3) ) ::operators // '🞀' and '🞂' need to be copypasted from the textual representation here.
[/scratchblocks]
And below is the actual textual representation that will render the above image.
[scratchblocks]
(sum((list[3][5][7]🞀 🞂 ::list ) / (3) ) ::operators // '🞀' and '🞂' need to be copypasted from here.
[/scratchblocks]
P. S.
Alternatively, if you don't want to bother with the textual representation, you can still use the image but don't forget the dimensions and percent,
(use backslashes)
tnx
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.