I hate computers December 9, 2013
Posted by mareserinitatis in computers, grad school.Tags: computers, dissertation, research, software
add a comment
I hate it when things don’t work the way they should….like when your software license that’s supposed to last for one year suddenly stops working after 8 months.
Sadly, that was pretty much the highlight of the day.
Wordless Wednesday: To find your P-value September 17, 2013
Posted by mareserinitatis in computers, math, photography.Tags: jokes, pictures, software, wordless wednesday
5 comments
Looking at logo July 18, 2013
Posted by mareserinitatis in computers, younger son.Tags: computers, logo, programming, younger son
1 comment so far
A few weeks ago, the younger son asked me what I was doing. I told him I was doing some research.
“But what are you doing?”
Fair enough. I told him I was writing a computer program, so he asked how someone does that. At that point, I was doing something in Fortran, so I wrote up a simple Hello World program and ran it. This program, however, said, “Hello, younger son.”
Since that point, he’s been asking me to teach him how to program. I suspect this comes from the fact that he’s very interested in Minecraft and wants to learn how to create mods. Unfortunately, I don’t know the first thing about that particular activity.
As you saw from my list the other day, I know several languages and software packages, but I figured most of them were not going to be terribly fascinating to a little boy whose age is still in the single digits.
Except, maybe logo.
I talked things over with Mike, and he thought logo would be good, as well, given it uses some of the math the younger son is learning and can be used to draw things.
Some folks at Berkeley have a nice (free!) logo interpreter along with some manuals on how to program in logo. I appreciate the manuals as it’s been a very long time since I’ve looked at anything pertaining to the language. I’m probably going to have to relearn everything, but I figure this will be fine as it’s something the younger boy and I can do together. I’m looking forward to it despite the fact that this probably isn’t a typical mother-son bonding activity.
Does this make me multilingual? July 16, 2013
Posted by mareserinitatis in computers, electromagnetics, engineering, grad school, math, physics, research.Tags: computers, dissertation, fortran, languages, programming
3 comments
I began my programming education quite young and have maintained my skills over the years. I have recently been thinking of documenting some of the various languages and software programs I’ve learned to use, so here is as good a place as any.
- 4th grade – TI Basic
- 8th grade – Logo
- 10th grade – BasicA and Apple Basic (pretty close to the same thing)
- 12th grade – Fortran and QBasic (these were at the college)
In college:
- took a class on C and had to learn unix, too
- learned Maple in a calc course
- learned matlab for a research project and used it extensively in a numerical analysis course
- learned mathcad for a physics lab course
- learned mathematica for intro to differential equations and used that for many other classes
During my MS, I was exposed to half a dozen software packages for computational electromagnetics modeling (half of which are trademarked, so I’m not going to bother listing them).
In the past couple years at work, I’ve gotten pretty handy with Scilab.
After all of this, you would think that I have a pretty complete toolkit. I should be able to do pretty much whatever I need with what I’ve already learned. I find it ironic, therefore, that I am back to using Fortran (one of the first things I learned). I also have been spending the past month trying to learn IDL (which, if you don’t mind me saying, seems like a less friendly version of matlab), so there is something new, again. Also, I have people pestering me to learn python.
Looking at this list, I’m starting to think I’m learning things so that I can simply forget them again later. I’m pretty sure I’ve forgotten more than I remember.
I almost speak Greek April 13, 2013
Posted by mareserinitatis in computers, humor, science.Tags: accuracy, greek, kappa, precision
add a comment
I was working on my thesis, trying to do some debugging, when I discovered a discrepancy between two pieces of code. Mike was standing nearby, and when I made that noise one makes when they discover something is afoot, he asked what was up.
“There’s a difference between kappa in these two programs.”
“What’s kappa?”
Of course, I blanked at that particular moment and couldn’t dredge up the meaning from the recesses of my memory.
“Umm….it’s that little K thingy.”
I think that’s the accurate but not precise answer…
Lost in translation March 18, 2013
Posted by mareserinitatis in computers, research.Tags: fortran, matlab, programming
add a comment
I took my first class in Fortran in the fall semester of 1992, while I was still in high school. I was taking some classes at the university as an early entry student, and the teacher of the course was a grad student. He was trying to explain something and kept getting the syntax wrong. I was getting horribly frustrated, as were the rest of us. He probably noticed as his response was to say, “I know three operating systems, which means I’ve become completely useless in all of them.”
I didn’t understand how he could confuse things like that as I was taking German and Spanish simultaneously and never seemed to have a problem with mixing things. I had no idea how different it was to learn spoken language versus coding language. That was before I’d learned to use a handful of programming languages and started using matlab commands in my fortran code. Debugging is even more of a pain because it looks right…and it is, but for another language.
The calm before the storm November 25, 2012
Posted by mareserinitatis in computers, engineering, teaching.Tags: office hours, programming, students, teaching
add a comment
I teach on Tuesdays and Thursdays. This past week was Thanksgiving, so I obviously had a bit of a dilemma. I don’t like getting the classes out of synch because that means I have two different preps to complete. The obvious solution, therefore, is to just cancel class during the week of Thanksgiving, and that is exactly what I did.
However, I’ve changed one of the assignments in the class from optional to required. You may remember that last year, I talked about Engineers Who Don’t Like to Program. I discovered that the majority of my students would rather do a presentation than learn how to program. I decided this year to change that. Instead of having two optional programming assignments, I moved some things around so that there is one assignment, very scaled back from what I had expected last year, and it was required to pass the class.
I had a lot of intimidated students, but I think cutting the length back significantly made them less afraid. I chose to have two weeks in the computer lab to work on the assignment. They ended up being the week before Thanksgiving and the week after. In the meantime, I decided to add an extra office hour during one of the cancelled classes so that students could come and ask me questions.
Not surprisingly, no one showed up. I’ll have to remind them of this when I have an flurry of requests from students needing extra help right before the assignment is due.
That’s totally the way it works… November 18, 2012
Posted by mareserinitatis in computers.Tags: bugs, computers
add a comment
When you finally have the time to sit down and work on something that you’ve been putting on the backburner but is very important, you know what’s going to happen: the computer will decide it’s the time to have a temper tantrum.
Doesn’t anyone ever comment any more? June 26, 2013
Posted by mareserinitatis in computers, research.Tags: commenting, comments, computer, programming
3 comments
While the title above may seem like a complaint about the blog, I am fairly certain that the lack of commentary is probably due to the lack of posting.
Instead, however, I feel like complaining about another issue (one I’ve likely addressed before): lack of comments in code. One thing that frustrates me about teaching students to program is that they are generally unaware of how important it is to comment your code, particularly when that code is for a research project and may need to be picked up by someone else.
I guess I’m getting old enough that I’ve had several instances of attempting to pick up an old piece of my own code and realizing what a horrible job I did in commenting. I’m now incredibly thorough when commenting my code so that I’ll be able to go back to it later and understand.
The real issue is, however, that no one ever taught me how to comment code. It’s something I had to figure out for myself. The only thing I ever saw was one brief section in Darnell and Margolis’ book. While I agree with the Do’s they listed, I strongly disagree with a couple of the Don’ts:
While I agree with the second bullet, I’ve learned over time that the first and third are bunk. Specifically, there is this notion that well-written code should make it obvious as to what is being done. Maybe if you’re the only person looking at your code, but that’s usually not the case. As much as we would like to think that meaningful variable names will substitute for explanation in the comments, I’ve found that one person’s meaningful variables may not be that to another person and will probably require significant elaboration. Further, truly meaningful variable names often need to be rather long, and few people want to take the time to type out names that would be exceptionally clear. (And then there’s the programmer I knew who used exotic dancer’s names for his variables. His code was a nightmare to debug.)
The first bullet is the one that really irritates me, however. I have pulled up code I wrote from a class to use in another class and been completely confused because it had been years since I looked at it. During the second go-around, I realized there was a chance I may end up using it again, so I started adding things in. Specifically, I put in the comments that it was algorithm to do linear interpolation. I even put a reference to the book I got the algorithm from, including page numbers, and what the inputs would need to be (including format requirements) as well as the outputs. I mentioned what needed to be changed to use the code for other programs. Finally, I went through and explained what was happening in each step or loop and what the variables meant (e.g., k is a counter, c is the coefficient array). Without *all* this information, it was impossible to take the code I’d written and modify it for another use without putting in some significant effort.
The reason I went into such elaborate detail (and continue to do so) is that a lot of code, particularly when dealing with algorithms, is almost never intuitive. If that were intuitive, references like the numerical recipes books would be useless. (Well, they kind of are, but you know what I mean.) Therefore, contrary to the advice given above, comment everything, how it works, what your variables mean, etc. You and anyone else who uses your code later will be very appreciative.