So I've been experimenting with a ketogenic diet. So far I have tried for 25 days and the results have been interesting. I've been keeping precise data for approximately 8 months in terms of my energy requirements. A keto diet is one in which your consumed carbohydrate are significantly low enough so that your body only uses adipose tissues for energy, which result in ketones as a by product (and which can be detected in a urine test you can buy at a drug store for very cheap). The theory of the popularized "Atkins" diet is that you can lose weight without decreasing how much you eat.
So far I've actually found that to be true, but I only have 25 samples and I need more data. The results of ketosis seem to be an increase in your maintenance metabolic rate, which is simply how many calories you have to consume to not gain or decrease weight.
My theory is that the reason your maintenance requirement increases is that using ketones and not the byproduct of carbohydrates for energy is a very inefficient process. Inefficient is good when it comes to weight loss because that means that it costs your body more energy to give you the same output. Sugars are absorbed very quickly and can be used for energy almost immediately, so they are a very efficient process. That's just my simple theory though.
Without further adieu, here is some of my data thus far:
2011-09-06 to 2011-11-11 (cut)
Days = 66
Change in Weight = -23.8 lbs
Calories / Pound = 3500 (assuming adipose) kCal / lbs
Caloric Deficit = 3500 * 23.8 = 83300 kCal
Average Calories Consumed = 1760 kCal / day
Maintenance Calories = 1760 + 83300 / 66 = 3022 kCal / day
2011-11-11 to 2012-02-01 (maintain)
Days = 83
Change in Weight = -4.6 lbs
Calories / Pound = 3500 (assuming adipose) kCal / lbs
Caloric Deficit = 3500 * 4.6 = 16100 kCal
Average Calories Consumed = 2250 kCal / day
Maintenance Calories = 2250 + 16100 / 83 = 2443 kCal / day
2012-02-01 to 2012-04-11 (bulk)
Days = 70
Change in Weight = +9.6 lbs
Calories / Pound = 3200 (assuming adipose + muscle) kCal / lbs
Caloric Deficit = 3500 * -9.6 = -30720 kCal
Average Calories Consumed = 2770 kCal / day
Maintenance Calories = 2770 - 30720 / 70 = 2331 kCal / day
2012-04-11 to 2012-05-06 (keto)
Days = 25
Change in Weight = -6.4 lbs
Calories / Pound = 3500 (assuming adipose) kCal / lbs
Caloric Deficit = 3500 * 6.4 = 22400 kCal
Average Calories Consumed = 2570 kCal / day
Maintenance Calories = 2570 + 22400 / 25 = 3466 kCal / day
This is a very high variance set of measurements, so the accuracy is in question. Also it is not a static system, in that as your weight fluctuates, so does your maintenance needs. It's very difficult to control for all the variables, and honestly I'm not here to write a paper about it, I'm just seeing how things work for me, so I am not being as scientific about this as I should be. But the trends are interesting, and it appears that my basic caloric needs can significantly increase just from ketosis. More data is needed.
Sunday, May 6, 2012
Tuesday, April 24, 2012
Housing Price Distribution
So one of the issues with the crash of 2008 in regards to housing prices was the inability to correctly calculate the risk of the mortgages (or, more specifically, the mortgage-backed securities). This is obviously an extreme simplicity, but from the books I've read, it appears that many risk management mathematics was based off the assumption of a normal distribution of housing price changes. In 2008, however, it appears that housing price changes were veering too far negative.
So I downloaded the raw housing data from each quarter from 1970 to 2011 from http://www.jparsons.net/housingbubble/ and performed some very simplistic analysis using Matlab.
I calculated the change in inflation-adjusted housing prices from each quarter, resulting in 167 values.
Here is a histogram of the change in housing prices from 1970 to 2007 with 15 bins (15 unique x-axis values):
Here is a histogram of the change in housing prices from 1970 to 2011 with 15 bins (15 unique x-axis values):
You can clearly see that from 2007 to 2011, the distribution looks more skewed.
I then performed a Chi-squared goodness of fit test. The output of the test "p" tells you the probability that the distribution is a normal distribution. But be careful here. You can only confidently say that the distribution is not normal when p < 0.05. Otherwise you can't really say much.
Here are the results, depending on the number of bins:
10 bins:
p (1970 to 2007): 0.2097
p (1970 to 2011): 0.0766
15 bins:
p (1970 to 2007): 0.5536
p (1970 to 2011): 0.0021
20 bins:
p (1970 to 2007): 0.2895
p (1970 to 2011): 0.1234
25 bins:
p (1970 to 2007): 0.6482
p (1970 to 2011): 0.2923
So it wasn't unreasonable to assume a normal distribution of housing price changes. Ideally the results should be more granular, and it's a very limited dataset (only 167 values).
The code used to do this was:
The lowest value was Q1 of 2008 in which housing prices dropped 7.8% in one quarter. If a normal distribution was used from 1970-2007, then dropping 7.8% in one quarter was 5.4 standard deviations from the mean. Put another way, if we assumed a normal distribution, the chance of getting a drop in prices of 7.8% or greater was .00000002.
So I downloaded the raw housing data from each quarter from 1970 to 2011 from http://www.jparsons.net/housingbubble/ and performed some very simplistic analysis using Matlab.
I calculated the change in inflation-adjusted housing prices from each quarter, resulting in 167 values.
Here is a histogram of the change in housing prices from 1970 to 2007 with 15 bins (15 unique x-axis values):
Here is a histogram of the change in housing prices from 1970 to 2011 with 15 bins (15 unique x-axis values):
You can clearly see that from 2007 to 2011, the distribution looks more skewed.
I then performed a Chi-squared goodness of fit test. The output of the test "p" tells you the probability that the distribution is a normal distribution. But be careful here. You can only confidently say that the distribution is not normal when p < 0.05. Otherwise you can't really say much.
Here are the results, depending on the number of bins:
10 bins:
p (1970 to 2007): 0.2097
p (1970 to 2011): 0.0766
15 bins:
p (1970 to 2007): 0.5536
p (1970 to 2011): 0.0021
20 bins:
p (1970 to 2007): 0.2895
p (1970 to 2011): 0.1234
25 bins:
p (1970 to 2007): 0.6482
p (1970 to 2011): 0.2923
So it wasn't unreasonable to assume a normal distribution of housing price changes. Ideally the results should be more granular, and it's a very limited dataset (only 167 values).
The code used to do this was:
[~, p] = chi2gof( quarterly_change(1:150), 'nbins', nbins )
[~, p] = chi2gof( quarterly_change(1:167), 'nbins', nbins )
The lowest value was Q1 of 2008 in which housing prices dropped 7.8% in one quarter. If a normal distribution was used from 1970-2007, then dropping 7.8% in one quarter was 5.4 standard deviations from the mean. Put another way, if we assumed a normal distribution, the chance of getting a drop in prices of 7.8% or greater was .00000002.
normcdf( -.0784, mean(quarterly_change(1:150)), std( quarterly_change(1:150) ) )Put another way, the chance of it dropping between 0% and 7.8% and was 39.8%.
ans = 1.9682e-008
normcdf( 0, mean(quarterly_change(1:150)), std( quarterly_change(1:150) ) ) ...
- normcdf( -.0784, mean(quarterly_change(1:150)), std( quarterly_change(1:150) ) )
ans = 0.39804
Wednesday, February 8, 2012
TEncryption Hash Algorithm Part 2
In 2009, I made a post about turning a 4-bit hash algorithm into an 8-bit hash algorithm.
My idea was:
"My Password" --> 1100 --> {"11", "00"} --> {0100, 1011} --> 01001011
However, after reading it over, I realized that there was a gaping flaw. The probability of a collision wouldn't change!
Let's say "Password a" and "Password b" both hash to a 4-bit value of 0101. They would both hash to the same 8-bit value in my implementation. This is a major issue, because in theory, an 8-bit hash algorithm should have significantly less collisions (2^4 / 2^8 = 1/16 less chance of a collision).
So how to avoid this issue? Simple. Don't use the 4-bit hash as the basis for the 8-bit hash. Rather, use permutations of the password as the basis for the 8-bit hash. This can include reversing the password, truncating the password, or rearranging the password. This will, in theory, decrease the number of collisions.
How about an example?
Previous implementation with collision:
"Password a" --> 1110 --> {"11", "10"} --> {1100, 1011} --> 11001011
"Password b" --> 1110 --> {"11", "10"} --> {1100, 1011} --> 11001011
New implementation with the same possible collision:
"Password a" --> {"Password a", "a drowssaP"} --> {1110,0110} --> 11100110
"Password b" --> {"Password b", "b drowssaP"} --> {1110,1000} --> 11101000
The point is just because one permutation of a password results in a collision with another password, with a good hash function, there is no indication that another permutation will also result in a collision.
Still, though, concatenation means that precomputing hashes of unsalted, known, commonly used passwords will help you figure out half the resulting hash is problematic. In the above example, the first four bits are 1110 in both passwords because of the collision. So to overcome that issue, you can salt the passwords with the username, or file name, or whatever, which should really be done anyway.
New implementation with salting
"Password a" --> {"Username, Password a", "Username, a drowssaP"} --> {1111,0110} --11100110
"Password b" --> {"Username, Password b", "Username, b drowssaP"} --> {0110,1000} -->01101000
New implementation with salting
My idea was:
"My Password" --> 1100 --> {"11", "00"} --> {0100, 1011} --> 01001011
However, after reading it over, I realized that there was a gaping flaw. The probability of a collision wouldn't change!
Let's say "Password a" and "Password b" both hash to a 4-bit value of 0101. They would both hash to the same 8-bit value in my implementation. This is a major issue, because in theory, an 8-bit hash algorithm should have significantly less collisions (2^4 / 2^8 = 1/16 less chance of a collision).
So how to avoid this issue? Simple. Don't use the 4-bit hash as the basis for the 8-bit hash. Rather, use permutations of the password as the basis for the 8-bit hash. This can include reversing the password, truncating the password, or rearranging the password. This will, in theory, decrease the number of collisions.
How about an example?
Previous implementation with collision:
"Password a" --> 1110 --> {"11", "10"} --> {1100, 1011} --> 11001011
"Password b" --> 1110 --> {"11", "10"} --> {1100, 1011} --> 11001011
New implementation with the same possible collision:
"Password a" --> {"Password a", "a drowssaP"} --> {1110,0110} --> 11100110
"Password b" --> {"Password b", "b drowssaP"} --> {1110,1000} --> 11101000
The point is just because one permutation of a password results in a collision with another password, with a good hash function, there is no indication that another permutation will also result in a collision.
Still, though, concatenation means that precomputing hashes of unsalted, known, commonly used passwords will help you figure out half the resulting hash is problematic. In the above example, the first four bits are 1110 in both passwords because of the collision. So to overcome that issue, you can salt the passwords with the username, or file name, or whatever, which should really be done anyway.
New implementation with salting
"Password a" --> {"Username, Password a", "Username, a drowssaP"} --> {1111,0110} --11100110
"Password b" --> {"Username, Password b", "Username, b drowssaP"} --> {0110,1000} -->01101000
New implementation with salting
(assuming "Username, Password ..." results in collision)
"Password a" --> {"Username, Password a", "Username, a drowssaP"} --> {0110,0110} --> 11100110
"Password b" --> {"Username, Password b", "Username, b drowssaP"} --> {0110,1000} --> 11101000
The only advantage of this is that an attacker could have precomputed that "Password a" hashes to 1110 if "Password a" is a commonly used password, but precomputing wouldn't help when salting.
Another "attack" on this idea is the fact that there might not actually be 2^8 unique hashes. This is because some 8-bit hashes might be impossible to construct from existing 4-bit hashes, and hence an attacker can significantly limit the search space if implausible hashes were to be precomputed. This, however, would be very difficult to do and would take a bit more brain power to figure out than I have available right now, although I recognize the theoretic possibility.
The only advantage of this is that an attacker could have precomputed that "Password a" hashes to 1110 if "Password a" is a commonly used password, but precomputing wouldn't help when salting.
Another "attack" on this idea is the fact that there might not actually be 2^8 unique hashes. This is because some 8-bit hashes might be impossible to construct from existing 4-bit hashes, and hence an attacker can significantly limit the search space if implausible hashes were to be precomputed. This, however, would be very difficult to do and would take a bit more brain power to figure out than I have available right now, although I recognize the theoretic possibility.
Tuesday, January 17, 2012
A Day In The Life Of...
Here's an interesting way of thinking about life and perhaps putting it in perspective. This may be motivational or demotivational to you; I'm not sure.
So let us say that you will live to 80 years old, which is reasonable in America. Assume that your life was compressed into a single day. Here is what it would look like.
At 24 years old, It's only around 10:50 am for me; I have a long day ahead of me and must get to work!
So let us say that you will live to 80 years old, which is reasonable in America. Assume that your life was compressed into a single day. Here is what it would look like.
| Hour | Age | |
|---|---|---|
| 6am - 7am | 0 - 5 years old | You just wake up. You're still a bit groggy, and are getting used to your surroundings. |
| 7am - 9am | 6 - 15 years old | You are up and exploring the world around you. Going through some trials and having some fun. |
| 9am - 11am | 16 - 25 years old | You venture outside, go to some parties, and hang out with your friends |
| 11am - noon | 26 - 30 years old | You first arrive at work, and try to prove that you belong to be there |
| noon - 7pm | 31 - 65 years old | Your most productive hours at your job, and the time you really establish your place. |
| 7pm - 8pm | 66 - 70 years old | You start to leave and retire for the evening |
| 8pm - 10pm | 71 - 80 years old | This is your time to do as you please. Have a few drinks before bed, and enjoy yourself. |
Friday, January 6, 2012
Craftsmanship
Since finishing my classes 2 semesters ago, most of my graduate school time has been split between writing papers and writing code. I must say I enjoy writing code more, but the papers have their purposes.
I have spent a good deal of time learning about how professionals write "good" code. I put that word in quotes because good isn't an objective measure, and is different for each project.
But I have come to see a beauty in the algorithms, libraries, protocols, and such. When I see a well designed project on github, or learn about how a large company uses version control to automatically distribute releases, or delve into the intricacies of the efficient and stable ZFS filesystem, I can't help but see the beauty in the system.
All the pieces have been so well designed, meant to perfectly fit together. The internal structure of the gas tank doesn't need to be visible to the engine, and the internal structure of the engine doesn't need to be visible to the driver. But when a car aficionado opens the hood of a well designed piece of machinery, he sees how beautifully designed every single piece has been, carefully fit together with its neighbor.
Then you take a step back, and realize that many of the pieces are actually used in other models. So you take another step back and see the beauty of the manufacturing process efficiency. Each piece has been designed minimize the ugly overhead of redesigning things for each new model, although this is sometimes necessary. I saw a commercial for a new Lexus car, in which they touted making a fuel optimizer system which can input any type of fuel, "even ones that haven't been invented yet." A simple improvement to a base system (such as a nut or bolt) can have a ripple effect of betterment for far reaching systems.
I am no car aficionado, but that's the type of beauty I see in a piece of software. And that's the type of craftsmanship I strive for in my own projects, research or otherwise.
I have spent a good deal of time learning about how professionals write "good" code. I put that word in quotes because good isn't an objective measure, and is different for each project.
But I have come to see a beauty in the algorithms, libraries, protocols, and such. When I see a well designed project on github, or learn about how a large company uses version control to automatically distribute releases, or delve into the intricacies of the efficient and stable ZFS filesystem, I can't help but see the beauty in the system.
All the pieces have been so well designed, meant to perfectly fit together. The internal structure of the gas tank doesn't need to be visible to the engine, and the internal structure of the engine doesn't need to be visible to the driver. But when a car aficionado opens the hood of a well designed piece of machinery, he sees how beautifully designed every single piece has been, carefully fit together with its neighbor.
Then you take a step back, and realize that many of the pieces are actually used in other models. So you take another step back and see the beauty of the manufacturing process efficiency. Each piece has been designed minimize the ugly overhead of redesigning things for each new model, although this is sometimes necessary. I saw a commercial for a new Lexus car, in which they touted making a fuel optimizer system which can input any type of fuel, "even ones that haven't been invented yet." A simple improvement to a base system (such as a nut or bolt) can have a ripple effect of betterment for far reaching systems.
I am no car aficionado, but that's the type of beauty I see in a piece of software. And that's the type of craftsmanship I strive for in my own projects, research or otherwise.
Thursday, January 5, 2012
Food Cost Basis
My good friends Joe and Clair, with whom I spend New Years Eve 2011, have decided that I need to write more blog posts, and even went so far as to suggest that it should be my new years resolution. So this is my first one of 2012.
As I think about the price of groceries, and food in general, I intuitively would look at the "$ / pound" label in the supermarket as my normalized basis for how much things actually cost. But that doesn't consider the nutritional content, as well as the amount of sustenance (calories) you actually get for that $.
Let's consider Kraft's 4% Cottage Cheese. Shoprite had this for $1.89 / container this week. The nutritional information lists 120 calories per 1/6 container. That comes to 720 calories / $1.89 or 380 calories / $. If you were on a 2000 calorie diet per day, it would cost you $5.25 to eat only cottage cheese that day.
If we look at a Subway Spicy Italian Sub, the footlong sub costs $5, and contains 960 calories. So that would cost you $10.40 per day, or 192 calories per $.
Just for fun, let's consider vodka. A handle is 1.5 liter, and contains 50 oz. In 80 proof vodka, 1 fluid oz is 64 calories. This means that vodka gives you 162 calories per dollar.
So this is just me ranbling on about random costs of food, and a list of some others I calculated can be found here, sorted by Calories / $. Turns out rice is the cheapest; who would have guessed. Also I completely ignored nutritional value in all of this analysis. I should really consider macronutrient composition of various foods and how much nutrition you get per dollar, not just how much energy. Maybe another time.
As I think about the price of groceries, and food in general, I intuitively would look at the "$ / pound" label in the supermarket as my normalized basis for how much things actually cost. But that doesn't consider the nutritional content, as well as the amount of sustenance (calories) you actually get for that $.
Let's consider Kraft's 4% Cottage Cheese. Shoprite had this for $1.89 / container this week. The nutritional information lists 120 calories per 1/6 container. That comes to 720 calories / $1.89 or 380 calories / $. If you were on a 2000 calorie diet per day, it would cost you $5.25 to eat only cottage cheese that day.
If we look at a Subway Spicy Italian Sub, the footlong sub costs $5, and contains 960 calories. So that would cost you $10.40 per day, or 192 calories per $.
Just for fun, let's consider vodka. A handle is 1.5 liter, and contains 50 oz. In 80 proof vodka, 1 fluid oz is 64 calories. This means that vodka gives you 162 calories per dollar.
So this is just me ranbling on about random costs of food, and a list of some others I calculated can be found here, sorted by Calories / $. Turns out rice is the cheapest; who would have guessed. Also I completely ignored nutritional value in all of this analysis. I should really consider macronutrient composition of various foods and how much nutrition you get per dollar, not just how much energy. Maybe another time.
Subscribe to:
Posts (Atom)