swap elements () and () of list, which tells the program that those indicies need to be swapped by the code. Support for adding elements, setting them, and removing them will also be added in the future.
Interesting, I just yesterday watched the video with this visualizer applied to Can’t Believe. I guess YouTube is making the same recommendations to you and me! :~)
In your Bubble Sort procedure you have
You don’t have to use CATCH and THROW in this situation. You can put a REPORT block anywhere in your code, not only at the end. So you can just
But, your project doesn’t work for me. It just shows the initial picture of the input list, and plays the final arpeggio.
Anyway, I don’t see why you do it in this complicated way, first doing the entire sort and then replaying it for the animation. Why not just write your SWAP ELEMENTS block so that it does the visualization as it’s doing the swap in the data? That would also avoid your problem of needing to know the context from which a block is called!
That happens to me also.
Sorry, I was trying to make some quick changes and forgot to get the project back up! I’ll do that as soon as I can. I’m putting the swap elements block as a seperate thing so that I can play back important transformations of the list instead of guessing when each iteration ends (That way you can put in any old list operation block and it will spit out a fun animation, not just a custom-built demo for the project.
I also figured reporting halfway through the list would just leave the list half sorted. I dunno though, ill try it
Also, was that the Matt Parker video you watched? That guy’s content is brilliant.
Where the THROW throws to is the REPORT block! So you’re reporting halfway through whether you do it via THROW-to-REPORT or via REPORT-in-place. What’s important is when in your algorithm the REPORT is run, not where it’s physically located in the script.
When you create a reporter, we include a REPORT block in the Block Editor as a convenience for one-liner reporters such as
As you’re creating this block, the odds are you’re already in the Operators palette and that makes it easy to finish editing the block, without having to detour to Control to find a REPORT block. Most custom reporters are one-liners, so we thought it’d be worthwhile to do this.
But the pedagogic cost of this convenience is that sometimes it misleads people learning Snap! into thinking that there can only be one REPORT block in your code and it has to be physically at the end of the script. That’s not the case. For example, another common pattern is
I dunno, YouTube says “stand up maths.”
I guess I copied a Java function essentially line-for-line and didnt realise how the function actually worked - Looking back at the code, I suppose that makes sense in hindsight.
That’s him! I really like his videos, they focus around more entertaining math stories like that.
please im really trying to fix it just give me a second
Looks like a script variable is set in the block, that context isnt saved with the lambda in one of the blocks. I dunno why this is the case, since the inputs to the block are saved in the lambda.
All right, it took a little messing around but I eventually got it to work how I wanted. Its now ready if anyone wants to mess with it.
