All assignments are to be submitted to Blackboard. Programming assignments have one part, a code archive. Projects have the code archive and a writeup, and thus need two separate submissions to Blackboard. A due date and 'drop dead' date are given for each one. After the due date the work is flagged by BB and your grade could suffer. After the drop dead date you can't submit.
Assignments can be submitted multiple times. For more details, plus grading policies, weights, and rubrics (what's worth what) see Grading Policies.
"BB ate my homework!" Well, maybe. Or maybe you hit the wrong key. You should check IMMEDIATELY (not, for instance, after final course grades come out) if something went wrong. You can and really, really should check every submission immediately to make sure BB received what you sent! "Trust but verify." If find a problem, the multiple submission feature lets you re-send.
README is an Ascii file with your name, the assignment's name, and a list of the files in the archive and a phrase or one-sentence description of each one.
Create README with Matlab script editor, (then it might be called README.m, which is OK). Or with Word® and "Save As" text. Or with simpler text editor.
The diary file is a copy of what appeared in the command window when you run main.m. Read the assignments for how to create it.
Your code submission must be a single zipped archive folder, which is a file containing all the code and code-related files (.m files, data, README, diary, etc.) for the project.
To create an archive on Windows: On recent Windows machines, like those in the IT labs around campus: Put all the submission files into one folder, maybe called Asst_X. Create a compressed or zipped file by simply right clicking on the Asst_X folder, pull down to the "Send To" menu, choose "Compressed (zipped) Folder" and A zipped folder will appear. It is in fact a single file you can then submit to BB, so do that.
Do not use .rar archive format. If you use WinRar, specify .zip as the output option, not .rar. WinZip works too, I hear.
Easy way to create an archive on OS-X (Mac): (there are more, but this is easy.) Simplest is to hold down CTRL (control) and click the folder you want to zip, choose the obvious option ('Create Archive', or something with the word 'Compress') and a compressed folder appears.
We don't guarantee to deal with non-.zip archives, and if we do there is a one mark penalty.
What goes in a Writeup, how it's graded, etc. is found in Grading Policies . Also there are some Sample Writeups .
Writeups must be submitted, un-zipped, as a single file in PDF format (.pdf files): The TAs are not obligated to try to read any other format and if they do, non-PDF work is penalized one mark (out of a maximum of three). You can save your Word® files as PDF ... usually "Save as PDF" or "Export as PDF" in the FILE menu, but at one time this conversion was only offered in Word® 's Print menu(!). Anyway figure out how and do it for machines you'll be using. Make sure that they really are PDF: For instance, can you open them with Adobe Acrobat?
Writeups are important in 160 because of the choices available in the selection of and approach to projects. Writeups explain what you did, and the more choices you exercised the more there is to explain. Also projects call for experimentation, and so methods and results must be explained (and preferably shown graphically).
As a general policy, your writeups should assume that the reader does not know what the assignment was, what procedure was followed, or what results were expected. You can assume a certain level of general knowledge on the part of the audience (i.e. you don't have to define what a matrix is unless the assignment calls for it) but nothing class or assignment specific.
A zipped archive containing your main.m file and diary
file. Here the README is pretty simple, and should look something
like
this:
Programming Assignment 1 Fred Bloggs main.m: main script implemting solutions for assignment. diary: transcript of main.m running
Later in the course archives (READMEs) will typically have (describe) several .m files and a .pdf file.
A zipped archive containing your code *.m files, your main.m script, the diary , and a README file.
Like Assignment I, only only now we'll need a passel of .m files for functions, and a main script file main.m, which calls and demonstrates the functions. Your name should be at the top of the README. If we type main we should get a run of all the exercises.
We want to see your code, but we can only give you credit for what the Writeup demonstrates is working. We will not look at computer code and try to figure out what you were trying to do (code is meant for computers, not people). Thus in a sense the writeup is the ONLY THING. We might look at your coding style (comments? neatness? organization?) but we can't guarantee to critique it, try to run it, much less debug it. Please consider that the only evidence we'll have that your code works is provided by the compelling examples in your writeup.
For the Code part of this assignment, hand in a zipped code archive containing your code *.m files, your main.m script, and a README file.
For the Writeup part, hand in project writeup in PDF format (a .pdf file), unzipped. NOT, for instance, Word® (a .doc or .docx file). We're not obligated to deal with non -.zip archives: if we do, there's a one-mark penalty.
Treat this part like a programming assignment.
Almost all emphasis on your project writeup, though of course the experimental code counts for something. If you corrected or improved basic code since it was handed in for credit, you can get juice out of that with a better report.
Hand in a zipped archive containing your code *.m files, your main.m script(s), and a README file.
Also a project writeup in PDF format (a .pdf file). NOT Word® (a .doc or .docx file).
This is an individual exercise, not a team exercise. Make sure your name is on your essay, and submit to Blackboard (unzipped, in .pdf) by the assigned date.
Each team member MUST submit something to Blackboard for this
lab.
One member should submit both the zipped code archive for the "LED
Lab Code" grade column and the .pdf writeup for the LED writeup grade
column. Make sure both names are on the README and writeup, and it
would
be good to mention both names in the submission comments.
The
other member should submit 1-liner .txt file "I worked with
so-and-so.". That makes it impossible to forget the partner who
doesn't submit code and writeup.
For the Code component, archive and submit all code with README for all four projects in Lab1, Lab2, Lab3a and Lab3b.
For the writeup component, identify the team members in the header of your PDF writeup, submit unzipped as usual.
The PDF writeup should consist of the plots from Labs 3a and 3b. For 3a, the three-plot graph (use legend to label the lines!) showing voltage drop across resistor, LED, and whole circuit. Include a caption-like short paragraph explaining what the plots show (a brief version is given in the assignment, maybe you can do better).
For 3b, one or two plots like the one in the assignment. Again, describe what the plots tell us.
As always, if you have notable insights or experiences, share those.
Each team member MUST submit something to Blackboard for this
lab.
One member should submit both the zipped code archive for the "LVDT
Lab Code" grade column and the .pdf writeup for the LVDT writeup grade
column. Make sure both names are on the README and writeup, and it
would
be good to mention both names in the submission comments.
The
other member should submit 1-liner .txt file "I worked with
so-and-so.". That makes it impossible to forget the partner who
doesn't submit code and writeup.
There's not much code, but zip up your functions, README, what-have you and submit for the Code component.
We want the usual report-style writeup of your experiments, results and conclusions (full sentences, paragraphs, good english, complete descriptions etc. Basically assume the reader did not read the assignment). The writeup should include all data (though not the thousands of raw reads). Writeup should also include at least one nice plot of the results, and the results of any line-fitting computations.
Procedures as for the Pi Project; remember that we want to see your code, but we can only give you credit for what the writeup demonstrates is working. We can't guarantee to look at computer code and try to figure out what you were trying to do (code is meant for computers, not people). Concentrate on the writeup: if it's done right it will totally convince the reader that you have working code. Typically the only evidence that your code works is provided by the compelling examples in your writeup: we don't usually try to run code independently.
For the Code component, submit a zipped archive containing your code *.m files, your main.m script, and a README file.
For the writeup component, submit a single non-zipped .pdf (not .docx or anything else) file.