Scenario Function Lecture Notes


Chapter 0  Preamble


The program is the final method of implementing our intention for the design of a system onto a computer. Therefore a program is required to accurately implement the intention, and solve any logic errors that do not abide by it. However, I have always had a doubt that as long as we create programs using our current instinctive method of thinking, we will not be able to fully implement the intention onto a computer. I started my research in 1973.

The motive for this was that we should think that a program is implemented from a much deeper place than the system design.

Back then, the IPA (Information-Technology Promotion Agency, Japan) was looking for someone to develop an "Online Debugging General Purpose Simulator". The development grant was 800 million JPY. The other contestants were Toshiba, NEC, Mitsubishi and Hitachi. The proposal that was adopted was mine from CSK, the company I worked for, if you could even call it a company. What made me happy was that the underlying thought process of my program development mentioned above was extremely valued too. This is a digression, but back then the IPA workers, who did not even have establishment, had so much willingness to advance. Looking back at it, it is very different to today's society where authoritarianism runs rampant. If we recapture the discovery/proof that humans make in terms of algorithms, we can establish new subjects and relating contexts.

When we talk about subjects, we are not talking about subjects in terms of language, but the data area established by the subjects. The scenario function program's source at execution I finally arrived at establishes the universal narrative of the algorithm that establishes the context of all subjects (subject genealogy) as the solution. That was 2008. The subject genealogy was already assumed to be the answer of the scenario function, but it also embodied the aspect of synchronous algorithms. In other words, the thought process we establish is in terms of asynchronous algorithms. Incidentally, scientific discoveries, system development, and conventional programs, basically everything is established by asynchronous algorithms. On the other hand, the scenario function can embody the synchronous algorithm that humans have established first. Moreover, the mechanism of the scenario function is established by the components of the declarative body called the subject vector and by checking the correctness of the context of the subject at the third rule which is established by the declarative body that has one entrance and four exits, and is established by seven rules.



The goal of the research is centered around scenario functions, but the journey to it took around 40 years. A large part of it was a lonely late night intellectual journey. The discussion that surrounded the final solution was centered around metaphysical issues instead of engineering issues. This is difficult to do in the "good friends clubs" of the universities and large organizations' research circles. The journey was not smooth, and until the questions around scenario functions were completely resolved, the jouney had to be continued.

In this research, the actions ① to ⑤ were taken in order to verify ⑥ and ⑦.

①Analyzing about 500 programs in terms of issues caused by subject contexts throughout the 15 years of research in order to find the root of the issues surrounding the conventional type of programming.

②Creating a developmental methodology called “project composite management technique(VOCJU)” that fulfills the largest class of requirements in the process of this research.

③Analyzing 200 programs in terms of subject contexts of the VOCJU programs in order to find the problem that lies in the program.

④Conceiving the LYEE theory.

⑤Analyzing 300 programs in terms of subject contexts of the LYEE program in order to find the problem that lies with the program.

⑥Deciding the theory of subject genealogy, which is the solution of the scenario function.

⑦Deciding the theory of the scenario function.



From the preceding ①, the context of subjects in the conventional programming method became ambiguous after say, 20 - 70 subjects. The problem was that in our conventional way of thinking, logic bound thinking, as the number of subjects increased over a certain number, the program unavoidably turned into an asynchronous algorithm. I realized this in around 1985. From this view point, we can say that as long as we base our methodology in logic bound thinking, and if the invention/discovery has over a certain number of subjects, then we can say it is not fully complete, much like conventional programs. In 1992, we created a tool that analyzes the subject genealogy of programs, so we analyzed multiple programming languages using that tool. A particular characteristic that came up often was that the languages had vulnerabilities in grammatical rationality. As we progressed through the aforementioned ③、⑤, the algorithm that had a complete subject genealogy was created, and we reached ⑥。Finally, the scenario function's structure was derived from the algorithm of ⑥.

Subject genealogy is an aspect of synchronous algorithms. Furthermore, the algorithm that is established when the scenario function, which uses subject genealogy as a solution, is executed is not like the asynchronous algorithm of the conventional program, but a synchronous algorithm. In other words, the scenario function releases us from the issues surrounding logic bound thinking (called logical combination thinking hereafter). As long as any program, such as payroll programs, anti-virus programs, system control programs, simulation programs, A.I. programs, etc. is fundamentally based on logical combination thinking, it is impossible to void the problems caused by number of subjects. Scenario functions are able to fulfill the conditions needed to execute the program and solve execution issues that arise on its own through the synchronous algorithms that it establishes.

Program problems occur daily and are getting more and more serious, the reason of which is ambiguity raised by our way of thinking. Unless we find the program structure to be able to solve this problem, computers cannot be used. Although we have the solution that is the scenario function, the researchers and engineers who are in academia who claim to be specialists have not realized this.

Therefore the scenario functions are obtaining many patents which can be of use to everyone with more cooperation of patent attorneys rather than academic literatures. The scenario function was first patented in 2016, in Japan. The second patent relating to it was released in 2017. From hereinafter, there are plans to release about 20 patents surrounding this topic.



The motive behind the research which started in 1973 was to create a programming structure that would solve the programming crisis.

At that time, the following ideas existed surrounding the structure of the program. Namely,

① Proposal to limit the program size up to about 500 lines in order to maximize the program development cost efficiency (IBM Researcher).

②Programing method to structuralize the program (components) (Professor Dijkstra, USA)

③ Get rid of the GOTO command in order to avoid errors (Professor Goto, USA)

④Thesis paper on the correlation between bugs and the number of condition statements, and a bugless programming method based on its application (Japan Fujitsu).

In my research, the program is to have logic atoms as its subjects and is the being to be constructed by them. So a program only becomes a program once all of its subjects are established genealogically correctly. This is the fundamental truth about programs.

"Genealogical correctness" refers to the synchronous aspect of all subjects being established simultaneously.

Incidentally, the conventional programs that use logical combination thinking do not establish concept of genealogically correct subjects. This has been overlooked ever since the great Alan M Turing created programs. While we are in a time where programs have a plethora of problems, the only program that can solve these issues is the scenario function. It is surprising that there is no research being done to solve this issue, and the reason for it is that since the 1990s, the research for programming languages has gone down significantly while programming languages that have nothing to do with solving the programming issue are used to develop systems.

It is sad that current society does not worry about the increasing issues of viruses and the inability to conduct complete program tests while humanity is using conventional programming methods to systemize ideas such as auto-pilot, robots, and A.I.. This is the proof that in these fields of study, the level of programming is still low.

The people who are in the part of this field are apt to just explain their viewpoint regarding the issues surrounding programming, basically like an information broker, but not contributing to actually solve the issue.

Under such circumstances, the field uses the ease of use as an excuse and acts as though the programming issues do not exist. However, the advent of viruses that can easily infect today's programs and systems is the proof that the ease of use can no longer be used as an excuse. Anyway, this field is filled with experts without the philosophy to solve fundamental program problems. Furthermore, for those who researched the solution to the programming problem like I did, it was clear that the research could not be continued unless they left this rigid establishment.



The mechanism of scenario functions uses all the subjects of the executed data, and by using data combination methods, it establishes a metaphysical model of the synchronous algorithm (i.e. algorithm to investigate the origin of the subject establishment). In the process of establishing the synchronous algorithm, the cognitive process regarding data (i.e. the operation process' algorithm) is established as well. Through the metaphysical modelling of the program analysis done on conventional programs, it was revealed that the algorithms we are familiar with (asynchronous) are established and embedded into the synchronous functions. Conversely, the scenario function's mechanism shows aspects of watermark carvings.


0.6 Reasons for Patenting

I think that the thesis papers of those who can't think of program issues and the knowledge of the modern examiner do not have real substance because there is no sense of philosophy in their works. This has been especially true for the past 20 years. I believe that it is important to give those who can understand the concept of scenario functions an opportunity to use it, which is why I patented the results of my research. In this aspect, patenting is a very effective system.

I believe that those people should make various tools that are based on scenario functions. If one understands scenario functions, it's not a hard task for younger people rather than for me who is old to make the tools. It makes more sense for the younger people to do it.

Incidentally, these tools will be used by the system engineers and administrators. Suppose that you completely understand the workings of the conventional programs. As far as you use that knowledge to hold conjectures on scenario functions, there will be many errors in your views because the conjectures will not hold for scenario functions even though they may hold for the conventional programs. You cannot understand synchronous algorithms using the knowledge of asynchronous algorithms. I recommend for you to take the 60 hours of lectures that LYEE provides.


Chapter 1: Themes of the Research >