Trance-0/NoteNextra-origin
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity

update

Browse Source
This commit is contained in:
Zheyuan Wu
2025-03-31 10:47:07 -05:00
parent c118ab699f
commit a71c860d8d
3 changed files with 322 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

200
pages/CSE332S/CSE332S_L16.md Normal file
View File

@@ -0,0 +1,200 @@
# CSE332S Lecture 16
## Intro to OOP design and principles
### Review: Class Design
Designing a class to work well with the STL:
- What operators are required of our class?
- `operator<` for ordered associative containers, `operator==` for unordered associative containers
- `operator<<` and `operator>>` for interacting with iostreams
- Algorithms require particular operators as well
Designing a class that manages dynamic resources:
- Must think about copy control
- **Shallow copy** or **deep copy**?
- When should the dynamic resources be cleaned up?
- Move semantics for efficiency
### OOP Design: How do we combine objects to create complex software?
Goals - Software should be:
- Flexible
- Extensible
- Reusable
Today: 4 Principles of object-oriented programming
1. Encapsulation
2. Abstraction
3. Inheritance
4. Polymorphism
#### Review: Client Code, interface vs. implementation
Today we will focus on a single class or family of classes related via a common
base class and client code that interacts with it.
Next time: Combining objects to create more powerful and complex objects
**Client code**: code that has access to an object (via the object directly, a reference to the object, or a pointer/smart pointer to the object).
- Knows an object’s public interface only, not its implementation.
**Interface**: The set of all functions/operators (public member variables in C++ as well) a client can request of an object
**Implementation**: The definition of an object’s interface. State (member variables) and definitions of member functions/operators
#### Principle 1: Encapsulation
Data and behaviors are encapsulated together behind an interface
1. Member functions have direct access to the member variables of the object via “this”
1. Benefit: Simplifies function calls (much smaller argument lists)
Proper encapsulation:
1. Data of a class remains internal (not enforced in C++)
2. Client can only interact with the data of an object via its interface
**Benefit**:
(Flexible) Reduces impact of change - Easy to change how an object is stored
without needing to modify client code that uses the object.
#### Principle 2: Abstraction
An object presents only the necessary interface to client code
1. Hides unnecessary implementation details from the client
a. Member functions that client code does not need should be private or protected
We see abstraction everyday:
- TV
- Cell phone
- Coffee machine
Benefits:
1. Reduces code complexity, makes an object easier to use
2. (Flexible) Reduces impact of change - internal implementation details can be
modified without modification to client code
#### Principle 3: Inheritance (public inheritance in C++)
**"Implementation" inheritance - class inherits interface and implementation of
its base class**
Benefits:
- Remove redundant code by placing it in a common base class.
- (Reusable) Easily extend a class to add new functionality.
**"Interface" inheritance - inherit the interface of the base class only (abstract base class in C++, pure virtual functions)**
Benefits:
- Reduce dependencies between base/derived class
- (Flexible, Extensible, Reusable) Program a client to depend on an interface rather than a specific implementation (more on this later)
#### One More Useful C++ Construct: Multiple Inheritance
C++ allows a class to inherit from more than one base class
```cpp
class Bear: public ZooAnimal {/*...*/};
class Panda: public Bear, public Endangered {/*...*/};
```
Construction order - all base classes are constructed first:
- all base classes -> derived classes member variables -> constructor body
Destruction order - opposite of construction order:
- Destructor body -> derived classes member variables -> all base class
destructors
**Rule of thumb**: When using multiple inheritance, a class should inherit
implementation from a single base class only. Any number of interfaces may be
inherited (this is enforced in Java)
#### Principle 4: Polymorphism
A single interface may have many different implementations (virtual functions and
function overriding in C++)
Benefits:
1. Avoid nasty switch statements (function calls resolved dynamically)
2. (Flexible) Allows the implementation of an interface to change at run-time
#### Program to an interface
Client should restrict variables to an interface only, not a specific implementation
- **Extensible, reusable**: New subclasses that define the interface can be created and used without modification to the client. Easy to add new functionality. Easy to reuse client.
- **Reduce impact of change**: Decouples client from concrete classes it uses.
- **Flexible**: The implementation of an interface used by the client can change at run-time.
In C++:
- Abstract base class using pure virtual functions to declare the interface
- Implement the interface in subclasses via public inheritance
- Client maintains reference or pointer to the base class
- Calls through the reference or pointer are polymorphic
```cpp
// declare printable interface
class printable {
public:
virtual void print(ostream &o) = 0;
};
// derived classes defines printable
// interface
class smiley : public printable {
public:
virtual void print(ostream &o) {
o << ":)" ;
};
};
class frown : public printable {
public:
virtual void print(ostream &o) {
o << ":(";
};
};
int main(int argc, char * argv[]) {
smiley s; // s restricted to
// a smiley object
s.print();
// p may point to an object
// of any class that defines
// the printable interface
printable * p =
generateOutput();
// Client unaware of the
// implementation of print()
p->print();
return 0;
}
```
Program to an interface
Allows easily extensible designs: anything that defines the printable interface can
be used with our client
```cpp
class Book : public printable {
vector<string> pages;
public:
virtual void print(ostream &o) {
for(unsigned int page = 0; page < pages.size(); ++page){
o << "page: " << page << endl;
o << pages[i] << endl;
};
};

121
pages/Math4121/Math4121_L28.md
View File

@@ -1 +1,120 @@
# Lecture 28
# Math4121 Lecture 28
## Continue from last lecture
### Lebesgue Measure
#### Outer Measure
$$
m_e(S) = \inf_{S \subseteq \bigcup_{j=1}^{\infty} I_j} \sum_{j=1}^{\infty} \ell(I_j)
$$
If $S\subseteq I$ is measurable, then $m_i(S)=m_e(I)-m_e(I\setminus S)$
#### Lebesgue criterion for measurability
$S\subseteq I$ is measurable if and only if $m_e(I)=m_e(S)+m_e(I\setminus S)$
#### Caratheodory's criteria
Lebesgue criterion holds if and only if for any $X$ of finite outer measure,
$$
m_e(X)=m_e(X\cap S)+m_e(X\setminus S)
$$
> **Local additivity**
>
> $\{I_j\}_{j=1}^{\infty}$ is a collection of disjoint intervals, then
>
> $$m_e\left(S\cap \bigcup_{j=1}^{\infty} I_j\right) = \sum_{j=1}^{\infty} m_e(S\cap I_j)$$
> Proved on Friday
Proof:
$\implies$ If Lebesgue criterion holds for $S$, then for any $X$ of finite outer measure,
$$
m_e(X)=m_e(X\cap S)+m_e(X\setminus S)
$$
First, we extend Lebesgue criterion to intervals $I$ that may not contain $S$. Then we can find $J,K$ intervals neighboring $I$ such that $S\subseteq \tilde{I}=J\cup I\cup K$.
By Lebesgue criterion,
$$
\begin{aligned}
m_e(\tilde{I})&=m_e(\tilde{I}\cap S)+m_e(\tilde{I}\setminus S)\\
&=m_e(S)+m_e(\tilde{I}\setminus S)\\
&=m_e(S^c\cap \tilde{I})+m_e(S\cap \tilde{I})\\
&=\sum_{L\in \{J,I,K\}}m_e(L\cap S^c)+m_e(L\cap S)\\
&\geq \sum_{L\in \{J,I,K\}}m_e(L)\\
&=m_e(\tilde{I})
\end{aligned}
$$
Therefore, $m_e(I)=m_e(S^c\cap I)+m_e(S\cap I)$.
Now, let $X$ has finite outer measure, let $\epsilon>0$, we can find $\{I_j\}_{j=1}^{\infty}$ covering $X$ and
$$
\sum_{j=1}^{\infty} \ell(I_j)<m_e(X)+\epsilon
$$
$$
\begin{aligned}
m_e(X)&\leq m_e(X\cap S)+m_e(S^c\cap X)\\
&\leq m_e\left(\bigcup_{j=1}^{\infty} I_j\cap S\right)+m_e\left(\bigcup_{j=1}^{\infty} I_j\cap S^c\right)\\
&\leq \sum_{j=1}^{\infty} m_e(I_j\cap S)+m_e(I_j\cap S^c)\\
&=\sum_{j=1}^{\infty} m_e(I_j)\\
&<m_e(X)+\epsilon
\end{aligned}
$$
QED
### Revisit Borel's criterion
1. $m(I)=\ell(I)$
2. If $\{S_j\}_{j=1}^{\infty}$ is a sequence of disjoint measurable sets, then $m\left(\bigcup_{j=1}^{\infty} S_j\right)=\sum_{j=1}^{\infty} m(S_j)$
3. If $R\subseteq S$, then $m(S\setminus R)=m(S)-m(R)$
#### Theorem 5.8 (Countable additivity for Lebesgue measure)
If $\{S_j\}_{j=1}^{\infty}$ is a sequence of disjoint measurable sets, whose union $S=\bigcup_{j=1}^{\infty} S_j$, has finite outer measure, then
$$
m_e(S)=\sum_{j=1}^{\infty} m_e(S_j)
$$
Proof:
First we prove $m_e(\bigcup_{j=1}^{\infty} S_j)=\sum_{j=1}^{\infty} m(S_j)$ by induction.
$n=1$ is trivial.
Let $n>1$ and suppose the statement holds for $n-1$. Take $X=\bigcup_{j=1}^{n-1} S_j$, then $S_n\cap X=S_n, X\setminus S_n=\bigcup_{j=1}^{n-1} (S_j)$.
By Caratheodory's criteria,
$$
\begin{aligned}
m_e(X)&=m_e(S_n)+m_e(\bigcup_{j=1}^{n-1} S_j)\\
m_e(\bigcup_{j=1}^{n} S_j)&=m(S_n)+\sum_{j=1}^{n-1} m(S_j)\\
&=\sum_{j=1}^{n} m(S_j)
\end{aligned}
$$
Take the limit as $n\to\infty$, and justify this.
$\sum_{j=1}^{\infty} m(S_j)=m_e(\bigcup_{j=1}^{\infty} S_j)\leq m_e(S)$
Since $m_e(S)$ is finite and $m(S_j)$ is monotone, the limit exists.
Therefore, $\sum_{j=1}^{\infty} m(S_j)\leq m_e(S)\leq \sum_{j=1}^{\infty} m(S_j)$
So $S$ is measurable.
QED

8
pages/Math4121/_meta.js
View File

@@ -31,10 +31,6 @@ export default {
Math4121_L25: "Introduction to Lebesgue Integration (Lecture 25)",
Math4121_L26: "Introduction to Lebesgue Integration (Lecture 26)",
Math4121_L27: "Introduction to Lebesgue Integration (Lecture 27)",
Math4121_L28: {
display: 'hidden'
},
Math4121_L29: {
display: 'hidden'
},
Math4121_L28: "Introduction to Lebesgue Integration (Lecture 28)",
Math4121_L29: "Introduction to Lebesgue Integration (Lecture 29)"
}