Anki Deck Changes

Commit: 27476445 - happy new year!

Author: lhorva <lhorva@student.ethz.ch>

Date: 2026-01-01T03:11:08+01:00

Changes: 8 note(s) changed (0 added, 8 modified, 0 deleted)

ℹ️ Cosmetic Changes Hidden: 2 note(s) had formatting-only changes and are not shown below • 1 HTML formatting changes

Note 1: ETH::A&D

Deck: ETH::A&D
Note Type: Horvath Classic
GUID: c9U$4,GAT:
modified

Before

Front

ETH::1._Semester::A&D::01._Introduction::1._Introduction
What is telescoping?

Back

ETH::1._Semester::A&D::01._Introduction::1._Introduction
What is telescoping?
By plugging in previous terms into a recursive definition we can get a feel for it's asymptotic runtime. This is only for intuiton, not a proof 

\(M(n + 1) = 3 \cdot M(n)\) turns into \(M(n + 1) = 3 \cdot (3 \cdot M(n - 1))\) and so on and so forth.

After

Front

ETH::1._Semester::A&D::01._Introduction::1._Introduction
What is telescoping?

Back

ETH::1._Semester::A&D::01._Introduction::1._Introduction
What is telescoping?
By plugging in previous terms into a recursive definition we can get a feel for it's asymptotic runtime. This is only for intuiton, not a proof. 

\(M(n + 1) = 3 \cdot M(n)\) turns into \(M(n + 1) = 3 \cdot (3 \cdot M(n - 1))\) and so on and so forth.
Field-by-field Comparison
Field Before After
Back By plugging in previous terms into a recursive definition we can get a feel for it's asymptotic runtime.&nbsp;<i>This is only for intuiton, not a proof</i>&nbsp;<br><br>\(M(n + 1) = 3 \cdot M(n)\)&nbsp;turns into&nbsp;\(M(n + 1) = 3 \cdot (3 \cdot M(n - 1))\)&nbsp;and so on and so forth. By plugging in previous terms into a recursive definition we can get a feel for it's asymptotic runtime.&nbsp;<i>This is only for intuiton, not a proof.</i>&nbsp;<br><br>\(M(n + 1) = 3 \cdot M(n)\)&nbsp;turns into&nbsp;\(M(n + 1) = 3 \cdot (3 \cdot M(n - 1))\)&nbsp;and so on and so forth.
Tags: ETH::1._Semester::A&D::01._Introduction::1._Introduction

Note 2: ETH::A&D

Deck: ETH::A&D
Note Type: Horvath Classic
GUID: qBT+Ifr6uX
modified

Before

Front

ETH::1._Semester::A&D::05._Data_Structures::1._ADT_List::1._Array
In what situation is the array the correct datastructure?

Back

ETH::1._Semester::A&D::05._Data_Structures::1._ADT_List::1._Array
In what situation is the array the correct datastructure?
When we have a fixed upper bound for the size of the list.

After

Front

ETH::1._Semester::A&D::05._Data_Structures::1._ADT_List::1._Array
In what situation is the array the correct underlying datastructure for a list?

Back

ETH::1._Semester::A&D::05._Data_Structures::1._ADT_List::1._Array
In what situation is the array the correct underlying datastructure for a list?
When we have a fixed upper bound for the size of the list.
Field-by-field Comparison
Field Before After
Front In what situation is the array the correct datastructure? In what situation is the array the correct underlying datastructure for a list?
Tags: ETH::1._Semester::A&D::05._Data_Structures::1._ADT_List::1._Array

Note 3: ETH::DiskMat

Deck: ETH::DiskMat
Note Type: Horvath Cloze
GUID: i
modified

Before

Front

ETH::1._Semester::DiskMat::5._Algebra::2._Monoids_and_Groups
A monoid has the following properties:

Back

ETH::1._Semester::DiskMat::5._Algebra::2._Monoids_and_Groups
A monoid has the following properties:
  • closure
  • associativity
  • identity

After

Front

ETH::1._Semester::DiskMat::5._Algebra::2._Monoids_and_Groups
A monoid has the following properties:
  1. Closure
  2. Associativity
  3. Identity

Back

ETH::1._Semester::DiskMat::5._Algebra::2._Monoids_and_Groups
A monoid has the following properties:
  1. Closure
  2. Associativity
  3. Identity
Field-by-field Comparison
Field Before After
Text A&nbsp;<b>monoid</b>&nbsp;has the following properties: A&nbsp;<b>monoid</b>&nbsp;has the following properties:<br><ol><li>{{c1::Closure}}</li><li>{{c2::Associativity}}</li><li>{{c3::Identity}}</li></ol>
Extra <ul><li>closure</li><li>associativity</li><li>identity</li></ul>
Tags: ETH::1._Semester::DiskMat::5._Algebra::2._Monoids_and_Groups

Note 4: ETH::DiskMat

Deck: ETH::DiskMat
Note Type: Horvath Classic
GUID: uCGhOduc{_
modified

Before

Front

ETH::1._Semester::DiskMat::4._Number_Theory::6._Application:_Diffie-Hellman_Key-Agreement PlsFix::DELETE
Explain the mechanical analog of the Diffie-Hellman protocol.

Back

ETH::1._Semester::DiskMat::4._Number_Theory::6._Application:_Diffie-Hellman_Key-Agreement PlsFix::DELETE
Explain the mechanical analog of the Diffie-Hellman protocol.

After

Front

ETH::1._Semester::DiskMat::4._Number_Theory::6._Application:_Diffie-Hellman_Key-Agreement PlsFix::DELETE
Explain the mechanical analog of the Diffie-Hellman protocol.

Back

ETH::1._Semester::DiskMat::4._Number_Theory::6._Application:_Diffie-Hellman_Key-Agreement PlsFix::DELETE
Explain the mechanical analog of the Diffie-Hellman protocol.
A padlock without a key.

Alice and Bob can exchange their locks (closed) and keep a copy in the open state. Then they can both generate the same configuration, namely the two locks interlocked. For the adversary, this is impossible without breaking open one of the locks.

Field-by-field Comparison
Field Before After
Back <img src="paste-39931b24c512906843c903f461b7c1cc9f5a6685.jpg"> A padlock without a key.<br><br>Alice and Bob can exchange their locks (closed) and keep a copy in the open state. Then they can both generate the same configuration, namely the two locks interlocked.&nbsp;For the adversary, this is impossible without breaking open one of the locks.<br><br><img src="paste-39931b24c512906843c903f461b7c1cc9f5a6685.jpg">
Tags: ETH::1._Semester::DiskMat::4._Number_Theory::6._Application:_Diffie-Hellman_Key-Agreement PlsFix::DELETE

Note 5: ETH::DiskMat

Deck: ETH::DiskMat
Note Type: Horvath Cloze
GUID: uK|j,XZw5[
modified

Before

Front

ETH::1._Semester::DiskMat::4._Number_Theory::6._Application:_Diffie-Hellman_Key-Agreement
For DHKE, both Alice and Bob choose \(x_A, x_B\) (their private keys) at random.
They then compute {{c2:: \(y_A := R_p(g^{x_A})\) and with \(y_B\)analogously, which are their public keys}} which is sent over the network to their partner.
The other {{c3:: then exponentiates by their private key to get the shared key \(k_{AB} \equiv_p y_B^{x_A} \equiv_p g^{x_B \cdot x_A} \equiv_p y_A^{x_B}\)}}.

Back

ETH::1._Semester::DiskMat::4._Number_Theory::6._Application:_Diffie-Hellman_Key-Agreement
For DHKE, both Alice and Bob choose \(x_A, x_B\) (their private keys) at random.
They then compute {{c2:: \(y_A := R_p(g^{x_A})\) and with \(y_B\)analogously, which are their public keys}} which is sent over the network to their partner.
The other {{c3:: then exponentiates by their private key to get the shared key \(k_{AB} \equiv_p y_B^{x_A} \equiv_p g^{x_B \cdot x_A} \equiv_p y_A^{x_B}\)}}.

After

Front

ETH::1._Semester::DiskMat::4._Number_Theory::6._Application:_Diffie-Hellman_Key-Agreement
For DHKE, both Alice and Bob choose \(x_A, x_B\) (their private keys) at random.

They then compute {{c2:: \(y_A := R_p(g^{x_A})\) and \(y_B\) analogously, which are their public keys}} which is sent over the network to their partner.

The other {{c3:: then exponentiates by their private key to get the shared key \(k_{AB} \equiv_p y_B^{x_A} \equiv_p g^{x_B \cdot x_A} \equiv_p y_A^{x_B}\)}}.

Back

ETH::1._Semester::DiskMat::4._Number_Theory::6._Application:_Diffie-Hellman_Key-Agreement
For DHKE, both Alice and Bob choose \(x_A, x_B\) (their private keys) at random.

They then compute {{c2:: \(y_A := R_p(g^{x_A})\) and \(y_B\) analogously, which are their public keys}} which is sent over the network to their partner.

The other {{c3:: then exponentiates by their private key to get the shared key \(k_{AB} \equiv_p y_B^{x_A} \equiv_p g^{x_B \cdot x_A} \equiv_p y_A^{x_B}\)}}.
Field-by-field Comparison
Field Before After
Text For DHKE, both Alice and Bob {{c1:: choose&nbsp;\(x_A, x_B\)&nbsp;(their private keys) at random}}.<br>They then compute {{c2::&nbsp;\(y_A := R_p(g^{x_A})\)&nbsp;and with&nbsp;\(y_B\)analogously, which are their public keys}} which is {{c2:: sent over the network to their partner}}.<br>The other {{c3:: then exponentiates by their private key to get the shared key&nbsp;\(k_{AB} \equiv_p y_B^{x_A} \equiv_p g^{x_B \cdot x_A} \equiv_p y_A^{x_B}\)}}. For DHKE, both Alice and Bob {{c1:: choose&nbsp;\(x_A, x_B\)&nbsp;(their private keys) at random}}.<br><br>They then compute {{c2::&nbsp;\(y_A := R_p(g^{x_A})\)&nbsp;and&nbsp;\(y_B\)&nbsp;analogously, which are their public keys}} which is {{c2:: sent over the network to their partner}}.<br><br>The other {{c3:: then exponentiates by their private key to get the shared key&nbsp;\(k_{AB} \equiv_p y_B^{x_A} \equiv_p g^{x_B \cdot x_A} \equiv_p y_A^{x_B}\)}}.
Tags: ETH::1._Semester::DiskMat::4._Number_Theory::6._Application:_Diffie-Hellman_Key-Agreement

Note 6: ETH::DiskMat

Deck: ETH::DiskMat
Note Type: Horvath Cloze
GUID: xelDz|Gp*?
modified

Before

Front

ETH::1._Semester::DiskMat::5._Algebra::2._Monoids_and_Groups::1._Neutral_Elements
A right (left) neutral element  is an elements such that for all \(a \in G\),  \(a*e = a\) (\(e*a = a\)).

Back

ETH::1._Semester::DiskMat::5._Algebra::2._Monoids_and_Groups::1._Neutral_Elements
A right (left) neutral element  is an elements such that for all \(a \in G\),  \(a*e = a\) (\(e*a = a\)).

After

Front

ETH::1._Semester::DiskMat::5._Algebra::2._Monoids_and_Groups::1._Neutral_Elements
A right (left) neutral element is an element such that for all \(a \in G\),  \(a*e = a\) (\(e*a = a\)).

Back

ETH::1._Semester::DiskMat::5._Algebra::2._Monoids_and_Groups::1._Neutral_Elements
A right (left) neutral element is an element such that for all \(a \in G\),  \(a*e = a\) (\(e*a = a\)).
Field-by-field Comparison
Field Before After
Text <div>A {{c1::right (left) neutral element}}&nbsp; is an elements such that for all&nbsp;\(a \in G\), {{c2::&nbsp;\(a*e = a\)&nbsp;(\(e*a = a\))}}.</div> <div>A {{c1::right (left) neutral element}} is an element such that for all&nbsp;\(a \in G\), {{c2::&nbsp;\(a*e = a\)&nbsp;(\(e*a = a\))}}.</div>
Tags: ETH::1._Semester::DiskMat::5._Algebra::2._Monoids_and_Groups::1._Neutral_Elements
↑ Top