Crap, I'm a moron. I had a bug in the regular expression, and I managed to work around it with the other code, causing the problems. This caused the code to insert a 0 between everything, yielding the alternating +/- numbers, and the "o" oddity was caused by two separators together in the source text.
Turns out all you need is one differentiation and a non-retarded regular expression that doesn't insert empty words between each pair of non-word characters.
I've also made the variable names resemble less those of the problem (read: not single-character madness). And added some comments.
text = "Ford's success has startled the country, almost the world, financially, industrially, mechanically. It exhibits in higher degree than most persons would have thought possible the seemingly contradictory requirements of true efficiency, which are: constant increase of quality, great increase of pay to the workers, repeated reduction in cost to the consumer. And with these appears, as at once cause and effect, an absolutely incredible enlargement of output reaching something like one hundredfold in less than ten years, and an enormous profit to the manufacturer"
def do_list(string):
return re.split(r"[,.:]+",string.lower()) # split by any combination of space, comma, period, colon.
def do_uniquify(lst):
out_l = []
for i in lst:
if i not in out_l: # ignore dupes
out_l.append(i)
return out_l
def do_relativity(textlist,datalist):
last_pos = 0 # keep track of last position
out_l = []
for word in datalist:
index = textlist.index(word) # find index in source text
out_l.append(index-last_pos) # differentiate index
last_pos = index
return out_l
That does you no good, since you need to write the proper function to proceed. Otherwise, the logic of the bottom block thing doesn't work. First, you need the proper Javascript function which implements the sticky block logic:
f = function(d) {
var h = d.length;
var w = d[0].length;
for(var y = h-2; y >= 0; y--) {
for(var x = 0; x < w; x++) {
if(d[y][x] &&
!dxy(x-1,y) &&
!dxy(x+1,y) &&
!dxy(x,y+1) &&
!(dxy(x+1,y+1) &&
dxy(x-1,y+1))) {
d[y][x]=false;
d[y+1][x]=true;
}
}
} }
This basically drops all the blocks in the field, unless they're touching another block on either side, below, or they're touching two blocks on both diagonal corners below. Here the field is an array of arrays, and the blocks are true or false.
Then, you get the Ford text plus a field in the bottom. The field accepts a list of integers. You have a "dropper". For each integer, the dropper moves that number of positions to the right (positive) or left (negative), and drops a block following your algorithm (that's why you need the JS function to work). Note that the positions are relative, not absolute.
Now for the Ford code. The hint is in the tooltip text. List, Uniquify, Relativity:
LIST the words in both the original text (from wikipedia) and the text that comes up after solving the problem. Split it into words (maintain apostrophes as part of words, since it's part of the word Ford's).
UNIQUIFY the original text, getting rid of duplicate words while maintaining the word order. Leave the first word of each.
RELATIVITY: Find the positions of each word in the mangled text from the original text. Given these positions, calculate the position change (relativize, differentiate, call it however you want). You'll get something like 0,-6,5,-5,4,-4,2,-2,1,-1,-1,1,-3,3,-4,4,-5,5.... Drop the first number of each pair (the initial zero is an artifact), leaving -6, -5, -4, -2... These are absolute positions of the dropper. Differentiate again, giving 0,1,1,2,1,2,2,1,1. Now that looks like a set of instructions for the dropper. Plug it in, and voila.
Here's the Python code to make it happen: #!/usr/bin/python
I don't have the function that passes the tests that they wanted yet
Here's a working non-cheating function, in case anyone cares. Basically, the logic is: from bottom to top (which ends up preserving the proper behavior for falling objects), drop blocks if there are no blocks to either side or below, and if at least one of the two diagonal corners below doesn't have a block. This is a rough simulation of falling and sticking blocks (it doesn't take into account the case of several horizontally stuck blocks which aren't resting at the bottom, which would cause them to hover in mid-air, but it passes the tests).
To put it another way: blocks fall unless they're stuck to either side, resting on another block, or have blocks diagonally below on both sides. And horizontal masses in mid-air hover because I'm too lazy to fix it.
f = function(d) {
var h = d.length;
var w = d[0].length;
False. Green laser pointers are about as powerful as red laser pointers. It's just that the human eye happens to be more sensitive to green light. The damage capability depends on power, not the perceived brightness, so they aren't more dangerous than red lasers.
Works fine for me. Are you sure you're not confusing/dev/null with/dev/zero? The latter's a real bitch, it's always too large for my destination drive! Gzip helps though; you can get compression ratios of approximately 2000:1.
I can fit the entire PACMAN arcade board (including the Z80) inside my S3E. 25% use, not counting RAM blocks, which are all in use because I'm too lazy to switch the code over to use an external ROM for the code. I have the $150 Spartan 3E Starter Kit.
The point is not to change everything. The point is to be able to change everything. If you look at my desktop, it isn't much changed from the default. I have an extra kicker panel on top with a few useful applets and I use the Polyester style, but other than that I haven't tweaked things much.
However, there are dozens of little tiny obscure features that I use and love, and that wouldn't exist if KDE weren't so configurable. Examples: I have a "stay on top" button on the window titlebars, which I use fairly often, I have several windows configured with custom settings through "Special Window Settings" (to make them show up on the right desktop, for example), I've disabled icons on my desktop altogether, I've tweaked my keyboard shortcuts and configured the extra keys on my keyboard for common actions, and a whole bunch of other little things that I've added over the years. These are less than 1% of the available options, but the point is that they're the 1% that I care about.
Gentoo will auto-run network init scripts when the network device appears. Stick your WiFi USB dongle in and Gentoo will automatically bring it up, as long as you have the init script configured.
I'm not sure about plugging in the cable (media detection instead of device detection), but I'd bet it's also implemented in some way.
It still happens. Nowadays it tends to be random files leftover in a game's directory structure. I seem to remember that Halo 2 came with a script file in one of the directories (I may be wrong on this one), and the Gamecube version of Twilight Princess comes with the Wiimote sounds still in there, plus a different file with some Mario sounds (maybe there's and embedded mario minigame in the Wii version? Or perhaps it's just a demo file). The GC TP also has a whole bunch of linker map files if I remember correctly.
Cubesats? 10x10x10cm, $65,00080,000 each. 5x5x5 seems pretty damn small to me (1/8th the volume of a cubesat), do those things exist? That would barely be even trackable, and fitting a gyro, electronics, a decent transmitter, a battery, and the solar panels into that thing would be an interesting exercise.
I'm on Florida Tech's FUNSAT team this year. And I'll make damn sure we have at least one funny easter egg or two in the software/transmissions, if we end up winning and making the thing.
Lights don't burn watts per hour, they burn watts. 2000 watts will give you 2000 watts of light for as many hours as you want. If you ran twenty 100watt bulbs at once, you'd use up that 2kw for as long as you wanted.
Watts are not a measurement of energy. They are a measurement of energy per time. The "per time" part is built-in to the unit watt. A 100 watt light bulb uses 100 joules per second, or 0.134102209 horsepower. Energy is also measured in watt-hours. That's watts TIMES hours, not watts per hour. a 1Wh battery will deliver one watt for an hour. Twenty 100watt bulbs at once will use 2kWh in an hour.
Good encryption doesn't work that way. That doesn't stop you from turning that hunk of random data into the Magna Carta. Or is using a crappy encryption algorithm illegal now?
Besides, it was just an example. Here's another one: give them the random data file again and a program that does an XOR. When they do random data XOR random data, they get all zeroes. That's the plaintext, all zeroes. Let them prove it isn't.
If it's less, duplicate the data or pad it. If it's more, compress the data or duplicate the original random data (requiring a larger key).
Of course, this develops into the argument of when does a set of data stop being encrypted content and start being the key. What if both files have an equal chance of being the key and the content, and are identical in function in practice? This causes a lot of fun legal problems. For example, you could have two sets of (by themselves) apparently random data that, when XORed, result in an MP3 file. But neither set is by itself representative of that MP3 file, and in fact one of them could be combined with a second file to produce a third set of data. 1 XOR 2 = file.mp3, 2 XOR 3 = private data. Do it the other way too, 0 XOR 1 = private data. Now which files constitute copyright infringement if distributed? Feel free to replace file.mp3 with CP and "copyright infringement" with "illegal contraband".
Even if you got 2kw per day out of the sun, that's only 20 hours for one 100 watt bulb. If you have a computer, fridge, 6 lights, and TV on, you could be hitting near 1000 watts per hour (depending on efficiency of course).
2kW per day is enough to run 20 100 watt bulbs by the end of the first day. After a year, you could be running your own datacenter.
Unless you're confusing watts with joules. But that's okay, since everyone does it, right? Right????
If done right, yes, it could be weeks or even months. It's definitely not going to die permanently - if you flip the switch in the back it would re-charge whatever. Even better, as I mentioned above, you could have a cycling system that detects when the capacitor or battery is close to discharged, uses what is left to start the PSU again, and recharges it (without really turning on the rest of the monitor).
Yes, it's the sync signal that triggers it. However, the sync signal is AC and consists of tiny pulses, with a very low duty cycle. The impedance is also relatively high. You just can't trip a relay directly with it. You also get into all sorts of issues with Sync-On-Green and whatnot. You can, however, use it to turn on a MOSFET that powers the relay from a battery or supercap, which will last a very, very long time without any power, since MOSFETs draw almost zero current when switched off.
Or a supercap, as I stated above. Supercaps are already used for this, to keep RTC clocks alive while wall power is off. Improve the power efficiency, throw in a bigger cap, and it will last pretty long.
As for LEDs, yeah, we can definitely get rid of a lot of them. Especially the clocks - there's next to no use for those, and they suck a lot of power.
Then use a cycle. Have, say, an aerogel capacitor charge up enough to run the LED for a few hours. When the capacitor is near to being discharged, switch on the standby power supply and recharge it. Lather, rinse, repeat. No need for a constantly running switching power supply, or solar panels, and standby acts just as it does now (with no time limit), just with lower power use.
I was debating whether devices with standby last longer or not, not how much power is used.
By the way, your average LED uses 0.04 watts of power, and your average RTC clock chip uses microwatts of power. You can a make much more efficient sleep mode and still maintain the LED and RTC clock. Companies just need to start using more efficient standby power supplies and do proper low-power design for sleep mode. Heck, with the 4W figures we've seen you can run several 40MIPS CPUs and still have plenty of power left. We don't need to get rid of features to improve sleep mode power consumption, we just need to stop being lazy asses and start to apply proper low power design techniques.
The standby circuit doesn't magically make the rest of the device last longer. Devices in standby are powered off, except for a small power control circuit. This circuit typically doesn't share much more than the input capacitor with the main power supply.
The problem is people refuse to buy the proper equipment. When electronics came out, we started using soldering irons instead of wrenches. Why would it be any different nowadays? A nice thin soldering iron isn't that expensive, and neither is an SMT rework station. Reworking SMT might require a little more care and possibly a mangnifying glass, but it's nowhere near impossible, at least for non-BGA packages. Once you get to BGA and beyond, you do need some more expensive equipment, but as usual the window will shift and in a few years you'll be able to buy a BGA rework station (and there will be some even more annoying package that you can't rework).
Yeah, that level isn't in the temple. You need special equipment to take proper screenshots of the DS, so these are probably lifted from other sources. Who probably lifted them from other sources, and so on, until you get to a proper reviewer with the special screen-shotting DS or to Nintendo themselves. The last and the middle screenshots, at least, are from a pre-release.
I think the touchscreen controls were great. They're highly intuitive and the boomerang and bombchu controls really add to the Zelda experience. It's the little touches that make it so great, like the fact that the boomerang actually lets you see beyond your usual range, and the bombchus let you look pretty far away. Drawing on the map makes a lot of sense, since many people will end up writing things down in previous zelda games. Making the note-taking an in-game element is an obvious continuation, and since it's encouraged, it lets the developers include puzzles that require higher amounts of "memorization" without being annoying. I definitely want to see thigs like these in the next Wii title.
The story was decent, though I expected to have some other "step" before fighting the final boss. Yesterday afternoon I managed to get the "master sword", and I didn't expect to have the game beat a few hours later. It was still very entertaining, though.
The graphics were awesome as far as DS graphics go. Remember, that's done with ~2048 triangles per frame. They're not as good as Wind Waker's, but they get really close. My only gripe is the nearest neighbor mapping (which you can't do anything about, that's just the way the DS works) and some textures (like the character's faces) that should have been twice the resolution. However, since the graphics are cel-shaded, these issues aren't as bad as they would be if the game were more realistic.
Overall, it's a pretty good game, and the controls really should set the standard for future DS and Wii Zelda titles. I can't wait for the next Wii Zelda:)
Slashdot Mirror
Crap, I'm a moron. I had a bug in the regular expression, and I managed to work around it with the other code, causing the problems. This caused the code to insert a 0 between everything, yielding the alternating +/- numbers, and the "o" oddity was caused by two separators together in the source text.
,.:]+",string.lower()) # split by any combination of space, comma, period, colon.
Turns out all you need is one differentiation and a non-retarded regular expression that doesn't insert empty words between each pair of non-word characters.
I've also made the variable names resemble less those of the problem (read: not single-character madness). And added some comments.
#!/usr/bin/python
import re
data = "Ford's, success, has, the, country, almost, financially, industrially, mechanically, exhibits, in, higher, than, persons, have, thought, possible, contradictory, requirements, of, efficiency, increase, great, workers, cost, consumer, And, cost, cost, consumer, And, cost, cost, consumer, And, workers, workers, workers, workers, to, repeated, great, increase, quality, increase, great, great, increase, quality, efficiency, efficiency, which, are, of, contradictory, contradictory, requirements, of, possible, have, have, thought, possible, have, have, persons, than, than, most, persons, persons, than, most, exhibits, exhibits, exhibits, exhibits, financially, financially, financially, financially, almost, the, the, country, almost, Ford's, Ford's, success, has"
text = "Ford's success has startled the country, almost the world, financially, industrially, mechanically. It exhibits in higher degree than most persons would have thought possible the seemingly contradictory requirements of true efficiency, which are: constant increase of quality, great increase of pay to the workers, repeated reduction in cost to the consumer. And with these appears, as at once cause and effect, an absolutely incredible enlargement of output reaching something like one hundredfold in less than ten years, and an enormous profit to the manufacturer"
def do_list(string):
return re.split(r"[
def do_uniquify(lst):
out_l = []
for i in lst:
if i not in out_l: # ignore dupes
out_l.append(i)
return out_l
def do_relativity(textlist,datalist):
last_pos = 0 # keep track of last position
out_l = []
for word in datalist:
index = textlist.index(word) # find index in source text
out_l.append(index-last_pos) # differentiate index
last_pos = index
return out_l
textlist = do_list(text)
datalist = do_list(data)
uniquelist = do_uniquify(textlist)
relative_numbers = do_relativity(uniquelist,datalist)
# stringize all numbers, join with commas.
print ",".join(map(str,relative_numbers))
That does you no good, since you need to write the proper function to proceed. Otherwise, the logic of the bottom block thing doesn't work. First, you need the proper Javascript function which implements the sticky block logic:
f = function(d) {
var h = d.length;
var w = d[0].length;
dxy = function(x,y) {
return x<w && y<h && x>=0 && y>=0 && d[y][x];
}
for(var y = h-2; y >= 0; y--) {
for(var x = 0; x < w; x++) {
if(d[y][x] &&
!dxy(x-1,y) &&
!dxy(x+1,y) &&
!dxy(x,y+1) &&
!(dxy(x+1,y+1) &&
dxy(x-1,y+1))) {
d[y][x]=false;
d[y+1][x]=true;
}
}
}
}
This basically drops all the blocks in the field, unless they're touching another block on either side, below, or they're touching two blocks on both diagonal corners below. Here the field is an array of arrays, and the blocks are true or false.
Then, you get the Ford text plus a field in the bottom. The field accepts a list of integers. You have a "dropper". For each integer, the dropper moves that number of positions to the right (positive) or left (negative), and drops a block following your algorithm (that's why you need the JS function to work). Note that the positions are relative, not absolute.
Now for the Ford code. The hint is in the tooltip text. List, Uniquify, Relativity:
LIST the words in both the original text (from wikipedia) and the text that comes up after solving the problem. Split it into words (maintain apostrophes as part of words, since it's part of the word Ford's).
UNIQUIFY the original text, getting rid of duplicate words while maintaining the word order. Leave the first word of each.
RELATIVITY: Find the positions of each word in the mangled text from the original text. Given these positions, calculate the position change (relativize, differentiate, call it however you want). You'll get something like 0,-6,5,-5,4,-4,2,-2,1,-1,-1,1,-3,3,-4,4,-5,5.... Drop the first number of each pair (the initial zero is an artifact), leaving -6, -5, -4, -2... These are absolute positions of the dropper. Differentiate again, giving 0,1,1,2,1,2,2,1,1. Now that looks like a set of instructions for the dropper. Plug it in, and voila.
Here's the Python code to make it happen:
#!/usr/bin/python
import re
data = "Ford's, success, has, the, country, almost, financially, industrially, mechanically, exhibits, in, higher, than, persons, have, thought, possible, contradictory, requirements, of, efficiency, increase, great, workers, cost, consumer, And, cost, cost, consumer, And, cost, cost, consumer, And, workers, workers, workers, workers, to, repeated, great, increase, quality, increase, great, great, increase, quality, efficiency, efficiency, which, are, of, contradictory, contradictory, requirements, of, possible, have, have, thought, possible, have, have, persons, than, than, most, persons, persons, than, most, exhibits, exhibits, exhibits, exhibits, financially, financially, f
I don't have the function that passes the tests that they wanted yet
Here's a working non-cheating function, in case anyone cares. Basically, the logic is: from bottom to top (which ends up preserving the proper behavior for falling objects), drop blocks if there are no blocks to either side or below, and if at least one of the two diagonal corners below doesn't have a block. This is a rough simulation of falling and sticking blocks (it doesn't take into account the case of several horizontally stuck blocks which aren't resting at the bottom, which would cause them to hover in mid-air, but it passes the tests).
To put it another way: blocks fall unless they're stuck to either side, resting on another block, or have blocks diagonally below on both sides. And horizontal masses in mid-air hover because I'm too lazy to fix it.
f = function(d) {
var h = d.length;
var w = d[0].length;
dxy = function(x,y) {
return x<w && y<h && x>=0 && y>=0 && d[y][x];
}
for(var y = h-2; y >= 0; y--) {
for(var x = 0; x < w; x++) {
if(d[y][x] &&
!dxy(x-1,y) &&
!dxy(x+1,y) &&
!dxy(x,y+1) &&
!(dxy(x+1,y+1) &&
dxy(x-1,y+1))) {
d[y][x]=false;
d[y+1][x]=true;
}
}
}
}
False. Green laser pointers are about as powerful as red laser pointers. It's just that the human eye happens to be more sensitive to green light. The damage capability depends on power, not the perceived brightness, so they aren't more dangerous than red lasers.
$ cat /dev/null | gzip - > devnull.gz
/dev/null with /dev/zero? The latter's a real bitch, it's always too large for my destination drive! Gzip helps though; you can get compression ratios of approximately 2000:1.
$
Works fine for me. Are you sure you're not confusing
I can fit the entire PACMAN arcade board (including the Z80) inside my S3E. 25% use, not counting RAM blocks, which are all in use because I'm too lazy to switch the code over to use an external ROM for the code. I have the $150 Spartan 3E Starter Kit.
Z80s aren't that big.
The point is not to change everything. The point is to be able to change everything. If you look at my desktop, it isn't much changed from the default. I have an extra kicker panel on top with a few useful applets and I use the Polyester style, but other than that I haven't tweaked things much.
However, there are dozens of little tiny obscure features that I use and love, and that wouldn't exist if KDE weren't so configurable. Examples: I have a "stay on top" button on the window titlebars, which I use fairly often, I have several windows configured with custom settings through "Special Window Settings" (to make them show up on the right desktop, for example), I've disabled icons on my desktop altogether, I've tweaked my keyboard shortcuts and configured the extra keys on my keyboard for common actions, and a whole bunch of other little things that I've added over the years. These are less than 1% of the available options, but the point is that they're the 1% that I care about.
Gentoo will auto-run network init scripts when the network device appears. Stick your WiFi USB dongle in and Gentoo will automatically bring it up, as long as you have the init script configured.
I'm not sure about plugging in the cable (media detection instead of device detection), but I'd bet it's also implemented in some way.
It still happens. Nowadays it tends to be random files leftover in a game's directory structure. I seem to remember that Halo 2 came with a script file in one of the directories (I may be wrong on this one), and the Gamecube version of Twilight Princess comes with the Wiimote sounds still in there, plus a different file with some Mario sounds (maybe there's and embedded mario minigame in the Wii version? Or perhaps it's just a demo file). The GC TP also has a whole bunch of linker map files if I remember correctly.
Oops, that was supposed to be $65,000-80,000.
Cubesats? 10x10x10cm, $65,00080,000 each. 5x5x5 seems pretty damn small to me (1/8th the volume of a cubesat), do those things exist? That would barely be even trackable, and fitting a gyro, electronics, a decent transmitter, a battery, and the solar panels into that thing would be an interesting exercise.
I'm on Florida Tech's FUNSAT team this year. And I'll make damn sure we have at least one funny easter egg or two in the software/transmissions, if we end up winning and making the thing.
Lights don't burn watts per hour, they burn watts. 2000 watts will give you 2000 watts of light for as many hours as you want. If you ran twenty 100watt bulbs at once, you'd use up that 2kw for as long as you wanted.
Watts are not a measurement of energy. They are a measurement of energy per time. The "per time" part is built-in to the unit watt. A 100 watt light bulb uses 100 joules per second, or 0.134102209 horsepower. Energy is also measured in watt-hours. That's watts TIMES hours, not watts per hour. a 1Wh battery will deliver one watt for an hour. Twenty 100watt bulbs at once will use 2kWh in an hour.
http://en.wikipedia.org/wiki/Watt#Confusion_of_watts_and_watt-hours
Good encryption doesn't work that way. That doesn't stop you from turning that hunk of random data into the Magna Carta. Or is using a crappy encryption algorithm illegal now?
Besides, it was just an example. Here's another one: give them the random data file again and a program that does an XOR. When they do random data XOR random data, they get all zeroes. That's the plaintext, all zeroes. Let them prove it isn't.
If it's less, duplicate the data or pad it. If it's more, compress the data or duplicate the original random data (requiring a larger key).
Of course, this develops into the argument of when does a set of data stop being encrypted content and start being the key. What if both files have an equal chance of being the key and the content, and are identical in function in practice? This causes a lot of fun legal problems. For example, you could have two sets of (by themselves) apparently random data that, when XORed, result in an MP3 file. But neither set is by itself representative of that MP3 file, and in fact one of them could be combined with a second file to produce a third set of data. 1 XOR 2 = file.mp3, 2 XOR 3 = private data. Do it the other way too, 0 XOR 1 = private data. Now which files constitute copyright infringement if distributed? Feel free to replace file.mp3 with CP and "copyright infringement" with "illegal contraband".
Tool = XOR
Key = RandomData XOR Magna Carta
Doesn't take much time, or access to powerful computers.
2kW per day is enough to run 20 100 watt bulbs by the end of the first day. After a year, you could be running your own datacenter.
Unless you're confusing watts with joules. But that's okay, since everyone does it, right? Right????
If done right, yes, it could be weeks or even months. It's definitely not going to die permanently - if you flip the switch in the back it would re-charge whatever. Even better, as I mentioned above, you could have a cycling system that detects when the capacitor or battery is close to discharged, uses what is left to start the PSU again, and recharges it (without really turning on the rest of the monitor).
Yes, it's the sync signal that triggers it. However, the sync signal is AC and consists of tiny pulses, with a very low duty cycle. The impedance is also relatively high. You just can't trip a relay directly with it. You also get into all sorts of issues with Sync-On-Green and whatnot. You can, however, use it to turn on a MOSFET that powers the relay from a battery or supercap, which will last a very, very long time without any power, since MOSFETs draw almost zero current when switched off.
Or a supercap, as I stated above. Supercaps are already used for this, to keep RTC clocks alive while wall power is off. Improve the power efficiency, throw in a bigger cap, and it will last pretty long.
As for LEDs, yeah, we can definitely get rid of a lot of them. Especially the clocks - there's next to no use for those, and they suck a lot of power.
Then use a cycle. Have, say, an aerogel capacitor charge up enough to run the LED for a few hours. When the capacitor is near to being discharged, switch on the standby power supply and recharge it. Lather, rinse, repeat. No need for a constantly running switching power supply, or solar panels, and standby acts just as it does now (with no time limit), just with lower power use.
I was debating whether devices with standby last longer or not, not how much power is used.
By the way, your average LED uses 0.04 watts of power, and your average RTC clock chip uses microwatts of power. You can a make much more efficient sleep mode and still maintain the LED and RTC clock. Companies just need to start using more efficient standby power supplies and do proper low-power design for sleep mode. Heck, with the 4W figures we've seen you can run several 40MIPS CPUs and still have plenty of power left. We don't need to get rid of features to improve sleep mode power consumption, we just need to stop being lazy asses and start to apply proper low power design techniques.
The standby circuit doesn't magically make the rest of the device last longer. Devices in standby are powered off, except for a small power control circuit. This circuit typically doesn't share much more than the input capacitor with the main power supply.
The problem is people refuse to buy the proper equipment. When electronics came out, we started using soldering irons instead of wrenches. Why would it be any different nowadays? A nice thin soldering iron isn't that expensive, and neither is an SMT rework station. Reworking SMT might require a little more care and possibly a mangnifying glass, but it's nowhere near impossible, at least for non-BGA packages. Once you get to BGA and beyond, you do need some more expensive equipment, but as usual the window will shift and in a few years you'll be able to buy a BGA rework station (and there will be some even more annoying package that you can't rework).
Yeah, that level isn't in the temple. You need special equipment to take proper screenshots of the DS, so these are probably lifted from other sources. Who probably lifted them from other sources, and so on, until you get to a proper reviewer with the special screen-shotting DS or to Nintendo themselves. The last and the middle screenshots, at least, are from a pre-release.
I think the touchscreen controls were great. They're highly intuitive and the boomerang and bombchu controls really add to the Zelda experience. It's the little touches that make it so great, like the fact that the boomerang actually lets you see beyond your usual range, and the bombchus let you look pretty far away. Drawing on the map makes a lot of sense, since many people will end up writing things down in previous zelda games. Making the note-taking an in-game element is an obvious continuation, and since it's encouraged, it lets the developers include puzzles that require higher amounts of "memorization" without being annoying. I definitely want to see thigs like these in the next Wii title.
:)
The story was decent, though I expected to have some other "step" before fighting the final boss. Yesterday afternoon I managed to get the "master sword", and I didn't expect to have the game beat a few hours later. It was still very entertaining, though.
The graphics were awesome as far as DS graphics go. Remember, that's done with ~2048 triangles per frame. They're not as good as Wind Waker's, but they get really close. My only gripe is the nearest neighbor mapping (which you can't do anything about, that's just the way the DS works) and some textures (like the character's faces) that should have been twice the resolution. However, since the graphics are cel-shaded, these issues aren't as bad as they would be if the game were more realistic.
Overall, it's a pretty good game, and the controls really should set the standard for future DS and Wii Zelda titles. I can't wait for the next Wii Zelda