I've been studying it for years and years and still don't think I know anything.
And yet you're expecting someone whose expertise is in a different field to know more about it than you?
We can't all be experts in everything. If you're the expert in the field of discussion, get used to educating your coworkers on the topic, or find another job where you're surrounded by people with the same education and expertise as you.
The average person is an expert in no more than two or three related areas. That's why people work in teams, to cover each other's blind spots.
having more than one way to do something can have a variety of benefits:
1) power users can take a faster path to the action and avoid confirmation dialogues when they know what they're doing. Terminal/console windows are great examples.
2) there's often two or more "intuitive" places for something to be. instead of picking one, put it in both places and it becomes a tad easier for 50% of the population to use. Is sleep after so long in screensaver a screensaver feature or an energysaver feature? Give access from both panels and make things easier for the users.
if you don't have a good understanding of algebra and geometry, computer graphics coding is going to suck for you.
I decided to write a primitive FPS, and the 3d rendering was an amazing retro back to the days of geometry... it would be totally impossible without a good background in geometry.
Here's a simple one to wrap your mind around: lets say we're in a 2.5-D world. (there's a vertical element to view, but all walls extend from floor to ceiling, so it's basically 2D rendered in 3D) To draw the walls in the player's view you can take two approaches, depending on your language's graphics speed. (1) draw only the parts of the walls you have to, or (2) draw all the walls in view, from farthest to nearest, so the nearer walls draw over the farther ones. For the language I used, it was (2).
So, what order to draw them in? Easy to determine really, but it relies on calculating intercept points. Given walls A and B, that have endpoints AX1,AY1 AX2,AY2 BX1,BY1 BX2,BY2, and the player's point PX,PY, you need to see if A blocks your view of B (one or both of its endpoints, or entirely) or vice versa or not at all. Then just draw the wall that is blocked first. Now start thinking about the math involved in doing that. iirc there were 28 distinct ways the two lines could be oriented relative to the observer, and I had an 18 page if-then-else ratsnest that ended up being a nightmare to debug but ran nice and fast.
Required mostly being able to calculate x and y intercepts as well as whether intercepts were on the line, or on the line segment. The math of drawing the walls themselves was trivial by comparison with the math to figure out the order of drawing. I can't imagine the headache of a true 3D world with three-dimensional space and polygons.
I don't think it's much of a reach to say that 50% of that money was simply cash shuffling sideways within the company, and that anyone believing "20th Century Fox uncertain about whether the $430 million that it and two financing partners had invested to produce and market the 3-D film would pay off" are complete chumps. They may have been uncertain if their overinflating internal numbers was going to "show" a profit or not, but there was simply no chance that they were going to actually lose money on it.
Nowadays with Hollywood Accounting, any movie that actually "shows" a profit made an absolute killing.
That being said, I really enjoyed the movie, and will be buying the bluray. (once thank you, not the initial release, the remaster, the director's cut, and the collector's edition..)
If you think about it, it's allowing China to profit twice on the same resource. They get mark-up on the material, and then if you have to process it in-country, they get markup a second time in processing. They'd be fools to do it any other way, since there's approximately zero chance of anyone bringing rare earths INTO China and providing them with processing business for ore other than that produced in-country. Processing their own ore is the only way they make business on it, may as well demand all you can.
Comments (and self-documenting code) should tell you "what" and "why", because the code is telling you "how".
Well-said. I will have to remember that. I'll rephrase it a bit, "the code only tells you the how, the comments tell you the what and more importantly, the why."
Re:One person's myth is another person's fact.
on
Myths About Code Comments
·
· Score: 5, Informative
I find the most important comments are those that tell you WHY something was done the way it was. I do this with my own code when I track down and fix a bug that turns out to be caused by some very subtle effect or easily made mistake. I put the comment there to stop myself (or someone else) from "fixing" / "cleaning it up" later because they don't realize why it's done the way it is. Comments like:
# yes, 1, not 0. If all four of the lists are allowed to go to 0, we will blow up later with DBZ.
And having a sometimes very poor memory of code written long ago, this saves me from myself more than others.
2. Where do you draw the line between admin and user? At my current employer roughly 1/3 of the staff administers something or other with lots of overlap.
There's probably already some major problems to iron out if you only have two tiers of users, admins and non admins.
Delegate authority and power in tiers. Don't hand out power to everyone in authority just because they're in authority. The guy handling the trouble tickets does not need the root pw on the db server. Nor does his manager. The people with the most understanding of each system should be the ones that have their paws in it. In the end it also requires fewer people when it's clear exactly who's responsible for what, and knowing that there aren't a half dozen randoms to factor in when working on something. ("is this a hardware problem, or did Bob monkey with it again?") It also removes the need for overlap to combat "I thought YOU were working on that?" fails.
Why is it ok to patent something physical, but not ok to patent software? I have never understood the distinction.
It's a lot easier to patent a specific method or physical design than it is to patent a program. The difficulty is where do you draw the line? Like patenting a song... what if I change a single note, does your patent apply? It's trivial for someone to take a chunk of code and make periodic, trivial changes, such a swapping order of adjacent instructions, and make it physically very different without changing it at all, and that clearly would allow someone to violate your IP if that's all it took.
So having a way to make clear rules is a big factor. For instance, in music it can get down to counting the number of identical notes in a row.
Programming also has other issues that are unique. Given the restrictions of a language, the simpler a task, the fewer ways there are available to you to perform the task. Opportunities for diversity grow rapidly as the code gets more complex, but at the same time those that want to patent their code then tend to want more general interpretation because it becomes increasingly easy to make minor changes to their work and now call it your own. Very basic and very well-known tasks have a single known most-efficient method to code them - such as a bubble sort in C, that any skilled programmer could develop independently. Those must fall into the area of "obvious", which is not patentable.
you just answered your own question. you'd count, "0", "00", "000", "0000" etc. It'd just be really inefficient for large (in more ways than one!) numbers.
yep I forgot to mention that the statement depends on what the existing cooling situation is. If it's already wrapped in a perfect insulator, then of course the heat reclamation will improve cooling. OTOH if it's already attached to a good heat dissipator, (and sweat evaporation is very effective) then you're going to reduce cooling efficiency, and that's what this thing is doing as far as I can tell.
Slashdot Mirror
Unless you share and/or have a very... interesting toy.
chobits!
Just avoid the Ginsu brand
(just look at that tomato!)
But, who knows, maybe somebody will start a company reverse engineering Psystar's DRM so for a small fee you can get your computer working again
I think I'm going to make up a new phrase for that: recursive irony
I've been studying it for years and years and still don't think I know anything.
And yet you're expecting someone whose expertise is in a different field to know more about it than you?
We can't all be experts in everything. If you're the expert in the field of discussion, get used to educating your coworkers on the topic, or find another job where you're surrounded by people with the same education and expertise as you.
The average person is an expert in no more than two or three related areas. That's why people work in teams, to cover each other's blind spots.
Google reportedly does not have plans to actively become an energy broker, a la Enron."
I rather doubt anyone has plans to be "a la Enron"
having more than one way to do something can have a variety of benefits:
1) power users can take a faster path to the action and avoid confirmation dialogues when they know what they're doing. Terminal/console windows are great examples.
2) there's often two or more "intuitive" places for something to be. instead of picking one, put it in both places and it becomes a tad easier for 50% of the population to use. Is sleep after so long in screensaver a screensaver feature or an energysaver feature? Give access from both panels and make things easier for the users.
That's also a good point. Like they were trained to know what C4 smells like? lol
fwiw, touching C4 with your bare hands gets some of the chemical immediately taken in by the skin and gives an almost instant intense migraine.
What 'fumes' exactly come from honey?
100% psychological of course. They expected to smell something evil, and thus they got sick. Makes no difference what they smelled. No surprise.
But the bees stored the honey in terrorist cells
if you don't have a good understanding of algebra and geometry, computer graphics coding is going to suck for you.
I decided to write a primitive FPS, and the 3d rendering was an amazing retro back to the days of geometry... it would be totally impossible without a good background in geometry.
Here's a simple one to wrap your mind around: lets say we're in a 2.5-D world. (there's a vertical element to view, but all walls extend from floor to ceiling, so it's basically 2D rendered in 3D) To draw the walls in the player's view you can take two approaches, depending on your language's graphics speed. (1) draw only the parts of the walls you have to, or (2) draw all the walls in view, from farthest to nearest, so the nearer walls draw over the farther ones. For the language I used, it was (2).
So, what order to draw them in? Easy to determine really, but it relies on calculating intercept points. Given walls A and B, that have endpoints AX1,AY1 AX2,AY2 BX1,BY1 BX2,BY2, and the player's point PX,PY, you need to see if A blocks your view of B (one or both of its endpoints, or entirely) or vice versa or not at all. Then just draw the wall that is blocked first. Now start thinking about the math involved in doing that. iirc there were 28 distinct ways the two lines could be oriented relative to the observer, and I had an 18 page if-then-else ratsnest that ended up being a nightmare to debug but ran nice and fast.
Required mostly being able to calculate x and y intercepts as well as whether intercepts were on the line, or on the line segment. The math of drawing the walls themselves was trivial by comparison with the math to figure out the order of drawing. I can't imagine the headache of a true 3D world with three-dimensional space and polygons.
Instead of spending $430million
I don't think it's much of a reach to say that 50% of that money was simply cash shuffling sideways within the company, and that anyone believing "20th Century Fox uncertain about whether the $430 million that it and two financing partners had invested to produce and market the 3-D film would pay off" are complete chumps. They may have been uncertain if their overinflating internal numbers was going to "show" a profit or not, but there was simply no chance that they were going to actually lose money on it.
Nowadays with Hollywood Accounting, any movie that actually "shows" a profit made an absolute killing.
That being said, I really enjoyed the movie, and will be buying the bluray. (once thank you, not the initial release, the remaster, the director's cut, and the collector's edition..)
If you think about it, it's allowing China to profit twice on the same resource. They get mark-up on the material, and then if you have to process it in-country, they get markup a second time in processing. They'd be fools to do it any other way, since there's approximately zero chance of anyone bringing rare earths INTO China and providing them with processing business for ore other than that produced in-country. Processing their own ore is the only way they make business on it, may as well demand all you can.
Comments (and self-documenting code) should tell you "what" and "why", because the code is telling you "how".
Well-said. I will have to remember that. I'll rephrase it a bit, "the code only tells you the how, the comments tell you the what and more importantly, the why."
he must be able think all the possible ways the thing can be done.
So, quoting a certain clever someone, "you've just go to think fourth-dimensionally"
oh wait, it wasn't broken, was it?
drat. can't bash. lets post to slashdot anyway!
I find the most important comments are those that tell you WHY something was done the way it was. I do this with my own code when I track down and fix a bug that turns out to be caused by some very subtle effect or easily made mistake. I put the comment there to stop myself (or someone else) from "fixing" / "cleaning it up" later because they don't realize why it's done the way it is. Comments like:
# yes, 1, not 0. If all four of the lists are allowed to go to 0, we will blow up later with DBZ.
And having a sometimes very poor memory of code written long ago, this saves me from myself more than others.
2. Where do you draw the line between admin and user? At my current employer roughly 1/3 of the staff administers something or other with lots of overlap.
There's probably already some major problems to iron out if you only have two tiers of users, admins and non admins.
Delegate authority and power in tiers. Don't hand out power to everyone in authority just because they're in authority. The guy handling the trouble tickets does not need the root pw on the db server. Nor does his manager. The people with the most understanding of each system should be the ones that have their paws in it. In the end it also requires fewer people when it's clear exactly who's responsible for what, and knowing that there aren't a half dozen randoms to factor in when working on something. ("is this a hardware problem, or did Bob monkey with it again?") It also removes the need for overlap to combat "I thought YOU were working on that?" fails.
third state change, not third state
or just toss your HD in a forge furnace. You should get two phase changes.
OR better yet... a "hardware override"?
Louisville Sluggers provide a great brute-force technique.
Could we consider that a "hardware failure"?
I'm surprised that this is their most advanced model and appears to have no wrist articulation whatsoever.
And the index finger control was obviously off by quite a bit.
NOT impressed. Anyone remember their Robotron? and this is all the better we've gotten in all those years?
Why is it ok to patent something physical, but not ok to patent software? I have never understood the distinction.
It's a lot easier to patent a specific method or physical design than it is to patent a program. The difficulty is where do you draw the line? Like patenting a song... what if I change a single note, does your patent apply? It's trivial for someone to take a chunk of code and make periodic, trivial changes, such a swapping order of adjacent instructions, and make it physically very different without changing it at all, and that clearly would allow someone to violate your IP if that's all it took.
So having a way to make clear rules is a big factor. For instance, in music it can get down to counting the number of identical notes in a row.
Programming also has other issues that are unique. Given the restrictions of a language, the simpler a task, the fewer ways there are available to you to perform the task. Opportunities for diversity grow rapidly as the code gets more complex, but at the same time those that want to patent their code then tend to want more general interpretation because it becomes increasingly easy to make minor changes to their work and now call it your own. Very basic and very well-known tasks have a single known most-efficient method to code them - such as a bubble sort in C, that any skilled programmer could develop independently. Those must fall into the area of "obvious", which is not patentable.
Your numbers would always be 0, or 00, or 000
you just answered your own question. you'd count, "0", "00", "000", "0000" etc. It'd just be really inefficient for large (in more ways than one!) numbers.
yep I forgot to mention that the statement depends on what the existing cooling situation is. If it's already wrapped in a perfect insulator, then of course the heat reclamation will improve cooling. OTOH if it's already attached to a good heat dissipator, (and sweat evaporation is very effective) then you're going to reduce cooling efficiency, and that's what this thing is doing as far as I can tell.