Automation^2

Doug_Adam

Member
Join Date
Sep 2002
Location
Perth
Posts
948
G'day everyone.

Back from leave, so time to post again.

I have been thinking for a while on methods to automate the automation process (thus automation^2). At the moment, most automation is at the hand crafted or maybe power tool stage of development. We do not yet have methods for automating the programming stage, although things are getting easier. Semi automation is possible, with reusable code and copy and paste, but full blown automation is not yet there.

Kicking round some thoughts on this, I got the idea of setting up a lookup book of truth tables vs optimal logic for that table. A bit of maths came up with the formula for number of inputs compared to number of solutions. A 3 input truth table has 8 entries, or 2^3. A four input truth table has 16 entries or 2^4, and an n input truth table has 2^n entries.
As far as possible optimal solutions are concerned, a 3 input combination has 256 possible truth tables, and therefor optimal solutions. A 4 input combination has 65536 possible truth tables. This means that there are 2^(2^n) possible logic combinations for n inputs.
For three inputs and 256 solutions, one page per solution, this lookup table can fit into a printed book.
For 4 inputs and 65536 solutions, this table can fit onto a CD rom with a search function.
5 inputs pushes the number of solutions to 4 Gig of solutions, possibly allowing them to fit on a large hard drive without compression.

A small PLC, with 8 inputs and 6 outputs can be setup for up to 10Exp68 Gig worth of solutions, probably exceeding the size of all media storage on the planet.

I have yet to consider internal bits and sequence bits.

Obviously, us programmers will not be replaced with a handbook of lookup tables for a while yet.

Doug
 
Obviously, us programmers will not be replaced with a handbook of lookup tables for a while yet.
Now, is that good news or is that good news? (y)
Long live the programming community! :site:

Kind regards,
 
What?

Doug_Adam said:
G'day everyone.

Back from leave, so time to post again.

I have been thinking for a while on methods to automate the automation process (thus automation^2). At the moment, most automation is at the hand crafted or maybe power tool stage of development. We do not yet have methods for automating the programming stage, although things are getting easier. Semi automation is possible, with reusable code and copy and paste, but full blown automation is not yet there.

Kicking round some thoughts on this, I got the idea of setting up a lookup book of truth tables vs optimal logic for that table. A bit of maths came up with the formula for number of inputs compared to number of solutions. A 3 input truth table has 8 entries, or 2^3. A four input truth table has 16 entries or 2^4, and an n input truth table has 2^n entries.
OK so far.

Doug_Adam said:
As far as possible optimal solutions are concerned, a 3 input combination has 256 possible truth tables, and therefor optimal solutions. A 4 input combination has 65536 possible truth tables. This means that there are 2^(2^n) possible logic combinations for n inputs.
What is a 'optimal solution'?

Doug_Adam said:
For three inputs and 256 solutions, one page per solution, this lookup table can fit into a printed book.
For 4 inputs and 65536 solutions, this table can fit onto a CD rom with a search function.
5 inputs pushes the number of solutions to 4 Gig of solutions, possibly allowing them to fit on a large hard drive without compression.

A small PLC, with 8 inputs and 6 outputs can be setup for up to 10Exp68 Gig worth of solutions, probably exceeding the size of all media storage on the planet.

I am not convinced

Doug_Adam said:
I have yet to consider internal bits and sequence bits.

Obviously, us programmers will not be replaced with a handbook of lookup tables for a while yet.

Doug

Programmers will not be replaced, but the tools they use might. Think about this. Some logic operations can be done in FPGAs or RAM. Think of using a 64K byte by 8 bit ram. The 8 data lines are for the outputs. 8 of the 16 address lines are for inputs and the other 8 inputs are for the last state of the 8 outputs. Now one can make a state machine that would operate as fast as ram ( low nano seconds ) can be accessed and all the logic is solved in parallel.

It is hard to find rams that small anymore.
 
I once had to reverse engineer a program that tried to accommodate a variety of system configurations with various indirect addressing schemes, truth tables, etc. Very elaborate code, very clever, and actually worked. In my assesment, though, not worth the effort.

It comes down, in my opinion, to one of those cases where caring for the tool is more work than doing the job without it. It is often the case, as it was in that job, where complexity that a programmer takes in stride is very difficult to write code for. You end up devoting more effort to automating the process than would be required to do it from scratch, or modify existing code, in the first place.

Artificial intelligence and expert systems and automatic code generation look great on paper and make good magazine articles. In the long run, though, I think the appliations where they are worth while are specialized and uncommon.
 
rsdoran said:
I would not be too sure about that, do not forget about AI.

Maybe so, but if I was replaced by a lookup table my pride would never recover.

Peter Nachtwey said:
What is a 'optimal solution'?

My assumption for this excercise was that there is one, and only one, optimal solution for each truth table. I have not yet tested whether this is true, or even worked out what the parameters of an optimal solution is vs a non optimal solution.

Peter Nachtwey said:
I am not convinced

2^(2^8) is around 10 Exp 77 or 10 Exp 68 Gig. If I got the maths wrong, it is still around this order of magnitue, which demonstrates that I was heading down a path leading nowhere.

Peter Nachtwey said:
Programmers will not be replaced, but the tools they use might. Think about this. Some logic operations can be done in FPGAs or RAM. Think of using a 64K byte by 8 bit ram. The 8 data lines are for the outputs. 8 of the 16 address lines are for inputs and the other 8 inputs are for the last state of the 8 outputs. Now one can make a state machine that would operate as fast as ram ( low nano seconds ) can be accessed and all the logic is solved in parallel.

It is hard to find rams that small anymore.

This is a good solution that has been well used for a long time (At least it was in my old university text book). Now a useful tool could be a compiler to convert this state machine directly to logic within the RAM. My guess is that someone would already have written one of these.

Mickey said:
Maybe you should go back on leave ?

Insanity leave?
 
Peter Nachtwey said:
Programmers will not be replaced, but the tools they use might. Think about this. Some logic operations can be done in FPGAs or RAM. Think of using a 64K byte by 8 bit ram. The 8 data lines are for the outputs. 8 of the 16 address lines are for inputs and the other 8 inputs are for the last state of the 8 outputs. Now one can make a state machine that would operate as fast as ram ( low nano seconds ) can be accessed and all the logic is solved in parallel.

Sometimes good to excurse out of practical plc world... so i will try a small thought myself ... what are you talking here is almost similar to techniques used inside common CPU, just binary input of incredible lenght is processed through plenty of pipelines and logical element fields, and in the end you'll get binary output of incredible length ...

but... just try to write code which will calculate number or try to create set of states which will use precalculated tables and then get the number from table using index ... well ....

- you will never need all possibilities at once
(so that would not be faster)
- from the implemenatation sight, it's much easier and
effective to create chip with ability to multiply
2^32 * 2^32 numbers than to have 4*4GB big memory module
with all these numbers precalculated ...

well ... just thought, no offense :)
 
Back
Top Bottom