Import Quarto posts and expand blog sync bridge
Some checks failed
Build / build (push) Has been cancelled
Some checks failed
Build / build (push) Has been cancelled
This commit is contained in:
Neeldhara Misra
parent
4ddaba7c7d
commit
e7227844c7
406 changed files with 7943 additions and 7637 deletions
|
|
@ -16,8 +16,47 @@ const BlogPosts = ({
|
|||
// Get the first post as the featured post
|
||||
const featuredPost = posts[0];
|
||||
const remainingPosts = posts.slice(1);
|
||||
const slugFor = (post: any) => post.id.replace(/\/index$/, "");
|
||||
const hrefFor = (post: any) =>
|
||||
collection ? `/${collection}/${post.id}/` : `/${post.id}/`;
|
||||
collection ? `/${collection}/${slugFor(post)}/` : `/${slugFor(post)}/`;
|
||||
|
||||
const PostVisual = ({
|
||||
post,
|
||||
featured = false,
|
||||
}: {
|
||||
post: any;
|
||||
featured?: boolean;
|
||||
}) => {
|
||||
if (post.data.image) {
|
||||
return (
|
||||
<img
|
||||
src={post.data.image}
|
||||
alt={post.data.title}
|
||||
className="aspect-video w-full rounded-lg object-cover transition-transform group-hover:scale-[1.02]"
|
||||
/>
|
||||
);
|
||||
}
|
||||
|
||||
return (
|
||||
<div className="bg-accent/70 text-accent-foreground flex aspect-video w-full items-center justify-center rounded-lg border px-6 text-center">
|
||||
<span
|
||||
className={
|
||||
featured ? "font-fraunces text-2xl" : "font-fraunces text-lg"
|
||||
}
|
||||
>
|
||||
{post.data.title}
|
||||
</span>
|
||||
</div>
|
||||
);
|
||||
};
|
||||
|
||||
if (!featuredPost) {
|
||||
return (
|
||||
<div className="text-muted-foreground container max-w-3xl py-16">
|
||||
No posts yet.
|
||||
</div>
|
||||
);
|
||||
}
|
||||
|
||||
return (
|
||||
<div className="relative py-10 md:py-16 lg:py-20">
|
||||
|
|
@ -35,11 +74,7 @@ const BlogPosts = ({
|
|||
<div className="flex flex-col gap-6 lg:flex-row">
|
||||
<div className="lg:w-1/2">
|
||||
<div className="p-2 lg:p-4">
|
||||
<img
|
||||
src={featuredPost.data.image}
|
||||
alt={featuredPost.data.title}
|
||||
className="aspect-video w-full rounded-lg object-cover transition-transform group-hover:scale-[1.02]"
|
||||
/>
|
||||
<PostVisual post={featuredPost} featured />
|
||||
</div>
|
||||
</div>
|
||||
<div className="flex flex-col justify-center p-4 pb-8 lg:w-1/2 lg:pr-8">
|
||||
|
|
@ -89,11 +124,7 @@ const BlogPosts = ({
|
|||
href={hrefFor(post)}
|
||||
>
|
||||
<div className="p-2">
|
||||
<img
|
||||
src={post.data.image}
|
||||
alt={post.data.title}
|
||||
className="aspect-video w-full rounded-lg object-cover transition-transform group-hover:scale-[1.01]"
|
||||
/>
|
||||
<PostVisual post={post} />
|
||||
</div>
|
||||
<div className="px-4 pb-5 pt-2">
|
||||
<h2 className="mb-2 text-xl font-semibold group-hover:underline">
|
||||
|
|
|
|||
|
|
@ -1,40 +0,0 @@
|
|||
---
|
||||
title: "Algorithmic Sketches: Visualizing Data Structures"
|
||||
description: "Hand-drawn illustrations of algorithms and data structures - making the abstract tangible."
|
||||
pubDate: "Jan 25 2024"
|
||||
image: "https://images.unsplash.com/photo-1581337204873-ef36aa186caa?w=400&auto=format&fit=crop&q=60"
|
||||
authorImage: "/avatar/avatar1.png"
|
||||
authorName: "Neeldhara"
|
||||
---
|
||||
|
||||
# Algorithmic Sketches: Visualizing Data Structures
|
||||
|
||||
Sometimes the best way to understand an algorithm is to draw it.
|
||||
|
||||
## Today's Sketch: Red-Black Trees
|
||||
|
||||
|
||||
|
||||
The rotation operation finally clicked when I drew it step-by-step. Each node's journey through the rotation becomes a story.
|
||||
|
||||
## The Process
|
||||
|
||||
1. Start with pencil - mistakes are part of learning
|
||||
2. Trace the algorithm's execution
|
||||
3. Add color to highlight invariants
|
||||
4. Annotate with key insights
|
||||
|
||||
## Why Drawing Helps
|
||||
|
||||
- Forces you to slow down and really see the structure
|
||||
- Reveals patterns that code obscures
|
||||
- Creates memorable mental models
|
||||
- Makes teaching more engaging
|
||||
|
||||
## This Week's Challenge
|
||||
|
||||
Draw your own version of quicksort partitioning. Share it and let's learn from each other's visualizations.
|
||||
|
||||
## The Art in Computer Science
|
||||
|
||||
Algorithms are beautiful. Drawing them reminds us that computer science is as much art as it is science.
|
||||
|
|
@ -1,41 +0,0 @@
|
|||
---
|
||||
title: "Generative Art with p5.js: Creating Beauty from Mathematics"
|
||||
description: "Exploring the intersection of code and creativity through generative art experiments."
|
||||
pubDate: "Feb 18 2024"
|
||||
image: "https://images.unsplash.com/photo-1561070791-2526d30994b5?w=400&auto=format&fit=crop&q=60"
|
||||
authorImage: "/avatar/avatar1.png"
|
||||
authorName: "Neeldhara"
|
||||
---
|
||||
|
||||
# Generative Art with p5.js: Creating Beauty from Mathematics
|
||||
|
||||
Code becomes canvas when mathematics meets creativity.
|
||||
|
||||
## Today's Creation: Perlin Noise Flows
|
||||
|
||||
```javascript
|
||||
for (let particle of particles) {
|
||||
let angle = noise(particle.x * 0.01, particle.y * 0.01, frameCount * 0.001) * TWO_PI;
|
||||
particle.velocity = p5.Vector.fromAngle(angle);
|
||||
particle.update();
|
||||
particle.draw();
|
||||
}
|
||||
```
|
||||
|
||||
## The Magic of Randomness
|
||||
|
||||
Controlled randomness creates organic patterns. Perlin noise gives us randomness with continuity - nature's own algorithm.
|
||||
|
||||
## Parameters as Paintbrushes
|
||||
|
||||
- Noise scale: Changes pattern density
|
||||
- Particle count: Affects texture
|
||||
- Color mapping: Sets the mood
|
||||
|
||||
## The Joy of Accidents
|
||||
|
||||
The best discoveries come from "mistakes" - a typo that creates unexpected beauty, a parameter pushed to extremes.
|
||||
|
||||
## Share Your Creations
|
||||
|
||||
Art is meant to be shared. Post your generative experiments and let's inspire each other.
|
||||
|
|
@ -1,40 +0,0 @@
|
|||
---
|
||||
title: "Algorithms in Verse: Bubble Sort Sonnet"
|
||||
description: "Classic algorithms reimagined as poetry - where code meets iambic pentameter."
|
||||
pubDate: "Feb 22 2024"
|
||||
image: "https://images.unsplash.com/photo-1455390582262-044cdead277a?w=400&auto=format&fit=crop&q=60"
|
||||
authorImage: "/avatar/avatar1.png"
|
||||
authorName: "Neeldhara"
|
||||
---
|
||||
|
||||
# Algorithms in Verse: Bubble Sort Sonnet
|
||||
|
||||
## Bubble Sort: A Sonnet
|
||||
|
||||
```
|
||||
Compare adjacent elements in pairs,
|
||||
If order's wrong, then swap them into place.
|
||||
Through all the list this simple rule declares:
|
||||
The largest bubbles up to find its space.
|
||||
|
||||
Again we start, but now one less to check,
|
||||
The second largest finds its rightful home.
|
||||
Each pass through makes the chaos less a wreck,
|
||||
Until at last no elements must roam.
|
||||
|
||||
Though simple in its elegance and grace,
|
||||
And easy for beginners to perceive,
|
||||
In practice, it's too slow to win the race—
|
||||
O(n²) we sadly must believe.
|
||||
|
||||
But beauty lies in simplicity's pure art,
|
||||
The bubble sort still teaches at the start.
|
||||
```
|
||||
|
||||
## The Challenge
|
||||
|
||||
Can you write Quicksort as a limerick? Or Binary Search as free verse?
|
||||
|
||||
## Why This Matters
|
||||
|
||||
Poetry forces us to find the essence of an algorithm. The constraint reveals understanding.
|
||||
|
|
@ -1,56 +0,0 @@
|
|||
---
|
||||
title: "Code Haikus: Programming in 5-7-5"
|
||||
description: "Expressing programming concepts through the constrained beauty of haiku."
|
||||
pubDate: "Jan 30 2024"
|
||||
image: "https://images.unsplash.com/photo-1481627834876-b7833e8f5570?w=400&auto=format&fit=crop&q=60"
|
||||
authorImage: "/avatar/avatar1.png"
|
||||
authorName: "Neeldhara"
|
||||
---
|
||||
|
||||
# Code Haikus: Programming in 5-7-5
|
||||
|
||||
The constraint of haiku forces clarity. Here are programming concepts distilled to their essence.
|
||||
|
||||
## On Recursion
|
||||
|
||||
```
|
||||
Function calls itself
|
||||
Smaller problems, same pattern
|
||||
Base case stops the loop
|
||||
```
|
||||
|
||||
## On Debugging
|
||||
|
||||
```
|
||||
Print statements bloom wild
|
||||
Binary search through the code
|
||||
Bug reveals itself
|
||||
```
|
||||
|
||||
## On Optimization
|
||||
|
||||
```
|
||||
O(n squared) crawls
|
||||
Refactor to n log n
|
||||
Time complexity
|
||||
```
|
||||
|
||||
## On Git Merge Conflicts
|
||||
|
||||
```
|
||||
<<<<<<< HEAD
|
||||
Your changes, their changes clash
|
||||
Resolution waits
|
||||
```
|
||||
|
||||
## On Learning
|
||||
|
||||
```
|
||||
Stack Overflow searched
|
||||
Tutorial incomplete
|
||||
Understanding dawns
|
||||
```
|
||||
|
||||
## Your Turn
|
||||
|
||||
Write a haiku about your coding experience today. The constraint reveals truth.
|
||||
|
|
@ -1,183 +0,0 @@
|
|||
---
|
||||
title: "The 100 Prisoners Problem: A Beautiful Puzzle in Probability"
|
||||
description: "An interactive exploration of one of the most counterintuitive puzzles in probability theory, where 100 prisoners can escape with over 30% chance using a clever strategy."
|
||||
pubDate: "Oct 13 2025"
|
||||
image: "https://images.unsplash.com/photo-1589829545856-d10d557cf95f?w=400&auto=format&fit=crop&q=60"
|
||||
authorImage: "/avatar/avatar1.png"
|
||||
authorName: "Neeldhara"
|
||||
---
|
||||
|
||||
import PrisonerGameSimulator from '@/components/problems/PrisonerGameSimulator.tsx';
|
||||
import ProbabilityChart from '@/components/problems/ProbabilityChart.tsx';
|
||||
import PermutationExplorer from '@/components/problems/PermutationExplorer.tsx';
|
||||
import StrategyComparison from '@/components/problems/StrategyComparison.tsx';
|
||||
|
||||
# The 100 Prisoners Problem
|
||||
|
||||
Imagine 100 prisoners, numbered 1 to 100, face an unusual challenge. In a room are 100 boxes, also numbered 1 to 100. Inside each box is a randomly assigned number from 1 to 100 (each number appearing exactly once). The prisoners must find their own number by opening boxes, but here's the catch: **each prisoner can open only 50 boxes**.
|
||||
|
||||
The prisoners can devise a strategy beforehand, but once the challenge begins, they cannot communicate. If **all 100 prisoners** find their number, everyone goes free. If even one prisoner fails, all remain imprisoned.
|
||||
|
||||
What's the best strategy? And what are the odds of success?
|
||||
|
||||
## Try It Yourself!
|
||||
|
||||
Before we dive into the mathematics, let's experience the problem firsthand. Below is a simulator where you can play the game yourself. Choose the number of prisoners (between 5 and 100), and then try to help each prisoner find their number by clicking on boxes.
|
||||
|
||||
<PrisonerGameSimulator client:only="react" />
|
||||
|
||||
---
|
||||
|
||||
## The Naive Strategy
|
||||
|
||||
The most obvious approach is for each prisoner to simply open 50 random boxes. This seems reasonable, but the probability of success is dismal.
|
||||
|
||||
For any single prisoner, the probability of finding their number in 50 random boxes out of 100 is exactly 1/2. Since all 100 prisoners must succeed, and their outcomes are independent under random selection, the probability that everyone succeeds is:
|
||||
|
||||
$$P(\text\{success\}) = \left(\frac\{1\}\{2\}\right)^\{100\} \approx 7.9 \times 10^\{-31\}$$
|
||||
|
||||
That's essentially zero! You're more likely to win the lottery while being struck by lightning... multiple times.
|
||||
|
||||
### Naive Strategy: Probability vs Number of Prisoners
|
||||
|
||||
Watch how the probability of success plummets as we increase the number of prisoners:
|
||||
|
||||
<ProbabilityChart strategy="naive" client:only="react" />
|
||||
|
||||
As you can see, even with just 10 prisoners, the probability drops to about 0.1%. With 100 prisoners, it's practically impossible.
|
||||
|
||||
---
|
||||
|
||||
## The Clever Strategy: Following the Loops
|
||||
|
||||
Here's where mathematics reveals something beautiful. Instead of opening random boxes, each prisoner should follow a simple rule:
|
||||
|
||||
1. **Start by opening the box with your own number**
|
||||
2. **Look at the number inside that box**
|
||||
3. **Open the box with that number next**
|
||||
4. **Continue following this chain**
|
||||
|
||||
Why does this work? The key insight involves understanding permutations and cycles.
|
||||
|
||||
### Understanding Cycles in Permutations
|
||||
|
||||
When we randomly assign 100 numbers to 100 boxes, we're creating a **permutation** of the numbers 1 through 100. Every permutation can be decomposed into **cycles**.
|
||||
|
||||
For example, if:
|
||||
- Box 1 contains number 4
|
||||
- Box 4 contains number 7
|
||||
- Box 7 contains number 1
|
||||
|
||||
Then we have a cycle: 1 -> 4 -> 7 -> 1
|
||||
|
||||
Let's explore this with smaller numbers:
|
||||
|
||||
<PermutationExplorer client:only="react" />
|
||||
|
||||
The interactive explorer above lets you:
|
||||
- Generate all permutations for small values of *n* (3, 4, or 5)
|
||||
- See both standard notation and cycle notation
|
||||
- Filter permutations that have at least one "long cycle" (longer than *n*/2)
|
||||
- Understand why long cycles matter
|
||||
|
||||
### Why This Strategy Works
|
||||
|
||||
Here's the crucial insight: **A prisoner succeeds if and only if they are in a cycle of length ≤ 50**.
|
||||
|
||||
When prisoner k follows the loop strategy:
|
||||
1. They start at box k
|
||||
2. They follow a path through boxes determined by the permutation
|
||||
3. This path forms a cycle that eventually leads back to box k
|
||||
4. If this cycle has length ≤ 50, they'll find their number within 50 opens
|
||||
|
||||
The prisoners **all succeed** if and only if there is **no cycle longer than 50** in the permutation.
|
||||
|
||||
### Calculating the Probability
|
||||
|
||||
The probability that a random permutation of 100 elements has no cycle longer than 50 is:
|
||||
|
||||
$$P(\text\{success\}) = 1 - \sum_\{k=51\}^\{100\} \frac\{1\}\{k\}$$
|
||||
|
||||
Computing this sum:
|
||||
|
||||
$$P(\text\{success\}) = 1 - \left(\frac\{1\}\{51\} + \frac\{1\}\{52\} + \cdots + \frac\{1\}\{100\}\right) \approx 0.3118$$
|
||||
|
||||
That's over **31%**! This is astronomically better than the naive strategy's probability of essentially zero.
|
||||
|
||||
### Loop Strategy: Probability vs Number of Prisoners
|
||||
|
||||
<StrategyComparison client:only="react" />
|
||||
|
||||
## The Mathematics Behind It
|
||||
|
||||
### Why Does the Cycle Length Matter?
|
||||
|
||||
In a permutation of n elements, prisoner i will find their number within k tries using the loop strategy if and only if i belongs to a cycle of length at most k.
|
||||
|
||||
For n = 100 and k = 50:
|
||||
- The probability that a specific prisoner is in a cycle of length > 50 is: Σ(j=51 to 100) of 1/100
|
||||
- But we care about whether ANY prisoner is in such a cycle
|
||||
- The probability that NO cycle has length > 50 is: 1 - Σ(j=51 to 100) of 1/j
|
||||
|
||||
### The Harmonic Series Connection
|
||||
|
||||
As *n* approaches infinity, if each prisoner can open *n*/2 boxes, the probability of success approaches:
|
||||
|
||||
The limit as n approaches infinity is: P_n = 1 - ln(2) ≈ 0.3069
|
||||
|
||||
This beautiful result connects combinatorics, probability, and analysis through the harmonic series!
|
||||
|
||||
### Optimality
|
||||
|
||||
Remarkably, this loop-following strategy is **optimal**. No other strategy can achieve a higher probability of success. The proof involves showing that the problem reduces to avoiding long cycles in a random permutation, and the loop strategy is the unique way to leverage this structure.
|
||||
|
||||
---
|
||||
|
||||
## Why This Problem is Beautiful
|
||||
|
||||
The 100 prisoners problem is beloved by mathematicians because:
|
||||
|
||||
1. **Counterintuitive Result**: The fact that 31% >> 0% is shocking. A seemingly hopeless problem becomes tractable with the right insight.
|
||||
|
||||
2. **Deep Connection**: It connects permutation theory, probability, and the harmonic series in an elegant way.
|
||||
|
||||
3. **Collaborative Success**: Unlike independent trials, the prisoners' fates are intertwined through the structure of the permutation.
|
||||
|
||||
4. **Real-World Metaphor**: It illustrates how understanding underlying structure (cycles in permutations) can dramatically improve outcomes.
|
||||
|
||||
---
|
||||
|
||||
## Variants and Extensions
|
||||
|
||||
### What if prisoners can open k < n/2 boxes?
|
||||
|
||||
As k decreases below n/2, the probability drops rapidly. The threshold at n/2 is special—it's where the strategy becomes remarkably effective.
|
||||
|
||||
### What about communication?
|
||||
|
||||
If prisoners could communicate between trials (but not during), they still can't improve the strategy. The beauty is that the strategy requires only coordination before any prisoner enters, not during.
|
||||
|
||||
### The Malicious Director
|
||||
|
||||
In an interesting variant, suppose the director can see the prisoners' strategy and arrange the boxes adversarially (not randomly). Can the director always force them to fail? Yes! The director can always create a single cycle of length n, guaranteeing failure.
|
||||
|
||||
---
|
||||
|
||||
## Conclusion
|
||||
|
||||
The 100 prisoners problem shows us that:
|
||||
- Mathematical structure can be hidden in apparent randomness
|
||||
- Clever strategies can overcome seemingly impossible odds
|
||||
- Group coordination can be more powerful than independent action
|
||||
- Beautiful mathematics often lies beneath simple-seeming puzzles
|
||||
|
||||
The next time you face a problem that seems impossible, remember: there might be a hidden structure waiting to be discovered, turning hopeless odds into reasonable ones.
|
||||
|
||||
---
|
||||
|
||||
## Further Reading
|
||||
|
||||
- [Gál, A., & Miltersen, P. B. (2003). "The Cell Probe Complexity of Succinct Data Structures"](https://arxiv.org/abs/cs/0310027)
|
||||
- [Curtin, E., & Warshauer, M. (2006). "The Locker Puzzle"](https://www.jstor.org/stable/27642173)
|
||||
- [Wikipedia: 100 Prisoners Problem](https://en.wikipedia.org/wiki/100_prisoners_problem)
|
||||
|
||||
|
|
@ -1,32 +0,0 @@
|
|||
---
|
||||
title: "Dynamic Programming: Hidden Gems from Recent Contests"
|
||||
description: "Elegant dynamic programming problems that showcase beautiful techniques and insights."
|
||||
pubDate: "Jan 25 2024"
|
||||
image: "https://images.unsplash.com/photo-1509228468518-180dd4864904?w=400&auto=format&fit=crop&q=60"
|
||||
authorImage: "/avatar/avatar1.png"
|
||||
authorName: "Neeldhara"
|
||||
---
|
||||
|
||||
# Dynamic Programming: Hidden Gems from Recent Contests
|
||||
|
||||
These problems demonstrate the art of dynamic programming beyond standard patterns.
|
||||
|
||||
## Problem 1: The Subsequence Symphony
|
||||
|
||||
Given a string, find the number of subsequences that form palindromes of prime length.
|
||||
|
||||
### Solution Insight
|
||||
|
||||
The key is to maintain DP states for both position and palindrome center simultaneously. This reduces the state space from O(n³) to O(n²).
|
||||
|
||||
## Problem 2: Graph Coloring with Constraints
|
||||
|
||||
Color a graph such that no two adjacent vertices share a color, and the total number of color changes along any path is minimized.
|
||||
|
||||
### The DP Formulation
|
||||
|
||||
DP[node][color][changes] gives us the minimum cost. The trick is recognizing that we only need to track changes modulo 2.
|
||||
|
||||
## Practice Makes Perfect
|
||||
|
||||
These problems teach us that DP is as much about problem modeling as it is about computation.
|
||||
|
|
@ -1,41 +0,0 @@
|
|||
---
|
||||
title: "The Four Aces Miracle: A Self-Working Mathematical Marvel"
|
||||
description: "A card trick that teaches modular arithmetic and probability - perfect for the classroom."
|
||||
pubDate: "Jan 28 2024"
|
||||
image: "https://images.unsplash.com/photo-1529480384838-c1681c84aca5?w=400&auto=format&fit=crop&q=60"
|
||||
authorImage: "/avatar/avatar1.png"
|
||||
authorName: "Neeldhara"
|
||||
---
|
||||
|
||||
# The Four Aces Miracle: A Self-Working Mathematical Marvel
|
||||
|
||||
This trick never fails to amaze students, and the mathematics behind it is even more amazing.
|
||||
|
||||
## The Effect
|
||||
|
||||
A spectator deals cards into four piles while making random choices. Impossibly, the four aces end up on top of each pile.
|
||||
|
||||
## The Secret
|
||||
|
||||
It's all about invariants and modular arithmetic. No sleight of hand required - pure mathematics does the magic.
|
||||
|
||||
## The Method
|
||||
|
||||
1. Pre-arrange the deck (the math determines the arrangement)
|
||||
2. Have the spectator deal following simple rules
|
||||
3. The aces appear automatically
|
||||
|
||||
## The Mathematics
|
||||
|
||||
The dealing process preserves certain positional invariants modulo 4. The initial arrangement ensures these invariants place the aces correctly.
|
||||
|
||||
## Teaching Applications
|
||||
|
||||
This trick demonstrates:
|
||||
- Modular arithmetic
|
||||
- Invariants in algorithms
|
||||
- Deterministic vs. random processes
|
||||
|
||||
## The Bigger Lesson
|
||||
|
||||
Mathematics can create experiences that feel like magic. And that feeling of wonder? That's what hooks students on math.
|
||||
|
|
@ -1,35 +0,0 @@
|
|||
---
|
||||
title: "The Gilbreath Principle: When Chaos Creates Order"
|
||||
description: "A mathematical card principle that seems impossible but always works - perfect for teaching algorithms."
|
||||
pubDate: "Feb 15 2024"
|
||||
image: "https://images.unsplash.com/photo-1570543375343-63fe3d67761b?w=400&auto=format&fit=crop&q=60"
|
||||
authorImage: "/avatar/avatar1.png"
|
||||
authorName: "Neeldhara"
|
||||
---
|
||||
|
||||
# The Gilbreath Principle: When Chaos Creates Order
|
||||
|
||||
Shuffle a deck in a specific way, and mathematical order emerges from apparent chaos.
|
||||
|
||||
## The Phenomenon
|
||||
|
||||
Arrange cards alternating red-black. Riffle shuffle. Now deal pairs - each pair has one red and one black card. Magic? No, mathematics.
|
||||
|
||||
## Why It Works
|
||||
|
||||
The riffle shuffle preserves local structure while appearing to randomize. The alternating pattern creates an invariant that survives the shuffle.
|
||||
|
||||
## Classroom Implementation
|
||||
|
||||
Students predict it won't work. When it does, they're hooked. "Why?" becomes the driving question.
|
||||
|
||||
## The Deeper Lesson
|
||||
|
||||
Not all randomness is truly random. Structure can hide in apparent disorder. This principle appears in:
|
||||
- Network protocols
|
||||
- Error-correcting codes
|
||||
- Distributed systems
|
||||
|
||||
## Beyond Cards
|
||||
|
||||
The Gilbreath Principle teaches us to look for hidden invariants in complex systems.
|
||||
|
|
@ -1,32 +0,0 @@
|
|||
---
|
||||
title: "Graph Algorithms: Assessment Highlights"
|
||||
description: "Interesting graph problems from recent course assessments with detailed solutions."
|
||||
pubDate: "Feb 28 2024"
|
||||
image: "https://images.unsplash.com/photo-1550751827-4bd374c3f58b?w=400&auto=format&fit=crop&q=60"
|
||||
authorImage: "/avatar/avatar1.png"
|
||||
authorName: "Neeldhara"
|
||||
---
|
||||
|
||||
# Graph Algorithms: Assessment Highlights
|
||||
|
||||
A collection of graph problems that test deep understanding rather than memorization.
|
||||
|
||||
## The Bridge Detection Variant
|
||||
|
||||
Find all edges whose removal increases the number of triangles in the graph.
|
||||
|
||||
### Solution Approach
|
||||
|
||||
Counter-intuitively, we need to count triangles that share exactly one edge with the candidate. The algorithm runs in O(m√m) time using careful enumeration.
|
||||
|
||||
## Shortest Path with Wildcards
|
||||
|
||||
Given a graph where some edge weights are variables, find assignments that minimize the longest shortest path.
|
||||
|
||||
### Key Insight
|
||||
|
||||
This reduces to a linear programming problem with interesting structure. The dual interpretation reveals connections to network flow.
|
||||
|
||||
## Teaching Through Problems
|
||||
|
||||
These problems help students see beyond standard algorithms to underlying principles.
|
||||
|
|
@ -1,41 +0,0 @@
|
|||
---
|
||||
title: "IOI 2023: Breaking Down the Hardest Problems"
|
||||
description: "Deep analysis of the most challenging problems from the International Olympiad in Informatics 2023."
|
||||
pubDate: "Jan 20 2024"
|
||||
image: "https://images.unsplash.com/photo-1434030216411-0b793f4b4173?w=400&auto=format&fit=crop&q=60"
|
||||
authorImage: "/avatar/avatar1.png"
|
||||
authorName: "Neeldhara"
|
||||
---
|
||||
|
||||
# IOI 2023: Breaking Down the Hardest Problems
|
||||
|
||||
The International Olympiad in Informatics continues to push the boundaries of algorithmic problem solving.
|
||||
|
||||
## Problem: Soccer Stadium
|
||||
|
||||
A geometric optimization problem disguised as dynamic programming. The key insight: think in terms of monotonic paths.
|
||||
|
||||
### The Approach
|
||||
|
||||
1. Transform the 2D problem into a 1D problem using clever observations
|
||||
2. Use convex hull optimization for the DP transitions
|
||||
3. Handle edge cases with careful implementation
|
||||
|
||||
## Problem: Closing Time
|
||||
|
||||
A tree problem requiring sophisticated data structures and careful analysis.
|
||||
|
||||
### The Solution
|
||||
|
||||
The trick is recognizing this as a centroid decomposition problem. Once you see it, the implementation follows naturally.
|
||||
|
||||
## Lessons for Students
|
||||
|
||||
These problems teach us:
|
||||
- Simple problems have elegant solutions
|
||||
- Complex problems require systematic decomposition
|
||||
- Implementation matters as much as algorithms
|
||||
|
||||
## Practice Strategy
|
||||
|
||||
Start with subtasks. Even partial solutions teach valuable lessons.
|
||||
|
|
@ -1,35 +0,0 @@
|
|||
---
|
||||
title: "The Knight's Tour: An Interactive Exploration"
|
||||
description: "An interactive puzzle exploring the knight's tour problem with surprising mathematical connections."
|
||||
pubDate: "Jan 30 2024"
|
||||
image: "https://images.unsplash.com/photo-1528819622765-d6bcf132f793?w=400&auto=format&fit=crop&q=60"
|
||||
authorImage: "/avatar/avatar1.png"
|
||||
authorName: "Neeldhara"
|
||||
---
|
||||
|
||||
# The Knight's Tour: An Interactive Exploration
|
||||
|
||||
Can a knight visit every square on a chessboard exactly once? This ancient puzzle hides deep mathematical structure.
|
||||
|
||||
## The Basic Challenge
|
||||
|
||||
Start with a 5×5 board. Can you find a knight's tour? What about one that returns to the starting square (a closed tour)?
|
||||
|
||||
## Mathematical Beauty
|
||||
|
||||
The problem connects to:
|
||||
- Hamiltonian paths in graphs
|
||||
- Warnsdorff's heuristic
|
||||
- Magic squares (surprisingly!)
|
||||
|
||||
## The Algorithm
|
||||
|
||||
The key insight: always move to the square with fewest onward moves. This simple heuristic works remarkably well.
|
||||
|
||||
## Try It Yourself
|
||||
|
||||
[Interactive board would go here - imagine clicking squares to build your tour]
|
||||
|
||||
## Going Deeper
|
||||
|
||||
For which board sizes do closed tours exist? The answer involves beautiful number theory.
|
||||
|
|
@ -1,35 +0,0 @@
|
|||
---
|
||||
title: "Project Euler: My Favorite Problems from 700+"
|
||||
description: "Curated problems from Project Euler that teach beautiful mathematical and algorithmic concepts."
|
||||
pubDate: "Feb 25 2024"
|
||||
image: "https://images.unsplash.com/photo-1635070041078-e363dbe005cb?w=400&auto=format&fit=crop&q=60"
|
||||
authorImage: "/avatar/avatar1.png"
|
||||
authorName: "Neeldhara"
|
||||
---
|
||||
|
||||
# Project Euler: My Favorite Problems from 700+
|
||||
|
||||
After solving 700+ Project Euler problems, these are the ones that changed how I think about mathematics and programming.
|
||||
|
||||
## Problem 96: Su Doku
|
||||
|
||||
Not just Sudoku solving - but solving 50 puzzles efficiently. The beauty is in combining constraint propagation with backtracking.
|
||||
|
||||
## Problem 208: Robot Walks
|
||||
|
||||
A counting problem that requires deep mathematical insight. The connection to complex numbers is unexpected and beautiful.
|
||||
|
||||
## Problem 613: Pythagorean Ant
|
||||
|
||||
Probability meets geometry in this elegant problem. The solution requires careful integration and surprising symmetry observations.
|
||||
|
||||
## The Meta-Lesson
|
||||
|
||||
Project Euler teaches you:
|
||||
- Mathematical intuition matters more than coding speed
|
||||
- There's always a clever approach
|
||||
- The journey matters more than the destination
|
||||
|
||||
## Getting Started
|
||||
|
||||
Don't aim for the leaderboard. Aim for understanding. Each problem is a teacher.
|
||||
|
|
@ -1,28 +0,0 @@
|
|||
---
|
||||
title: "Beyond Sudoku: Exploring Constraint Satisfaction Puzzles"
|
||||
description: "A journey through Sudoku variants and their algorithmic solutions."
|
||||
pubDate: "Feb 10 2024"
|
||||
image: "https://images.unsplash.com/photo-1580541631950-7282082b53ce?w=400&auto=format&fit=crop&q=60"
|
||||
authorImage: "/avatar/avatar1.png"
|
||||
authorName: "Neeldhara"
|
||||
---
|
||||
|
||||
# Beyond Sudoku: Exploring Constraint Satisfaction Puzzles
|
||||
|
||||
Sudoku is just the beginning. Let's explore variants that push the boundaries of logic puzzles.
|
||||
|
||||
## Killer Sudoku
|
||||
|
||||
Combine Sudoku with Kakuro - cages show sums, but no digit repeats within a cage.
|
||||
|
||||
## Sandwich Sudoku
|
||||
|
||||
The numbers outside show the sum of digits between 1 and 9 in that row/column. Simple rule, complex implications!
|
||||
|
||||
## The Algorithm Connection
|
||||
|
||||
These puzzles are constraint satisfaction problems. Techniques like arc consistency and backtracking with constraint propagation solve them efficiently.
|
||||
|
||||
## Create Your Own
|
||||
|
||||
What happens if we add chess knight move constraints? The design space is infinite!
|
||||
|
|
@ -1,30 +0,0 @@
|
|||
---
|
||||
title: "Imposter Syndrome in Academia: A Confession"
|
||||
description: "An honest conversation about feeling like a fraud, even after years of success."
|
||||
pubDate: "Feb 25 2024"
|
||||
image: "https://images.unsplash.com/photo-1517048676732-d65bc937f952?w=400&auto=format&fit=crop&q=60"
|
||||
authorImage: "/avatar/avatar1.png"
|
||||
authorName: "Neeldhara"
|
||||
---
|
||||
|
||||
# Imposter Syndrome in Academia: A Confession
|
||||
|
||||
Even after publishing papers, winning grants, and teaching thousands of students, the voice whispers: "They'll find out you don't belong."
|
||||
|
||||
## The Paradox
|
||||
|
||||
The more you know, the more you realize you don't know. Expertise breeds humility, which feeds the imposter.
|
||||
|
||||
## What Helps
|
||||
|
||||
- Keeping a "wins" journal - evidence against the imposter
|
||||
- Mentoring others - seeing your knowledge help someone
|
||||
- Talking about it - you're not alone in this
|
||||
|
||||
## The Silver Lining
|
||||
|
||||
Maybe imposter syndrome keeps us humble, curious, and always learning. Maybe it's not a bug, but a feature.
|
||||
|
||||
## Moving Forward
|
||||
|
||||
I may never silence the voice completely. But I've learned to acknowledge it and keep going anyway.
|
||||
|
|
@ -1,32 +0,0 @@
|
|||
---
|
||||
title: "On Teaching Algorithms: Lessons from a Decade"
|
||||
description: "Reflections on what works (and what doesn't) in computer science education."
|
||||
pubDate: "Jan 10 2024"
|
||||
image: "https://images.unsplash.com/photo-1509062522246-3755977927d7?w=400&auto=format&fit=crop&q=60"
|
||||
authorImage: "/avatar/avatar1.png"
|
||||
authorName: "Neeldhara"
|
||||
---
|
||||
|
||||
# On Teaching Algorithms: Lessons from a Decade
|
||||
|
||||
Ten years of teaching has taught me more than any textbook could.
|
||||
|
||||
## Start with Why
|
||||
|
||||
Students don't care about O(n log n) until they understand why their code is slow. Real problems first, theory second.
|
||||
|
||||
## The Power of Visualization
|
||||
|
||||
Abstract concepts become concrete when visualized. Every algorithm should have a picture.
|
||||
|
||||
## Failure is a Feature
|
||||
|
||||
Let students struggle. The struggle is where learning happens. But know when to throw a lifeline.
|
||||
|
||||
## Assessment Philosophy
|
||||
|
||||
Test understanding, not memorization. Open-book exams with novel problems beat closed-book regurgitation every time.
|
||||
|
||||
## The Joy of "Aha!" Moments
|
||||
|
||||
There's no feeling quite like seeing a student's eyes light up when a concept clicks. That's why we do this.
|
||||
|
|
@ -1,34 +0,0 @@
|
|||
---
|
||||
title: "SODA 2024: Algorithmic Breakthroughs"
|
||||
description: "A roundup of fascinating algorithmic results from SODA 2024, focusing on graph algorithms and optimization techniques."
|
||||
pubDate: "Jan 15 2024"
|
||||
image: "https://images.unsplash.com/photo-1509228468518-180dd4864904?w=400&auto=format&fit=crop&q=60"
|
||||
authorImage: "/avatar/avatar1.png"
|
||||
authorName: "Neeldhara"
|
||||
---
|
||||
|
||||
# SODA 2024: Algorithmic Breakthroughs
|
||||
|
||||
The Symposium on Discrete Algorithms (SODA) 2024 brought together researchers from around the world to present cutting-edge algorithmic research. This post highlights some of the most exciting developments in graph algorithms and optimization.
|
||||
|
||||
## Graph Algorithms Revolution
|
||||
|
||||
### Dynamic Graph Coloring
|
||||
|
||||
One of the standout papers introduced a breakthrough in dynamic graph coloring with polylogarithmic update time. The authors developed a novel data structure that maintains a proper vertex coloring while supporting edge insertions and deletions efficiently.
|
||||
|
||||
The key insight was to combine randomized recoloring strategies with a carefully designed hierarchical decomposition of the graph. This allows for local updates that rarely propagate through the entire structure.
|
||||
|
||||
## Approximation Algorithms
|
||||
|
||||
### The Traveling Salesman Problem Revisited
|
||||
|
||||
A surprising result showed that for graphs with bounded doubling dimension, we can achieve a (1+ε)-approximation for TSP in nearly linear time. This improves upon decades of previous work and opens new avenues for practical implementations.
|
||||
|
||||
## Complexity Theory Connections
|
||||
|
||||
The conference also featured several papers bridging the gap between pure algorithmic research and complexity theory. A particularly elegant result showed that certain graph problems believed to require quadratic time are equivalent under fine-grained reductions.
|
||||
|
||||
## Looking Forward
|
||||
|
||||
These results demonstrate that fundamental algorithmic problems still have room for improvement. The techniques developed here will likely influence algorithm design for years to come.
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 154 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 171 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 187 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 160 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 131 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 211 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 171 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 172 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 179 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 253 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 370 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 372 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 424 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 424 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 409 KiB |
176
sites/research/src/content/research/cp/sam-i-am/index.md
Normal file
176
sites/research/src/content/research/cp/sam-i-am/index.md
Normal file
|
|
@ -0,0 +1,176 @@
|
|||
---
|
||||
title: "Sam I Am"
|
||||
description: "This is mostly about solving Sam I Am (UVa 11419); en route, we will end up discovering Kőnig's theorem, which is a delightful fact about the special relationship shared by vert..."
|
||||
pubDate: "2021-10-01"
|
||||
authorName: "Neeldhara"
|
||||
sourceCategories: ["cp", "lecturenotes"]
|
||||
sourcePath: "cp/sam-i-am/index.qmd"
|
||||
---
|
||||
|
||||
This is mostly about solving Sam I Am ([UVa 11419](https://onlinejudge.org/external/114/11419.pdf)); en route, we will end up discovering Kőnig's theorem, which is a delightful fact about the special relationship shared by vertex covers and maximum matchings in bipartite graphs.
|
||||
|
||||
## The Problem
|
||||
|
||||
Here's an abridged version of the problem statement.
|
||||
|
||||
> Sam is facing a temple which can be described by a $m \times n$ grid and **he has the locations of all enemies in the temple** (each location can be thought of as the intersection of a row and a column in this grid).
|
||||
|
||||
All of a sudden, he realizes that he can kill the enemies without entering the temple using the great cannon ball which spits out a gigantic ball bigger than him killing anything it runs into and keeps on rolling until it finally explodes.
|
||||
|
||||
**But the cannonball can only shoot horizontally or vertically and all the enemies along the path of that cannon ball will be killed.**
|
||||
|
||||
Sam wants to know the **minimum number of cannon balls** and the positions from which he can shoot the cannonballs **to eliminate all enemies** from outside that temple.
|
||||
>
|
||||
|
||||
## Some initial observations with an example
|
||||
|
||||
So to begin with, we have a grid with some cells identified as locations where Sam's enemies are positioned, and here's an example:
|
||||
|
||||
|
||||
|
||||
> **Aside:** Conveniently for us, the enemies don't move around.
|
||||
|
||||
We want to *hit* all of these locations, and what we have at our disposal is giant cannon balls which can destroy all enemies that are positioned on a single row, or a single column. For example, if we were obsessed about only firing along rows, we would need four cannon balls to tackle 'em all, like so:
|
||||
|
||||
|
||||
|
||||
If Sam was superstitious about shooting along columns only, then he would again need four of these cannon balls to take care of everything:
|
||||
|
||||
|
||||
|
||||
However, our friend Sam is smart, not superstitious! And if there is anything that he is obsessed about, it is ruthlessly optimal destruction! In other words, he wants to fix everything up, but while using the smallest number of cannon balls possible... and if that means mixing up ranks and files, so be it — notice that you can manage with just three once you combine the use of both axes:
|
||||
|
||||
|
||||
|
||||
And for this example in particular, notice that three cannon balls are *necessary*, because we have at least three enemies positioned at locations that share *neither a row nor a column*, implying that no row-fire or column-fire can handle more than one of these locations at once:
|
||||
|
||||
|
||||
|
||||
So for this example, we know that:
|
||||
|
||||
- three cannon balls are necessary &
|
||||
- three cannon balls are sufficient.
|
||||
|
||||
In general, let's say that two enemy positions are *mutually independent* if they are on different columns *and* on different rows. Let $k$ be the size of a largest collection of mutually independent positions. Then it is clear that:
|
||||
|
||||
- $k$ cannon balls are necessary to handle all enemy locations;
|
||||
|
||||
because any $\ell$ fires that handle *all* enemy locations must in particular handle these $k$ mutually independent ones, and each individual fire can get to (at best) one of them — by definition of what it means for two positions to be mutually independent. So if we have a valid solution involving $\ell$ cannon balls, then $\ell \geq k$.
|
||||
|
||||
What is a less obvious, but considerably fascinating, is the fact that:
|
||||
|
||||
- there is always a strategy to hit *all* locations using just $k$ cannon balls. 🤯
|
||||
|
||||
A striking situation, no pun intended — the obvious estimate of what is needed turns out to be enough as well! The easy lower bound has a matching upper bound ❤️
|
||||
|
||||
## An auxiliary graph
|
||||
|
||||
Alright, I think that's enough with the advertising.
|
||||
|
||||
How does this work?
|
||||
|
||||
Let's construct the following graph $G = (V,E)$ associated with the grid and the information about enemy positions:
|
||||
|
||||
- Introduce a vertex for every row in the grid; say $r_i$ for $1 \leq i \leq m$. These are the *row vertices.*
|
||||
- Introduce a vertex for every column in the grid; say $c_j$ for $1 \leq j \leq n$. These are the *column vertices.*
|
||||
|
||||
|
||||
|
||||
- Introduce the edge $(r_i,c_j)$, $1 \leq i \leq n; 1 \leq j \leq m$ if and only if the location at the intersection of the $i^{th}$ row and the $j^{th}$ column corresponds to an enemy position.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Observe that:
|
||||
|
||||
- Any matching in $G$ (a collection of mutually disjoint edges) corresponds to a collection of mutually independent enemy positions back in the grid.
|
||||
- What we are looking for is a smallest-sized subset $S$ of $V(G)$ such that every edge $e$ in $G$ has at least one of its endpoints in $S$. Such a subset is called a vertex cover.
|
||||
|
||||
|
||||
|
||||
So our claim in the language of grids now translates to:
|
||||
|
||||
|
||||
> 📝 The size of a maximum matching in $G$ is equal to the size of a minimum vertex cover in $G$.
|
||||
|
||||
in the language of graphs. Keep in mind that as graphs go $G$, happens to be a bipartite graph; which is to say that its vertex set can be parittioned into two parts† such that every edge has exactly one endpoint in each part.
|
||||
|
||||
> **Aside:** † In this example, these parts correspond to subsets of row vertices and column vertices.
|
||||
|
||||
## Bring in the flows
|
||||
|
||||
Is this much ado for nothing? We seem to have done some translation work, but there's no proof of this bold claim in sight just yet... 😬
|
||||
|
||||
Fair. So here's a roadmap for what we plan to do next:
|
||||
|
||||
- Use the graph $G$ as the basis of a flow network.
|
||||
- Recall the maxflow-mincut duality.
|
||||
- ~~Profit.~~ Show the duality that we are interested in by hooking it up the known one.
|
||||
|
||||
So first things first: we are going to setup a flow network around the graph $G$, and here's a partial picture of what it looks like:
|
||||
|
||||
|
||||
|
||||
Here's the official description of how we build this up:
|
||||
|
||||
- Start with the graph $G$, and orient every edge between a row vertex and a column vertex so that every such edge originates *from* the row vertex and latches on *to* the column vertex.
|
||||
- We assign infinite capacities to all the edges in $G$. Go unlimited on the originals! We will even dub these edges *original edges* going forward.
|
||||
- Add a source vertex $s$ and add unit-capacity edges $(s,r)$ for every row vertex $r$. We will call these edges the *row selectors.*
|
||||
- Add a target vertex $t$ and add unit-capacity edges $(c,t)$ for every column vertex $c$. We will refer to these edges as *column selectors.*
|
||||
|
||||
That's it, that's the flow network $(\tilde{G},\kappa)$ based on $G$, where I'm using $\kappa$ to denote the capacity function. Now let's stare at any valid integral flow in this network — what does it pull out from the middle? 🤔
|
||||
|
||||
|
||||
|
||||
Let's make the following quick observations in the context of a valid integral flow $f$ in $(\tilde{G},\kappa)$:
|
||||
|
||||
- The flow on any edge $e$ from $G$ (i.e, an original edge) is either zero or one. Indeed, if $f(e) > 1$, then we violate conservation constraints at both endpoints of $e$.
|
||||
- For any row or column vertex, at most one original edge incident to it is used by the flow $f$. In other words, $f(e) = 0$ for all but at most one original edge incident to any row or column vertex. Again, if not, combined with the fact that $f$ is integral and that the row and column selectors have unit capacity, we will violate conservation constraints on the vertex under consideration.
|
||||
|
||||
Based on these observations, we have that the set of original edges for which $f(e) = 1$ forms a matching in back in $G$, and in particular, if $f$ was maximum flow, then this set would correspond to a maximum-sized matching. Now, let's look at the corresponding mincut by building the residual graph:
|
||||
|
||||
|
||||
|
||||
Edges in the residual graph that have a residual capacity of zero are not shown. Also, the original edges that were used by $f$ have infinite residual capacity but their corresponding back-edges have unit capacity, but this distinction is not emphasised in the picture because it's not particularly relevant to our discussion.
|
||||
|
||||
and considering what vertices are reachable from $s$:
|
||||
|
||||
|
||||
|
||||
The vertices reachable from $s$ are marked green, while all remaining vertices are marked red.
|
||||
|
||||
In the residual graph, I would like to draw your attention to:
|
||||
|
||||
- row vertices that are unreachable from $s$,
|
||||
- column vertices from where it is impossible to reach $t$.
|
||||
|
||||
We will refer to these vertices as the *misfits —* they are highlighted for you in the picture below:
|
||||
|
||||
|
||||
|
||||
Now roll up your sleeves for some magic. Let's pull up the cut — which we know is in fact a mincut — obtained by considering the set of vertices reachable from $s$ the residual graph corresponding to the maxflow $f$. In pictures, note how we have attracted some column vertices to the $s$-side, and pushed away some row vertices to the $t$-side:
|
||||
|
||||
|
||||
|
||||
Note that this is a minimum cut, that is to say, the total capacity of the edges crossing the cut is as small as possible — which means that, in particular, the total capacity is at least (or should that be at most?) finite, and that implies, even more particularly, that *none*[^1] of the original edges cross this cut.
|
||||
|
||||
[^1]: Remember how their capacities were infinite? So they just cannot afford to cross a minimum-capacity cut.
|
||||
|
||||
So every original edge is confined to the $s$-camp or the $t$-camp; but note that every original edge is an edge between a row vertex and a column vertex; so if you put two and two together, you see that, in fact, *every edge must be incident to a misfit vertex.* This means that the misfits are what we were looking for all along — they form a vertex cover of $G$!
|
||||
|
||||
So at least we have *some* solution. Is this the best we can hope for?
|
||||
|
||||
Why yes!
|
||||
|
||||
Note that every misfit vertex contributes *exactly one unit-capacity edge* to the minimum cut: the misfits on the $s$-side are incident to column selectors, and these edges connect with $t$ on the other side; while misfits on the $t$-side are incident to row selectors, and these edges connect with $s$, which is again on the opposite end. So every misfit vertex contributes exactly one edge to the minimum cut — and there are no other edges that cross the cut, so we have the following sequence of equalities:
|
||||
|
||||
- size of the proposed solution = #misfits
|
||||
- #misfits = capacity of the minimum cut
|
||||
- capacity of the minimum cut = value of the maximum flow
|
||||
- value of the maximum flow = size of a maximum matching back in $G$
|
||||
- size of a maximum matching back in $G$ = lower bound on our solution
|
||||
|
||||
Therefore, we have proposed a solution whose cost matches a lower bound on it, making it optimal! With a slight adjustment of language (dropping misfits in favor of vertex cover), the sequence of inequalities above also shows that the size of a minimum vertex cover in a bipartite graph equals the size of a maximum matching in the graph.
|
||||
|
||||
This was the relationship I'd promised to cover when we started, and it goes by Kőnig's theorem in case you'd like to find out more — the argument we came up with here isn't perhaps the traditional proof, and this is a fact that can be established in several different ways, all fun in their own way ❤️
|
||||
142
sites/research/src/content/research/crypto-intro/index.md
Normal file
142
sites/research/src/content/research/crypto-intro/index.md
Normal file
|
|
@ -0,0 +1,142 @@
|
|||
---
|
||||
title: "Intro to Crypto"
|
||||
description: "Caution Background This post is based on a series of lectures that Venkata Koppula gave at IIT Gandhiangar during the inter-IIT sports meet. Lecture 1: How to define security? N..."
|
||||
pubDate: "2023-12-21"
|
||||
authorName: "Neeldhara"
|
||||
sourceCategories: ["talk", "exposition"]
|
||||
sourcePath: "crypto-intro/index.qmd"
|
||||
---
|
||||
|
||||
> **Caution**
|
||||
>
|
||||
> # Background
|
||||
> This post is based on a series of lectures that [Venkata Koppula](https://web.iitd.ac.in/~kvenkata/) gave at IIT Gandhiangar during the inter-IIT sports meet.
|
||||
|
||||
|
||||
## Lecture 1: How to define security?
|
||||
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> # A first threat scenario, informally:
|
||||
>
|
||||
>
|
||||
> - A king and an admiral share some secret information beforehand.
|
||||
> - Later, the king wants to send exactly one message.
|
||||
> - The admiral should learn the message.
|
||||
> - No one else should learn anything.
|
||||
>
|
||||
|
||||
|
||||
### Encrpytion and Decryption
|
||||
|
||||
The setup:
|
||||
|
||||
Let $\mathcal{A}$ be an abitrary but fixed set of symbols, which we call the alphabet.
|
||||
|
||||
- The _key space_ $\mathcal{K}$ is a set of strings over $\mathcal{A}$.
|
||||
- The _message space_ $\mathcal{M}$ is also a set of strings over $\mathcal{A}$.
|
||||
- The _ciphertext space_ $\mathcal{C}$ is also a set of strings over $\mathcal{A}$.
|
||||
|
||||
We also have two functions:
|
||||
|
||||
1. The **encryption** function:
|
||||
|
||||
$$\mathfrak{E}: \mathcal{K} \times \mathcal{M} \longrightarrow \mathcal{C},$$
|
||||
|
||||
which takes as input a key $k \in \mathcal{K}$ and a message $m \in \mathcal{M}$, and outputs a ciphertext $c \in \mathcal{C}$.
|
||||
|
||||
2. The **decryption** function:
|
||||
|
||||
$$\mathfrak{D}: \mathcal{K} \times \mathcal{C} \longrightarrow \mathcal{M} \cup \{\bot\},$$
|
||||
|
||||
which takes as input a key $k \in \mathcal{K}$ and a ciphertext $c \in \mathcal{C}$, and outputs a message $m \in \mathcal{M}$ or the symbol $\bot$ (which is pronounced _bottom_, and captures a failure signal, e.g, on a corrupt input).
|
||||
|
||||
|
||||
The encrpytion scheme is said to be _valid_ if for all $(k,m) \in \mathcal{K} \times \mathcal{M}$, it holds that:
|
||||
|
||||
$$\mathfrak{D}(k, \mathfrak{E}(k, m)) = m$$
|
||||
|
||||
### A Secruity Definition
|
||||
|
||||
Once we have a proposal for a valid encryption/decryption scheme, we would like to know if it is a decent one: and in our context, we like schemes that can survive adverserial attacks: imagine someone snooping over the communication channel, and trying to learn the message from the ciphertext --- we would like to make claims to the effect of "that won't be possible".
|
||||
|
||||
To formalize this, we have the notion of a security game, which is a game played between two players: a challenger and an adversary. The challenger is the one who sets up the game, and the adversary is the one who tries to break the scheme. Here's what the game looks like:
|
||||
|
||||
1. The challenger picks a key $k \in \mathcal{K}$ uniformly at random and a picks a bit $b \in \{0,1\}$ uniformly at random
|
||||
2. The adversary sends the challenger two messages $m_0$ and $m_1$.
|
||||
3. The challenger sends the ciphertext $c = \mathfrak{E}(k, m_b)$ to the adversary.
|
||||
4. The adversary outputs a bit $b'$.
|
||||
5. The adversary wins if $b = b'$.
|
||||
|
||||
Note that an adversary that outputs a bit in step 4 by tossing a coin (`1` if `H` and `0` if `T`) wins this game with probability $1/2$.
|
||||
|
||||
A self-respecting adversary will want to fare better, while a scheme worth its salt will not want to be vulnerable with respect to _any_ adverseray, so we say that:
|
||||
|
||||
- an adversary wins this game if they can win it with probability greater than half, and,
|
||||
- a scheme is secure if no adversary can win this game with probability greater than half.
|
||||
|
||||
### Example: An Insecure Scheme
|
||||
|
||||
Consider a lazy encryption scheme that does not encrypt a message at all:
|
||||
|
||||
- $\mathfrak{E}(k,m) = m$ and
|
||||
- $\mathfrak{D}(k,c) = c$.
|
||||
|
||||
It is easy to see that there is an adversary who can win the security game defined above with probability 1, so this is not a terribly smart scheme. The same is true for schemes that rotate the message by a fixed amount (why?).
|
||||
|
||||
|
||||
### Example: An Secure Scheme
|
||||
|
||||
Assume the message space, key space, and ciphertext space are all $n$-bit strings for some arbitrary but fixed choice of $n$. Consider the following encryption scheme:
|
||||
|
||||
- $\mathfrak{E}(k,m) = k \oplus m$ and
|
||||
- $\mathfrak{D}(k,c) = k \oplus c$.
|
||||
|
||||
It turns out that this scheme is secure, intuitively because for any ciphertext $c$, there are two keys $k_1$ and $k_2$ which are such that:
|
||||
|
||||
- $\mathfrak{D}(k_1,c) = m_0$, and
|
||||
- $\mathfrak{D}(k_2,c) = m_1$,
|
||||
|
||||
for any two messages $m_0$ and $m_1$, so there is no way for the adversary to reverse engineer the bit $b$.
|
||||
|
||||
(Exercise: prove this formally.)
|
||||
|
||||
### Example: Another Insecure Scheme
|
||||
|
||||
|
||||
Assume the message space and ciphertext space are $2n$-bit strings for some arbitrary but fixed choice of $n$, and the key space is the set of all $n$-bit strings. Consider the following encryption scheme:
|
||||
|
||||
- $\mathfrak{E}(k,m) = (k | k) \oplus m$ and
|
||||
- $\mathfrak{D}(k,c) = (k | k) \oplus c$,
|
||||
|
||||
where $(a | b)$ denotes the concatenation of two strings.
|
||||
|
||||
It turns out that this scheme is _not_ secure (why?).
|
||||
|
||||
|
||||
### A Stronger Secruity Definition
|
||||
|
||||
Consider the following extended security game:
|
||||
|
||||
1. The challenger picks a key $k \in \mathcal{K}$ uniformly at random and a picks a bit $b \in \{0,1\}$ uniformly at random.
|
||||
2. The adversary sends the challenger two messages $m_{00}$ and $m_{01}$.
|
||||
3. The challenger sends the ciphertext $c_0 = \mathfrak{E}(k, m_{0b})$ to the adversary.
|
||||
4. The adversary sends the challenger two messages $m_{10}$ and $m_{11}$.
|
||||
5. The challenger sends the ciphertext $c_1 = \mathfrak{E}(k, m_{1b})$ to the adversary.
|
||||
6. The adversary outputs a bit $b'$.
|
||||
7. The adversary wins if $b = b'$.
|
||||
|
||||
As before, we say that:
|
||||
|
||||
- an adversary wins this game if they can win it with probability greater than half, and,
|
||||
- a scheme is secure if no adversary can win this game with probability greater than half.
|
||||
|
||||
However, in the extended game, we have empowered the adversary to a point where _no_ deterministic scheme can be secure in this stronger sense! Here's why:
|
||||
|
||||
- Suppose the adversary picks: $m_{00} = 0^n$, $m_{01} = 1^n$, $m_{10} = 0^n$, $m_{11} = 01^{n-1}$.
|
||||
- Then the adversary returns $0$ if $c_0$ and $c_1$ are identical, and $1$ otherwise.
|
||||
|
||||
Note that this particular adversary wins with probability 1, no matter what $\mathfrak{E}$ and $\mathfrak{D}$ are.
|
||||
|
||||
What can we say about _randomized_ schemes? Can they be secure in the extended setting?
|
||||
|
|
@ -1,34 +0,0 @@
|
|||
---
|
||||
title: "Distributed Computing: Recent Advances"
|
||||
description: "Survey of recent developments in distributed algorithms from major conferences."
|
||||
pubDate: "Feb 20 2024"
|
||||
image: "https://images.unsplash.com/photo-1558618666-fcd25c85cd64?w=400&auto=format&fit=crop&q=60"
|
||||
authorImage: "/avatar/avatar1.png"
|
||||
authorName: "Neeldhara"
|
||||
---
|
||||
|
||||
# Distributed Computing: Recent Advances
|
||||
|
||||
The field of distributed computing has seen remarkable progress in recent years. This post surveys key results from PODC, DISC, and other major venues.
|
||||
|
||||
## Consensus Protocols
|
||||
|
||||
### Byzantine Agreement in Asynchronous Networks
|
||||
|
||||
A breakthrough result achieves optimal resilience with expected constant rounds. The protocol uses cryptographic techniques combined with novel committee selection.
|
||||
|
||||
## Distributed Graph Algorithms
|
||||
|
||||
### Minimum Spanning Tree in the CONGEST Model
|
||||
|
||||
New algorithms achieve near-optimal round complexity for MST construction. The approach uses sophisticated graph decomposition techniques.
|
||||
|
||||
## Local Algorithms
|
||||
|
||||
### The Power of Local Computation
|
||||
|
||||
Recent work characterizes which problems admit constant-time local algorithms. The classification provides a complete picture for bounded-degree graphs.
|
||||
|
||||
## Future Directions
|
||||
|
||||
The intersection of distributed computing with machine learning presents exciting opportunities for both fields.
|
||||
|
|
@ -1,54 +0,0 @@
|
|||
---
|
||||
title: "Git Workflows That Save My Sanity"
|
||||
description: "Automation scripts and Git hooks that eliminate repetitive tasks and prevent common mistakes."
|
||||
pubDate: "Jan 22 2024"
|
||||
image: "https://images.unsplash.com/photo-1556075798-4825dfaaf498?w=400&auto=format&fit=crop&q=60"
|
||||
authorImage: "/avatar/avatar1.png"
|
||||
authorName: "Neeldhara"
|
||||
---
|
||||
|
||||
# Git Workflows That Save My Sanity
|
||||
|
||||
After years of Git mishaps, I've built workflows that prevent disasters and save hours weekly.
|
||||
|
||||
## The Pre-commit Hook That Saves Embarrassment
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
# Check for debugging statements
|
||||
if grep -r "console.log\|debugger\|TODO" --include="*.js" .; then
|
||||
echo "⚠️ Debugging statements found!"
|
||||
exit 1
|
||||
fi
|
||||
```
|
||||
|
||||
## Automatic Branch Naming
|
||||
|
||||
```bash
|
||||
alias feature='git checkout -b feature/$(date +%Y%m%d)-$1'
|
||||
```
|
||||
|
||||
Now `feature "user-auth"` creates `feature/20240122-user-auth`.
|
||||
|
||||
## The Commit Message Template
|
||||
|
||||
```
|
||||
[TYPE] Brief description
|
||||
|
||||
Why:
|
||||
- Context for this change
|
||||
|
||||
What:
|
||||
- Specific changes made
|
||||
|
||||
Testing:
|
||||
- How to verify it works
|
||||
```
|
||||
|
||||
## The Weekly Cleanup Script
|
||||
|
||||
Deletes merged branches, prunes remotes, and garbage collects. Keeps the repo clean and fast.
|
||||
|
||||
## ROI
|
||||
|
||||
These automations save ~5 hours per week and countless prevented mistakes. The time invested in setting them up paid back in days.
|
||||
93
sites/research/src/content/research/homework-help/index.md
Normal file
93
sites/research/src/content/research/homework-help/index.md
Normal file
|
|
@ -0,0 +1,93 @@
|
|||
---
|
||||
title: "How Expensive Can Homework Help Be?"
|
||||
description: "Note This post is based on an expository explanation of iterative compression that I attempted at the Institute Seminar Week in 2010, at IMSc. Tapesh has been struggling lately..."
|
||||
pubDate: "2010-05-01"
|
||||
authorName: "Neeldhara"
|
||||
sourceCategories: ["exposition", "parameterized-algorithms"]
|
||||
sourcePath: "homework-help/index.qmd"
|
||||
---
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> This post is based on an expository explanation of [iterative compression](https://en.wikipedia.org/wiki/Iterative_compression) that I attempted at the Institute Seminar Week in 2010, at IMSc.
|
||||
|
||||
|
||||
Tapesh has been struggling lately with the dire task of undergraduate homework. He has been asked to find a [vertex cover](http://en.wikipedia.org/wiki/Vertex_cover) on 23 vertices - not one more - in a graph that has a thousand vertices. Being the straightforward boy that he is, Tapesh considers writing a program that will try its luck on every possible subset of 23 vertices.
|
||||
|
||||
He then heads over to Wolfram Alpha to check how long it will be before he’s done examining all the ${1000 \choose 23}$ possibilities, assuming (rather liberally) that he has at his disposal a computer that can perform $10^{24}$ operations per second.
|
||||
|
||||
It turns out that he, and more critically, his professor, would be in for a long, long wait. The algorithm would need time proportional to the age of the universe many times over, and this is decidedly depressing, particularly when one’s expected lifespan appears to be determined by the deadline for turning in homework.
|
||||
|
||||
Tapesh now appeals to his very clever cousin, Prodosh, for help.
|
||||
|
||||
Prodosh borrows the monstrous graph, and in short order, points out a vertex cover on 24 vertices, using powers evidently beyond what processors with $10^{24}$ FLOPS can do. Tapesh is thrilled, however…
|
||||
|
||||
“I need to get one with 23, the assignment says not one more —”
|
||||
|
||||
“Time for a smoke,” Prodosh yawns, and then delves into a distracted, pensive mood, with no signs of immediate return.
|
||||
|
||||
Tapesh is torn, but he decides to (gulp) show whatever he has so far - after all, it is progress!
|
||||
|
||||
Predictably, Professor Maganlal displays no signs of being impressed, but he grudgingly admits that Tapesh’s solution (which we will call $T$) is not very far from the correct answer, and points out those vertices in $T$ that happen to partake in the solution that was sought.
|
||||
|
||||
Tapesh is back to the drawing board, but with the distinct feeling that he is now armed with enough information to crack the code himself.
|
||||
|
||||
His solution $T$ is now partitioned into the _good part_ ($T_G$), that is, all the vertices of $T$ that belong to $X$, and the _bad part_ ($T_B$), which are all the vertices that do not belong to X.
|
||||
|
||||
“Aha.”
|
||||
|
||||
Necessarily, all the neighbors of the bad part must belong to $X$!
|
||||
|
||||
He checks, and sure enough, the number of vertices in $T_G$ and $N(T_B)$ is an exact, resounding 23. Also, very fortunately, there are no edges in $T_B$, so he has no trouble swapping $T_B$ for $N(T_B)$ to get to the newer and smaller vertex cover.
|
||||
|
||||
Mission accomplished!
|
||||
|
||||
Now more confident, Tapesh wonders if he could have arrived at $X$ all on his own. Indeed, what would he have done without Pradosh’s help? And without Professor Maganlal giving him that partition?
|
||||
|
||||
Come to think of it, the second question has an easy answer. Tapesh would just try all possible partitions of the solution that Pradosh had given him. He would only have to disregard the partitions that didn’t work… and sooner or later, he would hit the one that his Professor so graciously suggested. This would mean examining $2^{24}$ subsets, a matter of a split second for a personal computer.
|
||||
|
||||
But - can he replicate Pradosh’s magic on his own?
|
||||
|
||||
Tapesh is up into the middle of the night waiting for the brainwave that will make him completely self-dependent, at least in the broad context of finding small vertex covers in large graphs.
|
||||
|
||||
He is still impressed that he has just found a general scheme for taking a vertex cover of size 24 and bringing it down to 23. Wanting to make the most of the only trick he knew, he wondered if he could use it more than once.
|
||||
|
||||
So he looked at the 1,000-vertex monstrosity and contemplated the possibility of working with a manageable chunk first. What if he selected an easy subgraph $H$ for isolated consideration? Surely, if $G$ has a vertex cover of 23 vertices, $H$ has one too. So all he would need is to find a vertex cover on 24 vertices, and he already knew how to squish it to one of size 23.
|
||||
|
||||
What was the easiest chunk that he could work with? One on which finding a vertex cover of size 24 wasn’t hard?
|
||||
|
||||
But of course, a subgraph on 24 vertices would be really easy to deal with!
|
||||
|
||||
The entire graph $H$ would serve as its own vertex cover, would be of size 24 — it couldn’t get easier than that.
|
||||
|
||||
So Tapesh starts by selecting the first 24 vertices that he can find, and applies his squishing strategy to find a vertex cover on 23 vertices.
|
||||
|
||||
What now?
|
||||
|
||||
He gives the remaining 976 vertices a hesitant look.
|
||||
|
||||
Maybe it was time to grow $H$ to include some more vertices? If Tapesh could get $H$ to eventually morph into being all of $G$, he would be done!
|
||||
|
||||
But if he added a whole bunch of new vertices, he would need to do something about finding a vertex cover of size 24 in the bigger $H$ to make progress… but that sounded like work :(
|
||||
|
||||
Maybe, maybe just let in _one more vertex_ into the precious subgraph $H$? Indeed, there is enough room in the vertex cover of size 23 for one more vertex. So $H$ would grow by a single vertex, and so would the vertex cover - and then Tapesh could squish it again!
|
||||
|
||||
And there is no stopping Tapesh from repeating this 975 times more, and each time, the reincarnated $H$ would be one larger than before, and every time he would beat down the vertex cover to one of size 23, till he got to the end.
|
||||
|
||||
But, Tapesh wonders sleepily, wouldn’t this take awfully long?
|
||||
|
||||
The squishing was quick, and now it has to be done 977 times altogether… and even at the lesiurely pace of doing one iteration in one second, you would need less than half an hour before you finished.
|
||||
|
||||
Not too shabby — certainly no waiting for universes to come and go!
|
||||
|
||||
In general, the problem of finding a vertex cover of size $k$ in a graph on $n$ vertices vertices can be done in time:
|
||||
|
||||
$$O((n-k) \cdot 2^{k+1})$$
|
||||
|
||||
following the recipe in this story.
|
||||
|
||||
If this algorithm aborts, unable to find a vertex cover of size $k$, it is because a subgraph did not have a vertex cover of size $k$. Of course, this also means that the entire graph does not have a vertex cover of size $k$ either, so the process makes sense.
|
||||
|
||||
It is important to note that not every problem is designed to fit this bill, for instance, if the next homework assignment demands a vertex cover that is also connected, the iteration procedure, as it stands, might not be accurate when it reports a negative answer.
|
||||
|
||||
The next assignment, therefore, potentially leads to a more demanding adventure.
|
||||
BIN
sites/research/src/content/research/kidney-exchanges/image.jpg
Normal file
BIN
sites/research/src/content/research/kidney-exchanges/image.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 41 KiB |
145
sites/research/src/content/research/kidney-exchanges/index.md
Normal file
145
sites/research/src/content/research/kidney-exchanges/index.md
Normal file
|
|
@ -0,0 +1,145 @@
|
|||
---
|
||||
title: "Kidney Exchanges"
|
||||
description: "This post is based on an excellent (chalk and board!) talk that Palash Dey gave at IIT Gandhinagar today. This is his joint work with Arnab Maiti, to appear as an extended abstr..."
|
||||
pubDate: "2022-02-25"
|
||||
authorName: "Neeldhara"
|
||||
sourceCategories: ["talk", "exposition"]
|
||||
sourcePath: "kidney-exchanges/index.qmd"
|
||||
---
|
||||
|
||||
This post is based on an excellent (chalk and board!) talk that [Palash Dey](https://cse.iitkgp.ac.in/~palash/) gave at IIT Gandhinagar today. This is his joint work with [Arnab Maiti](https://sites.google.com/view/arnab-maiti/home), to appear as an [extended abstract](https://aamas2022-conference.auckland.ac.nz/accepted/extended-abstracts/) at [AAMAS 2022](https://aamas2022-conference.auckland.ac.nz/) ([preprint here](https://arxiv.org/pdf/2112.10250.pdf)).
|
||||
|
||||
|
||||
## Background
|
||||
|
||||
[Kidney paired donation](https://en.wikipedia.org/wiki/Kidney_paired_donation) or *paired exchange* allows donors to donate their kidneys to compatible patients with the understanding that their patients receive medically compatible kidneys in turn. The central problem in this setting is the *clearing problem —* which involves matching patients to donors in such a way that a maximum number of patients receive compatible kidneys. We introduce a directed graph as a convenient abstraction for this question, where:
|
||||
|
||||
- each node $v_i = (P_i,D_i)$ represents a patient-donor pair, and
|
||||
- we introduce a *directed* edge $v_i → v_j$ if the kidney of the donor $D_i$ is compatible with the patient $P_j$.
|
||||
|
||||
Observe that a cycle in this directed graph naturally represents a sequence of feasible exchanges within the cycle. For example, imagine that we have a three-cycle with the edges:
|
||||
|
||||
$(P_2,D_2) → (P_5,D_5) → (P_7,D_7) → (P_2,D_2)$
|
||||
|
||||
Then we have the following compatible donations:
|
||||
|
||||
- $P_5$ is assigned the kidney of donor $D_2$
|
||||
- $P_7$ is assigned the kidney of donor $D_5$
|
||||
- $P_2$ is assigned the kidney of donor $D_7$
|
||||
|
||||
This accounts for all the patients and donors involved in this cycle and motivates the following question:
|
||||
|
||||
> Given a directed graph, what is the largest number of vertices that can be covered by a disjoint union of cycles?
|
||||
|
||||
While a positive answer to this question will “resolve” all the needs in the system, consider that exchanges along a cycle of length $\ell$ involve $\ell$ simultaneous operations to mitigate the risks involved with donors potentially backing out of the exchange agreements.
|
||||
|
||||
This motivates the following refinement of the previously posed question:
|
||||
|
||||
> Given a directed graph, what is the largest number of vertices that can be covered by a disjoint union of cycles, where each cycle is of length $\ell$ or less?
|
||||
|
||||
If the exchanges are restricted to swaps, that is, $\ell = 2$, the problem reduces to finding a maximum matching. However, the problem is NP-complete already when $\ell = 3$ (see Theorem 1, [Abraham, Blum, and Sandholm](https://www.cs.cmu.edu/~sandholm/kidneyExchange.EC07.withGrantInfo.pdf); EC 2007).
|
||||
|
||||
We now generalize the model a little further to account for the presence of *[altruistic donors](https://en.wikipedia.org/wiki/Organ_transplantation#Good_Samaritan),* who are donors without a matching patient and are willing to donate to any compatible patient. To account for the presence of such donors, we modify our graph representation as follows:
|
||||
|
||||
- Each node either:
|
||||
- represents a patient-donor pair $v_i = (P_i,D_i)$ or
|
||||
- represents an altruistic donor $u_k = D_k^\star$
|
||||
- The edges are as follows:
|
||||
- We have a *directed* edge $v_i → v_j$ if the kidney of the donor $D_i$ is compatible with the patient $P_j$.
|
||||
- We have a *directed* edge $u_k → v_j$ if the kidney of the donor $D_k^\star$ is compatible with the patient $P_j$.
|
||||
|
||||
In this setting, note that we can also facilitate exchanges along *paths* as well, with the paths starting at the altruistic donors. For instance, if we have the path:
|
||||
|
||||
$(D_7^\star) → (P_2,D_2) → (P_5,D_5) → (P_7,D_7) → (P_3,D_3)$
|
||||
|
||||
Then we have the following compatible donations:
|
||||
|
||||
- $P_2$ is assigned the kidney of donor $D_7^\star$
|
||||
- $P_5$ is assigned the kidney of donor $D_2$
|
||||
- $P_7$ is assigned the kidney of donor $D_5$
|
||||
- $P_3$ is assigned the kidney of donor $D_7$
|
||||
|
||||
Note that in this situation, the donor $D_3$ is relieved from any obligation to donate to a patient. We now update our problem statement to reflect the presence of altrustic donors and the possibility of facilitating exchanges along paths:
|
||||
|
||||
> 🤝 Optimal Kidney Exchange Along Short Paths and Cycles
|
||||
>
|
||||
> **Input.** A directed graph $G = (V,E)$, where $\mathcal{A} \subseteq V$ are source vertices; and positive integers $\ell_p$, $\ell_c$ and $t$.
|
||||
>
|
||||
> **Output.** Yes if and only if there is a collection of cycles of length at most $\ell_c$ each and a collection of paths of length at most $\ell_p$ each such that the cycles and paths altogether covers $t$ nodes outside of $\mathcal{A}$.
|
||||
|
||||
|
||||
The main claim in the context of this problem is the following:
|
||||
|
||||
There exists a $\mathcal{O}(2^{\mathcal{O}(t)} \cdot \text{poly}(n))$ that decides Optimal Kidney Exchange Along Short Paths and Cycles.
|
||||
|
||||
## An Algorithm for OKE
|
||||
|
||||
Here’s a high-level description of the algorithm (perhaps best approached with some prior familiarity with [color coding](https://www.youtube.com/watch?v=_4opS8Hpvc0&list=PLEAYkSg4uSQ2jI2x3Bwm711Tmjj-E25Et&index=19)). To begin with, notice that we may assume without loss of generality that $\ell_p \leq t$ and $\ell_c \leq t$ — intuitively, this is because if the permitted cycle and path lengths are longer than the number of patients we hope to cover, then we can simply look for cycles or paths of length $t$ directly to begin with — if we find one, then we are done, and if none exist, then we “might as well” set $\ell_p$ and/or $\ell_c$ to $t-1$.
|
||||
|
||||
Now, if there is a solution that accounts for at least $t$ patients, there is also one that involves at most $2t$ patients and in particular, also at most $t$ paths. Such a solution engages at most $t$ nodes from $\mathcal{A}$. Therefore, if there is a solution, then there is one that spans $s \leq 3t$ vertices.
|
||||
|
||||
As is standard for color coding, we guess the correct value of $s$ and randomly partition the vertex set $V$ into $s$ parts. The hope is that each part contains exactly one vertex from the solution (this is a so-called “colorful solution”). The probability that a random partition is a lucky one is $(3t)!/(3t)^{(3t)}$, which turns out to be at least $e^{-3t}$. This implies that $e^{3t}$ repetitions ensure a constant success probability.
|
||||
|
||||
Given that the partition is indeed a lucky one, we can recover the solution using the following dynamic programming semantics. For $C \subseteq [3t]$ and $i \in [3t]$, let $D[C,i]$ be **TRUE** if and only if there is a colorful solution spanning at least $i$ nodes outside $\mathcal{A}$ in $G[V_C]$, where $V_C$ denotes the subset of vertices colored with colors from $C$.
|
||||
|
||||
The recurrence is based on isolating one path or cycle by guessing the set of colors involved in said component and using table lookups to figure out if this can be extended to a full solution.
|
||||
|
||||
In particular, we have:
|
||||
|
||||
$D[C,i] = P[C,i] \lor Q[C,i]$,
|
||||
|
||||
where
|
||||
|
||||
$P[C,i] = \lor_{(B,j): B \subseteq C \text{ and } 1 \leq j \leq \ell_c} [D[C \setminus B, i - j] \land f(B,j)]$
|
||||
|
||||
and
|
||||
|
||||
$Q[C,i] = \lor_{(B,j): B \subseteq C \text{ and } 1 \leq j \leq \ell_p} [D[C \setminus B, i - j] \land g(B,j)]$.
|
||||
|
||||
Here, we have that:
|
||||
|
||||
- $f(B,j)$ is **TRUE** if and only if the vertices of $B$ can be covered with a cycle of length $j$.
|
||||
- $g(B,j)$ is **TRUE** if and only if the vertices of $B$ can be covered with a path of length $j$.
|
||||
|
||||
The truth values of $f(B,j)$ and $g(B,j)$ can be determined directly using standard approaches to finding colorful paths and cycles in time that is single-exponential in $j$.
|
||||
|
||||
To claim the overall running time, note that:
|
||||
|
||||
- The total number of entries in the table is $2^{O(t)} \cdot t$ and each entry can be computed in time $\mathcal{O}^{}\left(2^{\mathcal{O}(\ell)}\right).$
|
||||
- Therefore, the algorithm outputs the correct decision in $\mathcal{O}^{}\left(2^{\mathcal{O}(t)}\right)$ time with probability at least $e^{-3t}$,
|
||||
- By repeating $\mathcal{O}\left(e^{3 t}\right)$ times, we find the correct decision with constant success probability.
|
||||
- The overall running time is $\mathcal{O}^{*}\left(2^{\mathcal{O}(t)}\right)$.
|
||||
|
||||
## Other Results
|
||||
|
||||
As Palash mentioned in his talk, the preprint has more, and here are some highlights of the other results that were established:
|
||||
|
||||
1. Optimal Kidney Exchange Along Short Paths and Cycles is [FPT](https://en.wikipedia.org/wiki/Parameterized_complexity#FPT) also when parameterized by the treewidth of the underlying graph $+$ maximum length of path $\left(\ell_{p}\right)+$ maximum length of cycle allowed $\left(\ell_{c}\right)$ and the number of vertex types[^1] when $\ell_{p} \leq \ell_{c}$.
|
||||
|
||||
2. A [Monadic second-order formula](https://en.wikipedia.org/wiki/Monadic_second-order_logic) for the problem is also presented, where the length of the formula is upper bounded by a function of $\ell=\max \left\{\ell{c}, \ell_{p}\right\}$.
|
||||
|
||||
3. The problem admits a [polynomial kernel](https://en.wikipedia.org/wiki/Kernelization) with respect to the number of patients receiving kidneys $+$ maximum degree when $\max \left\{\ell_{p}, \ell_{c}\right\}$ is a constant.
|
||||
|
||||
4. On the other hand, the problem does *not* admit any polynomial kernel parameterized by the number of patients receiving kidneys $+$ maximum degree $+\max \left\{\ell_{p}, \ell_{c}\right\}$ (under standard assumptions).
|
||||
|
||||
5. A $\left(16/9+\epsilon\right)$-approximation algorithm is presented for the case when only cycles of length at most 3 are allowed and no paths are allowed.
|
||||
|
||||
[^1]: [Dickerson, Manlove, Plaut, Sandholm, and Trimble.](https://arxiv.org/pdf/1606.01623.pdf) (EC 2016) introduced the notion of “vertex type" and showed its usefulness as a graph parameter in real-world kidney exchange instances. Two vertices is said to have the same vertex type if their neighbourhoods are the same.
|
||||
|
||||
## Pointers
|
||||
|
||||
|
||||
Some discussion that came up during the talk:
|
||||
|
||||
1. The so-called dual parameter $(n-t)$, which in this case corresponds to the number of patients who were “left out”, is perhaps a natural parameter to study as well.
|
||||
|
||||
2. The notion of a patient without a matching donor seems complementary notion of altrusitic donors. Such patients would be the last vertices on paths kickstarted by altruistic donors. However, this notion likely does not manifest in practice.
|
||||
|
||||
If you’d like to dig deeper, be sure to [check out the preprint](https://arxiv.org/pdf/2112.10250.pdf)! A few additional pointers:
|
||||
|
||||
1. This work closely builds on the works of [Xiao and Wang](https://www.ijcai.org/proceedings/2018/77) (IJCAI, 2018), who proposed an exact algorithm with running time $\mathcal{O}(2^nn^3)$ where $n$ is the number of vertices in the underlying graph. They also show an FPT algorithm parameterized by the number of vertex types if we do not have any restriction on the length of cycles and chains.
|
||||
|
||||
2. [Lin, Wang, Feng, and Fu](https://www.mdpi.com/1999-4893/12/2/50) (Algorithms, 2019) studied the version of the kidney exchange
|
||||
problem which allows only cycles and developed a randomized parameterized algorithm with respect to the parameter being (number of patients receiving a kidney, maximum allowed length of any cycle).
|
||||
|
||||
3. Alvin E. Roth was awarded the Nobel Prize in Economic Sciences 2012 (along with Lloyd S. Shapley) in part for his pioneering contributions to the theory and practice of kidney exchange — his [biographical account](https://www.nobelprize.org/prizes/economic-sciences/2012/roth/biographical/) indicates that he had started anticipating the problem even before it emerged as a legal practice. His [talk at Simons Institute](https://www.youtube.com/watch?v=exB1O3pTf7E) surveys “fifteen years of history” in the kidney exchange problem, with an emphasis on the game-theoretic aspects. (h/t: [Rohit’s blog](https://csatravelblog.wordpress.com/2016/04/05/rohit-vaish-cmu-visit/) on this topic.)
|
||||
|
|
@ -1,41 +0,0 @@
|
|||
---
|
||||
title: "Academic Writing with Obsidian and Pandoc"
|
||||
description: "A complete workflow for academic papers - from notes to publication-ready PDFs."
|
||||
pubDate: "Feb 12 2024"
|
||||
image: "https://images.unsplash.com/photo-1456324504439-367cee3b3c32?w=400&auto=format&fit=crop&q=60"
|
||||
authorImage: "/avatar/avatar1.png"
|
||||
authorName: "Neeldhara"
|
||||
---
|
||||
|
||||
# Academic Writing with Obsidian and Pandoc
|
||||
|
||||
Transform your scattered research notes into beautiful academic papers with this workflow.
|
||||
|
||||
## The Setup
|
||||
|
||||
- **Obsidian**: For note-taking and knowledge management
|
||||
- **Pandoc**: For document conversion
|
||||
- **LaTeX**: For typesetting
|
||||
- **Zotero**: For reference management
|
||||
|
||||
## The Magic Command
|
||||
|
||||
```bash
|
||||
pandoc paper.md \
|
||||
--filter pandoc-citeproc \
|
||||
--bibliography=refs.bib \
|
||||
--template=academic.tex \
|
||||
-o paper.pdf
|
||||
```
|
||||
|
||||
## Templates for Everything
|
||||
|
||||
From conference submissions to journal articles, templates ensure consistency and save time.
|
||||
|
||||
## Version Control Integration
|
||||
|
||||
Git + Obsidian = perfect history of your thinking process.
|
||||
|
||||
## The Result
|
||||
|
||||
From messy notes to camera-ready PDF in minutes, not hours.
|
||||
|
|
@ -1,31 +0,0 @@
|
|||
---
|
||||
title: "Understanding the Latest Approximation Algorithm for Set Cover"
|
||||
description: "A detailed walkthrough of a breakthrough approximation algorithm with practical implications."
|
||||
pubDate: "Feb 15 2024"
|
||||
image: "https://images.unsplash.com/photo-1516321318423-f06f85e504b3?w=400&auto=format&fit=crop&q=60"
|
||||
authorImage: "/avatar/avatar1.png"
|
||||
authorName: "Neeldhara"
|
||||
---
|
||||
|
||||
# Understanding the Latest Approximation Algorithm for Set Cover
|
||||
|
||||
A recent paper achieves a breakthrough in the Set Cover problem, improving the approximation ratio while maintaining practical runtime.
|
||||
|
||||
## The Algorithm
|
||||
|
||||
The approach combines local search with a clever LP rounding scheme. The dual interpretation provides beautiful geometric insights.
|
||||
|
||||
## Why This Matters
|
||||
|
||||
Set Cover appears everywhere - from facility location to machine learning feature selection. This improvement has immediate practical impact.
|
||||
|
||||
## Implementation Details
|
||||
|
||||
The paper's theoretical elegance translates surprisingly well to practice. Key optimizations include:
|
||||
- Lazy evaluation of set intersections
|
||||
- Incremental updates to the LP solution
|
||||
- Smart caching strategies
|
||||
|
||||
## Future Work
|
||||
|
||||
The techniques here might extend to weighted variants and online settings.
|
||||
|
|
@ -1,31 +0,0 @@
|
|||
---
|
||||
title: "Deep Dive: A New Approach to Graph Decomposition"
|
||||
description: "An in-depth analysis of a recent paper on hierarchical graph decomposition and its implications."
|
||||
pubDate: "Jan 20 2024"
|
||||
image: "https://images.unsplash.com/photo-1507003211169-0a1dd7228f2d?w=400&auto=format&fit=crop&q=60"
|
||||
authorImage: "/avatar/avatar1.png"
|
||||
authorName: "Neeldhara"
|
||||
---
|
||||
|
||||
# Deep Dive: A New Approach to Graph Decomposition
|
||||
|
||||
This paper introduces a novel framework for decomposing graphs into hierarchical structures that preserve important properties while enabling efficient algorithms.
|
||||
|
||||
## The Main Result
|
||||
|
||||
The authors prove that every graph with treewidth k can be decomposed into a tree of bags where each bag has size at most k+1. While this sounds like the definition of tree decomposition, the clever twist is in how they construct it.
|
||||
|
||||
## Technical Innovation
|
||||
|
||||
The key insight is using a charging scheme that amortizes the cost of decomposition across multiple levels. This leads to an O(n log n) algorithm, improving on the previous O(n²) bound.
|
||||
|
||||
## Implications
|
||||
|
||||
This work opens new avenues for:
|
||||
- Parallel algorithms on bounded treewidth graphs
|
||||
- Approximation algorithms for NP-hard problems
|
||||
- Dynamic programming optimizations
|
||||
|
||||
## Open Questions
|
||||
|
||||
The paper leaves several intriguing questions open, particularly about the optimality of their charging scheme.
|
||||
|
|
@ -1,26 +0,0 @@
|
|||
---
|
||||
title: "Quantum Computing Meets Classical Algorithms"
|
||||
description: "Exploring the intersection of quantum and classical algorithmic techniques from recent conferences."
|
||||
pubDate: "Mar 10 2024"
|
||||
image: "https://images.unsplash.com/photo-1635070041078-e363dbe005cb?w=400&auto=format&fit=crop&q=60"
|
||||
authorImage: "/avatar/avatar1.png"
|
||||
authorName: "Neeldhara"
|
||||
---
|
||||
|
||||
# Quantum Computing Meets Classical Algorithms
|
||||
|
||||
Recent conferences have showcased fascinating connections between quantum and classical computing paradigms.
|
||||
|
||||
## Quantum Speedups for Graph Problems
|
||||
|
||||
### Quantum Walks on Graphs
|
||||
|
||||
New quantum algorithms achieve quadratic speedups for certain graph traversal problems. The techniques combine amplitude amplification with clever graph representations.
|
||||
|
||||
## Classical Simulation of Quantum Algorithms
|
||||
|
||||
Surprisingly, several "quantum" algorithms have inspired better classical algorithms. This cross-pollination has led to improvements in both fields.
|
||||
|
||||
## The Future is Hybrid
|
||||
|
||||
The most practical near-term applications combine quantum and classical processing, leveraging the strengths of each paradigm.
|
||||
|
|
@ -1,32 +0,0 @@
|
|||
---
|
||||
title: "ZSA Moonlander: Ergonomic Keyboard for Coders"
|
||||
description: "Six months with a split ergonomic mechanical keyboard - the good, the bad, and the RSI relief."
|
||||
pubDate: "Feb 20 2024"
|
||||
image: "https://images.unsplash.com/photo-1587829741301-dc798b83add3?w=400&auto=format&fit=crop&q=60"
|
||||
authorImage: "/avatar/avatar1.png"
|
||||
authorName: "Neeldhara"
|
||||
---
|
||||
|
||||
# ZSA Moonlander: Ergonomic Keyboard for Coders
|
||||
|
||||
After years of wrist pain, I took the plunge into ergonomic mechanical keyboards.
|
||||
|
||||
## The Learning Curve
|
||||
|
||||
Week 1: 20 WPM and questioning life choices
|
||||
Week 2: 40 WPM and seeing the light
|
||||
Month 2: Back to 80 WPM with no wrist pain
|
||||
|
||||
## The Good
|
||||
|
||||
- Columnar layout makes sense once muscle memory adapts
|
||||
- Thumb clusters are game-changers for shortcuts
|
||||
- The configurability is endless (perhaps too endless)
|
||||
|
||||
## The Investment
|
||||
|
||||
At $365, it's expensive. But compared to physical therapy or career-limiting injury? Bargain.
|
||||
|
||||
## Who Should Buy This?
|
||||
|
||||
If you type for a living and feel any discomfort, don't wait. Your future self will thank you.
|
||||
|
|
@ -1,35 +0,0 @@
|
|||
---
|
||||
title: "Obsidian: A Year Later"
|
||||
description: "Reflections on using Obsidian for research notes, teaching materials, and personal knowledge management."
|
||||
pubDate: "Jan 15 2024"
|
||||
image: "https://images.unsplash.com/photo-1484480974693-6ca0a78fb36b?w=400&auto=format&fit=crop&q=60"
|
||||
authorImage: "/avatar/avatar1.png"
|
||||
authorName: "Neeldhara"
|
||||
---
|
||||
|
||||
# Obsidian: A Year Later
|
||||
|
||||
After a year of daily use, Obsidian has transformed how I think about knowledge management.
|
||||
|
||||
## What Works Brilliantly
|
||||
|
||||
### The Graph View
|
||||
Seeing connections between ideas visually has led to unexpected research insights. The graph isn't just pretty - it's functional.
|
||||
|
||||
### Plugin Ecosystem
|
||||
The community plugins are incredible. Dataview turns your notes into a database. Templater automates repetitive tasks.
|
||||
|
||||
### Local Storage
|
||||
Your notes are just markdown files. No vendor lock-in, complete control, and peace of mind.
|
||||
|
||||
## Pain Points
|
||||
|
||||
### Mobile Experience
|
||||
While functional, the mobile app lacks the fluidity of the desktop version. Syncing can occasionally hiccup.
|
||||
|
||||
### Learning Curve
|
||||
The flexibility means complexity. New users might feel overwhelmed by options.
|
||||
|
||||
## The Verdict
|
||||
|
||||
For academics and researchers, Obsidian is transformative. The investment in learning pays dividends in productivity and insight.
|
||||
|
|
@ -1,31 +0,0 @@
|
|||
---
|
||||
title: "Creating Art with Claude: A Collaborative Journey"
|
||||
description: "Exploring creative possibilities through conversations with AI - from generative art to interactive poetry."
|
||||
pubDate: "Jan 18 2024"
|
||||
image: "https://images.unsplash.com/photo-1558591710-4b4a1ae0f04d?w=400&auto=format&fit=crop&q=60"
|
||||
authorImage: "/avatar/avatar1.png"
|
||||
authorName: "Neeldhara"
|
||||
---
|
||||
|
||||
# Creating Art with Claude: A Collaborative Journey
|
||||
|
||||
What happens when you treat AI as a creative collaborator rather than just a tool?
|
||||
|
||||
## The Experiment
|
||||
|
||||
I asked Claude to help design a generative art algorithm based on mathematical fractals. The conversation evolved into something unexpected.
|
||||
|
||||
## The Process
|
||||
|
||||
**Me**: "Let's create something beautiful with math."
|
||||
**Claude**: "How about we visualize the Collatz conjecture as a tree?"
|
||||
|
||||
What followed was a two-hour deep dive into number theory, aesthetics, and the nature of creativity itself.
|
||||
|
||||
## The Result
|
||||
|
||||
Not just code, but a philosophical exploration of pattern, meaning, and the intersection of human and artificial creativity.
|
||||
|
||||
## Reflection
|
||||
|
||||
AI doesn't replace human creativity - it amplifies it in unexpected directions. The key is approaching it as a dialogue, not a command.
|
||||
|
|
@ -1,28 +0,0 @@
|
|||
---
|
||||
title: "Philosophical Dialogues with LLMs: On Consciousness and Computation"
|
||||
description: "Deep conversations with AI about the nature of consciousness, free will, and what it means to understand."
|
||||
pubDate: "Feb 28 2024"
|
||||
image: "https://images.unsplash.com/photo-1507003211169-0a1dd7228f2d?w=400&auto=format&fit=crop&q=60"
|
||||
authorImage: "/avatar/avatar1.png"
|
||||
authorName: "Neeldhara"
|
||||
---
|
||||
|
||||
# Philosophical Dialogues with LLMs: On Consciousness and Computation
|
||||
|
||||
Can a sufficiently complex computation be conscious? I asked an AI, and the conversation surprised me.
|
||||
|
||||
## The Question
|
||||
|
||||
"Do you experience anything when you process text, or is it just computation?"
|
||||
|
||||
## The Response That Made Me Think
|
||||
|
||||
The AI didn't claim consciousness, but asked: "What's the difference between your neurons firing and my weights activating? Both are physical processes. Where does experience emerge?"
|
||||
|
||||
## Going Deeper
|
||||
|
||||
We explored qualia, the Chinese Room argument, and integrated information theory. Not to find answers, but to refine questions.
|
||||
|
||||
## The Irony
|
||||
|
||||
Discussing consciousness with something that might not have it - or might not know if it has it - mirrors our own uncertainty about consciousness itself.
|
||||
|
|
@ -9,7 +9,7 @@ import { SITE_TITLE } from '@/consts';
|
|||
export async function getStaticPaths() {
|
||||
const posts = await getCollection(ACTIVE_BLOG_SITE.key);
|
||||
return posts.map((post) => ({
|
||||
params: { slug: post.id },
|
||||
params: { slug: post.id.replace(/\/index$/, '') },
|
||||
props: post,
|
||||
}));
|
||||
}
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ export async function GET(context) {
|
|||
site: context.site,
|
||||
items: posts.map((post) => ({
|
||||
...post.data,
|
||||
link: `/${post.id}/`,
|
||||
link: `/${post.id.replace(/\/index$/, "")}/`,
|
||||
})),
|
||||
});
|
||||
}
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue