Slashdot Mirror

Early this year, I saw some fairly sophisticated interaction using a flexible input device called ShapeTape, made by Canada's Measurand. While the company is marketing it as a motion-capture and 3D modeling technology, Tovi Grossman at the University of Toronto's Dynamic Graphics Project has been working under Ravin Balakrishnan to explore other applications for ShapeTape, including as a general input device. For example, you can use it in computer-assisted design or animation to make and perform some fairly complex 3D curves and manipulations in far less time than it would take with keyboards, mice or drawing tablets.

The Association of Computing Machinery's computer-human interaction publication CHI Letters' latest edition includes their paper on the use of ShapeTape (2 MB PDF), which was presented at the ACM CHI 2003 conference on human factors in computing systems along with MPEG demonstration videos. (3 min. basic - 15 MB | 15 min. complete - 190 MB)

Grossman's Web page includes links to other videos and previous papers.

Computer graphics and animation tool-maker Alias|Wavefront also has several videos that featured former chief scientist Bill Buxton demonstrating ShapeTape in use:

• 3D Tapedrawing On The Wall 4:33 min. - 11MB
• Digital Tape Drawing 2:33 min. - 8.2MB
• Modeling With Shapetape 1:14 min. 3.9MB

And, of course, ShapeTape maker Measurand also has further information and videos.

Early this year, I saw some fairly sophisticated interaction using a flexible input device called ShapeTape, made by Canada's Measurand. While the company is marketing it as a motion-capture and 3D modeling technology, Tovi Grossman at the University of Toronto's Dynamic Graphics Project has been working under Ravin Balakrishnan to explore other applications for ShapeTape, including as a general input device. For example, you can use it in computer-assisted design or animation to make and perform some fairly complex 3D curves and manipulations in far less time than it would take with keyboards, mice or drawing tablets.

The Association of Computing Machinery's computer-human interaction publication CHI Letters' latest edition includes their paper on the use of ShapeTape (2 MB PDF), which was presented at the ACM CHI 2003 conference on human factors in computing systems along with MPEG demonstration videos. (3 min. basic - 15 MB | 15 min. complete - 190 MB)

Grossman's Web page includes links to other videos and previous papers.

Computer graphics and animation tool-maker Alias|Wavefront also has several videos that featured former chief scientist Bill Buxton demonstrating ShapeTape in use:

• 3D Tapedrawing On The Wall 4:33 min. - 11MB
• Digital Tape Drawing 2:33 min. - 8.2MB
• Modeling With Shapetape 1:14 min. 3.9MB

And, of course, ShapeTape maker Measurand also has further information and videos.

Early this year, I saw some fairly sophisticated interaction using a flexible input device called ShapeTape, made by Canada's Measurand. While the company is marketing it as a motion-capture and 3D modeling technology, Tovi Grossman at the University of Toronto's Dynamic Graphics Project has been working under Ravin Balakrishnan to explore other applications for ShapeTape, including as a general input device. For example, you can use it in computer-assisted design or animation to make and perform some fairly complex 3D curves and manipulations in far less time than it would take with keyboards, mice or drawing tablets.

The Association of Computing Machinery's computer-human interaction publication CHI Letters' latest edition includes their paper on the use of ShapeTape (2 MB PDF), which was presented at the ACM CHI 2003 conference on human factors in computing systems along with MPEG demonstration videos. (3 min. basic - 15 MB | 15 min. complete - 190 MB)

Grossman's Web page includes links to other videos and previous papers.

Computer graphics and animation tool-maker Alias|Wavefront also has several videos that featured former chief scientist Bill Buxton demonstrating ShapeTape in use:

• 3D Tapedrawing On The Wall 4:33 min. - 11MB
• Digital Tape Drawing 2:33 min. - 8.2MB
• Modeling With Shapetape 1:14 min. 3.9MB

And, of course, ShapeTape maker Measurand also has further information and videos.

Early this year, I saw some fairly sophisticated interaction using a flexible input device called ShapeTape, made by Canada's Measurand. While the company is marketing it as a motion-capture and 3D modeling technology, Tovi Grossman at the University of Toronto's Dynamic Graphics Project has been working under Ravin Balakrishnan to explore other applications for ShapeTape, including as a general input device. For example, you can use it in computer-assisted design or animation to make and perform some fairly complex 3D curves and manipulations in far less time than it would take with keyboards, mice or drawing tablets.

The Association of Computing Machinery's computer-human interaction publication CHI Letters' latest edition includes their paper on the use of ShapeTape (2 MB PDF), which was presented at the ACM CHI 2003 conference on human factors in computing systems along with MPEG demonstration videos. (3 min. basic - 15 MB | 15 min. complete - 190 MB)

Grossman's Web page includes links to other videos and previous papers.

Computer graphics and animation tool-maker Alias|Wavefront also has several videos that featured former chief scientist Bill Buxton demonstrating ShapeTape in use:

• 3D Tapedrawing On The Wall 4:33 min. - 11MB
• Digital Tape Drawing 2:33 min. - 8.2MB
• Modeling With Shapetape 1:14 min. 3.9MB

And, of course, ShapeTape maker Measurand also has further information and videos.

• Bright (download) is the best non-dithering quantiser in the whole world, and reasonably fast, too; based on dlquant
• pngrewrite sorts the palette
• pngcrush removes junk chunks, fixes Photoshop's gamma bug and tries many filters to find a smaller filesize
• OptiPNG is similar to pngcrush, but executes much faster
• pngout uses an alternative deflate, yields sometimes even smaller filesizes
• tweakpng manipulates chunks comfortably with a GUI
• pngquant quantises PNG24 with alpha transparency to PNG8 with transparent palettes, the result is alas mostly ugly

sleightplus demonstrates how to overcome IE's rendering bugs without polluting your markup or styles; no silly style inlining required, either. Use PNG images or backgrounds all the way they were intended.

Predecessors with only support for foreground images: Youngpup sleight, WebFX PNG behavior, mongus pngInfo, Bob Osola. PNGHack, a server side solution, is doomed to fail because of dysfunctional browser sniffing.

If that was useful for you, and you are a C hacker, I have a plea. Take the dlquant sourcecode (see above) and massage it so it works with PNG instead of the archaic PPM. I want a functional Bright clone for Linux that takes a true colour PNG and outputs a paletted PNG. Can you do that?

i can wholeheartedly referr you to this link and let you find out for yourself that you mixed up some interesting concepts and give us all a hard time discussing a triviality...

and btw., i really think, that you have way to much time on your hands.

I'm surprised nobody has brought up the value of open source drivers in this situation. If ATI, NV and all the other GPU board vendors were to provide their drivers in source form, the community could judge the situation based on the actual code instead of making guesses.

Selling hardware without providing source for the interface drivers verges on unethical in the same way that selling (for example) trusses for a building roof without engineering certification and detailed, approved installation documentation is not only unethical but actually illegal in most jurisdictions. In both cases the systems/structural engineer is prevented from knowing essential facts about the capabilities of an important component of the system/structure they are building. The truss manufacturer has to not only provide these things, it has to provide complete engineering data, materials specifications and test data prior to acceptance for use in construction. Then the engineer is required to use only certified trusses, and only according to the manufacturer's approved instructions.

Of course in _most_ situations, the actual impact on safety and health of a video card is unlikely to be large. Nevertheless, proper systems engineering requires complete knowledge of the software as well as hardware structure of any subsystem. I.e., what if I'm building a new version of Prof. Steve Mann's "Mediated Reality" system? Loss of quality could have dire consequences in this case, including loss of essential vision at a critical moment. More seriously, I've seen at least one warning on video-related software regarding the potential for seizures in some people with previously-undiagnosed epileptic tendencies. It is within the realm of possibility that a nonobvious timing interaction between the software drivers and the hardware could cause such a thing in some rare or unlikely circumstance. Where is the engineering data to prove otherwise? It is impossible to determine without full access to the source code.

Certainly in this case, availability to the community of the source code would have allowed complete, early analysis by anyone concerned - peer review - and helped keep the entire process honest and at a higher level of discourse than the "sue me/sue you blues".

As time goes on and computer systems become more and more important to our safety and health, open source must certainly become one of the essential and commonly expected tools to allow systems engineers to properly determine the applicability and safety of subsystems for their applications.

from the 2+2=5 dept

Step 1: -1/1 = 1/-1
Step 2: Taking the square root of both sides:
Step 3: Simplifying:
Step 4: In other words, i/1 = 1/i.
Step 5: Therefore, i / 2 = 1 / (2i),
Step 6: i/2 + 3/(2i) = 1/(2i) + 3/(2i),
Step 7: i (i/2 + 3/(2i) ) = i ( 1/(2i) + 3/(2i) ),
Step 8: ,
Step 9: (-1)/2 + 3/2 = 1/2 + 3/2,
Step 10: and this shows that 1=2.

therefore 2+2=1+1=3; QED

Thanks for the proof

If you want to recompress the bloated PNGs written by Photoshop, a guide to PNG optimization is available.

I really don't recall seeing a whole lot of the linux or freebsd kernels written in object oriented languages.

Well, except BeOS. And Hurricane, and Tornado, and K42.

I really don't recall seeing a whole lot of the linux or freebsd kernels written in object oriented languages.

Well, except BeOS. And Hurricane, and Tornado, and K42.

Interval methods automatically track all floating-point "errors". See GrafEq for an example graphing package that uses intervals: it doesn't produce incorrect graphs, even for tricky equations. (Not the case with Mathematica, Maple, etc.! They do give incorrect graphs on many simple equations.) See his siggraph paper.

This post is not off topic, I swear to Dios. The second paragraph contains a bunch of shit, but the first contains useful information. The first paragraph begins here: I just love it when some huge Microsoft ad comes up when I load up a story. Astute readers probably know that I hate Microsoft's guts and that I firmly believe that everything they are/sell/do/say is pure garbage. So when I see one of their ads on Slashdot, I click on it and when their ugly webpage finishes to load, I simply hit the 'back' button. I never look at what they're advertising. Even if I did, I would certainly not be interested in it, whatever it is, because I use products that are in every way superior to theirs. Products like six different distributions of Linux, all three BSDs, versions of BeOS ranging from 3 to 5 (because it's still useful), QNX, IRIX and HP-UX. There were others, but I reduced the list of operating systems to the ones listed here. So Microsoft has to pay for another click that led them nowhere. And I wasted some of their bandwidth. These two facts make me feel good about myself and about who I am. I firmly believe that causing them additional expenses such as the one described herein is a good way to increase one's self esteem (not that I need to do so, what with the 6 different girlfriends I have that don't know about each other, and would probably still love/screw me if they knew, since I am such a studmuffin, so yeah, I have lots of self esteem... girls love guys that troll Slashdot).Now, to what I was going to say about this article before that stupid ad got in my way... Oh, that was in the first paragraph... sorry, forgot.

Actually, I was going to stop here but I think I'll add more...

• http://www.cs.toronto.edu/~wayne/microsoft-sucks.h tml
• http://pub32.ezboard.com/fogrebattle6432793frm13
• http://brighten.bigw.org/humor/mine/microsoft_suck s.html
• http://www.taikahn.com/mssucks.html
• http://www.microsoftsucks.com/
• http://www.never.com/eva/
• http://www.zdnet.com/anchordesk/talkback/talkback_ 253.html
• http://www.kuro5hin.org/story/2002/12/18/155016/66
• http://www.spiffle.com/rants/10-05-1999_01-05am

This post has been moderated -9: Sewage.

Our Visual Computing class recently had to do our own morph software using the Beier-Neely Feature Based Metamorphosis Algorithm. It wasn't too difficult (well, we never went as far as Ghost-Busting sub-section of 3.3). Another cleaner copy of the algorithm can be found here.
Maybe you could implement the algorithm, and then run it on the original picture, plus a reduced size image of the subject with all the lines in the second picture proportionately smaller. Your in between morphs should have the look you desire (unless i'm reading your request wrong). Implementation of anti-aliasing using supersampling with a gaussian convolve before cross-dissolving does help!

Our Visual Computing class recently had to do our own morph software using the Beier-Neely Feature Based Metamorphosis Algorithm. It wasn't too difficult (well, we never went as far as Ghost-Busting sub-section of 3.3). Another cleaner copy of the algorithm can be found here.
Maybe you could implement the algorithm, and then run it on the original picture, plus a reduced size image of the subject with all the lines in the second picture proportionately smaller. Your in between morphs should have the look you desire (unless i'm reading your request wrong). Implementation of anti-aliasing using supersampling with a gaussian convolve before cross-dissolving does help!

I'm involved with a group known as The United Empire Loyalist Orchestra that put on two *live* shows in Ottawa under similar premises.

The first was a 24 hour drone show. No notes except D and its octaves. For 24 hours. And it was done.

The second show was a three hour version of O Canada, followed by a 48 second version. And if you want any idea of how it was done, here's the score.

David McCallum

I'm involved with a group known as The United Empire Loyalist Orchestra that put on two *live* shows in Ottawa under similar premises.

The first was a 24 hour drone show. No notes except D and its octaves. For 24 hours. And it was done.

The second show was a three hour version of O Canada, followed by a 48 second version. And if you want any idea of how it was done, here's the score.

David McCallum

I'm involved with a group known as The United Empire Loyalist Orchestra that put on two *live* shows in Ottawa under similar premises.

The first was a 24 hour drone show. No notes except D and its octaves. For 24 hours. And it was done.

The second show was a three hour version of O Canada, followed by a 48 second version. And if you want any idea of how it was done, here's the score.

David McCallum

> PNGs are a lot bigger than GIFs

It's not "a lot", it's around 50 bytes per image. Not kilobytes, bytes. That's an eyeblink on even the slowest connection.

This guy actually made a special effort to find gifs that are bigger than equivalent pngs, minus the png overhead. You can see for yourself how little success he has had.

GCL-GL.tar.gz: OpenGL/Mesa and Xlib bindings for GCL (Gnu Common Lisp).
http://groups.google.com/groups?q=gcl-gl&hl=en&lr= &ie=UTF-8&oe=UTF-8&selm=MANN.96Dec12144405%40orasi s.vis.toronto.edu&rnum=1
http://www.cs.toronto.edu/pub/mann/Software/Lisp/

Mesa is a "more free" version of SGI's OpenGL.

For the record, Cook was born in Buffalo, NY and obtained his Ph.D. at Harvard.

http://www.cs.toronto.edu/DCS/People/Faculty/sacoo k.html

my dreams have been filled with visions of large processor cores with no fixed pipeline that can reconfigure themselves for different tasks, and have several operations in progress at once, taking several pathways through the core.

To some extent, this is done already.

Any superscalar processor will at least potentially have multiple operations being performed at once, in different pipelines as well as the same pipeline. The pipeline typically forks manyfold after the fetch/decode stages and recombines when results are ready to be committed and instructions retired. Under ideal conditions, most or all of the functional unit pathways in a processor could be busy at the same time (though code that does this is very rare - usually you're limited by data availability and by mismatch between the processor's facilities and the resources needed by the code).

As for self-reconfiguring processors, there is much work yet to be done. I've seen a handful of papers on partly reconfigurable processors; a few are on my prof's page. However, reconfigurable functional units suffer from the twin problems of being slower than a hard-wired functional unit at a specific task, and being extremely difficult to produce optimized code for (generally, the more ways you can use something to change the workings of a program, the harder it is to find an optimal use for it).

It's still an interesting idea with potential in several types of situation, though.

Asynchronous logic also doesn't affect the reconfigurability of a block of logic. Reconfigurability happens at a higher level of the design.

I suppose, for the immediate future, that asynchronous logic elements will simply augment current processor designs as you (and others) have outlined in this discussion. How long, then, until we reach a paradigm shift and start designing our processors in a fundamentally different way?

Pulling a number out of a hat, I get 10-15 years. Superscalar, highly-pipelined architectures have almost reached the limits of extendability without a major breakthrough in design, but there are still performance-enhancing tweaks to be made. CMP - multiple cores on one die - is the way of the future, but the number of cores involved will be small for the next few linewidth shrinks. Beyond a certain point, though, we're going to have to change from using conventional cores on a fast crossbar-type interconnect to something that more closely resembles the larger parallel machines of today. It is at that point that new opportunities for optimization and design changes will arise, which may (or may not) lead to significant changes in the way individual processor cores are designed (as the place of a core in the system will have changed).

It's also possible that there never will be a drastic paradigm shift. Modern superscalar processors represent a fairly mature solution that matches the nature of most computing problems fairly well. Only time will tell whether something radically better will come along.

In the meantime, asynchronous logic may very well replace synchronous logic for the low-level implementation of processor circuitry.

I hate to be a downer, but that's way too big a question, and too fundamental. It's a catch-22: the fact that you are asking this question indicates you probably won't be able to accomplish the project.

If what you want to do is try your hand at designing a 3D modeller, I'd say you should fork or join (no pun intended) an open-source project. If you don't like some of their design decisions, then redesign those parts.

OK. Having said all that, I'm actually going to try to answer this question as best I can off the top of my head. Beware: this is a brain dump, and that's how it will read...

Start with the interfaces. They are everything. Without good interfaces, you find that the development time for a project with n lines of code will grow as n^2. With good interfaces, it's more like nlogn. I don't know much about 3D modellers, but I bet it will get big enough that this will matter. If your brain is too small to design all these interfaces at once, try to design as many as you can, and then start writing prototype implementations, but be ready to chuck them when you figure out their weaknesses; after all, that is why you are writing them.

For each interface, ask not what facility that interface provides, but rather what information it hides. That is, what changes could occur behind-the-scenes without requiring corresponding changes to the caller of that interface? If you can't describe in one simple sentence (with no "ands" or "ors" in it) what an interface is hiding, then it's no good, and you need to take another stab at it. (Of course, I didn't think up this information hiding thing myself.

As you design your interfaces, identify those that are truly fundamental (ask yourself: would every conceivable 3D renderer need to be able to do this?), and separate them from the others that contain some of your own personal choices. The former are your base interfaces that should (in theory) converge toward the ideal design, such that you feel less and less need to change them as development progresses. The simplicity and stability of these interfaces will determine the flexibility of your design. Their header files should be physically segregated from those of the other less-fundamental interfaces.

Then, remember to think big and code small. By that, I mean you should brainstorm while writing your interfaces, and design them so they could accomodate every plausible implementation; then, implement them in the simplest, most straightforward way you can. Churn out those prototype implementations with a focus on the shortest path toward correctness. Worry about everything else later; thanks to the flexibility of your interfaces, you can change any of the implementations later. This approach prevents premature optimization, and keeps you from writing lots of intricate code you don't need.

Recognize when you have opposing forces on each side of one of your interfaces (ie. the caller and the implementor), and split that interface into two. That way you can give both the caller and the implementor an interface they like. (That's described in my thesis--chapter 4--and the PowerPoint slides on my web site.)

When you don't know how you want to do something, see if you can make an interface that hides that decision. That way you don't need to think about it now; punt the decision until you have enough information to make a good choice. If there's no obvious "best" implementation, then that may be something you'll want to change later anyway, and you'll be glad you made an interface to hide it from the rest of the system.

I have only just barely scratched the surface here. This is a truly vast question you have asked.

Good luck with the project.

I hate to be a downer, but that's way too big a question, and too fundamental. It's a catch-22: the fact that you are asking this question indicates you probably won't be able to accomplish the project.

If what you want to do is try your hand at designing a 3D modeller, I'd say you should fork or join (no pun intended) an open-source project. If you don't like some of their design decisions, then redesign those parts.

OK. Having said all that, I'm actually going to try to answer this question as best I can off the top of my head. Beware: this is a brain dump, and that's how it will read...

Start with the interfaces. They are everything. Without good interfaces, you find that the development time for a project with n lines of code will grow as n^2. With good interfaces, it's more like nlogn. I don't know much about 3D modellers, but I bet it will get big enough that this will matter. If your brain is too small to design all these interfaces at once, try to design as many as you can, and then start writing prototype implementations, but be ready to chuck them when you figure out their weaknesses; after all, that is why you are writing them.

For each interface, ask not what facility that interface provides, but rather what information it hides. That is, what changes could occur behind-the-scenes without requiring corresponding changes to the caller of that interface? If you can't describe in one simple sentence (with no "ands" or "ors" in it) what an interface is hiding, then it's no good, and you need to take another stab at it. (Of course, I didn't think up this information hiding thing myself.

As you design your interfaces, identify those that are truly fundamental (ask yourself: would every conceivable 3D renderer need to be able to do this?), and separate them from the others that contain some of your own personal choices. The former are your base interfaces that should (in theory) converge toward the ideal design, such that you feel less and less need to change them as development progresses. The simplicity and stability of these interfaces will determine the flexibility of your design. Their header files should be physically segregated from those of the other less-fundamental interfaces.

Then, remember to think big and code small. By that, I mean you should brainstorm while writing your interfaces, and design them so they could accomodate every plausible implementation; then, implement them in the simplest, most straightforward way you can. Churn out those prototype implementations with a focus on the shortest path toward correctness. Worry about everything else later; thanks to the flexibility of your interfaces, you can change any of the implementations later. This approach prevents premature optimization, and keeps you from writing lots of intricate code you don't need.

Recognize when you have opposing forces on each side of one of your interfaces (ie. the caller and the implementor), and split that interface into two. That way you can give both the caller and the implementor an interface they like. (That's described in my thesis--chapter 4--and the PowerPoint slides on my web site.)

When you don't know how you want to do something, see if you can make an interface that hides that decision. That way you don't need to think about it now; punt the decision until you have enough information to make a good choice. If there's no obvious "best" implementation, then that may be something you'll want to change later anyway, and you'll be glad you made an interface to hide it from the rest of the system.

I have only just barely scratched the surface here. This is a truly vast question you have asked.

Good luck with the project.

I hate to be a downer, but that's way too big a question, and too fundamental. It's a catch-22: the fact that you are asking this question indicates you probably won't be able to accomplish the project.

If what you want to do is try your hand at designing a 3D modeller, I'd say you should fork or join (no pun intended) an open-source project. If you don't like some of their design decisions, then redesign those parts.

OK. Having said all that, I'm actually going to try to answer this question as best I can off the top of my head. Beware: this is a brain dump, and that's how it will read...

Start with the interfaces. They are everything. Without good interfaces, you find that the development time for a project with n lines of code will grow as n^2. With good interfaces, it's more like nlogn. I don't know much about 3D modellers, but I bet it will get big enough that this will matter. If your brain is too small to design all these interfaces at once, try to design as many as you can, and then start writing prototype implementations, but be ready to chuck them when you figure out their weaknesses; after all, that is why you are writing them.

For each interface, ask not what facility that interface provides, but rather what information it hides. That is, what changes could occur behind-the-scenes without requiring corresponding changes to the caller of that interface? If you can't describe in one simple sentence (with no "ands" or "ors" in it) what an interface is hiding, then it's no good, and you need to take another stab at it. (Of course, I didn't think up this information hiding thing myself.

As you design your interfaces, identify those that are truly fundamental (ask yourself: would every conceivable 3D renderer need to be able to do this?), and separate them from the others that contain some of your own personal choices. The former are your base interfaces that should (in theory) converge toward the ideal design, such that you feel less and less need to change them as development progresses. The simplicity and stability of these interfaces will determine the flexibility of your design. Their header files should be physically segregated from those of the other less-fundamental interfaces.

Then, remember to think big and code small. By that, I mean you should brainstorm while writing your interfaces, and design them so they could accomodate every plausible implementation; then, implement them in the simplest, most straightforward way you can. Churn out those prototype implementations with a focus on the shortest path toward correctness. Worry about everything else later; thanks to the flexibility of your interfaces, you can change any of the implementations later. This approach prevents premature optimization, and keeps you from writing lots of intricate code you don't need.

Recognize when you have opposing forces on each side of one of your interfaces (ie. the caller and the implementor), and split that interface into two. That way you can give both the caller and the implementor an interface they like. (That's described in my thesis--chapter 4--and the PowerPoint slides on my web site.)

When you don't know how you want to do something, see if you can make an interface that hides that decision. That way you don't need to think about it now; punt the decision until you have enough information to make a good choice. If there's no obvious "best" implementation, then that may be something you'll want to change later anyway, and you'll be glad you made an interface to hide it from the rest of the system.

I have only just barely scratched the surface here. This is a truly vast question you have asked.

Good luck with the project.

A much easier way to make the moon hit the earth is to slow it down, so that it takes up an elliptical transfer orbit with the perihelion underground.

Here, I drew some pictures. The one on the left has its orbit altered drastically, but it still misses the earth. The one on the right is slowed down enough so it falls into the earth; and it didn't need as much of a push.

Following are my responses to your post. They are not meant to be offensive, demeaning, or unentertaining in any way.

1) I don't really have any quarrel with that point. If you use the term "cartoon" to describe 2D-frame based animation that is primarily hand-drawn, then there's no error in your terminology. I suppose the term anime is used to apply to the general style of the genre that some claim 'separates it' from animation elsewhere in the world.

2) All I can advise is that you watch some anime geared at a more mature audience (Try something like Cowboy Bebop, Hellsing, Blood the Last Vampire, or anything else with a rather dark-sounding name) It tends not to have high-pitched squealy characters.

3) Please, take my word that cheesy, low-framerate slideshows are not representative of most anime out there. That style of animation seems to be hallmark of shows that are produced to the standard of a weekly episodic adventure about a boy and his [insert collectible item here]. Purely for marketing purposes. Try to compare it to a show that has a closed storyline and 13 episodes in total. Have a gander at Macross Plus, or Blue Submarine #6, or any of the other anime listed above. That's some very nice animation.

4) Lost in translation? Well, it happens, and I won't deny it. Watch some fan-subbed anime. They sometimes include translation notes indicating the meaning of mistranslated words that had to be bent to fit the English language. From what I gather, the English language has a lot less nuance than Japanese. Some things don't come over so well.

As for your quibbles with the language in FF7, there are some points where the translation really is terrible. A quick Google search for "Meaning of Materia" results in this site (albeit a bit buried). I wouldn't call it a bastardization of the word Material. In fact, it appears to be the Latin root of Material. One could in fact say that material is a bastardization of materia. Of course, there's probably some deeper meaning behind it all if one knows Japanese.

I personally don't understand much of the Japanese language, but from what I gather from the many hours I spent playing FF7 and watching subbed anime, the word "Mahou" (meaning magic [anyone feel free to correct me]) sounds tremendously similar to the "Makou" in the Makou reactor. And what do they get out the Makou reactors? The Huge materia, crystallized from the planet's magic (or something to that effect). So, that provides a vague explanation for the naming of materia and why they give you magic in the game. (Or at least the way I see it :) Of course, it could have merely been a commercial decision. Wasn't the original translation of "omnislash" supposed to be something along the lines of "Super Ultimate Champion War God Slash" or something? Omnislash sure sounds better to me.

5) Childish Dialog? Based on what you've said, it sounds like you've been watching childish anime. It follows that the dialog is going to be suitable for its target audience. If you want mature dialog, watch an anime for mature people.

Go support your local video rental chain, and check out some of the stuff I've mentioned. I can't say you'll like what you'll see, but it's definitely possible you might enjoy it. I'd say that the best introduction to anime would be Macross Plus. It is an anime that seems to be a good introduction to the anime style, but lacks many of the extreme oddities and conventions present in more light-hearted anime. Most importantly, Macross Plus is a movie (or small miniseries) that seems to be available in most major video chains, so you shouldn't have trouble finding it. Also, if you're into the really gory and somewhat sick stuff, I'd recommend you take a look at Ninja Scroll. Lotsa fighting, blood, dismemberment, and nudity there. The Kenshin OVA's are actually good in that respect too. A story of treachery, deceit, and a fair bit of action.

Well, all in all, I hope I haven't come off as too much of an anime-zealot. I want to emphasize that I don't believe that everyone in the world should be in love with anime because <SARCASM>it's the most wonderful thing in the world </SARCASM> or something (I hope those tags showed up right :) Everyone's got their tastes, and they all differ greatly. As such, if you'd like to flame me, then don't.

It's not really that hard to learn locomotion in a continuous environment, where you can improve a little bit at a time. Swimming and crawling were done years ago. Basically, you formulate the problem in terms of a measurement of how well you're doing, and provide a control algorithm with lots of scalar parameters that can be tweaked. You then apply a learning algorithm which tweaks them, trying to increase the success metric. Any of the algorithms for solving hill-climbing problems in moderately bumpy spaces (genetic algorithms, neural nets, simulated annealing, adaptive fuzzy control, etc.) will work.

There are limits to how far you can go with this technique, and they're fairly low. Gaits that require balance, such as biped walking and running, require more powerful techniques. Any task that requires even a small amount of prediction needs a different approach. Rod Brooks at MIT has explored the no-prediction no-model approach to control thoroughly, so we have a good idea now what its limits are.

The nutcase with the implant is Kevin Warwick, a professor of Cybernetics at Reading University, UK.

Steve Mann, who wrote the compositing code that this Slashdot article is about, is a professor at the University of Toronto, teaching wearable computing, and is the one who had his (non-implanted, despite what the slashdot post says) hardware ripped off in Newfoundland.

THEY ARE NOT THE SAME PERSON.

Perhaps a realistic example is in order. Shape, animal, and device driver toy examples don't scale to real things that I actually encounter.

A nontrivial example won't fit here, so I'll have to refer you to Parnas's original article on the topic. Its example could still be considered trivial by today's standards, but it's far better than anything I could fit in this space. It makes no reference to OO whatsoever. In fact, it's decidedly non-OO, with modules like "circular shifter" and "alphabetizer" that are most certainly procedural abstractions.

If you want a bigger example, there's my Master's thesis work, especially my defence presentation (PowerPoint slides). I consider it a good example of a successful application of information hiding principles, and it's about 23,000 LOC, so it's big enough to be considered nontrivial. It's also OO, so it doesn't prove that OO is orthogonal to information hiding, but I feel that its success arises from information hiding more than OO (especially since it's written in C and so makes no use of inheritance).

One can show that 3rd-generation languages can code the same thing with less code and be more transportable to other platforms than assembler.

The 3rd-generation-versus-assembly is the most clear-cut case of programming language expressive power there is, and yet it's still quite hard to "prove" in any meaningful way.

Relational tables are a protocol and organizational philosophy. They allow, for example, one to get GOF-like patterns with mere formulas instead of painstaking hand-referencing needed in OOP.

Perhaps a realistic example is in order. Shape, animal, and device driver toy examples don't scale to real things that I actually encounter.

A nontrivial example won't fit here, so I'll have to refer you to Parnas's original article on the topic. Its example could still be considered trivial by today's standards, but it's far better than anything I could fit in this space. It makes no reference to OO whatsoever. In fact, it's decidedly non-OO, with modules like "circular shifter" and "alphabetizer" that are most certainly procedural abstractions.

If you want a bigger example, there's my Master's thesis work, especially my defence presentation (PowerPoint slides). I consider it a good example of a successful application of information hiding principles, and it's about 23,000 LOC, so it's big enough to be considered nontrivial. It's also OO, so it doesn't prove that OO is orthogonal to information hiding, but I feel that its success arises from information hiding more than OO (especially since it's written in C and so makes no use of inheritance).

One can show that 3rd-generation languages can code the same thing with less code and be more transportable to other platforms than assembler.

The 3rd-generation-versus-assembly is the most clear-cut case of programming language expressive power there is, and yet it's still quite hard to "prove" in any meaningful way.

Relational tables are a protocol and organizational philosophy. They allow, for example, one to get GOF-like patterns with mere formulas instead of painstaking hand-referencing needed in OOP.

Yes, modular software is better. However, good luck finding any in the Real World. People think modularity has to be this heaviweight headache like COM or CORBA, or perhaps Java.

I think it is not widely understood that modularity can be fine-grained and pervasive while still being efficient, especially if it is done in such a way that module boundaries can be optimized away (eg. through inlining) at compile time.

(Incidentally, speaking of inlining, gcc is actually a pretty good compiler to use if you want to take this approach. It has great inlining facilities, which makes up for its lackluster optimization capabilities. I had a system I wrote using fine-grained modularity that relied very heavily on inlining for performance. When I moved from gcc to icc (Intel's own C compiler) it became about ten times slower, even after some fairly careful tweaking of icc's command line options. The difference was that icc simply refused to inline most of my function calls for a variety of reasons.)

That's easier to find than some might think. For the hexadecimal representation there exists a formula that allows to calculate digits of pi starting at an arbitrary place, maybe there is such a formula for the decimal case too. Anyway given a decent PC you can probably calculate up to 10.000.000 digits in a few days. But why bother, when it's easier to simply download them. Your choosen password should be in here, starting with the 470344th or 470343th digit (depends if you count the 3., but you didn't, line 4704, 5th block from digit 4).

No big deal. Just type in sucks and links on the first page explain why Microsoft sucks.

-

He's almost completely the father of wearable computing. He wore a pair of glasses and a "keyboard" interface everywhere he goes, and worked for MIT media lab. People who have met him say he seemed more intelligent than he actually is, because his vision sensors send information back to the lab which he can route to others for aid in identification, and he asked questions on the LAN IRC (I don't think they actually use that protocol) and got the answers from the minds of MIT. Its as though he can answer any question.

His page is at the University of Toronto now, and those glasses he's wearing are exactly the ones that I mentioned - at least, they're the fourth draft of the ones I mentioned.

Some other complaints about this "invented at Intel" terminalogy can be found at The Register.

Also Toronto has a nice slide show (pdf) on the topic.

For the record I contributed a little tiny bit to this stuff when I was at Intel (I found what I think was the first multi-processor bug for SMT.)

I think this is it: http://www.mudlib.org/~rassilon/p2c/

Emergence, which the reviewer didn't seem to cover very well, is not "keep moving backwards until you see something ordered." It is a behavior (usually, from what I've read about, in groups) where rules that pertain only to individuals give rise to complex behaviors.

The canonical example of this is flocking, from Flocks, Herds, and Schools by Craig Reynolds. Basically, if all members of a group avoid collisions (with obstacles and each other), match velocity with locally perceived group members, and stay close to local members, a flocking behavior is achieved. There is good evidence as well that this is how flocking is achieved in nature -- ornithologists (bird people.. may have gotten the word wrong:)) have studied Mr. Reynolds' simulations and found them to be indistinguishable from birds.

Another example is ants finding their way to food. They start off randomly travelling, leaving their pheremone trails everywhere. However, once food is found, the pheremone trail to that food is reinforced over and over, causing more and more ants to travel there. Eventually you see a line of ants going straight for the food -- all because of a "wander unless I sense enough pheremones" behavior.

The point of this is that emergence is not necessarily a global phenomenon -- it occurs at all levels.

That's quite ironic. I was just having dinner at one of U of T's dining halls, and a friend of mine mentioned that he hasn't been out of his room in two days, for any reason other than food; he's been playing Civ 3 ever since he copied it off of someone.

< Covalent's Version of Apache 2.0 To Drop Monday | Flat-Rate Wireless Where The Sun Don't Shine (Much) >

Big_Ass_Spork (446856)[ Preferences ]

Related Links

this article

budgeting complaints

More on Space

Also by timothy

Science

World Solar Challenge Set To Begin

Major Meteor Shower Next Weekend

Wind Tunnel for Birds

Pluto-Kuiper Express A Go (Again ... For Now ...)

IceCube Neutrino Telescope

Pointing the Way for Micro Motion

Neutrinos, Muons and the Standard Model

Satellite Observing Black Holes

USNA "Budget" Satellite Launched and Functioning

NuTeV result disagrees with Standard Model

Pluto-Kuiper Express A Go (Again ... For Now ...) | Preferences | Top | 4 comments | Search Discussion Threshold: -1: 4 comments 0: 3 comments 1: 2 comments 2: 2 comments 3: 0 comments 4: 0 comments 5: 0 comments Flat Nested No Comments Threaded Oldest First Newest First Highest Scores First Oldest First (Ignore Threads) Newest First (Ignore Threads) Save: The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way. Ass Penetration. (Score:-1, Troll)
by forkspoon on Saturday November 10, @11:27AM (#2548413)
(User #116573 Info) Hasn't this mission been on and off for years? It seems worthwhile, if only to get close-ups of Pluto.

Thanks,

Travis
forkspoon@hotmail.com
[ Reply to This | Parent ]

• Cool (Score:0, Offtopic)
  by p3d0 on Saturday November 10, @12:37PM (#2548539)
  (User #42270 Info | http://www.eecg.toronto.edu/~doylep) Interesting experiment: post a reasonable-souding article with a troll subject line, and see what the moderators do.
  
  The only trouble is that your post is content-free, so this is an unmitigated troll. However, I don't feel like wasting my mod points on it.
  
  Have a nice day.
  --
  Patrick Doyle [ Reply to This | Parent ]

[ Reply to This | Parent ] A Few Points (Score:2, Interesting)
by CheshireCatCO (weissj@nospam.colorado.edu) on Saturday November 10, @12:07PM (#2548466)
(User #185193 Info | http://bogart.colorado.edu/~weissj/cyrano.html) "Bastard stepchild..." The PKE was much too expensive. But, then, it was JPL's project, so no one was shocked at that. NASA was wise to have farmed it out for competing bids from other groups. And, in fact, the other groups are able to do at least as much (probably more) for less than JPL could. So calling it a 'bastard stepchild' seems unnecessarily derisive to me.

The 2006 launch date is not critical. One of the two competing team leaders has worked out that with Venus gravity assists, we could send a probe to Pluto in any given year. Furthermore, in reviewing the recent papers on the topic, he's determined that it is quite unlikely that the atmosphere will freeze out as was predicted a decade or two ago.

Also see this paper at wearcam.org.

1)
Well, there are several tri-band mobiles out there, and Europe and Japan there aren't many people, who use a 2 year old mobile.

2)
Actually, UMTS uses for paired bands UTRA FDD with W-CDMA (Wide-Band Code Division Multiple Access) and for unpaired bands UTRA TDD with TD-CDMA (Time Division Code Division Multiple Access) is employed.
IRC, UTRA FDD is used for symmetrical circuit-switched services like voice and video-telephone, so generally you will use W-CDMA.
Here some further explanations to UMTS and GSM.

A GSM cell has a range up to 64km (e.g. coastal region) and normally up to 32km. Those are protocol related limitations. Usually cells are smaller due to surrounding buildings or mountains. But those physical limitations apply to any radio signal.

Can you tell me what is the typical cell range of a CDMA or a D-AMPS system?

UMTS cell sizes, and CDMA-networks in general, depend on the number of users as the signal to noise ratio increases with the number of users.
This is unevitable, since one users will be noise for to the other users, which is the prinicple of CDMA.
With up to 5 users you have a cell range of about 1.4km with 40 users the cell range is only 0.6km, with 42 users the cell range is 0.3km.
CDMA cells tend to "breathe".
The numbers are of no importance for CDMA in general, but the tendency is.
How do you plan coverage for breathing cells?

>Digital technologies, especially GSM, require smaller cell sizes

Please explain to me, what the causal relationship between cell-size and employing digital technologies is.

My school (University of Toronto) owns the domain name

toronto.edu

however they don't like to use it. Canadian universities don't seem to like it. I guess they like to be a little nationalistic and use the .ca instead. So we end up with toronto.edu just pointing to

utoronto.ca

Witness also queensu.ca and mcgill.ca , although I don't think they have .edu names at all. Some people, like the math department, seem to just use the .edu when they refer to their site, but it could be that my professor is just used to that idea. The country thing is acceptable, but I've never really appreciated it's ubiquitous use in some countries... like www.shoddyelectronics.com.tw , or www.random.co.uk . It just seems to give up the whole 'international marketplace' feel that .com is supposed to have.

At least they don't rename their Electrical and Computer Engineering program to the local cable company!

And you thought that Disney webpage prank MIT pulled a while back was all for laughs!

http://www.dgp.toronto.edu/~ematias/papers/music

It's pretty easy to grasp and (unlike the book) it's free! :-)

You mention targeting a Wearable computer design -- have you spoken with anyone from any of the university Wearable Computing groups, or Professor Steve Mann?

Hey Folks,

I'm the inventor of the Half Keyboard.

Feel free to ask any questions. For the bashful, most of the research we did on it is summarized here:

• http://www.dgp.toronto.edu/people/ematias/papers/h ci96/

Edgar

Gil Pratt took over the Leg Lab, and focused more on actuator design. Raibert's machines worked, but needed hydraulic, electrical, and pneumatic umbilicals. Better machine design has produced more compact robots.

The idea of springy joints has been around for a while. It's common to model muscles as springs and dampers for which the spring constant, neutral point, and damping factor are adjustable. It's well-known that in mammal running, most of the energy of each stride is stored as spring energy in muscles. (As I recall, about 80% of the energy is recycled for the next stride, so this is a big win.) There's been work at Stanford on flexible manipulators, although that's more related to arms. McGill has a small, high-efficiency hopping machine.

Unless you use pneumatic actuators, off the shelf components aren't well-matched for this approach motion control. That doesn't mean it can't be done, but you spend a lot of time on component development. That's what the Leg Lab has been focusing on under Pratt, and that's why the little dinosaur model was tough to build.

Rod Brooks from MIT also tried a robotic startup, IS Robotics, which produced a $100K robotic insect. Didn't sell. It's really hard to sell mobile robots; I've known several people with failed startups.

I work on this sort of thing for games and animation.

Man, Streamsicle does rock! But what's the dilly with that dancing popsicle?
Multiplayer Strategy

Posted that one already, but here it is again

www.toronto.edu