All timestamps are based on your local time of:

[ « Newer ][ View: List | Cloud | Calendar | Latest comments | Photo albums ][ Older » ]

Thinking abstractly2023-06-03 09:45:06

Ever since I read The Information I've been noodling on the idea of abstraction. By this I'm specifically referring to the software engineering concept, where you have a bunch of complexity that you hide behind a simplified interface at different layer of abstraction, usually as a means of managing complexity.

That's a lot of words but it's something we do and use literally all the time. Here's a simple everyday example: say there's an apple in a cupboard and you want it but can't get it yourself, so you ask somebody else: "Would you please bring me the apple in the cupboard". This is an instruction at a pretty high level of abstraction.

You could accomplish the same goal using lower-level instructions, such as "Would you please walk over to the cupboard, open it, take out the apple, close the cupboard, walk over to me, and put the apple in my hand." Whereas the high level instruction was more goal-oriented, we can think of this as more action-oriented.

And you could imagine going into even lower-level abstractions by describing how to e.g. contract specific muscles or activate specific joints in your body to accomplish those actions. This might be considered a mechanism-oriented level of abstraction.

A couple of interesting notes on this.

First, the concept of "high" and "low" level abstractions is relative. In the example above, an even higher level abstraction would be, for example, "I want the apple to be in my hand." This might be considered a declarative- or state-oriented level of abstraction. That being said, this is still a very wishy-washy description of a level of abstraction, and I would love to see a more rigorous/numerical definition of it.

Second, given the nature of the problem, some abstractions are more appropriate than others. I would argue that solving problems at the correct level of abstraction is the best way to ensure the problems "stay solved" in the sense that the solutions don't need to be revisited or tweaked over time. I have found this time and again in the domain of software engineering and believe it applies in other domains as well. I'm specifically thinking of the way laws are formulated in response to problems, but often have unintended consequences because they are targeting the wrong level of abstraction and don't generalize well to new situations.

Finally, I believe that the concept of abstraction is severely under-emphasized and under-studied. Finding a way to measure the concept of abstraction numerically, the way Shannon did with the concept of "information" will unlock whole new fields of science and research. Bring able to quickly find the right level of abstraction at which to solve societal problems means that we can save tremendous amounts of time and pain, so the potential upside is huge.


I pity the fool2022-03-28 12:07:02

Over the past few years we've been reducing our direct use of fossil fuels in our household. This involved switching out three fuel-powered machines for electric equivalents: our car, water heater, and home heating.

The car was the first one we did (in late 2019), and was the one with the largest up-front cost. But given the supply chain shortages and rising gas prices, I'm glad we got that one done first. I haven't done a detailed financial analysis but I know that our insurance went up (simply because the base price of the EV was a lot higher than the ICE we had before) and all other costs went down. Overall I think financially it's a slight win in terms of operating costs, but the payback period for the up-front cost will be pretty long. However the pleasure of driving an EV counts for a lot! It just feels nice, even now 2.5 years later.

The water heater was the next one to go (in mid-2020). Previously we were renting a gas water heater; the rental company was not the best and I was eager to ditch them. After doing the math I concluded owning was strictly better than renting, so we purchased an electric water heater and had it professionally installed. The payback period on this was quite short, and we're already net positive two years later. Even if we have to replace it every 6 years (the warranty lifetime) it's still a win over renting. Plus the electric heater is new and doesn't look like it's going to explode if I look at it wrong (the old gas heater was quite old). Functionally it's equivalent or better - water is hot.

And finally, last week we replaced our nearing-end-of-life gas furnace and AC with an electric heat pump (plus a new gas furnace as an auxiliary heat source). It's only been a week but so far I'm pretty happy with the heat pump. Based on the rated capacity, I expect the backup gas furnace to only kick in a few days a year. The real test will come next winter though, so I'm going to withhold final judgement until then.

We still secondary fossil-fuel-based things like a propane BBQ and gas fireplace, but they're very infrequently used. It's quite satisfying to have all our primary energy needs met by the electrical grid. In Ontario at least most of our electricity comes from non-carbon-emitting sources, so that's a nice bonus.

I keep wondering what life would be like if things like cellphones and laptops ran on fossil fuels. Imagine having to open up a little port and pour in a thimble of oil into your phone every night instead of just plugging it in. I'm glad we live in the future.


Magical 3d printers2022-03-17 11:15:54

Imagine a 3D printer that sucked out carbon dioxide from the air, extracted the carbon atoms, and generated graphene/nanotubes in your desired configuration. Presumably with sufficient energy and some sort of catalyst this should be possible. This would be amazing! Not only does it create products with the properties of graphene (amazing strength, etc.), it fights climate change while doing so! And it's a 3D printer that doesn't require you to procure physical "raw materials" since it would suck it from the air.

A 100g print would require 100g of carbon, or ~367g of CO2. At the current atmospheric CO2 levels of ~420ppm, that requires around 873kg of air, or ~713 cubic meters of air. Assuming a 2.5m ceiling height, that's about the amount of air in a ~285 square metre house (~3068 square feet). That's a pretty big house, but a not-unreasonable order of magnitude. Hook up some giant fans and you're all set!

One day we'll probably discover that trees do exactly this.


The revenge of PGP2022-02-17 12:19:43

I recently read "Termination Shock" by Neal Stephenson. Good book for sure, although I prefer some of his other works.

There was a bit in the book that involved deepfake videos which I thought was interesting. Making a deepfake video of some authority figure (government, etc.) and spreading it as misinformation seems like a pretty bad thing, but it's also something that can be defended against. All you have to do is have authentic videos include a public-key signature that can't be faked. So e.g. the US government could have a published public key, and any official communications would be signed by the corresponding private key. Media distribution platforms could then verify the signature to authenticate that it hasn't been faked or modified.

In fact, this would be good even without the threat of deepfakes, because the signature would apply to the entire video rather than a soundbite/clip of it, and so if you extracted and shared a clip, the clip would not be verifiable. This is good because extracting a clip often loses important context and is not representative of the "whole truth". Sharing this kind of out-of-context information is in some cases equivalent to sharing blatant misinformation. Organizations that create the original video could still create shorter "approved" clips and sign them for sharing if they desire.

Same applies to any kind of digital document, really. That's why people do it for email!


On reusing takeout containers2022-02-04 21:25:41

Over time we've accumulated a fair number of black plastic takeout containers. The problem is there's a bunch of different sizes, and finding the matching lids can be quite annoying when they're all just stacked in a drawer. Today after much frustration I (with my trusty 3-year-old assistant) finally got around to sorting the containers to match up the lids and discarding all the pieces without matching parts.

The next step to prevent a re-occurence was to label them. Labeling the lids was easy enough with a permanent marker, since the lids are clear. However the containers are black plastic and none of the pens or markers I tried made any easily-visible mark. In the end I used a knife to make notches in the plastic, with the number of notches matching the number on the corresponding lid. This works pretty well; once I have a container I can quickly count the notches and find the matching lid.

I only wish I had thought to stack the containers by size before numbering them. As-is, lookup is O(n); I could have made it O(log n) using binary search if the lids were stacked in numerical order. If I stack numerically now, they don't stack well because larger ones get put inside smaller ones. But the constant factor is much smaller than it used to be, and that's the real win here. Adding a new container is now O(n) (vs O(1) previously) as I have to compare it to previous containers to determine which number it needs to get, but that should be a relatively infrequent operation.


Funding software supply chains2022-01-10 09:48:19

An author of popular free software packages intentionally inserted infinite loops into his code to break downstream users, as a form of protest. It's not the first time this sort of thing has happened, and it won't be the last. In this particular case I would say that both primary parties are in the wrong.

To the author: if you make your software freely available, obviously people are going to use it without paying for it. Why would you expect anything else?

To the users: if you use some random piece of software in your code without verifying it and just keep blindly updating it, obviously stuff like this is going to happen. Why would you expect anything else?

To me it seems like there's no strongly defined interface here, on either side. So you have to be prepared to accept any kind of behavior from the other party. What's surprising is that this doesn't happen more frequently.

What I would like to see is some mechanism for a formal "pay what you can" style of money transfer. As an author of various open source packages, I do it mostly for personal pleasure, but I also wouldn't be opposed to getting money from those that profit from the work. This is not my primary concern, but if it were easy to set up, why not? On the flip side, as a professional software developer working for a profitable company, I would love to be able to support the (large amounts of) open source work we rely on.

Approaches like Patreon are fine for "artisanal" stuff but they don't scale. What I want to be able to do is take a budget of any amount, say $1m and distribute it programmatically across the free software projects that we use. Ideally with most of it actually going to the project as opposed to getting sucked into transaction fees or middlemen.

So here's a strawman proposal: open source projects that are accepting donations should include a DONATIONS.txt file in their source tree, similar to README.txt, that provides a machine-readable money transfer address. These files can be scraped, collated, and funded by any consumer of the project.

The hard part, of course, is the "machine-readable transfer address" part. Obviously cryptocurrency seems like a good fit for this problem. It's trivial to create a wallet and let it accumulate donations, and only go through the hassle of extracting the value in fiat if there's enough to be worthwhile. And it works at internet scale, that is to say, regardless of what geopolitical area of the world the parties are in.

For people opposed to cryptocurrencies: sure, there are good reasons to be sceptical. But I challenge you offer a viable alternative instead of shooting down this proposal merely on the grounds that it involves cryptocurrencies.

[ 1 Comment... ]

What a time to be alive2022-01-02 11:01:24

I've been thinking lately about the revolutionary new technology transitions that humanity is going through. There's a few that I think will have a huge impact over the course of the next few decades:

  • artificial intelligence, which is already well under way
  • quantum computing, which is still early days, but will give humanity unprecedented ability to effectively engineer everything from materials to genomes
  • space exploration/colonization, which will be a driver for creating all sorts of new products that will benefit everybody

There's also a few shorter-term things like cryptocurrency/web3, 3D printing, and global internet coverage which are similar in nature but smaller in their impact.

What's interesting to me is that while all of these things are in development concurrently, I'm not sure humanity has enough bandwidth to digest all of these revolutions concurrently. In isolation, each piece of tech can be developed just fine. However, there's going to be a lot of work needed to integrate it with all existing tech and with each other. The "each other" part of it is particularly expensive because for n new technologies there are O(2^n) combinations and exploring each of those possibilities requires knowledge of one or more of these new technologies (where, by definition, the knowledge is not widespread). I'm not sure we have enough people to make it happen smoothly.

It will still happen, just less smoothly than we might like. By that I mean gaps will be exposed at the intersection of technologies that can and will be abused by bad actors. Fortunes will be made and lost to these gaps.

If this all sounds very abstract here are some more concrete (although rudimentary) example questions:

  • Who will update software to move off cryptosystems like RSA that can be broken by quantum computing? What will get left unpatched and hacked?
  • As products get lighter (mass efficiency being a key factor for space colonization) delivery via drone becomes feasible for a much larger set of products. Who will have the drone delivery capability to take advantage of it?
  • How do blockchain consensus protocols deal with the scenario where a bunch of nodes are on another planet with multiple minutes of latency in communications? Is a single unified system still feasible?

These questions are pretty basic and I don't think I have enough specialized knowledge to ask better ones. But I know they're out there, and they're important to think about.

Extrapolating on this line of thinking, there's probably some ideal ratio of scientific/research activity to engineering activity such that the rate is creation of new technologies doesn't overwhelm the ability to integrate those new technologies into the world. Over time, this ratio would increase in the direction of requiring more engineering activity per unit of scientific/research activity simply because each new technology can be integrated with the increasing number of technologies that came before.


Dewey Decimal Challenge2021-12-30 21:35:31

Over the course of 2022, pick a book from every major Dewey Decimal category and read it. This probably works best if your local library uses Dewey classification rather than Library of Congress or other classification systems, and if COVID isn't preventing you from actually browsing the library in person.


9 years and change2020-12-19 22:36:47

I should probably note here that November 20 was my last day as a Mozilla employee. In theory, that shouldn't really change much, given the open-source nature of Mozilla. In practice, of course, it does. I did successfully set up a non-staff account and migrate things to that, so I still retain some level of access. I intend to continue contributing; however, my contributions will likely be restricted to things that don't require paging in huge chunks of code, or require large chunks of time. In other words, mostly cleanup-type stuff, or smaller bugfixes/enhancements.

I still believe that the Mozilla mission to make the Internet healthier is important, but over the course of the past year, I've come to realize that there are other problems facing society are perhaps more important and fundamental. That, combined with more companies opening up remote positions, provided me with an opportunity that I decided to take. In January, I'll be starting work on the Cash App Platform team at Square, and hopefully will be able to help them move the needle on economic empowerment.

Working at Mozilla was in many ways a dream come true. It was truly an honour to work alongside so many world-class engineers, on so many different problems. I'm going to miss it, for sure, but I am also excited to see what the future holds.

A final note: if you follow this blog via Planet Mozilla, keep in mind that only posts I tag as "mozilla" show up there, and those posts will be much fewer in number going forward (not that they were particularly numerous before...). I have an RSS feed (yes, RSS is still a thing) if you care to follow that.


On comparing rates of return2020-08-30 21:28:22

Something that has bugged me for a while is how brokerages never seem to provide an annualized rate of return for stocks/portfolios. They tell you things like the book value, market value, and closed profit/loss, but computing a rate of return from that totally discounts the time factor and incremental/partial investments, and gives you a rate of return that is not meaningfully comparable across different stocks or portfolios.

I've written my own financial tracking software (this should come as a surprise to no-one who knows me) and I figured I should build this in. It turned out to be a somewhat interesting problem to come up with something reasonable, so I thought it would be worth describing.

First we have to figure out what kind of rate of return can be meaningfully compared across different investment portfolios. Consider an easy scenario:

t=0: Buy $100 of stock A
t=1 year: Sell stock A for $110

What should be the rate of return here? The obvious answer is 10% because we sold for 10% more than we bought. But compare against this:

t=0: Buy $100 of stock B
t=1 year: Sell half of stock B for $55
t=2 years: Sell remaining stock B for $60

We can think of this as two sub-stocks, B1 and B2:

t=0: Buy $50 of B1, $50 of B2
t=1 year: Sell B1 for $55
t=2 years: Sell B2 for $60

If we want to be consistent with our calculation for stock A, then B1 got a rate of return of 10%, and B2 got 20% but over 2 years. You could treat that as equivalent to 10% per year, but... if B1 was worth $55 at t=1 year, then so was B2. Which means B2 went up from $55 to $60 over the second year, which is less than 10% per year. So that seems like a contradiction.

With a bit of thought it seemed to me that what we really want here is a "continuous compounding" rate of return rather than a "yearly compounding" (or "no compounding") rate of return. The continuous compounding formula is:

Pt = P0 * er * t, where P0 is the initial investment, r is the rate of return and t is the time.

So let's look at B1 and B2 again:

Formula for B1: 55 = 50 * er * 1 which produces r as 9.53%.
Formula for B2: 60 = 50 * er * 2 which produces r as 9.12%.

This makes sense since we know B did worse in the second year than it did in the first year, so B2's rate over 2 years should be lower than B1's rate over the first year. (Note that with this formula we also get 9.53% for stock A above, which seems consistent.)

What about combining B1 and B2 back into a single rate of return for B? They're over different time periods so just taking the arithmetic mean doesn't seem right. I realized instead that we can think of the investments as putting money into and taking money out of an imaginary savings account with continuous compounding. That's similar to the stock market (or other investment vehicles) with the difference that the stock market fluctuates a lot and the instantaneous value at any given time is pretty meaningless, so we want to avoid using that anywhere in our calculations. We want to get away with just using the cash flows in and out of the investment.

So to compute the return for B, we could do something like this:

(((100 * er * 1) - 55) * er * 1) - 60 = 0

This says the $100 grew at continuously-compounded rate r for one year, at which point we removed $55 and let the rest grow for another year at the same r, and then removed $60 and ended up with $0 left. And here solving for r gives us 9.25% which seems like a reasonable number given our values for B1 and B2 above.

This solution can be extended for all sorts of complex scenarios spanning different time periods and with many cash flows in and out. I don't know if there's a closed-form solution to this but I ended up writing some code that did a binary search to converge on r.

Another interesting factor to consider is related transactions that don't actually affect the "stored value" in the investment. This includes things like dividend payouts (excluding reinvested dividends) or transaction commissions taken by the broker. I wasn't quite sure how to fit these in, but eventually decided that they should just be treated as non-compounding. So, for example, if we have this scenario:

t=0: Buy $100 of stock C
t=1 year: Receive $10 dividend from C
t=2 years: Sell all of C for $130

We'd use this formula:

(100 * er * 2) - 130 = 10

The left side is what we'd normally put in for the buy/sell transactions, but the right side is the net result of all the related transactions (in this case, a $10 dividend payout). In this case, it gives us a 16.82% rate of return, versus a 13.12% return without the dividend. So again, seems reasonable since the net value at the end is $40, versus $30 without the dividend.

Accounting for dividends this way makes it so that the time at which we receive the dividend doesn't make a difference to the overall rate of return - we could receive the dividend right at the beginning, or even after we sell the stock, and our rate of return will be the same. I considered the argument that dividends that arrive sooner are better, because we have access to the money earlier. Upon further reflection, I think that's only true if we actually invest that money in something. If that something is part of the portfolio we're evaluating, that dividend is effectively a reinvested dividend and shouldn't get counted as a dividend at all. And if that something is outside the portfolio we're evaluating, then it should get counted towards that other portfolio. I'm not totally sold on this bit yet but even with this caveat the overall approach seems to work well enough.


[ « Newer ][ View: List | Cloud | Calendar | Latest comments | Photo albums ][ Older » ]

(c) Kartikaya Gupta, 2004-2023. User comments owned by their respective posters. All rights reserved.
You are accessing this website via IPv4. Consider upgrading to IPv6!