Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A gama pong is created and connected to the event buffer. #102

Open
wants to merge 1 commit into
base: dev
Choose a base branch
from

Conversation

MoonWalker1997
Copy link
Collaborator

No description provided.

@MoonWalker1997 MoonWalker1997 self-assigned this Mar 14, 2024
@ccrock4t ccrock4t linked an issue Mar 14, 2024 that may be closed by this pull request
@bowen-xu bowen-xu added the enhancement New feature or request label Mar 14, 2024
@bowen-xu
Copy link
Collaborator

This pr is related to issue #12.

Copy link
Collaborator

@ccrock4t ccrock4t left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! There are only a few edits needed:

return task.is_event \
and task.term.type == TermType.STATEMENT \
return (task.is_event or task.is_operation) \
and (task.term.type == TermType.STATEMENT or task.term.type == TermType.ATOM) \
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree it is correct to let Operations in the Buffer. But, not the Atomic terms, since Atomic terms cannot be events.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But if there is an operation, say "^left", how to build relations between it and other events. I think in the design, this is achieved in the internal buffer, though currently we don't have it. Probably we can allow a special data structure containing only operations, running parallel with the event buffer, to create schemas like "event, operation / event".

Copy link
Collaborator

@ccrock4t ccrock4t Mar 15, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The term left is Atomic, though it is actually the name of the "Operator", not the Operation itself.
(The NAL book refers to this term as the "Operator" (p.146))

The Operation itself, ^left, is shorthand for a first-order Event that uses Product and SELF term together with the "Operator" relating them, for example:

^left $\Leftrightarrow \langle (*, self) \rightarrow left \rangle$


How it works is, when NARS executes Operation "^left", it returns a "motor copy", allowing NARS to directly observe the Event, $\langle(*, self) \rightarrow left\rangle. :|:$

If this Event comes through the Narsese channel, in our current design, it should automatically flow into the EventBuffer and form the temporal inductions.
Thus we will get statements like (A &/ ^left $\Rightarrow$ C) just from observing the motor copy

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a side note. I always found it a little weird that (*,self) is a valid syntax on OpenNARS. Products should have two or more components and in this case it always felt like a hack to me.

Copy link
Collaborator

@ccrock4t ccrock4t Mar 15, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You will have to take that one up with Professor. I do not have a strong opinion on the theory, but in the code I think we should stick to how the book defines it, unless we can find a better alternative


task_from_EB = event_buffer.generate_temporal_sentences()
if len(task_from_EB) != 0:
nars.input_narsese(str(task_from_EB[0]))
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No need to use EventBuffer in this file, there is already one in the Reasoner, which is executed at every working cycle.

All that is necessary for the Pong game is to input the Sensory Events into the Narsese Channel. The NARS should automatically process them with EventBuffer and put the results into the Overall Experience Buffer.

Copy link
Collaborator

@ccrock4t ccrock4t Mar 15, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The flow is like this currently:

image

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, that sounds nice. To confirm, we just need to put all sensory events to the Narsese channel. Do you know the API of inputting in the Narsese channel?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The nars.input_narsese(string "") should work

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Feature] Demos on Pong Game
4 participants