robot detecting algorithms ?
-
Nah, a computer can only determine the instructions available; not the intent. If you see me add stuff to a list, how would you determine whether it is a list that represents a high-score, or a list of all email-addresses on your machine? A robot is a computer; and most applications run inside a virtual machine nowadays.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
You're insisting you know, of course a computer can :) did you heard about Artificial Intelligence, Deep Learning ... We should just find the way even if it is difficult
Isawyouoo wrote:
We should just find the way even if it is difficult
Why? Google's AI cannot differentiate between Turkey (the bird) and Turkey (the country). How is it supposed to infer intention from a set of instructions? And what benefit would that bring? None actually.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
Hi! I'm thinking months of a bot(algorithm) that can detect algorithms(written in assembly or any language) and say what they are talking about. int factorial(int number){ int fact=1; for(int i=1;i<=number;i++){ fact*=i; } return fact; } the robot will read this(analyze it) and say to me that this is an algorithm that calculate factorial, it's a function that return an integer, what...(maybe he should execute it virtually, track registers, vars...) our technology is slow in development, we just invented computers, no robots yet :(
-
Isawyouoo wrote:
actually it's possible
No it isn't. I can only suppose you are using the formal definition of an algorithm, like the one in your original post ("this is an algorithm that calculate factorial,") In the vast universe of programming the cases of actual implementation of those methods represents such a small fraction of the total code base to be effectively zero. I would not be surprised if the percentage is even smaller than what it represented by winning the grand prize in a national lottery. In contrast then are a vast, vast number of "algorithms" in the general sense that do not have a formal definition. They solve business, research and even educational problems but one cannot 'define' them because they are unique. As an example following is some code that I just copied from my computer. What is the actual text that you expect your program to report for the "algorithm" for this?
public static void test(Object s)
{
Date daysAgo = Date.from(Instant.now().plus(-30L, ChronoUnit.DAYS));
System.out.println("Days ago=" + daysAgo);
} -
Isawyouoo wrote:
actually it's possible
No it isn't. I can only suppose you are using the formal definition of an algorithm, like the one in your original post ("this is an algorithm that calculate factorial,") In the vast universe of programming the cases of actual implementation of those methods represents such a small fraction of the total code base to be effectively zero. I would not be surprised if the percentage is even smaller than what it represented by winning the grand prize in a national lottery. In contrast then are a vast, vast number of "algorithms" in the general sense that do not have a formal definition. They solve business, research and even educational problems but one cannot 'define' them because they are unique. As an example following is some code that I just copied from my computer. What is the actual text that you expect your program to report for the "algorithm" for this?
public static void test(Object s)
{
Date daysAgo = Date.from(Instant.now().plus(-30L, ChronoUnit.DAYS));
System.out.println("Days ago=" + daysAgo);
}you said : but one cannot 'define' them because they are unique. if they are unique, sure they can be defined due to their unicity. the algorithm above, will be more understandable if it was in assembly or MSIL code, since it's very easy to examine each instruction and conclude the main idea and the objectif of the algorithm. As I say always, it's possible to figure what algorithms do, since every composition of instructions is unique.
-
you said : but one cannot 'define' them because they are unique. if they are unique, sure they can be defined due to their unicity. the algorithm above, will be more understandable if it was in assembly or MSIL code, since it's very easy to examine each instruction and conclude the main idea and the objectif of the algorithm. As I say always, it's possible to figure what algorithms do, since every composition of instructions is unique.
So what would be your desired output for the analysis of that code?
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
-
you said : but one cannot 'define' them because they are unique. if they are unique, sure they can be defined due to their unicity. the algorithm above, will be more understandable if it was in assembly or MSIL code, since it's very easy to examine each instruction and conclude the main idea and the objectif of the algorithm. As I say always, it's possible to figure what algorithms do, since every composition of instructions is unique.
Isawyouoo wrote:
if they are unique, sure they can be defined due to their unicity.
That isn't the problem. How are YOU going to define all such algorithms so that your proposed solution can output some 'definition' of it. Your factorial one is easy. It exists. Computer science and math defines it so if your solution finds it it can write out "factorial" but others have no such definition.
Isawyouoo wrote:
As I say always,
As my previous post said and the other poster noted as well what exactly is your program going to put out for the code that I posted?
-
Hi! I'm thinking months of a bot(algorithm) that can detect algorithms(written in assembly or any language) and say what they are talking about. int factorial(int number){ int fact=1; for(int i=1;i<=number;i++){ fact*=i; } return fact; } the robot will read this(analyze it) and say to me that this is an algorithm that calculate factorial, it's a function that return an integer, what...(maybe he should execute it virtually, track registers, vars...) our technology is slow in development, we just invented computers, no robots yet :(
-
you said : but one cannot 'define' them because they are unique. if they are unique, sure they can be defined due to their unicity. the algorithm above, will be more understandable if it was in assembly or MSIL code, since it's very easy to examine each instruction and conclude the main idea and the objectif of the algorithm. As I say always, it's possible to figure what algorithms do, since every composition of instructions is unique.
Isawyouoo wrote:
if they are unique, sure they can be defined due to their unicity.
You're absolutely right, of course they can be defined and identified. But the identifier can add no meaning and will probably look something like
87fad930-be8c-928a-0384feead334If that's what you want, then fine. You're asking for AI that can look at "any" algorithm and, from the universe of possible "things to do", extract a meaningful name / description. (e.g. find factorials; compute best route between 3 points; find a perfect love match). To do that the AI has to have "Knowledge" of the entire universe and the language used to describe that universe. At this point - and for the foreseeable future - no AI system is that widely knowledgeable. You could build a system that operates on algorithms in a very well-defined sector (e.g. fluid mechanics, perhaps) such that the system could "learn" to categorise code that implements one of a set of predefined algorithms. BTW, you can also - without the need for any AI at all - build a rule-based parser that uses English-like language to say "this is a routine that takes a string and an integer and uses them to return a string and a boolean". Depending on the algorithm you might even be able to further indicate that it determines whether the first [n] characters of input [string] contains a make of car (provided you give your tool a list of every maker of cars).Isawyouoo wrote:
it's very easy to examine each instruction and conclude the main idea
Sorry, but to put it bluntly, that's rubbish. A high-level language is (almost by definition) easier to extract "ideas" from. At a low level, trying to determine the importance of outcomes is virtually impossible. Loading a number into a register could be because you need that number in the register to do other things with outside of the algorithm itself, or it might be the primary objective of the algorithm. You can have no idea of the intent of the code when examining it at that level, partly because at that level the code is not divided up into clear enough structures to even know the boundaries of the algorithm, and partly because the sheer number of instructions at low level will complicate the task by several magnitudes. As an aside: many, many years ago I had the joy of maintaining a suite of COBOL programmes. The original coder had delighted in the following valid code: