
# Kubeflow Goals

**Author:**[Francisco Javier Arceo](https://www.linkedin.com/in/franciscojavierarceo/) | **Date:**Nov 20, 2024

We are at a critical moment in time for AI/ML. Open-source models have taken center stage, and resilient, scalable infrastructure has become critical to the success of AI. However, infrastructure alone isn't enough—tools must inspire excitement and engagement among users.

As a Kubeflow Steering Committee member, my core focus would be to drive engagement and increase adoption by improving the experience and impact of Kubeflow for end users, ensuring it's not only a robust platform but also one that people love to use. More precisely, I would focus on 6 key goals.

1. **Expanding Kubeflow Adoption:** increasing awareness, adoption, and engagement through collaborations with enterprises and startups.  
2. **Making RAG a first class priority:** the AI community has settled on Retrieval Augmented Generation (RAG) as a critical component for production AI. I will work to make this a new focus area for Kubeflow.  
3. **Improving the User/Developer Experience for Model Developers/Users:** simplifying workflows and enhancing usability to reduce barriers to entry.  
4. **Engaging and Empowering AI Engineers:** supporting software engineers integrating AI/ML into their products. By providing intuitive workflows, thoughtful defaults, and subsets of Kubeflow's tooling, we can ensure AI Engineers are set up for long-term success as they scale their products.  
5. **Building a more Feature-Complete AI/ML Platform:** driving development of critical features to support end-to-end AI/ML workflows.  
6. **Improving Documentation:** ensuring comprehensive, user-friendly docs and resources for the community.  
7. **Strengthening the Community:** fostering a vibrant, inclusive contributor and user ecosystem to support Kubeflow's long-term growth.

I believe [I am qualified](https://www.linkedin.com/in/franciscojavierarceo/) to help lead Kubeflow's [values and structure](https://github.com/kubeflow/community/blob/master/KUBEFLOW-STEERING-COMMITTEE.md#kubeflow-steering-committee) because of my past open-source contributions and professional experience. 

As a [leader](https://docs.google.com/document/d/1DgtDmLCBnXQF9qva9X6Vac2ehpplj2iz6ZYw76NL8gM/edit?tab=t.0), [maintainer](https://feast.dev/blog/the-future-of-feast/), and [contributor](https://insights.lfx.linuxfoundation.org/foundation/lf-ai-foundation/overview/github?project=feast&repository=https:%2F%2Fgithub.com%2Ffeast-dev%2Ffeast&routedFrom=Github&dateFilters=Last%2010%20Years&dateRange=2014-11-20%20to%202024-11-20&compare=PP&granularity=year&hideBots=true) to Feast, I have helped evolve a critical component of the MLOps ecosystem, driving innovation in feature storage and retrieval. My 12+ [years of experience](https://www.linkedin.com/in/franciscojavierarceo) at the intersection of data engineering, AI/ML engineering, and MLOps include technical and managerial leadership roles at Red Hat, Affirm, Fast, Goldman Sachs, and others. Across these positions, I've designed, built, and scaled AI **models and platforms** in production, gaining a deep understanding of user pain points and opportunities to innovate.

I bring this experience to Kubeflow with a vision of making it the leading open source platform for scalable, production-grade AI/ML. By expanding adoption, improving the user experience, and delivering a feature-complete solution, my goal is to empower MLOps teams to build a powerful AI/ML platform that enables their success and expands the global impact of AI.


Goals and vision for Kubeflow's future as a steering committee member

Kubeflow Goals



<blockquote class="twitter-tweet"><p lang="en" dir="ltr">you know, deploying machine learning models is very, very difficult</p>&mdash; Francisco Javier Arceo (@franciscojarceo) <a href="https://twitter.com/franciscojarceo/status/1544110672660807680?ref_src=twsrc%5Etfw">July 5, 2022</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>


# Some History

I've been working in the application of machine learning for nearly 10 years
and it's quite exciting to have experienced firsthand how much machine learning
infrastructure has changed in that time.

I spent the first half of my career as a "modeler" where I focused on building
machine learning and statistical models for a bunch of different use cases. Over
time I found that I migrated more and more to the engineering work to get the model
deployed because I always found this to be a bottleneck in the work I did.

Concretely, I'd build a pretty good model that suggested it would be impactful
(based on expectations of the performance) but I often found it was a rather
extraordinary effort to get it live and interacting with users/customers.

This is quite well cited by the data science / MLOps community today but it was
less obvious back in 2012 and it was very frustrating. The good news is that, for
better or worse, I was rather relentless in getting my models over the finish line.

Which, in many ways, is what led me to the career I have stumbled into today as
an engineering manager working at the intersection of machine learning, data,
and engineering.

All this to say that I have spent a surprising share of the last decade working
on getting models into live product experiences. Since I have some lessons
learned and some potentially useful opinions, I thought I'd write them down.

# Ten Lessons from a decade of Deploying ML

## 0: Create strict contracts with the input source of your features

This is the single most important and most frequently omitted step in the
machine learning pipeline. I say this because making unit tests for schemas is
mostly tedious work but, in my experience, this is 90% of the errors
that come up in production. Whether it be a missing field, new field, or a
change to the type of the field, it just seems to happen to *everyone* at some
point.

Whether your model is batch/offline or real-time/online having data/schema validations
is critical as often ML models are dependent upon data from a wide variety of
different upstream sources where the data producer has no knowledge about the
usage of the data, so a trivial change on their end could make cause a world of
chaos for you and the consumers of your models.

Some limitations with this approach are (1) that you may not always know the
top-level producer of your data so making a test may not be so trivial if you
rely on an intermediate data consumer to provide you the data or if you rely on
a vendor that changes something without your notice (this happens more often
than you think). Regardless of the limitations having some tests here
will certainly provide you more coverage and ensure higher quality.

## 1: Test your feature engineering more than you want to

Feature engineering is code.

When software engineers write code for microservices we write lots of unit
tests to capture schema changes, validate edge cases, and make the code
more readable.

Unfortunately, these software design concepts don't always translate to
machine learning applications. This isn't always the case but often this happens
because the skills needed to build good machine learning models are rarely
the same as the skills needed to write good software.

So the recommendation is simple: write lots of unit tests covering all of
the edge cases that come up during feature engineering.

What are some of the edge cases?

- Return type changed
- division by zero
- incorrect logic
- incorrect imputation
- incomplete if-else
- and others

In many ways this is laborious but it makes sense because the bulk of the work
(and code) in machine learning for tabular data is in the feature engineering
and the pipelines supporting those features, so that is where the bulk of the
testing should be.

## 2: Codify the range and scale of your features

Scale and range checking in practice can be rather challenging as sometimes
it's very hard to know what the upper or lower bound will be but often you can
apply sensible heuristics. For example, you can test that features that are
calculated as ratios or rates to between [0,1] and test large but sensible
extremum values for other features.

## 3: Separate your model execution from your feature engineering

Post-estimation a model is a rather trivial function call applied to a matrix
or tensor for most algorithms. The pipeline is usually as simple as:

```
# lots of stuff above
features = build_features()
predictions = model.fit(features=features)
# lots of stuff  below
```

But there are challenges that come up with the `model.fit()`. Specifically,
some models can be very large in size, especially ones using neural networks.
If you do have a large model you have to make sure you think about: right-sizing
the server that will hold the model in memory, where that model will be stored,
how the server will load the model, and what fail-over looks like.

These hardware and software considerations can get complicated on their own,
which is why it's worth not mixing up the model execution with the feature
engineering pipelines or other stuff if you don't have to.

## 4: Separate matrix serialization from model execution

This is another small step in practice but is very consequential as errors come
up and identifying the root cause can often be hairy. So I recommend that you
separate the matrix serialization from your model execution and feature
engineering because it is cleaner and you'll be able to triage inevitable
breaks sooner.

Two specific issues that come up are (1) passing a character to a matrix and (2)
passing a missing value (e.g., `np.nan`). (1) is not a number and in order for
the algorithms to do their fancy stuff they need explicit numbers and (2)
is effectively equivalent but some matrix implementations in python will allow
you to hold a placeholder for a missing value and may even behave with some
basic operations but will ultimately fail at the `model.fit()` step.

Here are two trivial examples that show this problem in action:
```python
# Just showing that this works as normal
xs = np.matrix([[1,2],[3,4]])
print(xs * 1.3)
#matrix([[1.3, 2.6],
#        [3.9, 5.2]])

# Example 1: Now let's try that character
xs = np.matrix([[1,2],[3,'c']])
print(xs * 1.3)
# ...it breaks! and eventually you see this confusing error:
# numpy.core._exceptions.UFuncTypeError: ufunc 'multiply' did not contain a loop with signature matching types (dtype('<U21'), dtype('<U3')) -> None

# Example 2: Now how about that np.nan?
xs = np.matrix([[np.nan, np.nan],[np.nan, np.nan]])
print(xs * 1.3)
# Wild that this works
matrix([[nan, nan],
        [nan, nan]])
```

Trivial in code, chaotic when it blows up a server.

## 5: Avoid mixing business logic with statistical operations

Machine learning systems, even those as simple as what is effectively a
glorified calculator can be surprisingly complicated so I generally recommend
keeping any business logic away from the machine learning or feature engineering
work. It's simply because both business logic and ml code tend to grow
complicated for all sorts of valid reasons but the skills used to debug or
even read and understand either are quite different, so the separation tends to
help with that.

## 6: Precompute what you can

I could write an entire book about feature engineering and the complexity that
it holds but the TL;DR version is that features tend to have all sorts of
different time representations (some feature representing real-time, others
data from yesterday, and others from 3 seconds ago) and this temporal component
ends up creating a lot of engineering complexity.

A general recommendation: precompute and run in batch as much as you possibly
can. You can actually get quite far for many use cases this way without having
to build the complexity that comes with real-time and streaming use cases.

Once you do get to real-time and streaming use cases, there's a whole other
bunch of work to do and I won't cover that here.

## 7: Load your model at service build time

In an ideal world your model is an isolated service or an isolated endpoint with
it's own memory (maybe on kubernetes, maybe not) and you simply load it at build
time. It's pretty simple but this all means you could store your model artifact
in either some [model registry](https://www.mlflow.org/docs/latest/model-registry.html)
or in an S3 buckets.

If you're early in your model building it's absolutely fine to store the model
in GitHub if it's not terribly huge but generally it's preferred to put it in
some other storage meant for larger file sizes.

## 8: Right size your server

Going back again to the challenges that come up when having a large model, you
may not just be encountering issues there. You may also find that some of the
data that you have to process in real-time can get bulky (e.g., if you're
dynamically calculating features based on user history and look back through a
year's worth of data for a bunch of different things).

So it's important to not only right size your server for the model that you will
be using but also for the features that you will be calculating in real-time.
This is usually fairly manageable and if you precompute a lot of features then
you're only doing a lookup and you'll likely have much less memory pressure but
it is worth validating this before deploying your model.

## 9: Monitor your model and features

While this is the last item, it's an extremely important one. A general truth
about models is that if you're launching one it's going to be impactful to some
process or customer experience (woo hoo!) but that means that people make
tradeoffs to get things shipped and monitoring tends to be one of them.

I've typically seen folks leave the monitoring of the model performance as some
afterthought or follow up work to be completed later and usually it does and
it's okay but it really should be top of mind. From a statistical standpoint
this is purely offensive as all sorts of chaotic things can go wrong
when you go from some historical data to a live machine.

It could turn out that your data wasn't from a representative sample, your model
was trained on the wrong metric, you're adversely impacting business metrics
(though this tends to be caught quickly), you have a bug in your code, or that
your model just doesn't work.

You can track most of that from monitoring, so don't omit it.

Most importantly, every applied machine learning model that I've built in
industry has degraded (eventually). It's mostly because things change over time
and that obviously makes sense. Without proper monitoring you will not be able
to observe this phenomena so please don't forget this core component as it could
be very consequential to your business.

It's worth mentioning that model degradation not driven by engineering problems
ends up being a lot of statistical work to understand what is driving the
decay of models. Suffice it to say that it's a complex, high-dimensional
problem.


# Some final thoughts

Reflecting on the list above, I can't help but call out that 9 of these 10 items
are purely focused on the engineering around deploying a model and that the
monitoring is the **last** step.

*As a brief aside, there is a significant amount of pre-work done here to build
these models during the model development lifecycle but I didn't discuss that
here as that's outside the scope of this blog post.*

You don't *actually* have to do anything on that list to get a model in production,
I just recommend it. At an early stage of your service it may not even make sense
to build a bullet-proof system but at a bigger scale these things actually do become
increasingly more important as preventative and defensive measures.

Lastly, I ranked these in order of importance and the most important ones are
all *preventative change controls*, i.e., they can all detect breaks before you
deploy something to production (i.e. in unit tests). Defensive change controls
are great too but one should remember that these will always come second place
to preventative controls simply because you're catching a mistake after it's in
production.


*Have any feedback on this post? Let me know on the [twitter](https://twitter.com/franciscojarceo)!*


10 lessons from a decade of deploying machine learning

The Difficulties of Machine Learning in Production


# The Irrationality of Humans

I find human behavior and decision making wildly fascinating...and mostly comical,
especially my own. This is because of the variety of paradoxes, cognitive biases,
and irrationalities that are constantly at play in our micro and macro conclusions.

In fact, these irrational behaviors are largely what led me into the career I have today.
It all started with *economics and statistics* (my first graduate degree/love)
and I've spent ten years working in understanding human behavior. Maybe the methods
and engineering are fancier now than back then but, at my core, I am still
fascinated by human behavior, data, and statistical inference—the methods that
provide a glimpse of understanding about a person's choices.

What I've found is that humans are just kind of ***weird*** in their
behaviors and decision making. Some would say down right irrational...I certainly
would.

Much of that irrationality comes from all sorts of paradoxes and cognitive
biases that are well known in different academic disciplines (particularly
behavioral economics and statistics) but that aren't as well known by most
folks. So I thought I'd write briefly about them and why they're important.

It's worth emphasizing that even if you are aware of these things, you are still quite
likely to be subject to them or make the mistakes they call out—***I do all of the
time***. Regardless, knowing them can—to some degree—help you mitigate them
and help you make better decisions.

I would like to over-emphasize that my own decision making is nothing to brag
about but I decided to write this because I thought it'd be fun and I do love
this topic.

# Paradoxes and Biases

I have decided to explicitly order these in the order I felt is the most
important. This, too, is ridden with bias but I believe that this is the
order most important to me and that I've found the most useful in my
personal and professional life.

## 00. The Dunning-Kruger Effect

[The Dunning-Kruger Effect](https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect)
is one of the most important cognitive biases that exist, probably because of how
impactful it is to everyone (i.e., we all suffer from the burden of incompetent
people and it is quite likely we, too, are someone's burden).

In short, people with low ability at a given task tend to overestimate their
ability and those with high ability tend to underestimate it.

If you pay attention, you will see this occurrence often...especially from
those without much experience in a given area of expertise (though this is not
always true).

You may see this often from people in business...run away.

## 01. The Double Standard

This is probably my favorite bias because people (like me, for example) commit
this often and it's such a subtle yet common thing. I believe this bias to be a
consequence of the Dunning-Kruger Efect mentioned above.

Definitionally, a Double Standard is "the application of different sets of
principles for situations that are, in principle, the same."

I find this to be very important professionally as people often have unrealistic
expectations of others that they wouldn't have of themselves. I find this
comes up when folks without domain expertise are frustrated by timelines of
for building various things.

Said another way, *"Why does this take so long?"*

As a manager, I regularly ask myself "If I were doing this, would I expect the
same outcome in the same time?" and I find that this helps me better empathize
and be more realistic about the outcomes.

More importantly, my colleagues probably find me more tolerable. :)

## 02. The Curse of Knowledge

I say this non-ironically: something is obvious when you know it, and not
if you don't—so too the definition of [the Curse of Knowledge](https://en.wikipedia.org/wiki/Curse_of_knowledge).

This is something I experienced a lot in my career because people often forget
all of the context they have when referencing something. Business is very
jargony so when I onboard people or explain things I very explicitly try to
avoid using acronyms or cryptic language. It certainly takes mental effort but
it makes it much less frustrating for the other party.

Also, I find that assuming someone knows something or being surprised that
someone *doesn't* know something can sound extremely condescending, so probably
it may be best to avoid that.

## 03. Simpson's Paradox

I could write an entire post about [Simpson's Paradox](https://en.wikipedia.org/wiki/Simpson%27s_paradox)
but, to keep it brief, Simpson's Paradox is a statistical phenomenon in which a
correlation between two variables can be reversed by the addition of another.

But how??? Time for a graph!

![Simpson's Paradox: Negative Correlation](simpsons_paradox_1.png)

Above variables $X$ and $Y$ are negatively correlated, quite strongly too with
a correlation coefficient of -0.74. But what if there was some other group
variable $Z$ which represented 5 groups, we would then be able to see:

![Simpson's Paradox: Positive Correlation](simpsons_paradox_2.png)

Oh no! The exact opposite conclusion! It's worth knowing that in statistics and
in life, you may never know of the existance of $Z$.

So while this is useful for regression and statistical inference, I find this
paradox to be applicable to many more situations.

Simply, I may *always* be missing a single, critical piece of information that
may flip my conclusion. So I tend to calibrate my opinions accordingly.

## 04. The Sunk Cost Fallacy

As elegantly written by [The Decision Lab](https://thedecisionlab.com/biases/the-sunk-cost-fallacy),
"The Sunk Cost Fallacy describes our tendency to follow through on an endeavor
if we have already invested time, effort, or money into it, whether or not the
current costs outweigh the benefits."

Emotion often clutters our ability to understand the *actual* expected
value/reward of a given thing we are putting effort into but sometimes it is
in our best interest to cut our losses rather than see it through.

It rarely feels good but can often be the optimal decision.

## 06. Loss Aversion

Loss aversion is simply the disproportional weight a person often places on
minimizing losses to acquire economic gains.

For example, someone may prefer to take \$10 with 100% certainty rather than
\$20 with 90% certainty because the displeasure from that 10\% possibility
outweighs the pleasure they'd receive from the additional \$10 (or expected
\$8 = (0.9 * 20) - 10).

This is extremely irrational and puts non-disciplined investors at a mathematical
disadvantage.

## 07. The Gambler's Fallacy

The [Gambler's Fallacy](https://en.wikipedia.org/wiki/Gambler%27s_fallacy)
refers to the incorrect belief that a given event is more
or less likely given a previous sequence of events when the event is not a
function of time.

This can be seen through coin flips. If you see 5 heads flipped in a row, you
may think that a tails is "due" but this is incorrect (assuming a fair coin) since
coin flips are always independent (i.e., one flip doesn't depend on the next).

## 08. Anchoring

Pulling again from [the Decision Lab](https://thedecisionlab.com/biases/anchoring-bias),
"Anchoring is a cognitive bias that causes us to rely too heavily on the first
piece of information we are given about a topic. When we are setting plans or
making estimates about something, we interpret newer information from the
reference point of our anchor, instead of seeing it objectively."

This is often used in marketing and pricing to delude you into thinking
something is on sale. :')

## 09. Sample Bias

Sample bias originates from statistics and is a result of a flawed collection
of an intended random sample.

This is particularly common in business and Twitter where people think their
customers or Twitter poll-responders are representative of the entire
population.

They're not and this can often lead to very poor decision making or conclusions.

## 10. Assignment Bias

[Assignment Bias](https://www.statisticshowto.com/assignment-bias/#:~:text=Assignment%20bias%20happens%20when%20experimental,people%20who%20are%20significantly%20smarter.)
is similar to Sample Bias in that it is a bias in the sample
but is rooted in a broken assignment system. For example, imagine an
experimental drug trial where the "random assignment machine" (i.e., a machine
that assigns things at random) only treated the young and healthy,
while that is a pathological and extreme example it highlights the issue.

By the way, it turns out that a good "random" sample is extremely hard to
collect in the real world—ask the Census.

## 11. Self-Selection Bias

[Self-Selection Bias](https://en.wikipedia.org/wiki/Self-selection_bias)
is another form of sample bias but it's caused by the participants choosing
whether or not to participate in the experiment or treatment.

Again, in the example above imagine instead that the "random assignment
machine" only treated the people who wanted to be treated and not the
ones that did.

Similar to the previous case it would ruin the experiment.

## 12. Decision Fatigue

[Decision Fatigue](https://en.wikipedia.org/wiki/Decision_fatigue) is a
phenomenon whereby an individual's decision making quality deteriorates after a
long session of decision making.

In short, you get tired of making choices and you start to get sloppy. In the
business and investing world, this is extremely consequential because your or
your investor's money is on the line.

## 13. Optimism Bias

To quote Wikipedia, "[Optimism Bias](https://en.wikipedia.org/wiki/Optimism_bias)
is a cognitive bias that causes someone to believe that they themselves are less
likely to experience a negative event. It is also known as unrealistic optimism
or comparative optimism."

It is good to be optimistic but it is *good-er* to balance it in reality.

## 14. Response Bias

[Response Bias](https://en.wikipedia.org/wiki/Response_bias) is both interesting
and counterintuitive.

It is catch-all for the frequent tendency of participants to respond
inaccurately or falsely to survey questions. This is part of the reason surveys
often conflict with reality.

As a statistician, I feel surverys are *kind of* useful but behaviors reveal the
truth. Measure behaviors.

For internet companies, you may find that user-survery metrics conflict with
tracking metrics that you have for your customer. What people say and what they
do are often wildly different.

## 15. The Accuracy Paradox

Lastly, [The Accuracy Paradox](https://en.wikipedia.org/wiki/Accuracy_paradox)
is the paradoxical finding that Accuracy isn't necessarily a good metric for for
measuring statistical or machine learning models.

This is because of an imbalance of outcomes.

Suppose I was trying to predict a whether someone had a rare illness (1
out of 10,000 people have it), if I predicted everyone didn't have it I'd still
have 99.99% accuracy.

So, accuracy can often be quite useless as a metric for assessing the
quality of things in general (though not always).

# Managing the Irrational

You *probably* can't completely stop yourself from irrational decision making
but you can *possibly* manage it.

My approach is simple: acknowledge the biases above, the idiosyncratic ones I have
from my life exeriences, and reflect frequently. I find that this results in me
changing my mind often.

This can be frustrating but I think that early reactions or understandings
are often not the optimal ones so I try to put effort into reflecting so that I
can just do better.

# Some Advice

(this advice may or may not be useful)

Being objective is nearly impossible when it relates to human judgement, and I'm
not even exactly sure what "objective" *really* means outside of mathematics.

But my advice on being as objective as possible is to write things down:
bullet points, a simple pros and cons list, or whatever suits you can highlight
flaws in your judgement and reasoning.

I find this brings me mental clarity more than anything else really. I also
tend to write things down on paper the good ol' fashion way (maybe it's an
old habit grounded in problem sets, who knows).

Managing cognitive biases and mitigating the adverse consequences they may hold
is extremely challenging but a well worthy endeavor, as good decisions compound
like great investments.

But don't worry too much if you find yourself struggling with it, we are all
human after all.

-Francisco



A brief review of some of my favorite paradoxes and cognitive biases.

Paradoxes and Cognitive Biases


It's always fun to learn some additional tricks in math and computer science and I recently started reading about digital representation of numbers and [Swarthmore](https://www.swarthmore.edu/NatSci/echeeve1/Ref/BinaryMath/NumSys.html#:~:text=In%20summary%3A-,bit,numbers%20from%200%20to%20255.) has some truly great material on this.

I was searching around the internet on how to programatically convert decimal numbers to binary and I found there wasn't *that* great of a resource and stackoverflow had mixed stuff so I thought I'd put it something together quickly.

I'll probably add to this tutorial later but I think the code is the most important part.

# The basics

In short, we want to represent a decimal number (i.e., a number represented in base 10 via the 10 digits we use [0-9]), e.g., 86, as a binary number (i.e., a number represented in base 2 via the 2 digits we are then limited to [0 and 1]).

As outlined in the tutorial above, this results in the two representations:

$$86_{10} = 1*64 + 0*32 + 1*16 + 0*8 + 1*4 + 1*2 + 0*1$$

and

$$86_{10} = 1*2^6 + 0*2^5 + 0*2^3 + 1*2^2 + 1*2^1 + 0*2^0$$

Which is equivalent to saying

$$86_{10} = 1010110_2.$$

The subscript $2$ denotes a binary number. Each digit in a binary number is called a bit. The number 1010110 is represented by 7 bits. Any number can be broken down this way, by finding all of the powers of 2 that add up to the number in question (in this case 26, 24, 22 and 21).

Cool.

So how do we do this with a computer?

# Binary Representation in Python

As we saw before, representing 86 in binary format requires us to deconstruct it from $2^n$, so with computers we can represent 86 by either recursively dividing by 2 (with some additional adjustment) or iteratively (via a while loop) doing pretty much the same thing. Here's the recursive version:

```python
def decimalToBinary(n: int) -> str:
    if n == 0:
        return ""
    else:
        return decimalToBinary(n // 2) + str(n % 2)
```

This is pretty simple and could be trivally mapped to a one-liner but for readability I'll say this is sufficient. Alternatively, we could solve this with a while loop using the following:

```python
def decimalToBinary2(n: int) -> str:
    bs = ''
    while n > 0:
        r = n / 2
        n = n // 2
        bs = str('1' if r % 1 > 0 else '0') + bs

    return bs
```

And this is also pretty simple. It's worth noting that the str() function call is required before concatenating the binary string variable (i.e., bs) because without it python will actually fail to execute the if-else logic and you will not get the behavior you are looking for.

# Decimal Representation from Binary in Python

Okay, so how do we confirm this is behaving correctly? Obviously we can just recover it.


```python
def binaryToDecimal(bs: str) -> int:
    n, r = len(bs), 0
    for i in range(n):
        r+= int(bs[i]) * 2**(n - i - 1)
    return r
```

And that's it! If you stare at this formula for a second you'll see it's just taking each bit in the string and multiplying the $i^{th}$ binary value by $2^{n-i-1}$.

We can verify that all of this works with some simple checks and comparisons:

```python
decimalToBinary(86) == decimalToBinary2(86) # 1010110 == 1010110 --> true
binaryToDecimal(decimalToBinary2(86)) == 86 # true, converted 1010110 -> 86
```

How cool is that?  I'll note that this is only accurate for positive integers but for the general case you can use the first digit to represent the sign of the numbers (with some handling for the 0 edge case).

Hope you found this interesting. As I said I'll elaborate more on this post eventually but I thought I mostly wanted to share the code as I didn't really see good examples providing this back and forth and it was something that helped me understand things more concretely.

Happy typing!

-Francisco


A tutorial on converting numbers from decimal to binary...and back!

Francisco Javier Arceo

Developer & open-source enthusiast.

Open source

Feast

Kubeflow

Llama Stack (now OGX)

vLLM Agentic API

Featured presentations

Open Agents. Distributed Inference. One Stack.

Running Codex and Claude Code CLIs with vLLM and Open Models

Securing the Agent: Vendor-Neutral, Multitenant Enterprise Retrieval and Tool Use

Publications & papers

OGX: An Open-Source, Vendor-Neutral Generative AI Application Server

Securing the Agent: Vendor-Neutral, Multitenant Enterprise Retrieval and Tool Use

Method and apparatus for facilitating provision of exposure management based on streaming data feeds via machine learning and low latency modeling

Notes & writing

Kubeflow Goals

The Difficulties of Machine Learning in Production

Paradoxes and Cognitive Biases

Binary Representation of Positive Integers