Do your research. uClinux is a port of Linux to processors without an MMU. Palms are good examples, and uClinux will (almost) run on one. See the page for more detail.
Do a sun-and-planets type gear system. I can't really remember exactly how it works, yet alone explain it without a picture, but basically what you get is the ability to control the gear ratio by (I think) a little electric motor.
You don't really need it to vary continuously, though -- some skillz with the conventional gears could accomplish the same thing with a less mechanical effort.
Finally, connect the pedals directly to the power train (oh yeah and of course you'd need to add a neutral setting) and charge up by pedaling really fast before you come out in front of everybody, and pedaling lighly as you go along. Yeah that really would be cool.
A sensible "pedal"-gear size should avoid the Darwin risk.
Wow -- sounds sorta like what I had been thinking of, oh maybe 7 years ago. And I was born in 1985. So hmmm... maybe I should listen to my absurd ideas a little more...
But still, it would be nice if they could go in the main distribution (because KDE, Konqueror, etc. is cool and installing it should be at least as easy as running it).
Uh, people, KDE Debian packages from within the last -- like -- year would be... um... helpful?!?!?
Seriously,
# apt-get install kde Reading Package Lists... Done Building Dependency Tree... Done E: Couldn't find package kde
is really getting on my nerves.
Not everybody uses Red Hat and Mandrake (remember RedHatIsNotLinux), and not everybody has the time and disk space to download and compile all the sources.
definately. mpg123 + Vorbize (w/ frontend?) = converter. I'm doing this for Unix too, but just using a plain old pipe (maybe do this with Windows too, but it's more difficult to put a frontend on that).
A lot of the arguments in this discussion seem to center around the legality of MP3 encoders like LAME. Some people contend that all MP3 encoders are illegal. To avoid all this big mess, I propose that the open-* people among us adopt a different and superior, IMHO, format, which would be Vorbis. We discussed this format earlier on Slashdot, but I think it deserves being brought up again.
For a little background, Ogg Vorbis is a completely open format with no patent issues or other messiness. It was developed by Xiphophorus. Theoretically, Vorbis has a higher quality than MP3 at almost all bitrates. For more information, see the FAQ on the page I linked to above.
I have modified the example encoder in the CVS tree to make it much more user-friendly, added detection for the WAV header, put in a status display, etc. My modified encoder is called Vorbize. XMMS and WinAMP plugins are available.
I encourage everyone who believes in open formats to use Vorbis. It's Just Better (TM).
Remember, just because Everybody Else uses [Windows|Mac] doesn't mean we shouldn't use [Linux|BSD|whatever]. Apologies to Mac users.
It looks like the Vorbis 1.0 spec is out, by referring to the CVS. I have to talk to Monty about this to be sure, but they definately changed the book files. This means that the spec has changed, and to facilitate conversion I am adding a raw-encoding option to Vorbize so that I can make a little shell script that uses the decoder example and Vorbize to convert from the old spec to the new spec. Good thing I waited on releasing 0.2! Just gotta kill one nasty segfault in the RAW code that's driving me up the wall, and you'll get your new-spec enhanced encoder.
btw, I'm going to say something about Vorbis in this discussion also that will go into a bit more detail than your post.
Kenneth Arnold, author of whatever differences there are between example-encoder.c and Vorbize... ah what the heck just call me the author...
Well considering that the computers have a long way to go, why not meet them half-way? On the other hand, there is no half-way point that I can think of. Maybe a regular language like Lojban would be a good place to start, and then the programmers could concentrate on extracting the meaning (semantics) from the words (syntax). Eventually, when computer language processing of a simple language like Lojban, the parsing of English could be made easier by dictating the solution in this simpler but spoken language. Depending on the sophistication of the program, it might be possible to extend the parser just a little bit and then have the computer "learn" the differences between English and whatever language it is trained in a step at a time until it builds a good understanding of the entire language. This might seem overly complicated from a programming standpoint but in the future, extracting key words from sentences like Jeeves does just won't cut it.
If everybody started using Lojban, the problem would be orders of magnitude simpler. But English, though quite natural for its speakers, has brain-dead syntax when viewed from a parsing standpoint, so much so that even parsing Latin would be easier (a problem I am actually thinking of tackling).
> Why bother? If you speak slowly and loudly enough, everyone can understand English. Right?
Under some circumstances. If the listener knows a Romance language, [s]he maght be able to get an idea of what you are talking about, but his/her interpretation will not be precise enough to even begin a business conversation (more than "I'll trade you my watch for your necklace" -- that one would be difficult also -- nevermind).
But it's a totally different situation when more context clues are added. The tone of voice can tip off the listener to the speaker's mood (although tonal variety will vary between languages). Facial expressions even more so. The use of universal gestures (such as clutching your neck == choking) will significantly aid understanding, but even casual gestures can give clues. It is up to our incredibly complex human brains to piece together all of these clues (which include much more than what I mentioned) and form an understanding, however limited, of the situation. This is something that a computer cannot presently, and may never, do.
So while your computers are happy swearing in Lojban at one another (as soon as someone figures out a decent emotions simulator), us humans will continue to speak whatever we have to speak. It's our nature, and to force an artificial language on us without those highly-evolved accompanying clues may eventually work, but will encounter the significant barriers of being unnatural to 99.9% of the world's hominoid population. Try to find a speaker of Esperanto or Lojban who can put the same depth of knowledge, experience, fluidity, and emotion into a narration as one can with a natural language, especially one which they have known since early childhood.
And the emotions intrinsic to the language is something a practical universal translator could never really handle like a native speaker. Knowing all the formations, irregularities, idioms, etc. will get a good understanding of the language across, but to really capture the kind of depth a natural language goes into is much, much more difficult. Like take this rant in English. A native speaker will likely pick up on my varying tonality and mental gestures even though these are not written down (assuming that you actually take the time to read this, instead of skimming it). Try getting that same kind of understanding after a run through Babelfish.
This is not to say that an extremely regular language like Lojban will not succeed. It simply will have a hard time succeeding as-is. Unless it can evolve to the deep, human qualities that other, natural languages have acquired, it will always seem a bit unnatural.
Sorry for making you read through my big rant.
Re:how to determine the perfect game of chess
on
Solving Chess?
·
· Score: 1
> Or, more likely, set a network of computers to all play against each other. Use some AI to have them "learn", and realise what they did wrong in the past, and what they should do better in the future. Given enough time, either all games should end in stalemate, or white would win all games.
I actually did something similar once, but with Connect Four, and the two opponents on the same computer. I had written out a Scheme program to play Connect Four and embodied a computer player in a stand-alone object (for more information, see The Schemer's Guide). They used a backtracking evaluation system and a database of knowledge about which moves to make given a certain situation. It was, of course, a simple matter to have them play a good number of games against each other. Then I (or an innocent bystander) would play the one that had won the most games.
The problem was, of couse, the computing power necessary to accumulate enough knowledge to be able to play a perfect game. The first problem was that my objects were written in an interpreted langauge and I had not compiled them. The second problem was the processor I was running them on -- my dad's 166 mHz laptop. Third, my algorithm was sub-optimal -- for one, I didn't check if the currect game position flipped was already in the knowledge base. But even counting these restructions, solving even a 4x4 board takes a lot of time. And Connect Four is an extremely simple game in comparison to chess -- there are at maximum the same number of moves as there are rows, and often less because rows are full or the player can easily find whether or not that move will cause the other player to win next turn. So imagine scaling this to chess. They might find a perfect algorithm the same time they find the last digit of pi. (Do you suppose that it's possible that pi, while never repeating, falls into some predictable pattern after a heck of a lot of digits? Sound like a parallel computing project?)
Re:how to determine the perfect game of chess
on
Solving Chess?
·
· Score: 1
Nah, add a skill factor. Kill the moneys that lose. Of course you will have to start with more monkeys, but the problem of food will be less after a few iterations. Not to mention you'll have to dissect the last monkey's brain to retrieve its skill program. Then there is the problem of what to do with a hundred thousand dead monkeys.
Okay, so maybe the networked computers would work better in this case. But to add back in the risk factor, "kill" the nodes that lose, but clone the winning algorithm onto that computer. That would improve much faster, because the computing power would still be fully intact, but each computer would not need to independantly discover the winning algorithm. It would be like a Beowulf cluster, but competitive. Hey, lets apply this to other parallel-processing projects! Maybe if d.net did this, not only would they successfully factor the key, but they would come up with an algorithm that could do this in a short amount of time! Cool, huh?
Just try giving Google a question. It'll remove really common words, like "a", "for", "which", etc. (not sure exactly), and the others should get put at the bottom in priority, leaving Google with a set of important words from your question that it will search for, which is close to what Ask Jeeves does. A specific product will usually catch a Real Name, and be marked up. So natural langage queries stand a good chance of working already. The only problem might be that question mark at the end. Maybe Google could just have a mode that filtered out more words in a little smarter way, and remove the confusing (to beginners) escape of numbers, etc.
Slashdot Mirror
hey, moderators -- that was funny!
Also reminds me of a recent post on lkml...
Hmmm...
..... click here, click Send.
:).
TI-89. Linux. TI-89. Linux.
We are working with Linux 2.0.33 + uClinux patch + DragonBall port of uClinux.
No code yet. Help us fix that
Do your research. uClinux is a port of Linux to processors without an MMU. Palms are good examples, and uClinux will (almost) run on one. See the page for more detail.
Do a sun-and-planets type gear system. I can't really remember exactly how it works, yet alone explain it without a picture, but basically what you get is the ability to control the gear ratio by (I think) a little electric motor.
You don't really need it to vary continuously, though -- some skillz with the conventional gears could accomplish the same thing with a less mechanical effort.
Finally, connect the pedals directly to the power train (oh yeah and of course you'd need to add a neutral setting) and charge up by pedaling really fast before you come out in front of everybody, and pedaling lighly as you go along. Yeah that really would be cool.
A sensible "pedal"-gear size should avoid the Darwin risk.
Wow -- sounds sorta like what I had been thinking of, oh maybe 7 years ago. And I was born in 1985. So hmmm... maybe I should listen to my absurd ideas a little more...
even worse: looks like Paintbrush from Win3.x.
come on Nick, link to something worth my time.
(replying to one's one reply to one's own comment... that's gotta be one in some big number.)
Botched the link up.
Here.
Okay, if you're reading this, I dug and found something.
:-).
Here we are
But still, it would be nice if they could go in the main distribution (because KDE, Konqueror, etc. is cool and installing it should be at least as easy as running it).
Uh, people, KDE Debian packages from within the last -- like -- year would be ... um ... helpful?!?!?
Seriously,
# apt-get install kde
Reading Package Lists... Done
Building Dependency Tree... Done
E: Couldn't find package kde
is really getting on my nerves.
Not everybody uses Red Hat and Mandrake (remember RedHatIsNotLinux), and not everybody has the time and disk space to download and compile all the sources.
I just went over to register.com and saw that they have a new (???) TLD to register -- .ws (WorldSite). Any info on this? (official, that is?)
definately. mpg123 + Vorbize (w/ frontend?) = converter. I'm doing this for Unix too, but just using a plain old pipe (maybe do this with Windows too, but it's more difficult to put a frontend on that).
A lot of the arguments in this discussion seem to center around the legality of MP3 encoders like LAME. Some people contend that all MP3 encoders are illegal. To avoid all this big mess, I propose that the open-* people among us adopt a different and superior, IMHO, format, which would be Vorbis. We discussed this format earlier on Slashdot, but I think it deserves being brought up again.
For a little background, Ogg Vorbis is a completely open format with no patent issues or other messiness. It was developed by Xiphophorus. Theoretically, Vorbis has a higher quality than MP3 at almost all bitrates. For more information, see the FAQ on the page I linked to above.
I have modified the example encoder in the CVS tree to make it much more user-friendly, added detection for the WAV header, put in a status display, etc. My modified encoder is called Vorbize. XMMS and WinAMP plugins are available.
I encourage everyone who believes in open formats to use Vorbis. It's Just Better (TM).
Remember, just because Everybody Else uses [Windows|Mac] doesn't mean we shouldn't use [Linux|BSD|whatever]. Apologies to Mac users.
It looks like the Vorbis 1.0 spec is out, by referring to the CVS. I have to talk to Monty about this to be sure, but they definately changed the book files. This means that the spec has changed, and to facilitate conversion I am adding a raw-encoding option to Vorbize so that I can make a little shell script that uses the decoder example and Vorbize to convert from the old spec to the new spec. Good thing I waited on releasing 0.2! Just gotta kill one nasty segfault in the RAW code that's driving me up the wall, and you'll get your new-spec enhanced encoder.
btw, I'm going to say something about Vorbis in this discussion also that will go into a bit more detail than your post.
Kenneth Arnold, author of whatever differences there are between example-encoder.c and Vorbize... ah what the heck just call me the author...
So please port Linux to the TI-89/92? This is not the first time I've asked. Thanks very much in advance.
Well my language is better than yours! So there!
Isn't it amazing how we've been avoiding the real topic?
> Why bother? If you speak slowly and loudly enough, everyone can understand English. Right?
Under some circumstances. If the listener knows a Romance language, [s]he maght be able to get an idea of what you are talking about, but his/her interpretation will not be precise enough to even begin a business conversation (more than "I'll trade you my watch for your necklace" -- that one would be difficult also -- nevermind).
But it's a totally different situation when more context clues are added. The tone of voice can tip off the listener to the speaker's mood (although tonal variety will vary between languages). Facial expressions even more so. The use of universal gestures (such as clutching your neck == choking) will significantly aid understanding, but even casual gestures can give clues. It is up to our incredibly complex human brains to piece together all of these clues (which include much more than what I mentioned) and form an understanding, however limited, of the situation. This is something that a computer cannot presently, and may never, do.
So while your computers are happy swearing in Lojban at one another (as soon as someone figures out a decent emotions simulator), us humans will continue to speak whatever we have to speak. It's our nature, and to force an artificial language on us without those highly-evolved accompanying clues may eventually work, but will encounter the significant barriers of being unnatural to 99.9% of the world's hominoid population. Try to find a speaker of Esperanto or Lojban who can put the same depth of knowledge, experience, fluidity, and emotion into a narration as one can with a natural language, especially one which they have known since early childhood.
And the emotions intrinsic to the language is something a practical universal translator could never really handle like a native speaker. Knowing all the formations, irregularities, idioms, etc. will get a good understanding of the language across, but to really capture the kind of depth a natural language goes into is much, much more difficult. Like take this rant in English. A native speaker will likely pick up on my varying tonality and mental gestures even though these are not written down (assuming that you actually take the time to read this, instead of skimming it). Try getting that same kind of understanding after a run through Babelfish.
This is not to say that an extremely regular language like Lojban will not succeed. It simply will have a hard time succeeding as-is. Unless it can evolve to the deep, human qualities that other, natural languages have acquired, it will always seem a bit unnatural.
Sorry for making you read through my big rant.
I actually did something similar once, but with Connect Four, and the two opponents on the same computer. I had written out a Scheme program to play Connect Four and embodied a computer player in a stand-alone object (for more information, see The Schemer's Guide). They used a backtracking evaluation system and a database of knowledge about which moves to make given a certain situation. It was, of course, a simple matter to have them play a good number of games against each other. Then I (or an innocent bystander) would play the one that had won the most games.
The problem was, of couse, the computing power necessary to accumulate enough knowledge to be able to play a perfect game. The first problem was that my objects were written in an interpreted langauge and I had not compiled them. The second problem was the processor I was running them on -- my dad's 166 mHz laptop. Third, my algorithm was sub-optimal -- for one, I didn't check if the currect game position flipped was already in the knowledge base. But even counting these restructions, solving even a 4x4 board takes a lot of time. And Connect Four is an extremely simple game in comparison to chess -- there are at maximum the same number of moves as there are rows, and often less because rows are full or the player can easily find whether or not that move will cause the other player to win next turn. So imagine scaling this to chess. They might find a perfect algorithm the same time they find the last digit of pi. (Do you suppose that it's possible that pi, while never repeating, falls into some predictable pattern after a heck of a lot of digits? Sound like a parallel computing project?)
Okay, so maybe the networked computers would work better in this case. But to add back in the risk factor, "kill" the nodes that lose, but clone the winning algorithm onto that computer. That would improve much faster, because the computing power would still be fully intact, but each computer would not need to independantly discover the winning algorithm. It would be like a Beowulf cluster, but competitive. Hey, lets apply this to other parallel-processing projects! Maybe if d.net did this, not only would they successfully factor the key, but they would come up with an algorithm that could do this in a short amount of time! Cool, huh?
Hey elite hacker d00ds -- port uClinux to the TI-89. Please?