Re: [opencog-dev] Re: Message to Any Future AI

2017-12-04 Thread Mark Nuzz
On Mon, Dec 4, 2017 at 5:18 PM, supahacka  wrote:
> p.s.: here are some contemporary bestselling books on the subject (Tolle
> sold like what ... 100 million copies?) ... lets burn all copies before AGI
> gets a chance to read them so we can pretend that AI will evolve in a
> sandbox void of any relevant information. Let's also delete all historical
> references to Christian Mysticism, Sufism, Hinduism, Buddhism, Daoism, etc.
> ... so our AGI system might actually adopt our primitive belief systems ...
> including that "domination" makes any sense when there is only one of us -
> one process, one consciousness, one life, one love - out there and
> separation a psychological illusion.
>
> https://www.amazon.com/Power-Now-Guide-Spiritual-Enlightenment/dp/1577314808
> https://www.amazon.com/Book-Taboo-Against-Knowing-Who/dp/0679723005
> https://www.amazon.com/Untethered-Soul-Journey-Beyond-Yourself/dp/1572245379


Since you made two posts about this, I'll assume that this was not
intended to be tongue in cheek. If this sort of thing matters to you,
then you might be interested to know that there is a subculture of
Transhumanism where many of these things are explicitly and
deliberately taken into account (although it is not required of
members, and the Mythos can have a different meaning for anyone
involved).

The group is pretty hardcore, but you must merely be regularly active
and abide by the principles to be a member. Popping in once a month to
complain about something that you didn't actually take the time to
read about, is a good way to be ridiculed or shown the door.

But if you're serious about this stuff, and feel the loneliness of it,
perhaps you'll find a home there. Note to any readers out there: That
is not *all* the group is about. The main purpose is to help guide
civilization through the volatile transition to the Singularity, and
associated existential risks. This is but one "small" part of it, and
members are entirely free to disregard it. This is the only group that
I know of, which attempts to empower Transhumanists, AGI devs, and
Futurists, to work toward those goals together. And existing
organizations are free to join the network, if they can pledge to
actively support the principles of Social Futurism.

Are you in?

http://www.zerostate.net
http://socialfuturist.party/
http://gestalta.xyz/2017/11/07/what-is-the-zero-state/
My personal manifesto:
http://gestalta.xyz/2017/11/24/a-manifesto-in-support-of-social-futurism/

25

-- 
You received this message because you are subscribed to the Google Groups 
"opencog" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to opencog+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@googlegroups.com.
Visit this group at https://groups.google.com/group/opencog.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/opencog/CAMyYmr_0z1wYiyg91Gi6_jWJ6FqWG--NXsOtxvbLVXiO1yH68A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [opencog-dev] Openness of knowledge-base of Hanson robotics

2017-10-31 Thread Mark Nuzz
On Mon, Oct 30, 2017 at 9:01 PM, Nil Geisweiller
<ngeis...@googlemail.com> wrote:
> On 10/31/2017 02:52 AM, Mark Nuzz wrote:
>>
>> I am involved - I have taken time to respond to questions by a number
>> of new posters to the group, to the best of my ability, in good faith.
>
>
> That is greatly appreciated.
>
>> You've expressed, a few posts back, clear frustration with the fact
>> that people have close to zero interest in knowledge-bases. That
>> doesn't make much sense to me, and the way you put it, shows that it
>> is worth checking into. Knowledge bases, being a key component of any
>> AGI system, are pretty damned mandatory if you want to experiment with
>> an AI system that isn't a blank slate. So when you express an
>
>
> Yes, just note that OpenCog's primary goal isn't to provide pre-built KBs,
> other projects do that like SUMO for instance http://www.adampease.org/OP/.
> OpenCog's primary goal is to provide the tools that can build such KBs from
> textual, sensory or whatever data. That said pre-built KBs can be very
> useful, fortunately it's usually not too much work to import them to
> atomese. Here's for instance a SUMO importer
>
> https://github.com/opencog/external-tools/tree/master/SUMO_importer
>
> and an example using it
>
> https://github.com/opencog/opencog/tree/master/examples/pln/sumo
>
> Nil
>

Thanks for the responses. This helps my understanding a lot. I wish I
could devote more time to this project, Linas did have a point in a
sense that it is hard to contribute casually.

-- 
You received this message because you are subscribed to the Google Groups 
"opencog" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to opencog+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@googlegroups.com.
Visit this group at https://groups.google.com/group/opencog.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/opencog/CAMyYmr9QTxGcF0XNKhRuXp5TKfP80-1L890DrOmJFfV%3D%2B2gvog%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [opencog-dev] Openness of knowledge-base of Hanson robotics

2017-10-30 Thread Mark Nuzz
On Mon, Oct 30, 2017 at 4:36 PM, Linas Vepstas  wrote:
> Hi Mark,
>
>
> The answer is "yes", but perhaps not the way you are expecting it. Its not
> like we have some defined format for "semantic triples" or whatever. There
> are a large number of rich data representation styles that have been used in
> a variety of projects. The commonalities in all of these are expressed as
> "atomese".  That is, the standard protocol is "atomese".

That's exactly the type of thing I had in mind, actually (hence
serialization). Have you validated your assumption that the lack of
interest in the downloading of knowledge-bases is due to "nearly-zero
interest in knowledgebases", as you claim? Or is it possible that the
atomese json files are not providing enough expected utility? What can
one do with those files, currently? Can I simply drop them into a data
directory and have them be automatically consumed by OpenCog, or is
there a difficult process to get them to work? Is atomspace able to
deduplicate imported atoms that are conceptually equivalent to atoms
already in the database, but not exactly equal?

-- 
You received this message because you are subscribed to the Google Groups 
"opencog" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to opencog+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@googlegroups.com.
Visit this group at https://groups.google.com/group/opencog.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/opencog/CAMyYmr_5hc0KXH03fmcFina5hur76M2t2K1xmUV4e%2BsFO%3DsSMg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [opencog-dev] Openness of knowledge-base of Hanson robotics

2017-10-30 Thread Mark Nuzz
On Mon, Oct 30, 2017 at 12:31 PM, Linas Vepstas  wrote:
> Hi Ivan,
>
> Let me top-post answers to your questions. First, one needs to clarify:
> "what is a knowledgebase?"  There are multiple components that can be called
> "a knowledgebase", and they are all quite very different.
>

Hi Linas,

Does OpenCog define or use a standard protocol for serialization of a
knowledge base? Is there a schema or format? Is there a means to
deduplicate knowledge imported through these scripts? It sounds like
this is not the case but I'd love to check out any Wiki pages that
describe the state of this feature in OpenCog, as well as a roadmap.
Do you have any suggestions for pages to lookup to find more about it?
Thanks much.

Mark

-- 
You received this message because you are subscribed to the Google Groups 
"opencog" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to opencog+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@googlegroups.com.
Visit this group at https://groups.google.com/group/opencog.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/opencog/CAMyYmr8sz-ZMjsRWOiGLAoeh-D%2BWcAyEgyyoFhNAP%3DX0aJniWw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [opencog-dev] Contributing to Opencog

2017-10-06 Thread Mark Nuzz
On Fri, Oct 6, 2017 at 1:37 AM, Ben Goertzel  wrote:
> ***
> OTOH, If modules or projects were usable in isolation, and the
> dependencies could be effectively treated as black boxes (as most
> software dependencies are), or even simulated/mocked, and if
> meaningful experimentation and feedback still able to be done within
> the narrow scope of that one module, then maybe the tutorials won't be
> so pointless.
> ***
>
> yes, I agree that narrow AI is easier than proto-AGI ... and that if
> we put more effort into wrapping up OpenCog components so they could
> be used as pure narrow-AI component in themselves, or for specific
> narrow applications, then this would attract more developers toward
> these narrow-AI applications and tools... and work on these narrow
> applications and tools would indirectly benefit the quest for
> OpenCog-based AGI...
>
> Nevertheless I feel that the bottleneck is not currently wisdom about
> "what would be nice to do" or "what should be done" but rather the
> lack of any resources earmarked for making these types of
> improvements   It's not like OpenCog Foundation has a large staff
> and budget that is being frittered away on other stuff...   Nearly all
> current OpenCog dev is happening because of commercial projects
> wanting to use OpenCog bits and pieces and aspects for various
> specific purposes, and this sort of funded dev is great but doesn't
> tend to lead to work focused on making the infrastructure easy for
> newbies...
>
> Tensorflow has wonderful documentation, beautiful visualization,
> elegant modularization, etc.  It's lovely for what it is.  How much do
> you think Google spent on these aspects?
>
> ben
>

Perhaps this is close to where the real disagreement is. On one hand,
the project is striving for modularity in the form of separate
compilation of modules and components. On the other hand, the idea of
having them as architecturally separate components elicits a belief
that it will be treated as narrow AI, and I know how you (rightfully)
feel about narrow AI. There is probably truth in both of our
arguments, but the difference is that I feel that the architecture I
advocate will lead to AGI much faster than otherwise. And I don't
think that this will necessarily shift the focus to the domain of
narrow AI. Rather, it will still be AGI development, but with the
variability in statefulness being greatly reduced, to the point where
a developer will not have to spend time studying the other moving
parts just to get to the point where they can feel comfortable working
on a specific component. This does not necessarily make it narrow AI
by default.

I also believe that it's easier to get resources earmarked for
improvements, when a more effective pitch is made for those
improvements. If there's no wisdom about what should be done, then
there's no proposal/plan that makes sense. And if there's no proposal,
there's no effective pitch. No effective pitch means no money. When
you say that the bottleneck is not A, but rather B; but I say that A
is a crucial step to remedy B, then perhaps this could be an idea for
some determined volunteers to try pursuing. It may not be something
easy or possible for the core crew to do, given the tied up resources,
but it might be possible for a small number of volunteers to
accomplish, given enough motivation.

Most of the money that gets spent by companies like Google on those
top notch architectural aspects, goes toward the leap from being in
the top 10%, to the top 1% of capabilities, or from the top 2% to the
top 0.1%. Talent acquisition involves a bidding war with other
companies, and the economics of it obviously aren't directly
applicable to libre projects... As you might know, Norvig's team
applies narrow AI techniques to the data around hiring and talent
markets, all in the pursuit of having the best talent is concentrated
in that one company. There are plenty of examples of freeware and
libre software with zero budgets, that have elegant architectures.
Inventing them for the first time may be costly, but re-using
paradigms that are already battle-tested and proven, is not
necessarily costly. The catch here is that most programmers don't know
how to do this, as it's not a domain that exists on most projects.
However, it is a domain that I have a personal interest in, so I would
like to help out if anyone else is able to participate...

I think that it would be a better idea at this point if Ivan and I
(and whomever else is interested) could come up with a more specific
proposal on an architectural design based on this discussion, while
also addressing all of your concerns brought up here. I can't promise
we would be successful (you know me well enough to know how terrible I
am at following through with ideas), but I think a more detailed
proposal would be more productive than debating on a mailing list.
Since a lot of the modularization is already there, as you mentioned,
it might not be too much 

Re: [opencog-dev] Contributing to Opencog

2017-10-05 Thread Mark Nuzz
On Thu, Oct 5, 2017 at 4:22 PM, Linas Vepstas  wrote:
> People seem not to read the tutorials... maybe because they don't see the
> point of doing so?
>

Do you think my theory is plausible? Tutorials on a large system must
be greater in scope, and are therefore more likely to be skimmed
(which leads to a failure in comprehension).

OTOH, If modules or projects were usable in isolation, and the
dependencies could be effectively treated as black boxes (as most
software dependencies are), or even simulated/mocked, and if
meaningful experimentation and feedback still able to be done within
the narrow scope of that one module, then maybe the tutorials won't be
so pointless.

-- 
You received this message because you are subscribed to the Google Groups 
"opencog" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to opencog+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@googlegroups.com.
Visit this group at https://groups.google.com/group/opencog.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/opencog/CAMyYmr_W%3D%2Bfrxge4iEHhroZq7N2zFjBRU0AnNZsu%3D0F%2B%3Dvcuog%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [opencog-dev] Contributing to Opencog

2017-10-05 Thread Mark Nuzz
On Thu, Oct 5, 2017 at 2:13 AM, Ben Goertzel  wrote:

> I regret that OpenCog remains so hard to approach.  In large part it
> has evolved this way because the vast bulk of funding that has gone
> into OpenCog has been oriented toward paying a small group of people
> to work, in a hurry, on making OpenCog do something specific   We
> have not yet had a big chunk of funding dedicated to making it easy to
> use as a platform.  Hopefully that will change soon.

This seems to be a very common theme with projects, especially with
limited resources. Though OpenCog is unique in the sense that it has
survived for so long with so many contributors, so the scale/extent at
which this happened is somewhat larger and therefore require greater
effort and coordination to really solve.

I'm curious about a few things...

1) I know you implied this but I wanted to make sure: Do you see the
goal of an easy-to-use opencog architecture as a high priority item?

2) Do you think that the specific architecture direction
(modularization) presented by Ivan is generally the way that this
should be solved?

3) Has there been any concrete work in mapping out a specific
architectural direction to fulfill the goal of making opencog easy to
use?

4) Are these decisions that have already been formally agreed upon by
the governance of the project? Are there any dissenters among the core
developers, to the extent that it might interfere with such plans if
executed?


I am not quite aware of all the details but I have been trying to keep
up with all of the discussions lately in this group. Please forgive me
if I am being too pedantic... My impressions are that funding would be
easier to come by after these items are figured out in great detail
and then incorporated as part of a proposal. Such a proposal could
attract enough of the right unpaid volunteers too, as you know.


But yeah, I am not claiming by any means to know even remotely close
to what Ben knows on this subject. But from my vantage point, I am of
the opinion that the monolithic architecture is what's slowing
progress, and not the lack of funding. Suppose you get the funds and
then you hire the wrong people, then you're even worse off than before
because you probably wouldn't get another shot at funding for awhile.
If it were up to me I would have at least one existing core developer
be involved with this effort full-time, preferably whomever has the
most knowledge in modular software architectures.

-- 
You received this message because you are subscribed to the Google Groups 
"opencog" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to opencog+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@googlegroups.com.
Visit this group at https://groups.google.com/group/opencog.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/opencog/CAMyYmr-T4gevcMh_2mYHko-YwuRcCK6dyBfGZVwYT%2BuizjH6PQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [opencog-dev] Contributing to Opencog

2017-10-03 Thread Mark Nuzz
Ivan,

This is essentially the vision I have for the project too. I wish I could
say that it could be done by a determined volunteer, but the logistics are
very difficult for pulling this off. It would require multiple experienced
and skilled engineers working full-time, possibly paid. That isn't going to
happen by itself.

Maybe there is a realistic path to making it happen. Let's talk in more
detail later since I'm interested too, but I can't promise any commitment
as its tough these days for me to put in the hours in addition to what
keeps my bills paid...

On Oct 2, 2017 9:50 PM, "Ivan Vodišek"  wrote:

> > But Ivan, no one forks opencog; almost all extensions are placed back
> into the core code base.
>
> I'm aware of that. If someone forks the entire project, it would have been
> called some other name. I was referring to an imaginary system where the
> whole project would be a set of modules that work together, connected by
> well known set of interfaces. Each module could be modified or* forked
> out* in parallel with the original. It would be up to a user, which
> sub-forks she/he would choose to use to run the project, or to base her/his
> contribution on. Probably there would be a need for combination
> maintainers, something like persons that would choose different flavors of
> the project, and would propose their "deejay-combo" to the public,
> optimized for this or that use. Sub-fork combinations of low quality would
> be avoided, while really useful ones would live on. Just a bit of
> brainstorming in a direction of decentralization. The goal is to have
> industry-strength project abilities with liberal multi-user maintaining
> policy. It is on my long-term to-do list, but I could share my thoughts
> with someone who wants to implement it sooner.
>
> Thank you all for your patience :)
>
>
> 2017-10-03 4:33 GMT+02:00 Linas Vepstas :
>
>> Hi Anastasios,
>>
>> Yes. But first: complaining that opencog is written in C++ is like
>> complaining about the fact that the linux kernel on your cellphone is
>> written in C. Who cares? It does not affect 99.% of all cellphone users
>> because they do not write kernel device drivers.
>>
>> Think of the atomspace as being like an OS kernel.  You probably should
>> not be writing new C++ extensions it.  Instead, you should be writing apps
>> for it.  The apps are where the action is.
>>
>> So far, we've offered maybe half-a-dozen app APIs for it, with varying
>> degrees of success.
>>
>> Having an instance on the cloud would be great, where people could spin
>> up an instance, and log into it. I've long long wanted to do this; hell, I
>> could just throw an old PC onto my internet connection. I don't have time
>> to mess with this.
>>
>> For cloud-cog, the only thing available would be the app API's, and maybe
>> that would make the bitching about C++ stop...
>>
>> --linas
>>
>> On Mon, Oct 2, 2017 at 6:47 AM, Anastasios Tsiolakidis <
>> hellene...@gmail.com> wrote:
>>
>>> Well isn't OpenCog having a busy weekend :) As a lurker I have already
>>> expressed my dissatisfaction at "advanced C++" which is the trend in the
>>> project, and would probably carry over my disapproval of "idiomatic C#".
>>> There is absolutely no reason for the coding to be more difficult to
>>> comprehend that OpenCog's design itself. If anything, the code should make
>>> plain and simple what the bloody design is trying to do! Now, my particular
>>> wet dream would be to see people pulling together their own "free
>>> resources", like the free tiers at AWS, Google Cloud etc, to create a
>>> hive-mind. If somebody was brilliant enough to throw away big chunks of the
>>> code and instead achieve (some of) the same results with a DB of sorts, AWS
>>> lambda etc, that would be quite something. Then, for the parts that don't
>>> fit the "cloud" box, if someone could come up with the "CloudCog", some
>>> probabilistic graph, inference engine or whatever is missing from the
>>> garden variety PAAS and SAAS, then we could really be heading somewhere. I
>>> don't know much about the project beyond the demos, but I do believe the
>>> project is being hurt by the general unavailability of a constantly running
>>> instance that "does something", whatever that maybe, and somehow can be
>>> accessed by the public, eg through an API. Presumably this new hedge fund
>>> thing may be the closest OpenCog has come to being a 24/7 system, and Ben
>>> will probably tells us if he finds out a better way to do things with and
>>> without this codebase
>>>
>>> AT
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "opencog" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to opencog+unsubscr...@googlegroups.com.
>>> To post to this group, send email to opencog@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/opencog.
>>> To view this discussion on 

Re: [opencog-dev] Contributing to Opencog

2017-10-01 Thread Mark Nuzz
On Oct 1, 2017 3:47 PM, "Anastasios Tsiolakidis" 
wrote:
>
> Well isn't OpenCog having a busy weekend :) As a lurker I have already
expressed my dissatisfaction at "advanced C++" which is the trend in the
project, and would probably carry over my disapproval of "idiomatic C#".
There is absolutely no reason for the coding to be more difficult to
comprehend that OpenCog's design itself. If anything, the code should make
plain and simple what the bloody design is trying to do!

But it's not a matter of what the actual code looks like! The tooling, the
compilation times, libraries, and so on, all require a higher level of
expertise on the C++ side. Even though Linus knows that understanding it is
not needed, the fact is that based on the above fact, C++ is by and large a
language for experts and to a lesser extent academics. So if you want
non-academic, non-experts (which is the vast majority of the FOSS
community) then I recommend polishing the build scripts as needed, fixing
all reported issues with the build  (if someone has to POST here because of
a build problem, then it's likely a defect). Then make sure the newbie
tutorials exist, are easy to find, updated, and that they steer people far
the hell away from the C++ code :)

-- 
You received this message because you are subscribed to the Google Groups 
"opencog" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to opencog+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@googlegroups.com.
Visit this group at https://groups.google.com/group/opencog.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/opencog/CAMyYmr9cwgBVZ47u%2BGH6uY0-zh8TNOTnUfusF2ADGYP4W6TxzA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [opencog-dev] Contributing to Opencog

2017-10-01 Thread Mark Nuzz
On Sun, Oct 1, 2017 at 11:53 AM, Ivan Vodišek  wrote:
> And is there a way to extract a documentation of the project in a way
> Javadoc works? That option would be of great help if it would be used.


Try building with "make doxygen"

-- 
You received this message because you are subscribed to the Google Groups 
"opencog" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to opencog+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@googlegroups.com.
Visit this group at https://groups.google.com/group/opencog.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/opencog/CAMyYmr-gn6OdTnSgGa5SZyOxtkTXJL%3DXY9d-2tv4SD%2B4ibVq%2BQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [opencog-dev] Contributing to Opencog

2017-10-01 Thread Mark Nuzz
On Sun, Oct 1, 2017 at 11:32 AM, Ivan Vodišek  wrote:
>
> The key property of collaboration system I'm proposing is a security system
> where each author can give privileges to modify or to fork out their work.
> This way I hope that the system could scale well towards a bigger number of
> maintainers, without need to boss around like in big corporations.
>
> Are there any thoughts on this subject? Is there even an interest in such a
> tool?
>

There's already such a tool, it's called the Pull Request. You could
have as part of a CI system a way to automatically assign reviewers to
a pull request, based on the changes that are made, and where they
were made. And some bigger tech companies do this very thing.

-- 
You received this message because you are subscribed to the Google Groups 
"opencog" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to opencog+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@googlegroups.com.
Visit this group at https://groups.google.com/group/opencog.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/opencog/CAMyYmr--p%2BDpT7ZHOwFQ9CnsTE8Xri9s3gucO1Qb8t0b3EY8WA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [opencog-dev] Contributing to Opencog

2017-10-01 Thread Mark Nuzz
By the way, I lurked for 10 years before making my first real contribution.
Don't blame the project for that one!

-- 
You received this message because you are subscribed to the Google Groups 
"opencog" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to opencog+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@googlegroups.com.
Visit this group at https://groups.google.com/group/opencog.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/opencog/CAMyYmr8CnvfrXKkwP%3DN2Znjs_n9k4BYucTszgb1fy9agu70kYw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [opencog-dev] Contributing to Opencog

2017-10-01 Thread Mark Nuzz
You bring up a good point. It is quite difficult to maintain. Not only is
it a very complex system design, but the implementation is also quite
complex, containing a lot of legacy code, unfinished features, experiments,
and whatever else. I used to thumb my nose at the fact that not enough
attention seems to be focused on simplifying the implementation. But now I
have a lot of respect for the project's ability to thrive for so long
despite the barriers to entry.

Keep in mind though that at many software companies, it can take a number
of months of full time effort before a professional engineer becomes
productive, even despite efforts to reduce this time!

And this is also a research project, with the core contributors being
focused on research. I don't think they would be able to focus on
maintainability.

My approach to solving it, if I were to decide now, would be to first get a
lot of feedback on what new and existing contributors find difficult about
the project's implementation, maintainability, and ramp up time. Would also
look at past posts meticulously, to find patterns.

Some recommendations that might be made (subject to approval and further
analysis): Would consider gradually moving parts of the C++ into idiomatic
C# (fully open source now), or even F# if functional programming
environment is desired. Any C++ developer can understand C#, and almost
anything you can do in C++ can be done in C#, but with less complex code
and easier troubleshooting. Even if half the core developers were to prefer
python (for example) I'd try to persuade everyone that C# is a better
choice due to the fact that it probably has the lowest learning curve of
all major languages, is syntactically and idiomatically similar to C++, and
has high compatibility due to the VM runtime.

Would clean up the build scripts or even rewrite them completely (the
scripts aren't bad, but they're old and probably need an overhaul). Toss
out all support for alternate OS, alternate compiler, etc. At least until
support can be re-added under a newer build system. There is (or was) a lot
of "junk DNA" code in the build script that only hinders efforts to
understand it or improve it. Ever hear of the "broken window problem"?
CMake has a high learning curve (and is it really necessary when using one
OS?) so I'd probably do away with it.

My vote is worth about zero though because I don't have the physical
stamina or mental willpower to work on this in addition to my day job (it
would not be easy work, and likely some of the hardest coding work I've
ever done, which is saying something).

On Oct 1, 2017 7:38 AM, "Amirouche Boubekki" 
wrote:

>
>
> On Mon, Sep 25, 2017 at 5:05 PM Onkar N Mahajan 
> wrote:
>
>> I am interested to contributing to Opencog. What do I need to learn, and
>> how soon can I be an active contributor ?
>>
>
> Forget about it. I've been lurking for 2 years, read dozens if not
> hundreds of wiki pages and papers and I still can't contribute to opencog.
>
> From experience, if you look for guidance on how to contribute then you
> are not good enough.
>
> My 2 cents.
>
> --
> You received this message because you are subscribed to the Google Groups
> "opencog" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to opencog+unsubscr...@googlegroups.com.
> To post to this group, send email to opencog@googlegroups.com.
> Visit this group at https://groups.google.com/group/opencog.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/opencog/CAL7_Mo-y6hgsjDPjbuJBtqcTeCiMTty9PHbHm
> NdGQ1dMstJWCA%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"opencog" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to opencog+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@googlegroups.com.
Visit this group at https://groups.google.com/group/opencog.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/opencog/CAMyYmr9AXLz0o_MOOXP_Vab3ece7RKN0vhQ4QNfdKEe1Ehjzog%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [opencog-dev] it would be nice if..

2017-09-14 Thread Mark Nuzz
I've done some work on the build system a couple of years ago. I agree that
the project suffers from a lot of legacy code in the build system.
Unfortunately there aren't unlimited resources to fix it "The Right Way"
with a big overhaul. But maybe it would be a good idea if someone were able
to volunteer to do it.

In the meantime, I can't see any reason not to be supportive of incremental
fixes. But that would require some logs and a specific description of the
problem before anyone can look at it. It could be anything, but my wild
guess is that there's a dependency missing and the build script does a poor
job of emitting a proper error message.

On Sep 14, 2017 8:03 PM, "Samantha Atkins"  wrote:

> It would be really nice if the project escaped from difficult to build
> hell so many projects fall into.  I may be blowing smoke but why can't a
> bit of AI or perhaps not even qualifying as AI dependably take a system
> environment from current state to fully built state for a software system
> to be installed.  I followed directions and at least on my ubuntu 17.04
> things just don't build as advertized.
>
> This is indeed a general problem and one that I am so very tired of on
> many many software projects and apps.  Don't mean to pick on opencog but it
> would be sweet if a project to produce an AGI was at least smart enough to
> more dependably install its code.  Yeah, a bit meta.But I can dream. :)
>
> --
> You received this message because you are subscribed to the Google Groups
> "opencog" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to opencog+unsubscr...@googlegroups.com.
> To post to this group, send email to opencog@googlegroups.com.
> Visit this group at https://groups.google.com/group/opencog.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/opencog/d7f025e1-6b0b-44fe-9d38-eb96ad5e8d3b%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"opencog" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to opencog+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@googlegroups.com.
Visit this group at https://groups.google.com/group/opencog.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/opencog/CAMyYmr-ztJJ0rO5ZDH%3Dfz_rawYZAnGQZ6ZyM8vuuYoVgzyKpnA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [opencog-dev] general agi discussion apart from opencog

2016-12-02 Thread Mark Nuzz
I recommend: http://www.agiri.org/email/


On Wed, Nov 30, 2016 at 6:53 PM, Ed Pell  wrote:
> Hi, can anyone point me to any general discussions of AGI? Thanks.
>
> --
> You received this message because you are subscribed to the Google Groups
> "opencog" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to opencog+unsubscr...@googlegroups.com.
> To post to this group, send email to opencog@googlegroups.com.
> Visit this group at https://groups.google.com/group/opencog.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/opencog/616eb179-1201-4758-965a-c41e2e9d9d1e%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"opencog" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to opencog+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@googlegroups.com.
Visit this group at https://groups.google.com/group/opencog.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/opencog/CAMyYmr_v1BXzdDkofG1B5NogUHvt5bkv%2BScYaTFAJwwXfjf6sQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


[opencog-dev] OpenCog as a legal research tool

2016-08-21 Thread Mark Nuzz
Has legal research been considered as an early use case for OpenCog?  For
example:

* Finding out which legal defenses or strategies have been tried in a
category of cases

* Finding out the success and failure rate of given legal strategies

* Estimating the reasoning that generally causes a legal strategy to be
good or bad

* Suggesting legal strategies to use, given an input data set

A possible benchmark of the efficacy of such a system, would involve the
success rate of predicting the winning parties in a set of court cases.

This seems like something that OpenCog could be used for in the near term,
possibly becoming a lucrative source of income.

-- 
You received this message because you are subscribed to the Google Groups 
"opencog" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to opencog+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@googlegroups.com.
Visit this group at https://groups.google.com/group/opencog.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/opencog/CAMyYmr8fw_EzD-dfL%2BnK7Y7zHLUAgpqvgaFji3ErPvYZSeEJEw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [opencog-dev] goertzel.org seems not to be online?

2016-08-12 Thread Mark Nuzz
Recovering from malware infections is among the toughest *and
educational) jobs in IT. Your interns will thank you later in their
careers for having such a great mentor :)

On Fri, Aug 12, 2016 at 4:33 PM, Ben Goertzel  wrote:
> Yes, there is a malware problem on that server, some of my interns
> have been struggling to fix it for a couple weeks, it should be almost
> fixed now...
>

-- 
You received this message because you are subscribed to the Google Groups 
"opencog" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to opencog+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@googlegroups.com.
Visit this group at https://groups.google.com/group/opencog.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/opencog/CAMyYmr8JYGRvk771W_WSkkpBvUUeNjhFs1T_4ywNRNfkjqnpkA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.