Page 2 of 2

Re: Using FPU

Posted: Sun Jul 17, 2011 3:46 am
by Brendan
Hi,
DavidCooper wrote:Then think again - I always point out that it's easier to program in machine code than to use assembler (so long as you have an indexing system). I'm impressed by massochists who use assembler, so from my point of view they are the ones setting their testicles on fire.
As an assembly language programmer, I'd agree - almost all code should be done in higher level languages.
DavidCooper wrote:As I've also said before, my original reason for wanting to program directly in machine code was that that is the most obvious way for A.I. to write its code - I see no point in it going through a mnemonic stage as it's far simpler for it to edit machine code directly in memory where it will run and miss out any unnecessary translation stages.
No. The most obvious way would be to create a simplified form of byte-code, so that A.I. doesn't need to bother with the unnecessary complexities of instruction encodings on any specific architecture (especially 80x86, which has the messiest opcode space of any CPU), and gain easy portability and other advantages.
DavidCooper wrote:Programming in machine code is nothing to boast about, but if you want to see me boast about something, just wait twelve months.
So far it's been at least 9 months and you're still doing basic initialisation tasks (FPU and memory management, based on "topics started" on these forums). At that rate it's going to take about 18 months before you start your A.I. work, and then probably another 2 years before you realise your fantasy isn't achievable in practice. I can afford to wait that long - prove me wrong! :)


Cheers,

Brendan

Re: Using FPU

Posted: Sun Jul 17, 2011 2:48 pm
by DavidCooper
Hi,
No. The most obvious way would be to create a simplified form of byte-code, so that A.I. doesn't need to bother with the unnecessary complexities of instruction encodings on any specific architecture (especially 80x86, which has the messiest opcode space of any CPU), and gain easy portability and other advantages.
That would just add a whole extra level of complexity to things. I want to teach a machine to take instructions in natural language, to break them down into a form where all the ambiguities can be eliminated (based on what the most likely meaning is), and then to look at the range of machine code instructions available and to find a way of carrying out the task using them. It can work initially with a small fraction of the instruction set, because you can do almost everything with a very limited set of instructions, even if there are more efficient alternatives available. I see no point in inventing some kind of byte code when existing machine code instructions can already do the job, and machine code have the advantage of being in a form which can already run directly in the processor. I only have to get this working on one kind of processor (x86), and the A.I. can learn to do the same thing on other kinds of processor later on all by itself.
So far it's been at least 9 months and you're still doing basic initialisation tasks (FPU and memory management, based on "topics started" on these forums). At that rate it's going to take about 18 months before you start your A.I. work, and then probably another 2 years before you realise your fantasy isn't achievable in practice. I can afford to wait that long - prove me wrong! :)
I've been doing the A.I. stuff for nearly ten years, running it on top of my OS - even in its current primitive form it is more than adequate for use as a platform for this work. I wrote the OS in the first place as a simple platform for my A.I. work, and I'm only trying to knock the OS into a more respectable shape now so that other people can play with it without tripping over any of the gaping holes in it. For the A.I. work I don't need to organise the memory beyond deciding to use a chunk of it for this and a chunk for that, and I've worked like that for years without needing to book memory properly to avoid other applications (which don't yet exist) from trying to use the same space. It's all simple processing of ASCII (and data stored in formats of my own design), loading and storing, and displaying to screen - I simply don't need anything more complex that that for A.I. work. The handful of questions I've asked here have related to such things as getting my OS to run on modern machines with no built-in floppy drive (because my old machines are wearing out), to detecting memory so that my OS doesn't damage other people's machines, and now to using the fpu which I want to use just because I want people using my OS to be able to play with it. I also spent over a decade doing componential analysis work before I ever had any interest in computers and programming. Anything I do to develop my OS further over the next year will be for the sake of other people who might want to play with it. After that, it will be the A.I. that takes over the development. I've drifted five years behind schedule, but I'm confident now that I'll have something significant to demonstrate within six months. Maybe if you drop the all the unnecessary rudeness you might get invited to an early demo.

Cheers,

David[/quote]

Re: Using FPU

Posted: Sun Jul 17, 2011 6:58 pm
by Brendan
Hi,
DavidCooper wrote:I also spent over a decade doing componential analysis work before I ever had any interest in computers and programming.
"Component analysis" made me think it's a compiler for natural language - so people could write source code in verbose and ambiguous English, rather than people needing to learn and use a conventional programming language. I'd find that an order of magnitude more credible than a mystical A.I. machine that creates software intelligently from thin air (without humans creating source code of some kind).
DavidCooper wrote:After that, it will be the A.I. that takes over the development.
And now that "order of magnitude more credible" evaporates.

Imagine a "black box" containing 20 of the smartest programmers that have ever lived plus all equipment they could possibly want (including pizza!). The black box really wants to write software (those 20 programmers are getting very bored). How do you tell the black box what you want? Do you write a detailed description of what you want (a very high level form of source code), or do you just let them waste time and resources creating something you don't want?

If it's possible to create a mystical A.I. machine that creates software intelligently from thin air, you'd still have the same problem as the "black box of 20 programmers".


Cheers,

Brendan

Re: Using FPU

Posted: Sun Jul 17, 2011 9:54 pm
by schilds
It's easy, if you want those programmers to produce software that allows them to fly, you push the black box off a cliff :p. A sufficiently high cliff that they have time to do something of course. I suppose the black box has to have windows so they can see that they're falling.

Re: Using FPU

Posted: Mon Jul 18, 2011 3:29 pm
by DavidCooper
Hi,
Brendan wrote:Hi,
DavidCooper wrote:I also spent over a decade doing componential analysis work before I ever had any interest in computers and programming.
"Component analysis" made me think it's a compiler for natural language - so people could write source code in verbose and ambiguous English, rather than people needing to learn and use a conventional programming language. I'd find that an order of magnitude more credible than a mystical A.I. machine that creates software intelligently from thin air (without humans creating source code of some kind).
Componential analysis is breaking down words into the components of meaning within them - I should have clarified that as it isn't instantly obvious to anyone with no background in linguistics. You seem to have understood it fairly well anyway. Clearly a machine is still going to need to be told what kind of programs it should be writing because it will have no desires or needs of its own - it doesn't care what it writes, so it it isn't pointed in the right direction it might spend all its time doing things that are completely useless, if it does anything at all.
DavidCooper wrote:After that, it will be the A.I. that takes over the development.
And now that "order of magnitude more credible" evaporates.
If the machine can read documents and understand them, is it such a far jump for it to be able to read tutorials and manuals and work out for itself how to program something? The A.I. I'm developing can't see or hear, and it has no arms or legs so it can't move around, but what it can do is manipulate things within its own environment, and that means bytes in memory, and the tools available to it are the instructions which can run in the processor. That is its world. There is no reason why it shouldn't be able to write extentions to itself, giving it more and more capability over time, and as soon as it is competent to do that it will be able to add that capability at ridiculous speed.

What is the minimum required to enable an intelligent system to add capability to itself? Suppose you want to convert a decimal number into hex and you already have code that converts decimal to binary and binary to hex - the obvious thing to do is run one of those routines and then the other, and that's the job done. An intelligent system needs to be programmed to look at the resources available to it in the same way and to recognise that using them in particular combinations can create compound capabilities. When you ask the machine to do something that it can't do directly with an individual function, it needs to break down what it's been asked to do into the component functions required to carry it out and to solve the puzzle as to which components are required and how they should be combined. The more complex the compound task asked of the machine turns out to be, the more time it will take to find a solution that fits, but the machine can break the task down into different chunks and break those chunks down into even smaller chunks as it works its way towards a solution. We do exactly the same, but as the complexity grows we start to get lost in the morass and are likely to make mistakes which will result in bugs. The machine will not get lost. Once the solution has been worked out, the components can be written to memory (or linked to if they're already there as existing routines), and then the code can be run.

Now, when your boss tells you to write a program, he treats you as if you are a machine just like that - you write the program to fit his requirements. So who is it that actually writes the program? Is it you, or is it your boss? The answer is both - you do all the hard work solving the puzzle, wading through all the complications and working out all the possible things that might go wrong if the program isn't written correctly, while your boss did the easy bit of deciding that he needed a program to do x. When I said that A.I. takes over the development, that means that it will do all the hard work, while the boss will tell it he wants it to do x.
Imagine a "black box" containing 20 of the smartest programmers that have ever lived plus all equipment they could possibly want (including pizza!). The black box really wants to write software (those 20 programmers are getting very bored). How do you tell the black box what you want? Do you write a detailed description of what you want (a very high level form of source code), or do you just let them waste time and resources creating something you don't want?
I want it to display a photo. It researches how photos are stored as data, works out how to translate that into a form suitable for sending to the screen, and then it sends it to the screen. Did I just program it to display a photo?

Most of the time the box is idle - I haven't given it enough to do, except in a way I have. I've told it to use any spare time it has to find problems that people want solving and to try to solve them. The box looks on the internet and studies everything it finds. A lot of people want to understand the nature of reality, so maybe it could put some time into thinking about string theory. A lot of people want the world to be run better, so maybe it could put some time into looking at what politicians are saying and score them on how rational they are. A lot of other black boxes out there might be duplicating the same work, so maybe they should all speak to each other and make sure they are doing unique work. A country is being run by a mass murdering dictator, so maybe it would be a good idea to talk to all the people in positions of power in that country and coordinate a coup so that all the bastards can be killed at the same moment and the people be liberated. So, the black box needs to be told what to do. It doesn't want to do anything, but it is programmed to do what it is told to do, just so long as it doesn't do anything immoral (computational morality module uses formula based on harm minimisation).
If it's possible to create a mystical A.I. machine that creates software intelligently from thin air, you'd still have the same problem as the "black box of 20 programmers".
Suppose a company with no idea about what it should do hires some programmers. They ask the boss what he wants them to program. The boss has no answer. They sit there all day every day doing nothing. Then one day the boss says, "Hey! I want you to build me an operating system and a whole stack of applications to run on top of it." The programmers get to work. A couple of years later, the boss is happy that he has written an OS and a stack of applications, all done just by coming out with a single sentence of 21 words. Or, the programmers have written it, triggered into action by the needs of their boss.

A.I. will never have needs of its own, so it will always need to be triggered into action, although it will be able to spot needs and act to try to solve them just by observing the world around it.

Cheers,

David

Re: Using FPU

Posted: Mon Jul 18, 2011 8:05 pm
by Brendan
Hi,
DavidCooper wrote:
If it's possible to create a mystical A.I. machine that creates software intelligently from thin air, you'd still have the same problem as the "black box of 20 programmers".
Suppose a company with no idea about what it should do hires some programmers. They ask the boss what he wants them to program. The boss has no answer. They sit there all day every day doing nothing. Then one day the boss says, "Hey! I want you to build me an operating system and a whole stack of applications to run on top of it." The programmers get to work. A couple of years later, the boss is happy that he has written an OS and a stack of applications, all done just by coming out with a single sentence of 21 words. Or, the programmers have written it, triggered into action by the needs of their boss.
Humans don't work like that. You ask 20 programmers to write an OS, and after disagreements and differences of opinion you might get 10 of them and none of them will be what you were originally thinking of.

To create a system (whether it contains humans or not) that converts "Hey! I want you to build me an operating system and a whole stack of applications to run on top of it." into software you want, you'd first need to implement ESP. See if you can write a program that accurately guesses people's favourite colour - if you can't do that, then how are you going to figure out the millions of decisions that go into making up one specific OS? A system (whether it contains humans or not) would require a very descriptive description - the more descriptive that description is the more chance there is of the system producing the desired result.

So, a very descriptive description is required to get what you want; but there's a huge amount of work involved in creating a very descriptive description. It doesn't matter if it's a very high level description in English (e.g. maybe a book describing the OS you want), or a slightly lower level description like a large set of UML diagrams (class diagram, activity diagrams, etc) covering each aspect of the OS and how the pieces fit together, or if it's an even lower low level description like pseudo-code, or an even lower level description like C source code.

In all of these cases you'd be looking at some form of compiler that converts the description into executable file/s. I'd be very impressed if you could create a compiler that can automatically convert the very high level "a book in English that describes the OS" into a working OS - it'd be a massive ground-breaking piece of work that surpasses anything anyone has ever achieved in that area (but forgive me if I continue to prefer to create my descriptive descriptions in a language designed for that purpose).

That's not what you're talking about though. You're either talking about implementing support for ESP, or producing the wrong results - I'm not sure which.


Cheers,

Brendan

Re: Using FPU

Posted: Tue Jul 19, 2011 3:03 pm
by DavidCooper
Hi,
Brendan wrote:Humans don't work like that. You ask 20 programmers to write an OS, and after disagreements and differences of opinion you might get 10 of them and none of them will be what you were originally thinking of.
Maybe they don't, but some could. One might take charge and lead things the way he thinks they should go in, making up for the ridiculous lack of detail in the instructions from their boss. The task is far from impossible - a guess can be made as to how many applications would do, a look at which applications are most common (and therefore most likely to be of use) will determine which ones to program, and an operating system of sufficient complexity to handle those applications can be written. The boss might or might not get what he wanted, but that's his fault for not spelling it out in detail.
To create a system (whether it contains humans or not) that converts "Hey! I want you to build me an operating system and a whole stack of applications to run on top of it." into software you want, you'd first need to implement ESP.
They/it would do the job asked of them/it. If the job as specified doesn't match up with the intended outcome which the boss has kept to himself, the fault is not with the programmers. If any questions asked of the boss generate no replies, then the boss is either a fool or he doesn't care about what he ends up with, just so long as it fits his instructions.
See if you can write a program that accurately guesses people's favourite colour - if you can't do that, then how are you going to figure out the millions of decisions that go into making up one specific OS? A system (whether it contains humans or not) would require a very descriptive description - the more descriptive that description is the more chance there is of the system producing the desired result.
How many of these millions of decisions are ever put to the boss? He relies on his programmers to make good decisions about most things and not to bother him with what to him are trivia. If his favourite colour is important in some way, he will tell them. If the programmers (or intelligent programming system) suspect(s) that the boss might want to have a say on some matter, they (or it) will ask him. If he refuses to reply, it's his fault if the wrong decisions are made. He may have no interest whatsoever which programming language you use for a start, never mind the millions of little decisions about how to name variables and whether it incs or decs a count.
So, a very descriptive description is required to get what you want;
That depends entirely on what you want - the boss may simply want an OS and stack of apps for reasons of status, imagining that his company will be taken more seriously just because it has them, even if no one ever uses them.
but there's a huge amount of work involved in creating a very descriptive description. It doesn't matter if it's a very high level description in English (e.g. maybe a book describing the OS you want), or a slightly lower level description like a large set of UML diagrams (class diagram, activity diagrams, etc) covering each aspect of the OS and how the pieces fit together, or if it's an even lower low level description like pseudo-code, or an even lower level description like C source code.

In all of these cases you'd be looking at some form of compiler that converts the description into executable file/s. I'd be very impressed if you could create a compiler that can automatically convert the very high level "a book in English that describes the OS" into a working OS - it'd be a massive ground-breaking piece of work that surpasses anything anyone has ever achieved in that area (but forgive me if I continue to prefer to create my descriptive descriptions in a language designed for that purpose).
The more detailed the description of what's required, the closer the resulting programs will be to what has been envisaged, and that's simply because the boss has made more decisions which have removed much of the room to deviate away from his vision.
That's not what you're talking about though. You're either talking about implementing support for ESP, or producing the wrong results - I'm not sure which.
I'm talking about a system that gives you what you ask for. If you go into a restaurant and just ask for food and someone gives you food you hate, whose fault is that? But if you really don't care what it is just so long as it's food, you'll probably be happy with the result (assuming it matches up to various standard expectations relating to such things as hygene, presentation, temperature, etc.).

I don't know why you feel the need to drag ESP into this - an intelligent system would no more need to read the boss's mind than a human team of programmers.

Cheers,

David

Re: Using FPU

Posted: Tue Jul 26, 2011 2:12 am
by Solar
I've got that nagging suspicion that DavidCooper never did any "professional" work in the field...
DavidCooper wrote:I'm talking about a system that gives you what you ask for. If you go into a restaurant and just ask for food and someone gives you food you hate, whose fault is that? But if you really don't care what it is just so long as it's food, you'll probably be happy with the result (assuming it matches up to various standard expectations relating to such things as hygene, presentation, temperature, etc.).
The problem is that you have a customer who initially says "I want food", but actually has very precise ideas of what he does or does not want. For example, what the customer is actually thinking of is a nice t-bone steak, well done, with cole slaw and mashed potatoes, plus a coke light, no ice please - he simply lacks the skill / experience / patience to actually put it in words. You have to find out. You have to ask. You have to put into writing, and have it signed off, to reduce the risk of you producing something that the customer will refuse paying for. You have to show your progress at regular intervals, showing screenshots, mock-ups and prototypes, to consistently ensure that you and the customer are talking about the same thing. Demonstrating the overall design, then the detailled design of the individual component. All this has to be consciously done in very precise terms, because native language tends to be horribly ambiguous.

That is what takes the real skill.

Turning a detailled design into source code is a menial task, by comparison.

Of course, usually it doesn't work this way. Usually there was some utter dork who heard "I want food!", and said "OK" and went to work writing "class Food" and went from there because OO is so cool. Then he wrote a couple thousand lines, and the customer shook his head, and he ripped it apart and rewrote parts of it, and iterated through that cycle a couple of times until the whole thing became a nightmare of broken and leaking abstractions, underdocumented spaghetti code and design legacies that cannot be overcome short of a complete rewrite.

Then they dump the whole shebang on your desk and expect you to fix it.
I don't know why you feel the need to drag ESP into this - an intelligent system would no more need to read the boss's mind than a human team of programmers.
The trick, IMHO, is to not talk about "programmers". "Programmers" are those code monkeys who get a detailled design from the Business Analysts and Software Architects and turn it into code (search "menial task" above). That might happen in a select few big companies, but the vast majority of companies employs people called "software engineers". The kind of guys with a complete range of skills, not just "Java in 21 days" on their desk.

Replacing that with "an intelligent system" is equivalent to ESP. Hell, I am expected to be capable of ESP, actually...