mirror of
https://github.com/janishutz/eth-summaries.git
synced 2026-03-14 04:40:07 +01:00
[EProg] Improve summary
This commit is contained in:
Binary file not shown.
@@ -24,12 +24,20 @@
|
||||
\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).
|
||||
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}
|
||||
EProg is sadly known for testing your knowledge of the edge cases. Here are some common pitfalls at the exams.
|
||||
|
||||
The best way to prepare for the programming exam is to solve the programming exercises during the semester and solve a few of the old programming exams that are available.
|
||||
|
||||
To prepare for the theory, solve as many of the old exams as you can, as they can be completed, including correction, in under one hour.
|
||||
|
||||
|
||||
\subsection{In EBNF}
|
||||
\begin{itemize}
|
||||
\item Unbalanced brackets
|
||||
|
||||
@@ -97,13 +97,13 @@ We use boxes around them if we want to use them as literals, not as EBNF charact
|
||||
\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}
|
||||
\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}
|
||||
|
||||
@@ -112,17 +112,17 @@ We use boxes around them if we want to use them as literals, not as EBNF charact
|
||||
\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}
|
||||
\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}
|
||||
\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}
|
||||
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
\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 \texttt{File} API is a bit weird.
|
||||
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.
|
||||
@@ -15,27 +15,31 @@
|
||||
\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 (though they can come in handy if you want the loop body to always execute at least once)
|
||||
\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 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 We can change the visibility of a method of a class from unset 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:
|
||||
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}
|
||||
|
||||
\section{Actually resonable stuff in Java}
|
||||
\begin{itemize}
|
||||
\item for, while, try-catch, typing
|
||||
\item \texttt{for}, \texttt{while}, \texttt{do \dots while} (if you are unaware, it executes the body of the loop \textit{at least} once), \texttt{try-catch}, typing
|
||||
\item Generics (apart from type erasure)
|
||||
\item Automatic type casting exists (even though sorta weird)
|
||||
\item Automatic type casting exists (even though they can be a bit weird initially)
|
||||
\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
|
||||
@@ -48,12 +52,14 @@ The Reference type is the type that the reference has (also called \textit{stati
|
||||
\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}$
|
||||
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{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
|
||||
@@ -66,31 +72,31 @@ The Reference type is the type that the reference has (also called \textit{stati
|
||||
\centering
|
||||
\begin{tabular}{lcc}
|
||||
\toprule
|
||||
\textbf{Points} & \textbf{Abstract class} & \textbf{Interface}\\
|
||||
\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\\
|
||||
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.
|
||||
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>();}.
|
||||
Similar to plain objects in \texttt{TypeScript}, or dictionaries in \texttt{Python}, \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.
|
||||
Work similarly to \textsc{Arrays}, but are dynamic size (like Vectors in Rust, Lists in Python and Arrays in JavaScript / TypeScript).
|
||||
Usually, we use \textsc{ArrayList}, but \textsc{Stack} and \textsc{Queue} also implement this interface.
|
||||
\texttt{List<Type> list = new ArrayList<Type>();}
|
||||
|
||||
\subsection{Sets}
|
||||
@@ -99,12 +105,13 @@ Work similarly to \textsc{Arrays}, but are dynamic size (like Vectors in Rust).
|
||||
|
||||
|
||||
\subsection{Different implementations}
|
||||
\textsc{Maps} \& \textsc{Sets} share similar implementations for the interfaces.
|
||||
\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}$
|
||||
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}$
|
||||
|
||||
Reference in New Issue
Block a user