Speaker 1: Imagine you're managing a nationwide campaign, right, Okay, you have
Speaker 1: this massive database, like a million potential voters, but you
Speaker 1: only have the time and the budget to knock on
Speaker 1: I don't know, ten thousand.
Speaker 2: Doors, right, extremely limited resources.
Speaker 1: Exactly, So how do you mathematically guarantee that you're knocking
Speaker 1: on the exact right ones? Or or take a massive
Speaker 1: retailer like Target.
Speaker 2: Oh yeah, the famous pregnancy example.
Speaker 1: Yes, how do they know a customer is pregnant and
Speaker 1: can start sending them coupons for baby clothes before that
Speaker 1: person has even told their own family.
Speaker 2: I mean it sounds like corporate espionage or literal mind reading,
Speaker 2: it really does, But it's actually just recognizing patterns in
Speaker 2: you know, seemingly mundane data like unscented lotion purchases suddenly
Speaker 2: correlating with a second trimester, or, in the case of
Speaker 2: the twenty twelve Obama campaign, finding the exact combination of
Speaker 2: demographic data and pass voting behavior that signals that a
Speaker 2: person just needs a very slight nudge to actually show
Speaker 2: up at the bulls, Which.
Speaker 1: Is wild, right, because we see the end results of
Speaker 1: these models every single day. You tap a glossy button
Speaker 1: on a smartphone, a little progress bar spins, and an
Speaker 1: app confidently tells you who to date, what to buy,
Speaker 1: what movie to watch next.
Speaker 2: Yeah, it's curated reality exactly.
Speaker 1: There's this expectation of seamless magic. We like things to
Speaker 1: be hidden behind a sleek interface.
Speaker 2: Which is exactly why so many people get a massive
Speaker 2: shock when they actually step into the discipline of data
Speaker 2: science itself. Oh for sure, because that glossy interface it's
Speaker 2: entirely stripped away. You are suddenly looking at a landscape
Speaker 2: that is raw, messy and honestly totally unforgiving. Yeah, and
Speaker 2: a concerning number of practitioners today are they're overly reliant
Speaker 2: on shiny, prepackaged libraries.
Speaker 1: The black boxes.
Speaker 2: Exactly. They plug data into a black box, Yeah, and
Speaker 2: they just trust whatever comes out, without having any idea
Speaker 2: how the underlying engine actually functions.
Speaker 1: Well, that is the exact trap we are dismantling today.
Speaker 1: Welcome to our deep dive into Jowel gris Verus book
Speaker 1: Data Science from Scratch First Principles with Python.
Speaker 2: It's a fantastic text.
Speaker 1: It really is. And our mission for this deep dive
Speaker 1: is to basically throw out the automated frameworks. No massive
Speaker 1: black box libraries doing the heavy lifting for us. We
Speaker 1: are going to look at the raw.
Speaker 2: Mechanics right down to the studs.
Speaker 1: Exactly. By the end of our conversation, you are going
Speaker 1: to understand how fundamental algorithms process information. We're moving from
Speaker 1: basic data structures into the mechanics of visualization, all the
Speaker 1: way down to the bare metal of linear algebra.
Speaker 2: Because data science isn't about memorizing syntax to import a
Speaker 2: machine learning library, right, It's about answering questions that no
Speaker 2: one has even thought to ask yet. Yeah, and those
Speaker 2: answers are buried in this massive glut of everyday information.
Speaker 2: You can only extract them if you fundamentally understand the
Speaker 2: tools you're holding.
Speaker 1: Okay, let's unpack this because before we look at a
Speaker 1: single line of actual code, the book sets up this
Speaker 1: brilliant hypothetical sandbox for us to play in the startup. Yeah,
Speaker 1: you've just been hired a data science sstor, which is
Speaker 1: a fictional social network built exclusively for data scientists.
Speaker 2: I mean, it's a great framing device. So on your
Speaker 2: very first day, the VP of networking drops a massive
Speaker 2: data dump on your desk as they do, right, and
Speaker 2: gives you your first assignment identify the key connectors among
Speaker 2: the users. But this data isn't sitting in some neat,
Speaker 2: easily searchable database.
Speaker 1: No it's not.
Speaker 2: It is raw Python data structures. You get a list
Speaker 2: of users where each person is represented by just a
Speaker 2: simple dictionary.
Speaker 1: Right. So I'm looking at this list in the book,
Speaker 1: and it's just basic pairs. User ID zero is named hero,
Speaker 1: User ID one is done, just raw text, yep. And
Speaker 1: alongside that you get the friendship data. But it's not
Speaker 1: a visual web of connections. It's just a list of
Speaker 1: tuples exactly.
Speaker 2: And a tuple is just an immutable or unchangeable sequence
Speaker 2: of elements. In this case, it's just a pair of IDs. Okay,
Speaker 2: So if you're as of friends with done, the data
Speaker 2: just shows a tuple parenthesis zero coma one parenthesis. That
Speaker 2: is your entire social graph. It's entirely abstract.
Speaker 1: So if I'm tasked with finding the most important person
Speaker 1: in this abstract graph, my immediate instinct is to just
Speaker 1: I don't account who has the most tupuls with their
Speaker 1: ID in it, just do a raw headcount.
Speaker 2: And that is the concept of degree centrality. You're simply
Speaker 2: asking who has the most direct connections, you sum them up,
Speaker 2: sort the list, and whoever is at the top is
Speaker 2: theoretically your most central figure.
Speaker 1: But I'm looking at that and thinking that's just high
Speaker 1: school popularity pretty much. Yeah, it's measuring who sits with
Speaker 1: the most people at lunch. But does having a high
Speaker 1: raw headcount actually make you the most critical node in
Speaker 1: a flow of information?
Speaker 2: It rarely does, and Grease highlights this exact flaw by
Speaker 2: introducing an anomaly in the data Sciencestor.
Speaker 1: Network right the Dune and Thor situation exactly.
Speaker 2: So, if you look at the raw numbers, the user Done,
Speaker 2: who is ID one, has three direct friends, but another
Speaker 2: user Thor ID four, only has two. So if you
Speaker 2: blindly run a degree centrality algorithm, it ranks Done as
Speaker 2: more important than Thor.
Speaker 1: Wait, but if I actually map out these connections visually,
Speaker 1: Thor is sitting dead in the middle of a chasm.
Speaker 1: He's the only link bridging two completely separate, isolated clusters
Speaker 1: of users.
Speaker 2: Precisely, if Done leads the network, his three friends can
Speaker 2: still talk to each other through other paths WHOA. But
Speaker 2: if Thor leads a network, it literally breaks in half.
Speaker 2: The flow of information stops entirely. Thor is a bottleneck. Intuitively,
Speaker 2: that makes him far more critical to the network than
Speaker 2: Done despite having fewer direct friends.
Speaker 1: So if I just used a prepackaged function that calculates popularity,
Speaker 1: I would have handed my boss the wrong name on
Speaker 1: day one.
Speaker 2: You would have And that proves why you can't blindly
Speaker 2: trust a default metric. You have to look at the
Speaker 2: structure of the data. You have to build functions that
Speaker 2: look at say mutual friends or shared interest. And to
Speaker 2: build those functions you have to use the language, in
Speaker 2: this case Python, But you don't just write Python. The
Speaker 2: book Stress is right pythonic.
Speaker 1: Code, which is a whole different mindset. And I noticed
Speaker 1: the book adhees specifically to Python two point seven, which,
Speaker 1: while it introduces some serious quirks into how we handle data.
Speaker 2: Oh the division quirk.
Speaker 1: Yes, if I open Python two point seven and type
Speaker 1: five divided by two, it doesn't give me two point five.
Speaker 1: It spits out two.
Speaker 2: Because of how it handles integer division, it truncates the
Speaker 2: decimal entirely unless you explicitly tell the environment to use
Speaker 2: floating point math.
Speaker 1: Which seems so counterintuitive.
Speaker 2: It is you literally have to type from future import
Speaker 2: division to make basic math behave the way human expects
Speaker 2: it to. It's I mean, it's a harsh reminder that
Speaker 2: the underlying environment shapes the reality of your data.
Speaker 1: That feels incredibly rigid, but honestly not as rigid as
Speaker 1: white space formatting. Oh yeah, I'm used to seeing code
Speaker 1: wrapped in curly braces or having explicit end statements, but
Speaker 1: Python relies entirely on indentation.
Speaker 2: Right. It forces you to write readable code. There's no
Speaker 2: visual clutter. But the trade off is that it's strictly enforced.
Speaker 1: Meaning if you mess up a space.
Speaker 2: If you're copying and pasting a block of logic to analyze, say,
Speaker 2: user salaries, and you have one accental space, the entire
Speaker 2: script crashes. It forces discipline, but the reward for that
Speaker 2: discipline is access to incredibly elegant tools right out of
Speaker 2: the box, things like default, picked encounter.
Speaker 1: Okay, let's start there, because I want to understand the
Speaker 1: mechanics of why these are so vital. Let's say my
Speaker 1: next task at data Sciencestor is to figure out what
Speaker 1: our users care.
Speaker 2: About, Okay, finding their interests?
Speaker 1: Right, I want to count how many times specific words
Speaker 1: show up in their profile bios words like hadoop or
Speaker 1: psychic learn. If I use a standard Python dictionary to
Speaker 1: keep a running tally, how does that actually execute?
Speaker 2: It's incredibly clunky. A standard dictionary throws a literal error
Speaker 2: if you try to modify a key that doesn't exist yet.
Speaker 2: Oh really yeah, So as your program reads the word
Speaker 2: hadoop for the very first time, you have to write
Speaker 2: logic that says, check if hadoop is in the dictionary.
Speaker 2: It isn't. Okay, create the key hadoop and set the
Speaker 2: value to one.
Speaker 1: That sounds exhausting.
Speaker 2: It is. Oh look, the next word is hadoop again.
Speaker 2: Check if it exists, yes, okay, increment the value by one.
Speaker 1: You are writing multiple lines of repetitive safety checks just
Speaker 1: to count words. That seems like a massive waste of
Speaker 1: processing time and just human effort.
Speaker 2: It totally is enter default dict. It intercepts that missing
Speaker 2: key error. If you ask it to modify hodup and
Speaker 2: a dupe isn't there, It gracefully creates it on the fly,
Speaker 2: assigns it a default value like zero, and then lets
Speaker 2: your code increment it. It removes all the boilerplate safety
Speaker 2: checks that.
Speaker 1: Is so much cleaner, and then counter takes that a
Speaker 1: step further.
Speaker 2: Right, Yes, counter is a subclass designed specifically for this
Speaker 2: exact problem. You just handed a raw list of a
Speaker 2: million words, and in one single line of code, it
Speaker 2: absorbs the list and spits out a map dictionary of frequency.
Speaker 1: It transforms a multi step, error prone loop into a
Speaker 1: single elegant command exactly. Oh wait, you just casually mentioned
Speaker 1: a list of a million words. When we're dealing with
Speaker 1: data at scale, moving a million items around has to
Speaker 1: cause problems, huge problems. Like if I try to assign
Speaker 1: a list of a million numbers to a variable, Python
Speaker 1: is literally allocating memory for all one million of those
Speaker 1: numbers instantly, right correct, And if.
Speaker 2: Your data set is large enough, your machine will completely choke.
Speaker 2: It runs out a RAM and crashes. This is where
Speaker 2: the book introduces the concept of lazy.
Speaker 1: Evaluation using generators.
Speaker 2: Specifically using generators.
Speaker 1: I always picture this well, it's like watching a movie.
Speaker 1: If I use a standard list, it's like downloading a
Speaker 1: massive four K movie file to my hard drive. I
Speaker 1: can't watch a single second of it until the entire
Speaker 1: one hundred gigabyte file is sitting in my memory.
Speaker 2: That's a perfect analogy, but.
Speaker 1: A generator is like streaming it. I'm just pulling the
Speaker 1: exact frame I need, exactly when I need it, and
Speaker 1: then discarding it to make room for the next frame.
Speaker 2: That is an excellent way to visualize it. A generator
Speaker 2: yields values one at a time. It pauses its state,
Speaker 2: waits for you to ask for the next value, and
Speaker 2: only computes what is strictly necessary in that moment.
Speaker 1: Which is incredibly memory efficient. Extremely Okay, But if streaming
Speaker 1: is so much lighter on my system, why am I
Speaker 1: ever downloading the file? Like? Why wouldn't I use a
Speaker 1: generator for absolutely everything in my data pipeline?
Speaker 2: Ah? Because a generator is ephemeral. You can only iterate
Speaker 2: through it once.
Speaker 1: Wait, really, once I read it, it's just gone.
Speaker 2: Exactly. If you have a massive data set of user
Speaker 2: interactions and you need to loop through it to find
Speaker 2: the average, and then loop through it again to find
Speaker 2: the standard deviation, a generator will be completely exhausted after
Speaker 2: that first pass.
Speaker 1: Oh wow, I didn't realize that.
Speaker 2: Yeah, you would have to recompute the entire stream from
Speaker 2: scratch for the second pass. So the engineering challenge is
Speaker 2: constantly balancing memory efficiency against how many times you actually
Speaker 2: need to interact with that specific data set.
Speaker 1: Okay, all of this, the dictionaries, the generators, it's beautiful logic.
Speaker 1: But all of these elegant Python tools are really just
Speaker 1: for us, the develops. Sure, if I take a default
Speaker 1: dict full of raw frequencies and drop it on the
Speaker 1: VP of networking's desk, their eyes are going to glaze over.
Speaker 1: You have to translate those numbers into a visual space, which.
Speaker 2: Brings us to the visual translation layer matt plotlib.
Speaker 1: The book touches on the standard toolkit, you know, bar
Speaker 1: charts for buckets of discrete data, line charts for continuous trends,
Speaker 1: scatterplots for pairing two variables together to see if they correlate.
Speaker 1: The basics, right, but we don't need to dwell on
Speaker 1: what a line chart is. What's interesting is that the
Speaker 1: book spends a very specific amount of time warning the
Speaker 1: reader about the mechanics of visual deception.
Speaker 2: Yes, the trap of the misleading act axis. Yeah, when
Speaker 2: you're translating raw numbers into a visual space, you are
Speaker 2: essentially creating a narrative, and that narrative is incredibly easy
Speaker 2: to manipulate.
Speaker 1: Here's where it gets really interesting. The example Groose uses
Speaker 1: is brilliant. Let's say we are tracking how many times
Speaker 1: the phrase data science is mentioned on user profiles YEP.
Speaker 1: The data shows that in twenty thirteen there were five
Speaker 1: hundred mentions. In twenty fourteen there were five hundred and
Speaker 1: five mentions.
Speaker 2: That is an increase of exactly five Right.
Speaker 1: So if you plot those two bars on a chart
Speaker 1: and you start your YAG access at zero, the difference
Speaker 1: between five hundred and five oh five is basically imperceptible.
Speaker 2: It looks like a flatline. The narrative there is growth
Speaker 2: has completely stagnated.
Speaker 1: But what if I want my boss to think I'm
Speaker 1: doing an amazing job growing the platform. I go into
Speaker 1: my plotting tool and I manually force the axis to
Speaker 1: start at four ninety nine and end at five.
Speaker 2: Oh six, And suddenly the twenty fourteen bar is towering
Speaker 2: over the twenty thirteen bar. It visually implies this massive
Speaker 2: explosive increase.
Speaker 1: It's the visual equivalent of taking a photo of a puddle,
Speaker 1: cropping it incredibly tight so you can't see the edges,
Speaker 1: and trying to convince the viewer it's the ocean.
Speaker 2: That's exactly what it is.
Speaker 1: If it is that easy to lie with data. How
Speaker 1: can anyone trust a chart in a corporate presentation.
Speaker 2: Well, what's fascinating here is this vulnerability is exactly why
Speaker 2: the premise of the book is so vital. How So,
Speaker 2: when you use black box visualization libraries, they often auto
Speaker 2: scale the axes based on the minimum and maximum values
Speaker 2: of the data provided. Oh, I see a tool might
Speaker 2: automatically crop the access to four ninety nine without any
Speaker 2: malicious intent, just to save space on the screen.
Speaker 1: So the software might accidentally lie to.
Speaker 2: Me, yes, or a human might do it intentionally to
Speaker 2: sell you a false narrative. But when you learn Matt
Speaker 2: plotlib from scratch and you physically write the code to
Speaker 2: define the axis limits, you see how it works exactly.
Speaker 2: You internalize the mechanics of how the visual is constructed.
Speaker 2: You train your brain to instantly look at the axis
Speaker 2: before you let the shape of the line influence your judgment.
Speaker 2: You're basically immunizing yourself against bad data science.
Speaker 1: I love that immunizing yourself, But I want to push
Speaker 1: deeper into the actual geometry of what we're doing here.
Speaker 2: Okay, let's do it.
Speaker 1: When we take two variables. Let's say we're plotting a
Speaker 1: user's number of friends against the minutes they spend on
Speaker 1: the site. Every day we put a dot on a
Speaker 1: scatter flot, we are essentially placing a vector in a
Speaker 1: mathematic space.
Speaker 2: Correct and to truly grasp how algorithms find patterns in
Speaker 2: that space, we have to strip away the Python syntax,
Speaker 2: strip away the visual charts, and look at the hidden
Speaker 2: architecture that runs the entire.
Speaker 1: Discipline, which is linear algebra.
Speaker 2: The dreaded linear algebra.
Speaker 1: That is the phrase that makes half the room breakout
Speaker 1: in a cold sweat.
Speaker 2: I know, I know.
Speaker 1: But abstractly, vectors are just objects that can be added
Speaker 1: together or multiplied by scalers to form new vectors.
Speaker 2: And concretely, for our purposes anyway, there are simply points
Speaker 2: in a finite dimensional space. Representing user data as vectors
Speaker 2: is the foundational trick of machine learning. The text gives
Speaker 2: a very grounding example a person's physical attributes. You have
Speaker 2: a list of three numbers seventy one, seventy and.
Speaker 1: Forty meaning seventy inches tall, one hundred and seventy pounds,
Speaker 1: and forty years.
Speaker 2: Old exactly, And Python is just a list. But mathematically
Speaker 2: it is a single coordinate in three dimensional space.
Speaker 1: Okay, so I have this coordinate. But the book forces
Speaker 1: a to actually do math with these lists from scratch.
Speaker 1: If I want to add two user vectors together, I
Speaker 1: can't just put a plus sign between two Python lists.
Speaker 2: No, it doesn't work like that. By thought would just
Speaker 2: stick the two lists together and in right.
Speaker 1: So the book introduces the zip function. Walk me through
Speaker 1: the mechanics of that.
Speaker 2: Vectors must be added component wise. The first element of
Speaker 2: vector A adds to the first element of vector B.
Speaker 2: So if vector A is one two and vector B
Speaker 2: is two one, the zip function acts like a physical zipper.
Speaker 2: It takes the first element from both lists, the one
Speaker 2: and the two, and binds them into a pair. Then
Speaker 2: it takes the second elements the two in the one
Speaker 2: and binds them.
Speaker 1: And once they're paired up, the book uses a list
Speaker 1: comprehension to iterate through those pairs, add them together, and
Speaker 1: spit out a new vector three three.
Speaker 2: From there you build a function for the dot product,
Speaker 2: which is just multiplying those matching pairs and summing up
Speaker 2: the total.
Speaker 1: Let me stop you right there, because I understand the
Speaker 1: mechanics of what you just described, But why are we
Speaker 1: doing it? Why does an algorithm care about the sum
Speaker 1: of multiplied components.
Speaker 2: Because the dot product gives you the magnitude of a vector,
Speaker 2: and more importantly, it allows you to calculate the angle
Speaker 2: between two vectors.
Speaker 1: And why does the angle matter?
Speaker 2: This is how algorithms determine similarity. If you plot the
Speaker 2: interest of two users as massive vectors, and you calculate
Speaker 2: the cosine of the angle between them using the dot product,
Speaker 2: the math tells you exactly how similar those two people are.
Speaker 2: A small angle means their vectors are pointing in the
Speaker 2: exact same direction. They like the exact same things. That
Speaker 2: is literally how Acupid knows who you should date.
Speaker 1: That is fascinating, But I have to be completely honest here.
Speaker 1: I'm looking at the sheer amount of code it takes
Speaker 1: to build a vector ad function from scratch using zip
Speaker 1: and list comprehensions. Highly optimized libraries like numpi can execute
Speaker 1: vector addition across millions of data points in a fraction
Speaker 1: of a millisecond.
Speaker 2: Well absolutely so, groose.
Speaker 1: Forcing us to manually zip lists together feels a bit
Speaker 1: like hazing. Are we doing this?
Speaker 2: It's a fair question, but think of it this way.
Speaker 2: If you don't understand basic arithmetic, a pocket calculator seems
Speaker 2: like a magic box. You punch in some numbers and
Speaker 2: it spits out the truth, right. But if you accidentally
Speaker 2: hit the division key instead of the multiplication key, the
Speaker 2: calculator will spit out a completely absurd answer.
Speaker 1: And because I don't intuitively understand the math, I wouldn't
Speaker 1: even realize the answer is absurd. I'd just trust the
Speaker 1: screen exactly.
Speaker 2: Relying on numbpi without understanding linear algebra is the exact
Speaker 2: same danger, but on a massive scale. When everything works,
Speaker 2: you're fine. But what happens when you encounter the curse
Speaker 2: of dimensionality? The what the cursive dimensionality? What happens when
Speaker 2: you're dealing with data in one hundred dimensions and the
Speaker 2: distance between all your points mathematically approaches uniformity, breaking your
Speaker 2: predictive model.
Speaker 1: The black box isn't going to tell me why it broke.
Speaker 2: No, it won't, And because you don't understand the arithmetic
Speaker 2: of the vector space, you won't know how to fix it.
Speaker 2: You won't realize as your data is behaving absurdly, building
Speaker 2: it from scratch builds your mathematical intuition. It ensures you
Speaker 2: remain the mechanic, not just a passenger.
Speaker 1: That perfectly encapsulates this entire journey. I mean, we started
Speaker 1: today looking at a raw, confusing data dump from data Sciencestor.
Speaker 1: We realized that default metrics like degree centrality can completely
Speaker 1: blind us to the actual structural reality of a network.
Speaker 2: We tamed that raw data using the strict elegance of
Speaker 2: Python learning, the mechanical advantage of tools like default dick
Speaker 2: to skip boilerplate logic, and lazy generators to keep our
Speaker 2: systems from crashing under the weight of massive lists.
Speaker 1: We took those insights and visualized them, digging into the
Speaker 1: mechanics of the axis so we could actively defend ourselves
Speaker 1: against manipulated narratives. Yes, and finally, we translated our users
Speaker 1: into mathematical vectors, exploring the literal architecture of similarity that
Speaker 1: powers every recommendation engine on Earth.
Speaker 2: Knowing these first principles is your shield. Whether you were
Speaker 2: analyzing your own company's user behavior preparing for a high
Speaker 2: level strategy meeting, We're just trying to navigate a world
Speaker 2: driven by algorithms. Understanding the how protects you against the hype.
Speaker 1: I want to leave you with a final thought to
Speaker 1: chew on something that stretches beyond the scope of Python
Speaker 1: two point seven. Okay, we've spent this entire deep dive
Speaker 1: manually building these models so we can truly comprehend the
Speaker 1: how and the why. When we talk about a three
Speaker 1: dimensional vector of height, weight, and age, our human brains
Speaker 1: can picture it. We can imagine that dot floating in
Speaker 1: a room.
Speaker 2: But the bleeding edge of this field isn't operating in
Speaker 2: three dimensions exactly.
Speaker 1: Modern neural networks and depth learning systems are analyzing patterns
Speaker 1: across millions of dimensions simultaneously.
Speaker 2: Yeah, it's unfammable.
Speaker 1: They are finding mathematical correlations in vector spaces that no
Speaker 1: human mind can actually visualize or comprehend. So the provocative
Speaker 1: question is this, as these self learning algorithms become infinitely
Speaker 1: more complex, will we eventually reach a threshold where even
Speaker 1: the mechanics, the people who build system from absolute scratch,
Speaker 1: can no longer truly understand the why behind the insights
Speaker 1: the machine produces.
Speaker 2: We're moving from an era of tools we fully comprehend
Speaker 2: to an era of intelligences we merely point in a direction.
Speaker 1: We might end up right back where we started on
Speaker 1: day one, staring at an unimaginably massive humming engine block
Speaker 1: and having absolutely no idea why it's moving. Thank you
Speaker 1: for joining us on this deep dive into the foundations
Speaker 1: of data science.