Add eprog summary

This commit is contained in:
2025-09-20 14:29:05 +02:00
parent bc5a14fe08
commit ea8f61b401
4 changed files with 298 additions and 0 deletions

Binary file not shown.

View File

@@ -0,0 +1,47 @@
\documentclass{article}
\newcommand{\dir}{~/projects/latex}
\input{\dir/include.tex}
\load{recommended}
\setup{Introduction to Programming}
\begin{document}
\startDocument
\usetcolorboxes
\printtoc{Aquamarine}
\include{./parts/ebnf}
\include{./parts/java}
\section{Loop-Invariant}
\begin{enumerate}
\item Write down a table with the loop iteration number and what the state of each variable in the loop is
\item Check what causes the loop to end (in \texttt{while}, it's the inverse of the condtion, in \texttt{for}, it is the same concept)
\item Then, use that break condition (inverted) and establish an upper (or lower) bound for the variable involved. (e.g. \texttt{i < arr.length} in the loop condition turns into \texttt{i < 0 arr.length} in the loop invariant)
\item Specify all condtions for all the variables known through the pre and post-conditions, as far as applicable
\end{enumerate}
Also, all other variables that are being changed need to be addressed in the invariant, ensuring that the statements resolve to boolean when executed (\texttt{==} and not \texttt{=} for comparison (because valid Java Syntax required).
For the pre- and postconditions, ensure to also address ALL variables in the loop, even if it seems unnecessary.
\section{Mean things}
\subsection{In EBNF}
\begin{itemize}
\item Unbalanced brackets
\end{itemize}
\subsection{Java}
\begin{itemize}
\item Non-private attributes that could be changed prior to execution
\item Spaces in variable names
\item Using reserved names as variable names
\item Unbalanced brackets
\end{itemize}
\end{document}

View File

@@ -0,0 +1,141 @@
\section{EBNF}\label{ebnf}
= Extended Backus Naur Form / Extended Backus Normal Form
\begin{itemize}
\item Can be used to describe automatic tests
\end{itemize}
\subsection{Rules}
\begin{definition}[]{EBNF-Rule}
A rule is described as follows
\begin{verbatim}
LHS <- RHS
\end{verbatim}
where LHS is the left hand side, which gives the name of the rule. That name is usually written in italic or inside \texttt{\textless{}...\textgreater{}}. The RHS is the description of the rule using elements, which are literals, names of other EBNF rules defined previously or after or a combination of the four control forms
\end{definition}
A character as EBNF rule would be something like
\begin{verbatim}
<digit_zero> <- 0
\end{verbatim}
Another EBNF rule as RHS would be something like:
\begin{verbatim}
<number_zero> <- <digit_zero>
\end{verbatim}
We have to also define an entry rule, which, if nothing else is specified, is the last rule. It marks the entry point from where the checks are run.
\subsection{Control forms}
\subsubsection{Sequence}
\begin{definition}[]{Sequence}
Concatenation of the elements. Noted with a space between the elements.
\begin{verbatim}
<rule> <- E1 E2 E3
\end{verbatim}
\end{definition}
\subsubsection{Decision}
This control form has two options, namely selection and option.
\begin{definition}[]{Selection}
We can choose \textit{exactly} one of the elements listed with pipe characters (called stroke).
\begin{verbatim}
<rule> <- E1 | E2 | E3
\end{verbatim}
\end{definition}
\begin{definition}[]{Option}
We can either choose to use the element or not. Noted with square brackets. $\epsilon$ is the empty element, which is returned if the option is not chosen.
\begin{verbatim}
<rule> <- [E]
\end{verbatim}
\end{definition}
\subsubsection{Repetition}
\begin{definition}[]{Repetition}
Repeat an element $n \in \N_0$ times, so repeating it $0$ times is also valid. Noted using curly brackets.
\begin{verbatim}
<rule> <- {E}
\end{verbatim}
\end{definition}
\subsubsection{Recursion}
\begin{definition}[]{Recursion}
Recursively repeat an element, by adding it to the RHS of itself
\begin{verbatim}
<rule> <- <digit> <rule>
\end{verbatim}
\end{definition}
We can have direct or indirect recursion, where indirect recursion is when the recursion is not directly on the rule itself, but through elements of the RHS of the rule.
\subsection{Parenthesis}
There are precedences, but for where they have not been covered, parenthesis are used to clarify what is meant. Always put them there, if it is not 100\% clear what is meant.
\fhlc{Aquamarine}{Covered precedences:}
Sequence binds weaker than everything else.
\subsection{Special caracters}
We use boxes around them if we want to use them as literals, not as EBNF characters, i.e. if we want to write \texttt{\{\}}, then we write \fbox{\{\}}, same goes for space, which we can also write using the space symbol, \begin{Large}\textvisiblespace\end{Large}
\newpage
\subsection{Nomenclature \& Notation}
\begin{terms}[]{EBNF}
\begin{itemize}
\item \textbf{\textit{Legal}}: A word is considered legal if there is a derivation of the character sequence
\item \textbf{\textit{Derivation}}: Sequence of derivation steps
\item \textbf{\textit{Derivation step}}:
\begin{itemize}
\item Replace rules with their definition (RHS)
\item \textit{Selection}: Select element in a selection
\item \textit{Option}: Choose whether to select an optional element
\item \textit{Repetition}: Decide on the number of repetitions of the element
\end{itemize}
\end{itemize}
\end{terms}
\subsubsection{Notation of derivation}
\begin{notation}[]{Derivation}
\begin{itemize}
\item Derivation table
\begin{itemize}
\item First row is the entry rule
\item Last row is a sequence of characters
\item Transition between rows is a derivation step
\end{itemize}
\item Derivation tree
\begin{itemize}
\item Root is the name of the entry rule
\item Leafs are characters
\item Connections are the derivation steps
\end{itemize}
\end{itemize}
\end{notation}
\subsubsection{Syntax vs. Semantics}
Syntax = Structure / Form (Grammar), Semantics = Meaning / Interpretation
\subsection{Graphical noatation of EBNF}
With syntax graph. We can replace names in the syntax graph with another graph.
\fhlc{ForestGreen}{Sequence}: \texttt{A B C} $\Longrightarrow$ $\rightarrow$ A - B - C $\rightarrow$
\fhlc{ForestGreen}{Selection}: \texttt{A | B | C} $\Longrightarrow$ $\rightarrow$ Parallel circuit-like notation $\rightarrow$
\fhlc{ForestGreen}{Option}: \texttt{[A]} $\Longrightarrow$ $\rightarrow$ Parallel circuit-like notation, two options, top is the element, bottom is empty $\rightarrow$
\fhlc{ForestGreen}{Repetition}: \texttt{\{A\}} $\Longrightarrow$ $\rightarrow$ Similar to option, but there is a loop back at the top element (allowing repetition) $\rightarrow$

View File

@@ -0,0 +1,110 @@
\newsection
\section{Peculiarities of Java}
\begin{itemize}
\item Automatic casting in additions works for all data types (including primitives)
\item Automatic casting in comparisons only works for \texttt{int} (as well as \texttt{short} and \texttt{long}, but with \texttt{long} we lose precision on conversion) to \texttt{double}
\item \texttt{Array.toString()} outputs the memory address.
\item \texttt{Class.toString()} is automatically called when outputing to stdout or casting to \texttt{string}.
\item \texttt{Arrays.toString()} outputs the array's elements with \texttt{.toString()} (if non-primitive), use \texttt{Arrays.deepToString()} to fix
\item \texttt{File} API is as ugly as a Zombie. Works as follows: \texttt{Scanner sc = new Scanner(new File('/path/to/file'));} then using normal Scanner api is possible (e.g. \texttt{sc.nextLine()})
\item Accessing \texttt{super}'s private fields is compiler error
\item Using an implicit constructor of \texttt{super} which has a different implementation causes a runtime, not compile time error.
\item Abstract class without methods is valid.
\item Compile time error if two classes do not share a \texttt{super} class when using \texttt{instanceof} (because that would evaluate to false at all times)
\item \texttt{super.x} fine, \texttt{super.super.x} not (compiler error)
\item \texttt{StackOverflow} error can be caught by try-catch
\item Method overloading instead of optional parameters
\item Incrementation of variable binds stronger than addition. If we have $x = 2$ and calculate \texttt{++x + x++}, we get $6$, $x = 4$, thus, we have $3 + 3$, as $x$ is first incremented, then added (pre-increment). $++x$ first increments, then the incremented value returned. $x++$ is first returned, then incremented.
\item Do-While Loops\dots I mean wtf
\item We can change the visibility of a method of a class from not set to \textit{public}
\item We can cast a class to a super class if we then only call the methods also defined in said super class. If the method is overridden, the overridden method (the one from the sub-class) is called.
\item We can't cast to a subclass (which makes sense), but it's Runtime, not Compile time error (because Java's compiler does type erasing and hence can't check that. Pure idiocy)
\item The compiler considers the reference type for an object reference when determining if \texttt{instanceof} is possible or not
\item Casting a class to a different class of a different branch causes an Exception, not a compile time error
\item Casting to an interface or class if there is a connection through a subclass (or subsubclass, \dots), runtime rather than compile time error.
\end{itemize}
The Reference type is the type that the reference has (also called \textit{static type}). Casting a pointer to a different type only changes the reference type, thus all the behvaiour making much more sense:
\begin{itemize}
\item Calling methods that are not defined on the reference type $\rightarrow$ Compile time error
\end{itemize}
\section{Actually resonable stuff in Java}
\begin{itemize}
\item for, while, try-catch, typing
\item Generics (apart from type erasure)
\item Automatic type casting exists (even though sorta weird)
\item Comparisons between incompatible types is compiler error
\item Chaining comparison operators not allowed (but boolean, i.e. \texttt{\&\&} and \texttt{||} is allowed)
\item Objects are passed by reference, primitives are copied
\item Can't call \texttt{var.super.method()} (same with \texttt{this} for that matter)
\end{itemize}
\newsection
\section{Tips \& Tricks}
\begin{itemize}
\item \textbf{Last four digits of int}: \texttt{number \% 10000}
\item \textbf{Decide if number is even}: \texttt{number \%} $2 = \begin{cases}
0 & \text{if number is even}\\
1 & \text{else}
\end{cases}$
\item \textbf{Parenthesis}: Always use explicitly
\item \textbf{Casting}: \texttt{(double) 19 / 5} $= 3.8$ instead of $3$ ($19$ is cast to double, then auto-casting to double of 5 $\rightarrow$ division of doubles)
\item \textbf{Scanner}: \texttt{Scanner scanner = new Scanner(System.in);}, then e.g. \texttt{int age = scanner.nextInt();}. It is safest to read input as string and then manually cast / convert to required types, as we can handle additional PEBCAK (Problem Exist Between Chair And Keyboard). This is done using \texttt{scanner.nextLine()}.
\item \textbf{Random}: \texttt{Random.nextInt(n)} returns a random number in $[1, n]$
\item \textbf{De Morgan's Rules}: Use them for inverting the expression (but also kinda unnecessary)
\item \textbf{Off-by-one errors}: Try to run through with small iteration counts and check edge cases
\item \textbf{CompareTo method}: \texttt{o1.compareTo(o2) < 0 // o1 < o2}
\end{itemize}
\newsection
\section{Abstract class vs Interface}
\begin{table}[h!]
\centering
\begin{tabular}{lcc}
\toprule
\textbf{Points} & \textbf{Abstract class} & \textbf{Interface}\\
\midrule
Abstract methods & \checkmark & \checkmark\\
Concrete methods & \checkmark & X\\
Static methods & \checkmark & \checkmark\\
Inheritance count & 1 only & multiple\\
Access modifiers & Any & None\\
Variables & Member allowed & All \texttt{public static final}\\
Instantiation possible & X & X\\
\bottomrule
\end{tabular}
\caption{Comparison of abstract classes and interfaces}
\end{table}
Abstract classes are used when there is a default implementation of a method that is expected not to be overridden and a different class should only inherit this class and not combine, in any other case Interface, since it's more flexible.
\newsection
\section{Maps, Lists \& Sets}
\subsection{Maps}
Similar to plain objects in TS, \texttt{Map<KeyType, ValueType> map = new HashMap<KeyType, ValueType>();}.
\subsection{Lists}
Work similarly to \textsc{Arrays}, but are dynamic size (like Vectors in Rust). Usually, we use \textsc{ArrayList}, but \textsc{Stack} and \textsc{Queue} also implement this interface.
\texttt{List<Type> list = new ArrayList<Type>();}
\subsection{Sets}
\textsc{Set}s are like mathematical sets, in that they only allow an element to be in it once. See the different implementations below for details on how they can be implemented.
\texttt{Set<Type> set = new HashSet<Type>();}
\subsection{Different implementations}
\textsc{Maps} \& \textsc{Sets} share similar implementations for the interfaces.
A \textsc{TreeSet} / \textsc{TreeMap} is based on a binary tree and a class \texttt{E} has to implement \texttt{Comparable<E>} (i.e. the \texttt{compare} method). \timecomplexity \tco{\log(n)}
A \textsc{HashSet} / \textsc{HashMap} uses a hash table (a table that stores a reference to an object of which a hash was computed). The order of elements is not guaranteed and not predictable from system to system \timecomplexity \tco{1}.
A \textsc{LinkedHashSet} / \textsc{LinkedHashMap} work similarly to \textsc{HashSet} / \textsc{HashMap}, but the order is maintained (i.e. output in the order the elements were added). \timecomplexity \tco{1}