summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJoshua Liu <joshua.liu@sourceobby.com>2026-10-03 20:20:26 -0400
committerJoshua Liu <joshua.liu@sourceobby.com>2026-10-03 20:20:26 -0400
commit0e5d36dff67ce6f416948bd573628b7be769bd77 (patch)
treed8e540df0499ead7b3b3e4f84ce4dd0594996c34
feat: putting together my class notes, information cutoff 0916
-rw-r--r--main.pdfbin0 -> 103006 bytes
-rw-r--r--main.tex264
2 files changed, 264 insertions, 0 deletions
diff --git a/main.pdf b/main.pdf
new file mode 100644
index 0000000..9c39cf4
--- /dev/null
+++ b/main.pdf
Binary files differ
diff --git a/main.tex b/main.tex
new file mode 100644
index 0000000..199d2fa
--- /dev/null
+++ b/main.tex
@@ -0,0 +1,264 @@
+\documentclass[a4paper]{article}
+
+% Imports
+\usepackage{amssymb}
+\usepackage{amsmath}
+\usepackage{multicol}
+\usepackage{ragged2e}
+\usepackage{blindtext}
+\usepackage[english]{babel} %this is the dictionary you will use
+\usepackage{graphicx,mathdots,chemarr,fancyvrb,comment} %some more packages
+\usepackage{tikz} %some more packages
+%the packages from here on will help with creating a graph
+%tikzpicture
+\graphicspath{ {/home/butterdog/Documents/texassets/} }
+\usepackage[many]{tcolorbox}
+\usepackage{wrapfig}
+\usepackage{scalerel}
+\usepackage{pict2e}
+\usepackage{tkz-euclide}
+\usepackage{scalerel}
+\usepackage{pict2e}
+\usepackage{tkz-euclide}
+\usepackage{listings}
+\usepackage{color}
+\usepackage{xifthen}
+\usepackage{hyperref}
+\usepackage{xstring} % for \IfStrEqCase
+\usepackage{etoolbox}
+\tcbuselibrary{listings,skins,breakable}
+
+\newcounter{lemmacount}
+\newcounter{proofcount}
+\definecolor{dkgreen}{rgb}{0,0.6,0}
+%\definecolor{gray}{rgb}{0.5,0.5,0.5}
+\definecolor{red}{HTML}{ffb3b3}
+\definecolor{redbar}{HTML}{ff0000}
+\definecolor{mauve}{rgb}{0.58,0,0.82}
+\definecolor{cyanbar}{HTML}{00bfff}
+\definecolor{cyan}{HTML}{b3f0ff}
+\definecolor{greenbar}{HTML}{00ff00}
+\definecolor{green}{HTML}{8cd98c}
+\definecolor{black}{HTML}{000000}
+\definecolor{main}{HTML}{5989cf} % setting main color to be used
+\definecolor{sub}{HTML}{cde4ff} % setting sub color to be used
+\tcbset{
+ sharp corners,
+ colback = white,
+ before skip = 0.2cm, % add extra space before the box
+ after skip = 0.5cm % add extra space after the box
+} % setting global options for tcolorbox
+% ---- colors ----
+\definecolor{codebg}{rgb}{0.98,0.98,0.98}
+\definecolor{codeframe}{rgb}{0.15,0.15,0.15}
+\definecolor{dkgreen}{rgb}{0,0.5,0}
+\definecolor{mauve}{rgb}{0.58,0,0.82}
+\definecolor{codeblue}{rgb}{0,0,0.8}
+% ---- a "no highlighting" pseudo-language, so lstlisting won't choke ----
+\lstdefinelanguage{Pseudocode}{
+ morekeywords={},
+ sensitive=false,
+ morecomment=[l]{//},
+ morestring=[b]",
+}
+
+% ---- terminal-ish monospace font (swap for your favorite) ----
+\newcommand{\codefont}{\ttfamily\small}
+
+\newtcblisting{codebox}[3]{
+ enhanced,
+ breakable,
+ listing only,
+ listing engine=listings,
+ colback=codebg,
+ colframe=codeframe,
+ colbacktitle=codeframe,
+ coltitle=white,
+ fonttitle=\bfseries,
+ boxrule=0.6pt,
+ arc=2pt,
+ top=5pt, bottom=5pt, left=20pt,
+ title={#2\ifstrequal{#3}{}{}{\; {\normalfont\itshape\footnotesize -- #3}}},
+ listing options={
+ basicstyle=\codefont,
+ showstringspaces=false,
+ columns=flexible,
+ breaklines=true,
+ breakatwhitespace=true,
+ tabsize=4,
+ numbers=left,
+ language=#1,
+ keywordstyle=\ifstrequal{#1}{Pseudocode}{}{\color{codeblue}\bfseries},
+ commentstyle=\ifstrequal{#1}{Pseudocode}{\color{gray}}{\color{dkgreen}\itshape},
+ stringstyle=\ifstrequal{#1}{Pseudocode}{}{\color{mauve}},
+ },
+}
+
+\makeatletter
+
+%My Custom Commands
+\newcommand{\mnewline}{\newline\newline\newline}
+\newcommand{\mline}{\rule{0.5cm}{0.5pt}}
+\newcommand{\proj}[1]{\text{Proj}_{#1}}
+\newcommand{\st}{\ni:}
+\newcommand{\evaline}[2]{\Big|^{#1}_{#2}}
+\newcommand{\nulli}[1]{\text{Null }{#1}}
+\newcommand{\ran}[1]{\text{ran }{#1}}
+\newcommand{\col}[1]{\text{Col }({#1})}
+\newcommand{\re}[1]{\text{Re}({#1})}
+\newcommand{\im}[1]{\text{Im}({#1})}
+\newcommand{\spa}[1]{\text{span}\{{#1}\}}
+%\newcommand{\neproof}[3]{$\text{Let } \epsilon > {#2} \text{ be given}$\\\text{Choose $N = {#1}$\text{ Suppose $n > N > {#3}$}}}
+\newcommand{\neproof}[3]{ %The first one is without the 3rd argument and the second one is
+ \ifthenelse{\isempty{#3}}{$\text{Let } \epsilon > {#2} \text{ be given}$\\\text{Choose $N = {#1}$\text{ Suppose $n > N$}}}
+ {$\text{Let } \epsilon > {#2} \text{ be given}$\\\text{Choose $N = {#1}$\text{ Suppose $n > N > {#3}$}}}
+}
+\newcommand{\infobox}[2]{\begin{InfoBox}
+ \smash{\raisebox{-5pt}{\includegraphics[width=0.77cm,height=0.68cm]{information}}}{\bf #1}\newline\newline
+ {#2}
+\end{InfoBox}}
+\newcommand{\warningbox}[2]{\begin{WarningBox}
+ \smash{\raisebox{-6pt}{\includegraphics[width=0.70cm,height=0.70cm]{warning}}}
+ {\bf #1}\newline\newline
+ {#2}
+\end{WarningBox}}
+\newcommand{\theorybox}[2]{\begin{TheoryBox}
+ \smash{\raisebox{-6pt}{\includegraphics[width=0.70cm,height=0.70cm]{theorem}}}
+ {\bf #1}\newline\newline
+ {#2}
+\end{TheoryBox}}
+\newcommand{\notebox}[2]{\begin{NoteBox}
+ \smash{\raisebox{-6pt}{\includegraphics[width=0.55cm,height=0.70cm]{reminder}}}
+ {\bf #1}\newline\newline
+ {#2}
+\end{NoteBox}}
+\newcommand{\proofbox}[3]{%
+ \IfStrEqCase{#1}{%
+ {lemma}{\stepcounter{lemmacount}\def\proofboxlabel{Lemma \thelemmacount}}%
+ {proof}{\stepcounter{proofcount}\def\proofboxlabel{Proof \theproofcount}}%
+ }[\PackageError{proofbox}{Unknown proofbox type '#1'}{Use 'lemma' or 'proof'}]%
+ \begin{ProofBox}
+ \IfStrEq{#2}{}%
+ {{\bf \proofboxlabel:}}%
+ {{\bf \proofboxlabel\ (#2):}}%
+ \newline\newline
+ {#3}
+ \end{ProofBox}
+}
+\renewcommand*\env@matrix[1][*\c@MaxMatrixCols c]{%
+ \hskip -\arraycolsep
+ \let\@ifnextchar\new@ifnextchar
+ \array{#1}}
+\newtcolorbox{InfoBox}{
+ colback = sub,
+ colframe = main,
+ boxrule = 0pt,
+ leftrule = 6pt % left rule weight
+}
+\newtcolorbox{WarningBox}{
+ colback = red,
+ colframe = redbar,
+ boxrule = 0pt,
+ leftrule = 6pt % left rule weight
+}
+\newtcolorbox{TheoryBox}{
+ colback = cyan,
+ colframe = cyanbar,
+ boxrule = 0pt,
+ leftrule = 6pt % left rule weight
+}
+\newtcolorbox{NoteBox}{
+ colback = green,
+ colframe = greenbar,
+ boxrule = 0pt,
+ leftrule = 6pt % left rule weight
+}
+\newtcolorbox{TitleBox}{
+ boxrule = 2pt,
+ rounded corners
+}
+\newtcolorbox{ProofBox}{
+ boxrule = 1.3pt,
+}
+\makeatother
+\usepackage[letterpaper,left=6mm,includemp=true,marginparwidth=12mm,marginparsep=1mm,reversemarginpar,right=19mm,
+includefoot=true,top=19mm,nohead,footskip=12mm,bottom=6mm]{geometry}
+% Here are the custom commands I have created. They are increadibly retarded
+% mnewline: creates 3 newlines
+% mline: Creates a horizontal line
+% proj: Creates a Proj with a suitable subscript - Takes an argument
+% st: creates a ni and a : as the 'such that'
+% evaline: creates a vertical line for evaluated definite integrals. First argument is upper limit, second is lower. - Takes two arguments
+% nulli: creates a Null (with a whitespace) - Takes an argument
+% col: creates a Col (with a whitespace) - Takes an argument
+% ran: creates a ran (with a whitespace) - Takes an argument
+% re: creates a Re() - Takes an argument
+% im: creates a Im() - Takes an argument
+% sp: creates a span{} - Takes an argument
+% neproof: Creates a cookie cutter N-epsilon proof. First argument set's N's value and second argument sets epsilon greater than value and the third (optional) argument sets the n > N > value. IF YOU DO NOT WANT THE THIRD ARGUMENT YOU NEED AN EMPTY CURLY BRACKET
+\begin{document}
+ \setlength{\parindent}{1cm}
+ \begin{center}
+ {\bf \Large CSCC85}
+ \end{center}
+ \begin{TitleBox}
+ \begin{center}
+ \section{Main Notes}
+ \end{center}
+ \end{TitleBox}
+ \tableofcontents
+ \pagebreak
+ \section{Fault Tolerant Systems}
+ \subsection{Introduction}
+ So, what does it mean for a system to be fault tolerant, what does it mean for a system to be reliable? How do we know if a system is reliable? How can we make it more reliable? These concepts will be explored in this chapter.
+ \theorybox{Definition --- Fault Tolerance}{A system is fault tolerant if\\
+ \begin{center}
+ {\bf the system continues to operate CORRECTLY and SAFELY in the presence of faults}
+ \end{center}
+ }
+ Simple enough, but what is a fault?\\
+ \theorybox{Definition --- Fault}{A fault is an unexpected irregularity within the input or output of the system.}
+ We should note that it is impossible to make something completely fault proof, there are too many environmental factors to make this possible. With these basic definitions under our belt, we will explore some systems that proved not fault tolerant, and some that proved to be and why.\\
+ But first, lets list some particular industries where fault tolerance is not a nice-to-have, it is a necessity. Then we will look at specific examples.
+ \subsection{Examples}
+ \begin{enumerate}
+ \item Transportation\\
+ Can be broken down further into specific industries like cars, boats, trains, planes, etc\\
+ {\bf The flops}\\
+ Big flop is Boeing. The issue was that they had made a new derivative of the 737, the 737 MAX. Boeing had made several changes to the 737 MAX, and one of these changes was a system to warn the pilots if the plane was stalling using an angle of attack sensor. The 737 MAX had two, however the software system only used one, and never checked the measured values against other sensors that could be used to complement the reading for accuracy. Furthermore, because pilots were never told about this new feature, they were not ready to handle it. In short, the fleet was grounded because the new system had a {\bf single point of failure}. And when this went, everything else did too.
+ \item Banking
+ \item Medical Devices
+ \item Space
+ \item Energy
+ \item Communications
+ \end{enumerate}
+ \theorybox{Definition --- Reliability}{Reliability has a specific definition for us. While we know what it MEANS to be reliable or not reliable, reliability is:
+ \begin{center}
+ {\bf the probability that a system will continue operation correctly during a period of time}
+ \end{center}
+ }
+ \theorybox{Definition --- Availability}{Availability is defined as:
+ \begin{center}
+ {\bf the probability that at a given moment, the system is working correctly and is available.}
+ \end{center}
+ }
+ \warningbox{When we say correctly, we mean it!}{Note that this is for continuous reliability, if you say that system has $0.99$ percent reliability during a $5$ hour interval, there cannot be these consistent spikes in instability after the first hour, that means the system is not $0.99$ percent reliable during this time period.}
+ As with most things, engineers and scientists cannot resist modelling stuff with equations. Reliability is no exception. We generally say that reliability is modelled as:
+ \begin{equation}
+ R(t) = e^{-\lambda t}
+ \end{equation}
+ where $t$ is defined as the time, and the output is the reliability of the system at $t$. So if we wanted our $.99$ reliability at $5$ hours, we would need for
+ \subsection{How to make a system more fault tolerant}
+ The main point of this section can be summed up as {\bf \large Redundancy}. Redundancy is the best way to achieve a more fault tolerant system. While having things such as high quality batteries, ECC memory, or well designed and implemented software, redundancy is what will let you make the most out of such equipment.
+ \subsubsection{Hardware}
+ \subsubsection{Software}
+ Software is an interesting case, since as long as the hardware doesn't give way, software will do exactly what you tell it to do, that and only that. So much thought must go into how you make the software and verify it.\\
+ However, when you are running software, redundancy is still important. The way that redundancy in software is achieved is by running multiple copies of the software. The way that this can achieve redundancy is that if there is some mission critical variable (such as angle of attack!), after each program has calculated its value for such variable, they can vote (especially if it is discrete), or take a mean, median, mode, whatever. If they take all the values and average them out, hopefully they will smooth out any error and come to as close of an accurate value as possible.
+ \begin{center}
+ {\bf \large Multiple Implementations}
+ \end{center}
+ Given some set of requirements designed by engineers, you could have multiple teams implement the same set of requirements. By having this, your goal is to minimize the amount of faults that can occur through bugs in implementation.
+ \theorybox{Definition --- $N$ Version Programming}{When you have $N$ teams implement the same set of requirements.}
+ \section{Sensors}
+\end{document}
+