FTSE

"We can solve any problem by introducing an extra level of

indirection."

Love it >:-} ...Jim Thompson

-- | James E.Thompson | mens | | Analog Innovations | et | | Analog/Mixed-Signal ASIC's and Discrete Systems | manus | | STV, Queen Creek, AZ 85142 Skype: skypeanalog | | | Voice:(480)460-2350 Fax: Available upon request | Brass Rat | | E-mail Icon at

| 1962 | It's what you learn, after you know it all, that counts.

What is the 'FTSE'

This index, more colloquially known at the Footsie, is arguably the most popular and widely used stock market index around the globe. This index is representative of approximately 80% of the market capitalization of the LSE in its entirety. Larger companies comprise a greater portion of the index because it is weighted by market capitalization. The FTSE 100 is managed by the FTSE Group. The name is a mashup of its co-owners. It is calculated in real time, and when the market is open it is updated and published every 15 seconds.

Mikek

Prefer horizontal integration over vertical integration.

There's a lot of truth in that. Whether you regard that as guidance or reflection depends on whether you are an optimist or a pessimist.

Similar aphorisms are "Almost all programming can be viewed as an exercise in caching" "The solution to signal processing problems is to integrate for longer".

exercise in caching"

is to integrate for longer".

Or the famous pseudo-mathematical induction:

All programs have bugs

All programs can be made smaller.

Therefore:

All programs can be reduced to a single incorrect instruction.

Cheers

Phil Hobbs

The PDP-11 had the LandMine 16-bit opcode

MOV -(PC), -(PC)

which copied itself just below itself and re-executed.

You could also do fun things like

NEG PC

--

John Larkin         Highland Technology, Inc 
picosecond timing   precision measurement  

jlarkin att highlandtechnology dott com 
http://www.highlandtechnology.com

One luminary (Wirth? Dijkstra?) had entered some kind of programming contest. His program was slow and correct, and lost to a program that was faster but not always correct.

His response was that if he had realised incorrect solutions were permissible, he could have made his program much faster and delivered it much sooner.

It is depressing how often I've had to deploy that example as an admonition.

The allied example is salesdroids that proudly announce how many lines of code their product autogenerates without programmer intervention. One particularly pernicious droid claimed

500,000 lines. Fortunately my PHBs got the point when I said I "is that all? I could generate 1,000,000 in the same time".

Grin, The best I can do is from a guy I was working for as a handyman when I was in high school. I was smaller then, struggling to get a lug nut loose on a lawn tractor. "Don't force it. Get a bigger hammer."

George H.

IEFBR14

On early versions of Honeywell DDP computers, you could physically destroy the computer with for instance Load Accumulator instruction.

The DDP 16 bit memory location could hold a 14 bit address and an indirect bit. When you performed for instance attempted to load the accumulator and the memory location referenced in the instruction contained the indirect bit set, the 14 bit was used to locate a new location. If that new location also had the indirect bit set, the 14 bit address of _that_ word was used. Thus the load accumulator instruction could reference tens of word or there could be an infinite loop, when the last word referenced the first indirect word. This of course halted the program execution. However if a word containing the indirect bit and the address pointed to the word itself, a very tight loop was created. Remembering that each read operation on a core is actually an RMW operation, which generates some heat. Finally the cores in that word were overheated, destroying the those cores.

Later models of the DDP family had some hardware protection, to terminate such loops before the core was destroyed.

Sadly it does ring true. I have seen software solutions engineered to fit into a particular hierarchical model where some levels were NOPs.

The right amount of abstraction helps make code more maintainable and extensible, but too much or too little can be a bad thing.

--
Regards, 
Martin Brown