-
Notifications
You must be signed in to change notification settings - Fork 5
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
Correcting AS-MOSES outputs:Approach Suggestion #115
Comments
Thanks @Eman22S, that's very useful info. Have you tried to enable If you use diff, you can remove timestamps prior to that, with https://github.com/singnet/cogutil/blob/master/scripts/util/rm-timestamps.sh |
@ngeiswei, that sounds plausible. How do I use that when running |
For log level just use |
@Eman22S, @ngeiswei I think the problems we are facing right now with as-moses rise from same root. The data population is not working properly, specifically the population from input table. The first problem is the I recommend two things |
Overview
This is to address the issue raised in the report Optimizing as-moses: Reports #109. To summarize,
asmoses
is currently not working as required comparing its prediction of programs tomoses
's. When the problem is passed as a dataset of contin only or boolean only values, however small it might be, it fails to come up with the correct program prediction. The slow down discussed in the report is also very likely to be related to this, as running demo problems with and withoutatomspace-port=1
do not create a significant slow down as much as when the dataset is passed.Observation
My observation on the behavior of
asmoses
is as follows:Running a demo problem using
![no-discrepency](https://user-images.githubusercontent.com/18707775/70506449-5fa6aa80-1b3b-11ea-886f-e5bc234435f9.png)
atomspace port =1
produces the correct output and no discrepancy created betweenmoses
andasmoses
Running the same problem which is disjunction using a csv dataset however creates incorrect results
![dataset-or-weired](https://user-images.githubusercontent.com/18707775/70507346-31c26580-1b3d-11ea-849a-5b0f0abe3f21.png)
dataset-test2.csv
contains :The following is the result of solving a conjunction problem using a csv dataset:
![dataset-and-weired result](https://user-images.githubusercontent.com/18707775/70506950-77caf980-1b3c-11ea-8171-f6d58c258a47.png)
dataset-test1.csv
contains:Suggestions
Looking at these outputs we might conclude that somewhere in the workflow of
asmoses -i dataset.csv
, a logic error is created in writing these codes. The same argument cannot be made for demo problems,however, as they are working as expected.I have tried to look into some of these codes and got few speculations. Ctable population is one of which I have doubt on:
So the dataset is compressed and each of its features is populated into its atomspace in a condensed non-redundant structure. For instance, if we have a two column with 9 rows it condenses to say 2 or 3 rows and gets populated into the atomspace. The target column however is not populated in a way where the compression structure is kept for
atomese
to understand. what I am saying is, we don't have a compressed table representation foratomses
and that might be what's creating all that Compressed Table Representation #19. Henceasmoses
is not quite understanding thectable
is actable
when populating it but turning it into a dataset it likes.Conclusion
I would like to hear your thoughts @ngeiswei @kasimebrahim on the above and what testing strategy I should follow. My initial testing approach is black box testing of each module in the workflow of
asmoses
. But I am quite sure, given the above problem description, there is a systematic way of coming across it.The text was updated successfully, but these errors were encountered: