Open colinleach opened 1 month ago
I'm not sure if it's too advanced of a topic, but we could mention that tuples can still be broadcast over (requiring the .
syntax to do so).
1 .+ (3, 2) = (4, 3)
1 + (3, 2) = MethodError
It might also be good to mention that tuples are more performant than vectors, so should be preferred in cases when mutability isn't necessary.
It might also be good to mention that tuples are more performant than vectors
Definitely yes.
we could mention that tuples can still be broadcast over
Maybe/probably. I'm still trying to work out what to do about introducing broadcasting, but it's moving up my TODO list. It's important!
For mixed reasons, I haven't made much progress on the Julia syllabus in the last few days. I'm currently getting near the end of the Randomness concept (I hope!), which turned out to be significantly more complicated and difficult than I expected. There has been talk in the Julia core team about reorganizing all the statistics-related stuff, and I hope they get it sorted. Currently, things are scattered around in a way I find quite confusing, and struggle to explain to students in the syllabus.
For mixed reasons, I haven't made much progress on the Julia syllabus in the last few days.
You've made huge progress as is, so no need to explain downtime :)
I was wondering if you would like me to make the lessons for these wips when one is decided upon? It's something I quite enjoy doing (since it involves solving the exercise in Julia), so I'm more than happy to contribute in this way.
Maybe/probably. I'm still trying to work out what to do about introducing broadcasting, but it's moving up my TODO list. It's important!
Come to think of it, I would assume it's best left to a full concept rather than an aside, so maybe best to be left out here.
I was wondering if you would like me to make the lessons for these wips when one is decided upon?
Absolutely! You'll notice I have mostly concentrated on Concepts, rather than exercises. Various reasons:
Feel free to pick your exercises, either from what we discussed or from your own ideas. Once we know the scope of the exercise, we can cut down the corresponding about.md
to an introduction.md
. Always remembering "Jeremy's Rule" that the intro should contain only what the student needs to solve the exercise: the boss is pretty intense about this.
I assume you've read the documentation on this? We'll be under pressure to conform, both to avoid repeating past syllabus mistakes (by no means just Julia - several tracks failed and were abandoned), and to help the GH repo integrate well with the website.
Sounds good! I'll try to follow the specs as best I can.
How should we join the exercises and concepts? Should I just keep them in my fork until we're ready?
How should we join the exercises and concepts? Should I just keep them in my fork until we're ready?
It's a bit complicated to know where to put things, given the pushback we got on tidying up the existing repo structure. When I PRd squeaky-clean
and currency-exchange
, I put them in exercises/concept
(their final location), but submitted them as draft to avoid triggering a review before we're ready. That just requires finding the right option on GH, which I sometimes still struggle with.
I've mostly been putting the concepts in concepts.wip
, but with hindsight I don't think that was the best choice.
You'll notice I've been PR'ing stuff well before it is ready for review, so it's entirely up to you how long you keep them on your own fork. I do the early trial-and-error stuff on an entirely separate private repo that I would be embarrassed to show to the world!
Maybe we can create a new folder to keep the exercises before we merge everything? I find it's kind of a pain to keep more than one on a fork before merging.
I'll look into creating some exercises tomorrow (or the day after) that align with what we've talked about.
Your choice, whatever works for you.
A popular exercise to go with this is
tisbury-treasure-hunt
(Python and several other languages), but we have multiple choices.