Forgot your password?
Close
typodupeerror
Earth

Sticky Rice Is the Key To Super Strong Mortar 194

Posted by timothy from the what-can't-sticky-rice-do? dept.
lilbridge writes "For over 1,500 years the Chinese have been using sticky rice as an ingredient in mortar, which has resulted in super strong buildings, many of which are still standing after hundreds of years. Scientists have been studying the sticky rice and lime mortar to unlock the secrets of its strength, and have just determined the secret ingredient that makes the mortar more stable and stronger. The scientists have also concluded that this mixture is the most appropriate for restoration of ancient and historic buildings, which means it is probably also appropriate for new construction as well."

Submission + - Sudden Demand for Logicians on Wall Street (wordpress.com) 1

Submitted by Anonymous Coward
An anonymous reader writes: In an unexpected development for the depressed market for mathematical logicians, Wall Street has begun quietly and aggressively recruiting proof theorists and recursion theorists for their expertise in applying ordinal notations and ordinal collapsing functions to high-frequency algorithmic trading. Ordinal notations, which specify sequences of ordinal numbers of ever increasing complexity, are being used by elite trading operations to parameterize families of trading strategies of breathtaking sophistication. Ordinal notation high-frequency trading algorithms pit their strategies against similar algorithmic opponents on electronic exchanges for a few fleeting seconds, during which thousands of trades are executed, including exploratory trades that test the strategies of opposing human and machine traders.

The monetary advantage of the current strategy is rapidly exhausted after a lifetime of approximately four seconds–an eternity for a machine, but barely enough time for a human to begin to comprehend what happened. The algorithm then switches to another trading strategy of higher ordinal rank, and uses this for a few seconds on one or more electronic exchanges, and so on, while opponent algorithms attempt the same maneuvers, risking billions of dollars in the process.
Hardware

Submission + - When mistakes improve performance (bbc.co.uk)

Submitted by
jd
jd writes: "Professor Rakesh Kumar at the University of Illinois has produced research showing that allowing communication errors between microprocessor components and then making the software more robust will actually result in chips that are faster and yet require less power. His argument is that at the current scale errors in transmission occur anyway and that the efforts of chip manufacturers to hide these to create the illusion of perfect reliability simply introduces a lot of unnecessary expense, demands excessive power and deoptimises the design. He favors a new architecture, which he calls the "stochastic processor" which is designed to gracefully handle data corruption and error recovery. He believes he has shown such a design would work and that it will permit Moore's Law to continue to operate into the foreseeable future. However, this is not the first time someone has tried to fundamentally revolutionize the CPU. The Transputer, the AMULET, the FM8501, the iWARP and the Crusoe were all supposed to be game-changers but died a cold, lonely death instead — and those were far closer to design philosophies programmers are currently familiar with. Modern software simply isn't written with the level of reliability the Stochastic Processor requires in mind (and many software packages are too big and too complex to port), and the volume of available software frequently makes or breaks new designs. Will this be "interesting but dead-end" research, or will the Professor pull off a CPU architectural revolution really not seen since the microprocessor was designed?"

Comment Make your mind up. (Score 1) 246

by snester (#24393375) Attached to: Software, Tools, Or Techniques For UI Review?

I have designed about 30 applications from Commodore 64, Amiga, BBC Arhcimedes, Windows 3.1, n64 through to Vista and Embedded deivces

1. Do you have a vision or not? And who is going to use it.

If you don't then use a committee method to design your UI. Say bye-bye to what you want.

1. If you do have a vision then get your needs/features down on paper
2. Define the platform/platforms you are planning your application to run on. (things like screen aspect, minimum/maximum resolution and input device are very important considerations.
3. Start to mock up designs and position the features you are planning
4. Start to create working mock-ups of key interface elements
5. Start to get feedback on the two or three ideas you have (try getting people to see the idea you like the best - explain why)

6. Do a prototype (even if it ends up as a commercial prototype)
7. Evaluate the issues people have and the way people use it. Create a new version if your prototype is unusable - otherwise let it grow as much as it can.

Slashdot Top Deals

To the systems programmer, users and applications serve only to provide a test load.

Close