Train with dynamic responses using functions

[controversial]

It'd be great if you could use functions (which return strings) in trainining dialog.

Example:

import time
def whattime():
    return time.strftime("%a, %d %b %Y %H:%M:%S")

chatbot.train(["what time is it",whattime])

Chatterbot could recognize that time is a function, not a string, and then return the result of calling that function in response to the question of "what time is it". That way, I could get the real time and date back from asking what time is it.

[DarkmatterVale]

This sounds like a very good idea. I will work on implementing this in the plugin_chooser class.

[controversial]

If added in the plugin_chooser class, how would this look if used in code? Would it look like my example or different? Also, if you don't mind my asking, how long (as a rough estimate) might it take to implement? If it's longer than a week, I might attempt to modify the code myself.

[controversial]

I have a few friends and myself in a discord chat, which uses the discord API to implement chatterbot. I'm finding that having a few people regularly interacting with it through a system that is designed for easy communication is a great way to train the bot. I really love your project, very helpful.

[LucasZielke]

@DarkmatterVale This is sorta what i encouraged the inline parsing for, by that i mean

inputRes = finalResponse.split("[")
output = ()
for phrase in inputRes:
     if (phrase[(len(phrase)-1):] == "]"):
          output.append(exec(phrase[(len(phrase)-1):])
     else:
          output.append(phrase)
finalResponse = output.join()

So that when training the bot, you would set the output as (in the time case)

" The time is [import time;print time.strftime("%a, %d %b %Y %H:%M:%S")] "

[DarkmatterVale]

@LucasZielke I see what you mean. This might be kind of difficult for large plugins, however, because then the code could get very long. Maybe this could be used for shorter plugins though as a quick and easy way to get a fast response.

@The-Penultimate-Defenestrator You would have to train the bot to determine what plugin is valid given an input. Then, the bot would find the plugin with the highest confidence in its answer ( something I want to implement ) and call the respective function. That is the easiest and most general way to design the code so that it is not reliant on any specific code additions for a plugin.

Feel free to go ahead and try to write some code up! I will probably not get to it for multiple weeks ( got a lot of todos here ).

[controversial]

Ok. Can you add some doc strings into the example PluginAdapter plugin class? I understand what should_answer does, but not what process does. Does process return another string that is passed again to the response algorithm, or return the final answer?

[LucasZielke]

@The-Penultimate-Defenestrator : process seems to return the input value = and then answer, so:
one plus 3 times 5 gets normalized to
1+35 and sent into the eval() so the entire function would return
1+35= 16

@DarkmatterVale Thats why you should build plugins that require only a quick little two lines

[controversial]

thanks, @LucasZielke. I'll take a look, see what I can figure out.

[gunthercox]

I'm going to vote against the proposed implementation of this one. Something like this would be better implemented as a logic adapter as ChatterBot moves towards a muti-adapter structure in the future. As a logic adapter the setup would need to check if the input value contained a time-centric question and then return the current time as a response statement.

The reason for this design choice is to ensure greater flexibility in the future by preferring analysis over regex. A logic adapter would be modular and easily maintained, while a training method such as the one proposed leaves the database in a state in which it will always require statements to be checked for this dynamic format.

The most ideal implementation would be a logic adapter that internally trains itself based on a set of similar questions such as "What time is it?", "Do you know the time?", etc. As well as false values such as "Do you have a dog?", "Is it time to go?", etc. The adapter should then recognize when an input statement contains a valid question and return the current time accordingly. This would provide the greatest flexibility, likely accomplish language independence, and still accomplish the desired result as proposed initially.

[controversial]

I think this would be more practical if logic adapters could be more deeply embedded into chatterbot. As of right now, they have to decide independently whether they can answer a question. If the should_answer function could somehow access the logic that powers the rest of chatterbot, this would be more realistic.

[gunthercox]

If you take a look at #85, it covers the future changes to logic adapters that will make this possible. The key parts are rating confidence values and tie-breaking.

[controversial]

Great, this sounds like a really great solution.

On Thu, Dec 24, 2015 at 8:36 PM Gunther Cox notifications@github.com
wrote:

If you take a look at #85
#85, it covers the
future changes to logic adapters that will make this possible. The key
parts are rating confidence values and tie-breaking.

—
Reply to this email directly or view it on GitHub
#94 (comment)
.

[gunthercox]

@The-Penultimate-Defenestrator I am closing this off as #103 demonstrates the implementation of this feature as I described it. Feel free to checkout the code for these changes: https://github.com/gunthercox/ChatterBot/pull/103/files

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.