Algorithms and OOD (CSC 207 2014F) : EBoards

# CSC 151: Extra Session 2 (Thursday, 11 Sept. 2014)

Overview

``````Repeat
Repeat
Until we run out of time or you run out of questions
Repeat
Until we run out of time or you start asking questions again
Until we run out of time
``````

Sam: What do you see as the difference between int, Integer and BigInteger?

• Student: Boy Sam, that's in the reading. I know that one.

Student: So, how does BigInteger work?

• Yay! We distinguish implementation from interface. You don't have to know how it accomplishes its task.
• And that's normal. Do you know how `3 * 12` works in C (or on the chip)?
• You'll learn this in 211.
• But we can hypothesize, and we could implement our own ArbitraryLengthInteger class
• Implementation questions
• Linked or area of memory (array)?
• What fields do we need?
• Other general principles?
• An integer is just a sequence of digits (plus a sign)
• To add: Starting from the right of each sequence, add each digit, keeping track of the carry
• To multiply: You know the algorithm!
• Of course, BigIntegers probably use unsigned ints for each digit, rather than a number in the range 0-9.

Sam: What's the most confusing part of 207? Student: Organizing all the files. Testing.

• It's somewhat painful that we have so many things to keep track of.
• GitHub repository
• Eclipse Project
• One or more packages
• One or more classes
• Should be a one-one correspondence between the first three.
• Three different ways of thinking about the same set of files.
• Package

• Logical grouping of classes
• Encapsulation idea: Different groups for different purposes
• One set for my Ushahidi code `edu.grinnell.rebelsky.ushahidi`
• Another set for string utilities (or all utilities) `edu.grinnell.rebelsky.utils`
• Encapuslation enforcement: Java's protection levels let you say "All classes in the same package can access a (field, method, constructor, class, etc.); things in different classes can't"
• E.g.

package foo; public class Foo { int x; ...; } // class Foo

package foo; public class Bar { ... f = new Foo(...); f.x = 3; // permitted } // class Bar

package qux; import foo.Foo; public class Qux { ... f = new Foo(...); f.x = 3; // not permitted } // Qux

• As the example above suggests, classes in one package can still refer to classes in another package, but you need to import or use the full name.
• We also make packages to avoid problems with repeated names.

What does the `import foo.Foo` or `import java.io.PrintWrinter` mean?
(Or any import.)

• It doesn't quite mean what it sounds like (which is "it sounds like C's include")
• It really means "I don't want to have to give the fully qualified class name for Foo", so accept that the class name implies the fully qualified class name.
• I don't want to type `java.io.PrintWriter pen = new java.io.PrintWriter(...)`
• This lets me type `PrintWriter pen = new PrintWriter(...)`
• We can't use import for two classes with the same base name. `import edu.grinnell.walker.Utilities; import edu.grinnell.rebelsky.Utilities;`
• Ambiguious! Ambiguity is bad. Java/Eclipse will complain.
• For this reason, Sam discourages `import java.io.*;`.

Can you have more than one class in a Java file?

• You can have only one public class in a Java file.
• Many pundits discourage you from putting multiple classes in a file (with a few exceptions, such as anonymous classes or inner classes)

How should we deal with parsing BigIntegers?

• new BigInteger(string)