I was all worried about how I was going to scale the axes and make the tick marks
and then it was already part of the template! That said, it was super helpful to
be able to see under the hood on how all the formatting and setup was done.
Overall the process went well. Having the structure for part of drawing the axes
made that section very smooth. I had made a typo in the dtaw_points portion where
I had used () instead of [] when indexing a list amd the error message was just
cryptic enough to make me think I had made some other, more serious mistake after
correcting the typo; turns out, I had just not resaved scatterplot.py after correcting
so of course I was going to keep getting the same error message. Other than that,
the assignment was straightforward and implementing the functions we made in transform.py
was easy enough to get the axes drawn and points plotted. I'm happy with how it turned out.
Top-down design made this process accessible, as far as I'm concerned. Without breaking
this up into small steps, there's no way I would have been able to do this all at once.
I really appreciated your clarity and breakdown throughout the prompt. The whole system
up to this point has been a great model for how I need to approach projects/labs in the
future with my courses. When I was teaching physics, it was sort of second-nature to go
through an example, break down a problem, and then have the students apply it themselves
but one thing I haven't dialed in on the cs-side yet is how much do I give to the students
and at what point can they do it themselves. I usually fall into the trap of wanting them
to do too much too fast and when they're confronted with a problem they (think they) can't
solve, they shut down.
I was getting errors when running test_transform.py not because of transform.py
(I think) but instead because of how the arguments were being passed into the
functions within. I removed the list-in-a-list from the clamp(), ratio(), and
scale() tests and things seem to be working as expected.
A lot of the extra thinking for checkpoint 2 was related to my attempt to avoid
overthinking the problem. I found myself more than once starting to rewrite functions
that I had already made, so upon taking another look at my plan, I realized the
easier route would be to use things like the clamp() or minimum() function, for example,
in order to save myself time and possible hard-to-diagnose bugs later on. Keeping
with the theme of top-down design, breaking the problem up into smaller, simpler pieces
also makes things easier to test as progress is made. The biggest strategy I employed
was writing down, in English/pseudocode, what I wanted to do, then as I started to write
out my code, I would explain to myself what was supposed to happen, which is where I
started to go back to my previous functions to continue using them in the next function
to be made.
I could make the marker, draw the lines, and move the turtle around appropriately
to make a reasonable plot, but the thing I'm wondering about is the scale of the plot.
It should be easy enough to modify later if it's a problem, but I'm wondering if I should
have planned ahead for a plot with so many points, the whole thing should be resized.
I'm not 100% sure how I'm going to do the increment for the axis label yet; it's easy
enough to calculate the difference and turn that into, say, 5 equal divisions, but I
haven't quite decided how I should deal with rounding the number out so it's not something
like 63, 154, 245, 336, 427, 518. It's not the worst thing in the world if that's the output
but I wouldn't be particularly happy with how it's presented.
Pat Wick
pwick