TheCurle/guinevere-parse
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Add the main file, with the majority of the documentation.

Browse Source
This commit is contained in:
Curle 2019-10-15 20:18:12 +01:00
parent 3f609fd255
commit f01e087e27
1 changed files with 108 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

108
main.cpp Normal file
View File

@ -0,0 +1,108 @@
#include <iostream>
#include <string>
using namespace std;
/* Team Kitty, 2019 */
/* Guinevere One */
/* This package is the parsing system (NLP) for the Guinevere system.
This package is split up into 5 different parts, each controlled by
modules. This is the file that controls all of the other modules,
making sure that the system reacts the way it was configured.
It should be mentioned here, before we start, that this system does
not use advanced Machine Learning systems, or anything automagical.
It runs entirely on predetermined algorithms, which are fully
designed manually, so the system is not infallible.
The system can be configured to run in 3 different ways;
- As a console application, where it uses stdio to communicate with
the user, parsing internally. This is ideal for command-line usage,
and was designed purely for testing the system. This is not the
intended usage.
- As a web server. In this configuration, it starts a web server on a
configurable port and listens for incoming connections. This is the
intended usage of the Guinevere parsing system, as it can then send
out commands to other devices.
- As a web client. In this configuration it listens for input over
stdin and sends it out to the listen server. This makes developing
the main clients considerably faster.
Maybe implement this into the Guinevere main clients eventually?
Currently, the program has 5 sections, as mentioned above:
- Input; this is where the 3 modes mentioned above are implemented
- Parsing; this is only done if the console app configuration is
chosen above. Otherwise, it skips this module.
- Evaluation; this is only done in debug mode, in console app
configuration. It tries to prepare an output that tells the user how
likely it was to pick each module for the given input.
- Knowledge; if the output was strange, and if "Define" was the most
likely module in Evaluation, it can save time by enabling the
Knowledge system to attempt to get a definition of the "Define"
keyword from Wolfram|Alpha. Since this cuts down the rate of network
access by half, it might improve data usage.
- Output; finally, once all of the sections have yielded, it tries
to output the requested data in a decent format. If the system is
running as a console app, it outputs to STDOUT. If the system is
running as a web server, it sends a nicely formatted JSON
encoded package to the connected client, or displays said package if
running as the client.
The Parsing and Knowledge systems connect to various Modules:
- Identify: Triggered by "What is", "Who is" and "How do I" questions.
It tries to pull a short definition from WikiTL;DR, or redirects to
the most appropriate Wiki page if that fails. If the user complains,
saying "That wasn't useful", or "Try again", it tries to reach out
to Plowie or W|A to get an answer there. If Identify doesn't work,
it falls through to the next appropriate module.
This is the module expected to be used the most, so it will have
the most time put into it.
- Control: Triggered by "Set", "Play" or other commands that are
deemed to be likely to control or change the state of something.
The Guinevere system was originally designed to be used with
custom Smart Home electronics and systems, so this will probably
be the second most developed system. It will have subsystems for
changing the color and intensity of smart lighting, as well as
systems for controlling custom Smart Locks eventually.
This will not be forseeable for quite a while, though.
- System Control: A subsystem of Control, but important enough to
require an explanation nonetheless. If Guinevere is eventually
integrated within Sync, this module will allow voice control of many
internal components of the system. With a builtin passcode, it can
also be used to control kernel level things, like multitasking
methods and paging control systems. In user-land, it can also be
used for dictation input (if you trust my algorithms enough)
or for changing user settings, such as keyboard layout, hotkey
behaviour, or window manager/compositor settings.
Perhaps this interface could eventually be used as an
optional replacement for configuration files?
- Define: The fallthrough. If the user says a random word, which is
not identified as a custom keyword, then the system will ping W|A to
get a nicely formatted definition of that word.
*/
// First is the definition of the common types:
/* There are three main classes used in the processing of requests:
- First, there is the input. The input is returned by the input
detection system, and is used in Processing for determining the
Intent.
- Second, there is the Intent itself. The Intent is a construction
of how likely the input command is to belong to a module. Since
the Intent algorithm is an algorithm and not a Machine Learning/
Neural Network thing, it can be easily changed and tweaked to match
the correct criteria. Out of the Processing system, the intent is
used to trigger the correct module and the Intent is then discarded.
- The output is a structure which is given from Processing to Output,
and is used to generate a nicely formatted output. The output itself
is sent around inside the program as a JSON/XML string. I have yet
to decide.
*/
int main() {
return 0;
}