That assumption should have been stated in the explanation and the graphics need to reflect that constraint, right? Or am I still missing something here?
I was able to do it with my jeans, so I expect it's possible with any trousers. You should note that the inversion is not symmetrical. You are basically pulling one pant leg into the other one. In the end you are left with one pant leg which is inside-out and straight and the other pant leg is inside of the first.
The inversion of the parameters is now noticeable. You started with basically a donut with a very wide hole (formed by the pant legs -- I'm ignoring the hole where your waist goes). After the inversion, the pant legs form a donut which is very narrow (just the width of the inside of the pant leg) and is very tall (the height of the pant leg).
I stared at the animated example for nearly two hours last night. I did get the one leg inside of the other donut, but it didn't /look/ like the animated example, so I disregarded it. Thank you -- "not symmetrical" did not occur to me -- it was bugging me. There's a lot of this same sort of visual thought that goes into designing various garments, but the surface is not a torus.
The program is drawing on a grid 9 wide by 10 high. The loop is going over each space in this grid. It puts a * in each cell that falls within the equations described by the four inequalities. Here's a slightly more simplified version.
int putchar ( int ) ;
int main ( void )
{
int z;
int width = 9;
int height = 10;
for (z = 0; z < width * height; z++)
{
int x = z % width;
int y = z / width;
putchar (
x + y > 3 && /* top left */
x + y < 14 && /* bottom right */
y < x + 6 && /* bottom left */
y > x - 5 /* top right */
? '*' : ' ' );
if (x == width - 1)
putchar ( '\n' );
};
putchar ( '\n' ) ;
return 0;
}
It would be clearer to separate the main loop into nested loops for x and y, but I've left it as is to show a closer resemblance to the previous version.
The fun part is that you can now play with the various settings. Try increasing the height and width and scaling the equations appropriately. Replace x by 2 * x or x * x for more interesting shapes. You can bound the picture by any equations you like. Example: http://ideone.com/53Qh3
It's much much harder to gain muscle and lose fat simultaneously, than it is to simply focus on one then the other. They are fundamentally at odds with each other: to lose fat, you need less calories; to gain muscle, you need more calories.
The advice I've heard is to build strength and size first, by eating lots and training hard until you have the muscles you're after. Then you can turn your attention to losing fat and maintaining muscle, by eating less (though you'll still need more calories than before, as larger muscles burn a lot more energy even at rest), lowering the intensity of your training, and focusing more on cardiovascular exercise like jogging and cycling.
Up to a certain point, you can do both just by exercising more and harder. A complete beginner starting from zero volume will definitely lose fat and gain muscle if they start working out, as long as they eat no more than enough to maintain their weight. The only problem is that you can only do it if you're pretty poorly trained to start with. Most people who work out seriously are well past the point where they can do both at the same time.
Do you really need to do both? Seems to me you should lose fat first, for the health benefits if nothing else.
Try two things: rowing and push-ups. Rowing is spectacularly good cardiovascular exercise, and once you work your way up to 45+ minutes a day, you'll lose weight fairly rapidly. Rowing does not build muscle, but it does tone what you have. Once you've lost fat and toned up, you might actually like the results. If you don't, then start weight training. Starting Strength, etc.
As for push-ups, they're just plain good for you. Start something like the "hundred push-ups" program.
For your diet, just eat healthy meals and don't obsess with counting calories for now.
That's a pretty difficult path to follow. Chances are you'll end up not eating enough, and start burning muscle in addition to fat. If you lose more than about 1 kg / ~2.2 lbs a week, you're at risk of doing just that. On the other extreme, you can easily wind up eating too much, and gaining more than fat than actual muscle.
To really know what's going on, you'd of course have to measure actual body fat lost, rather than just weight lost. Muscles weigh more than fat, some build muscle more easily than others, etc.
Generally I'd say there's a reason most body builders bulk up for months, then spend time dropping excess weight, rather than aiming for a steady increase in muscle mass with zero fat gain.
For the most, my experience is that aiming for slow weight / fat loss through any muscle exercise is also bound to provide some muscle build up. That seems adequate for most people.
Eat meat and veggies. Eliminate any foods that are white and come in a box or bag from the middle of the supermarket. Walk a lot in between working out, and swim from time to time.
Go for a caloric surplus (and hit proteins) shortly after you finish your workout when your muscles are rebuilding / recharging, while keeping a caloric deficit for the whole day.
Have to disagree with people who say you do one and not the other.
Building muscle, without changing your diet, will cause changes in your body that will reduce the impact of what you eat. A pound of muscle takes ~100 calories a day to survive, a pound of fat ~10. It also changes your body in other, more subtle ways.
Serious low-carb dieters (as opposed to people who just binge on meat instead of cake) often do weight-training. (Especially women!)
They eat 11-15 calories/lb of current body weight, with lots of protein, which sustains them healthily and creates a caloric deficit. (And the ketosis helps.)
"A pound of muscle takes ~100 calories a day to survive"
This defies math when on the order of 1/3rd of your weight is muscle. The more commonly cited value is 50 calories a pound, and even that appears too high.
If the conjecture is true then any finite sequence of numbers can be found in the digits of pi. As others have noted, infinite sequences are not guaranteed or even likely to appear. As zackattack points out, for example, the decimal expansion of 1/9 does not appear in the digits of pi.
From the article it appears that in "rechtub klat" the letters in a word are reversed, but the words have the same order in the sentence. So it would be:
I'm a single developer who has recently switched from subversion to git and I'm having a few problems adjusting. My setup is that I work on my code from various places (home, laptop, school) and I want to a consistent view of my code from each place. That is, if I create a git branch at home and write some code in it, I want to see that branch right away when I start working from school.
Right now, I have a main server set up where I push my changes to after finishing work for the day. But now suppose I create some new tags and branches. I need to do
git push --all
git push --tags
Then when I start working from a different location next time, I do
Where I have to do the last command for each new branch that I want to see in my working copy. Things are even worse when I want to delete a branch (after having merged it into the mainline). I do
And this will remove the branch from the local repository and my main repo, but at each of the other repositories I still need to delete the remote tracking branch.
Does anybody know a way to simplify this workflow with git?
From location1, if you just want to be able to make your working copy look like origin/<branchname>, you don't have to create a new branch. You can checkout on a tracking branch. You just can't do all your normal work there (i.e., when you want to commit, you'd need to checkout a branch to commit on). If you want to create local branches that track all the remote branches, the command you're currently using (minus the --track option) is what you need.
As for deleting a branch, the simplest way is to not push branches that you're not going to keep. I understand what your context is, so you'll likely be stuck with maintaining branches in your central repository.
There's not a dramatic simplification I can see in your workflow, but here's where Git's strong-suit really kicks in: it's very, very scriptable. It would be nearly trivial to write simple bash scripts to do most of this in one command (you might even be able to get there with aliases).
Regarding the push command, it currently does not allow both the --all and --tags options to be used together (very strange).
Regarding not pushing temporary branches, this seems contrary to one of the reasons I started using git: it makes branches cheap and easy to throw away when you are done with them.
I can understand the way git works regarding each developer using only the branches they are interested in, but I can't seem scale this philosophy down to a single developer. I want all my working copies to be the same. I want new branches to propagate. I want branch deletions to propagate.
I've thought about scripting some of this, but for some pieces I am not sure how to proceed. Consider branch deletion. The problem here is that I can delete the branch from the main repository, but that doesn't force deletion for each of the clients. Instead, I would need to write a custom "git pull" style command that I run in a working directory before I start my work. Should this command delete all remote branches so that actual deletions are propagated, and then "git pull" restores the remote branches which still exist?
[edit: I've discovered that "git remote prune" will delete remote tracking branches that are no longer in the repo]
Don't other git users have this issue? Presumably there are others who work from more than one location and want a consistent view from each, yet I can't seem to google for any help on these issues.
Yeah, I realized post-facto that --all and --tags doesn't work. Alternatively, you can list your tags with things to push, like
git push origin master my-tag ...
That might also work with --all. If it does, you could get away with:
git push --all origin my-tag
As for the rest...I'm not sure what your best way forward is. One way might be simply to don't delete branches. They'll clutter the list of branches, but so what? Just ignore them if you don't use them.
The 'git remote prune' way is probably best. Run that, and then check for local branches that aren't tracking a remote. That's scriptable.
I don't think there's a simple and elegant answer here, because what you're doing basically turns Git into subversion. That's pretty much unavoidable when one is doing what you're doing.
You could be more "distributed" if you only worked on specific features or modules (or whatever) at specific locations. Then you could just merge when necessary instead of always having to keep your branches in sync :-)
I have a similar work flow to yours and I experience many of the same problems you do with DVCS. I'm currently thinking about just using rsync to keep my development environments the same. I haven't made this move yet but, I can't think why I couldn't.
