Scan_P debug

[Twenkid]

The older thread got too long.

What's the current specific bug?

Sorry these day I've been a bit distracted, a bit busy to collect big enough chunk of focus to say something meaningful. Regarding CogAlg I was thinking about how exactly to bite the problem of trackingl, either to start manually or immediately to approach automation which includes code analysis and would be ore general and easier for application for the other modules. I may start manual for some variables and thrn move to semi- automatic with an editor. I was also checking Python stuff.

That approach with locals() and exec could work persistently only in Python2, in 3 they don't allow write-access to the system dictionary of local vars outside of the official program flow, perhaps for security reasons and due to changes in the implementation of exec, which has turned from a special statement to a function. Another explicit dictionary of the local variables has to be used, like with the approach of sending arguments as a dictionary, or the vars to be set explicitly in normal code, if I use something like that I'd generate it.

I know you don't need that now, but I opened that topic and needed to clarify this.

https://github.com/boris-kz/CogAlg/blob/dbcbf3413363bb52600cb0dc3a364abd858a230a/frame_dblobs.py#L129

[boris-kz]

What's the current specific bug?

I rarely simulate these days Todor, just go over the code and edit it according to the logic. That's the only way to internalize it. scanP seems to be ok now, I am editing higher functions.

Sorry these day I've been a bit distracted, a bit busy to collect big

enough chunk of focus to say something meaningful.

Are going to do something about it? You need to cultivate focus, there is no way around it.

Regarding CogAlg I was thinking about how exactly to bite the problem of trackingl, either to start manually or immediately to approach automation which includes code analysis and would be ore general and easier for application for the other modules. I may start manual for some variables and thrn move to semi- automatic with an editor.

I don't think you will understand the logic unless you do it manually. And we probably need to talk a bunch of times.

[Twenkid]

OK, let's try to talk next week. In the meantime I'll try to spend some time observing the code carefully through its control flow and reflect about it and take some notes on the assignments and how the patterns are nested and when, also how functions are nested while calling. Both should be automated when I have enough focus.

I guess I'll be more concentrated once real rich feedback starts to come with recognition of real patterns and more material progress, as well as earning big enough prizes on a regular basis (I know it depends on the contribution) - both would suggest my brain that it shouldn't waste more time with the other unproductive nonsense, or at least to spend less time, depending on the results. :)

Are going to do something about it? You need to cultivate focus, there is
no way around it.

Maybe yes. Well, if you mean to focus only on your project 24H a day - no... :) That's too much. Especially in its current state.

Yes, I have to be able to follow the code "manually", step by step, and to see the relations. The tracking would track everything, code in general, assignments, how variables are transferred, where patterns are created, how they map to the input, ... Something like "Data mining for/with code". ...

BTW, I understand one reason why you stick to the raccoon, besides it was default in spectral clustering and for keeping a stable frame for the errors.

It has areas with low gradient, others with high; smooth leaves and sharp fur and mustaches, circular shapes of the eyes, thin contrasting lines etc.

(However any complex/visually rich image is supposed to have these.)

With the automation and automated testing it'd be useful if a set of simplified small images are applied, for debug and educational purposes, so that we can see how specific types of input are processed without a huge amount of varying patterns which complicate the output.

One with single contrasting pixel, with a short horizontal line - same color, gradient+-; vertical line, diagonal lines, different shapes etc. The whole image with dots and empty spaces, short horizontal lines and empty spaces, gradients left-to right etc.

[boris-kz]

OK, let's try to talk next week. In the meantime I'll try to spend some time observing the code carefully through its control flow and reflect about it and take some notes on the assignments and how the patterns are nested and when, also how functions are nested while calling. Both should be automated when I have enough focus.

I guess I'll be more concentrated once real rich feedback starts to come with recognition of real patterns and more material progress, as well as earning big enough prizes on a regular basis (I know it depends on the contribution) - both would suggest my brain that it shouldn't waste more time with the other unproductive nonsense, or at least to spend less time, depending on the results. :)

Or you might get interested in reasoning behind the code.

Are going to do something about it? You need to cultivate focus, there is no way around it.

Maybe yes. Well, if you mean to focus only on your project 24H a day - no... :) That's too much.

Because you are busy with more important things...

Especially in its current state.

You can't imagine advancing "the state"? If it's so simple, you should have no problem debugging it.

[Twenkid]

Don't switch to that mode, please. :) Even my bad focus on cogalg is still better than the focus of anyone else of the contributors or rather of all others combined.

Or you might get interested in reasoning behind the code.

Yes and they go together and should suggest each other, especially in ambiguous cases.

Are going to do something about it? You need to cultivate focus, there is no way around it.

Maybe yes. Well, if you mean to focus only on your project 24H a day - no... :) That's too much.

Because you are busy with more important things...

I can't be focused all the time on any of my other interests, either. There are high intensity sessions, as well as breaks and diversity. You can't be non-stop productive in any job, one day you can work 10 hours, then you're tired or get bored after one or 20 mi utes, sometimes you stall and "working" on the same problem produces no progress, so you need to look aside, have a break and return later refreshed. Sometimes you have also "environmental" issues from life that you have to deal with or which distract you, even if you were a monk or have the best working and living conditions for your style or desires.

Especially in its current state. You can't imagine advancing "the state"?

No, I said that I expect to have more fun and longer focused productive sessions when the state advances to a funnier and structurally etc. more interesting state and thus can better compete with other stimuli.

If it's so simple, you should have no problem debugging it.

True. I have to know what's a bug and what's feature and also to be motivated to focus for enough time to see the vars or develop something with pattern matching that will make it easier.

It's traversals, assignments, adding derivatives, recollections of tuples (in some cycles with rng, when rng is big, some may be redundant). Nesting a structure in another, reading it back. I have to see what's so interesting.

—

You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/boris-kz/CogAlg/issues/10#issuecomment-423786821, or mute the thread https://github.com/notifications/unsubscribe-auth/AWSP2GhKCg5nWfSZyb5zSnrE0YGXld1jks5udvA-gaJpZM4W0XYx .t

[Twenkid]

One Pycharm's debugger function that may be useful:

View as array (on NP arrays, ndarray). With slicing.

https://www.jetbrains.com/help/pycharm/debug-tool-window-variables.html image[80:90, 20:30]

[boris-kz]

I tried array view but my tuples are too complex and uneven, regular "variables" is better.

Or you might get interested in reasoning behind the code.

Yes and they go together and should suggest each other, especially in

ambiguous cases.

Most of the code is designed from the first principles.

I have to know what's a bug and what's feature

The purpose is described in the comments, and we can always talk.

and also to be motivated to focus for enough time to see the vars

Motivation is a matter of practice too.

and thus can better compete with other stimuli.

It's easy, just block them: https://getcoldturkey.com I use whitelisting, with pro version. I never said anything about 100% focus, but more is better.

Sometimes you have also "environmental" issues

Minimize them. I can pay you more than enough to live on Todor, for a lifetime. But you have to get into "rational design".

On Sun, Sep 23, 2018 at 5:14 PM Todor Arnaudov notifications@github.com wrote:

One Pycharm's debugger function that may be useful:

View as array (on NP arrays, ndarray). With slicing.

https://www.jetbrains.com/help/pycharm/debug-tool-window-variables.html image[80:90, 20:30] [image: slice] https://user-images.githubusercontent.com/23367640/45933002-29105e80-bf8e-11e8-8502-8c021d7369fd.png

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/boris-kz/CogAlg/issues/10#issuecomment-423848418, or mute the thread https://github.com/notifications/unsubscribe-auth/AUAXGRWNs5CcXi7Y0nKmQS8M0Ji-WX7Xks5ud_mlgaJpZM4W0XYx .

[Twenkid]

I tried array view but my tuples are too complex and uneven, regular "variables" is better.

Well, then I see you actually do agree that visualisation-tracking-everything tools would be helpful.

Most of the code is designed from the first principles.

OK, one day I'll "bite" it and it would be easier.

The purpose is described in the comments, and we can always talk.

OK

I can pay you more than enough to live on Todor, for a lifetime. But you have to get into "rational design".

I agree I have to make changes in my life design in order to direct the change.

I appreciate the pension offer, too, but let's hope CogAlg would work so I won't have to "live on" with it.

However, as of the "rational design", actually the Numpy fancy indexing thread was created because of unrational decision and wrong design in another computer vision related project I've been working on lately and which has feedback and results, a visual effects one.

As of being rational in general, practically and financially AGI is not... Especially back in the 2000s, it was "insane" for the "normal people". To me it's one of the many financially-wise terribly wrong decisions, but I wasn't interested for financial reasons.

As a developer and researcher I could be in the Valley since late 2000s and earning "more than enough" etc.

[boris-kz]

I tried array view but my tuples are too complex and uneven, regular

"variables" is better.

Well, then I see you actually do agree that visualisation-tracking-everything tools would be helpful.

Pycharm Vars is all I need for now. There is no point in visualizing everything, it won't be comprehensible.

Most of the code is designed from the first principles.

OK, one day I'll "bite" it and it would be easier.

Holding my breath :)

But you have to get into "rational design".

I agree I have to make changes in my life design in order to direct the change.

That too, but I meant rational code design.

I appreciate the pension offer, too,

Not a "pension" :)

but let's hope CogAlg would work so I won't have to "live on" with it.

Right.

As of the being rational in general, practically and financially AGI is not... Especially back in the 2000s, it was "insane" for the "normal people".

That doesn't make it irrational. I didn't start in the 2000s, it was 1980s, or even 70s, depending on what you count. The latter is long before I first saw a computer.

[Twenkid]

Well, then I see you actually do agree that visualisation-tracking-everything tools would be helpful.

Pycharm Vars is all I need for now. There is no point in visualizing everything, it won't be comprehensible.

TRACKING

I meant any of all possible - tracking of everything that's desirable, of course not displaying every variable in the same time.

Also in an an automated and scripted way, probably animated as well, with saved states, instead of pumping until breakpoints, etc. That would get more important when the simulations become larger - should we wait for an hour to replicate an error, or when the variables get even more deeply nested - dig into endless trees by clicking deeper and deeper.

The user should be able to query anything more easily and see whatever she wants with less efforts.

Etc., I'll show one day, better than trying to convince you.

That too, but I meant rational code design.

RATIONAL CODE DESIGN

I see some of it. It's defined in your text, but for a start it might be easier if it could be induced from the code.

I'd word it for now (mundanely, better when coded) as a generative traversal of a combinatorial space of variables and basic operation. Some of the variables are limits, or "terminal" (you even use that term). When they are traversed, that's a conclusion of the pass and is producing a new element. It could be either an operation or a variable (derivative, pattern; function as well - code level. In this view I see the formation of function, segmentation of processing, as a part of the that meta-algorithm that generates the code of your algorithm.

Different variables and functions have to be connected, there's a flow of assignments.

I assume, recalling your notes, another principle is applying the same operation(s) recursively over the newly generated representation.

(I remember you've said "iteratively" and then suggested that you mean "recursively", which IMO was/is confusing: https://techdifferences.com/difference-between-recursion-and-iteration-2.html )

Syntax-wise as of the specific generation, the initial variable identifiers are following constraints of being short and remind the "generator" (you) what they mean, so you usually take the first letters or a short beginning of the concepts (texts) that are immediately mapped to them, with the respective constraints of minimal length, while distinguishable to the others. If the label is already occupied, you search for another letter etc. and fill another space of syntax code-level representation entities.

...

RATIONAL

As of rational - it depends how you define rational... In some philosophy schools rational is cognitive, something about concepts and generalized input, while irrational is driven or linked to any of the emotions (which vary), i.e. not cognitive. In that regard yours is "rational" for yourself, but in general IMO everything that an agent does according to its own goals, model of the world, reward values is "rational", it's the best at the moment given the predictions. This however is not very meaningful without a model of the agent's cognition with high enough resolution.

In the past in the literature it was fashionable to be claimed how "irrational" human's decision are, with another meaning: "not optimal", by some abstractly selected measure. Like the case in economics, the "discovery" that people do not always search for the lowest nominal price in money numbers, and that this was considered surprising. While it's obvious that there are other costs like time for travelling, for search, cognitive efforts on selection, available time for search, habits and personal preferences of salesmen, shops etc.

So this is "irrational" to some ones, but it's not for the agent itself, just the rationality is more complex than the model of the ones who do not understand it

Also, personally, individuals change over time and the current model does not match completely the past; also there's more data about what happened after the moment of decision and also general models of the world. Thus the old decisions get reevaluated with new "filters" and now some are considered "wrong", according to current predictions.

However yet again that's for the current model, which does it, for the "same filter span". :)

A moment later the model may change back or forward and recognize that the old decision was "right" ("rational", profitable, optimal - for the newly selected periods and values) etc. or admit that it was the best given the information available at the moment etc.

—

You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/boris-kz/CogAlg/issues/10#issuecomment-424183065, or mute the thread https://github.com/notifications/unsubscribe-auth/AWSP2HZrMcnVo1D_vUX8Lvhc9rdf3qQxks5ueY9ugaJpZM4W0XYx .

[boris-kz]

TRACKING

I meant any of all possible - tracking of everything that's desirable, of course not displaying every variable in the same time.

Also in an an automated and scripted way, probably animated as well, with saved states, instead of pumping until breakpoints, etc. That would get more important when the simulations become larger - should we wait for an hour to replicate an error, or when the variables get even more deeply nested - dig into endless trees by clicking deeper and deeper.

The user should be able to query anything more easily and see whatever she wants with less efforts.

You won't know what sort of tracking is needed until you start designing the code.

RATIONAL CODE DESIGN

I see some of it. It's defined in your text, but for a start it might be easier if it could be induced from the code.

I'd word it for now (mundanely, better when coded) as a generative traversal of a combinatorial space of variables and basic operation. Some of the variables are limits, or "terminal" (you even use that term). When they are traversed, that's a conclusion of the pass and is producing a new element. It could be either an operation or a variable (derivative, pattern; function as well - code level. In this view I see the formation of function, segmentation of processing, as a part of the that meta-algorithm that generates the code of your algorithm.

Different variables and functions have to be connected, there's a flow of assignments.

I assume, recalling your notes, another principle is applying the same operation(s) recursively over the newly generated representation.

I remember you've said "iteratively" and then suggested that you mean "recursively", which IMO was/is confusing:

It's both, and more.

Current frame functions are only iterative, they perform same operations on a sequence of inputs.

Line_POC and ultimate 1st level frame or sequence algorithms are recursive, with conditional re-input of their outputs.

Ultimate hierarchical algorithm will also need recursive code generation, because level's outputs have higher-order syntax than it's inputs.

To process this higher-order syntax, next-level algorithm must be augmented with higher-order functions, and this augmentation should be recursive per level.

As of rational - it depends how you define rational... In some philosophy schools rational is cognitive, something about concepts and generalized input, while irrational is driven or linked to any of the emotions (which vary), i.e. not cognitive. In that regard yours is "rational" for yourself, but in general IMO everything that an agent does according to its own goals,..

In the latter sense, "rational" could be current or predictive.

Current means maximizing a sum of rewards for all of subject's drives, * their current intensity.

But that's pointless because decisions are made for the future and intensity of the drives changes all the time.

So, it helps to predict how that intensity will change, and that prediction itself will change it too.

And if you predict far enough, then only one drive will survive: curiosity.

Because everything else is stupid, finite, soon to be obsolete biology.

So, the two of your meanings of "rational" will converge.

None of that is meant to feed your philosophy habit :).

[Twenkid]

Working with the code - this kind of software obviously goes with studying (observing) the code anyway, its purpose is for studying/understanding the code better and easier, both static and dynamic analysis, and generation and design. The aim is eventually to be able to generate your code from another meta-model and to adjust such a model - it would reflect the "understanding" of the algorithm.

Stop with these remarks, please... :) My way of work and what's more convenient for me are not yours and probably won't be. That's supposed to be obvious by the fact that you're a "generalist" whatever it is, while I consider myself a "renaissance person" and other terms like "юнак" in my extension of Bulgarian called "Yunashki dialect".

Our interests intersect at the AGI crossroad, they should intersect at some level of representation, but we arrived at the crossroad from different highways thus our engines and vehicles may be different.

...

The rationality discussion reminds me of a "seminal" paper of mine on NLU and Reinforcement Learning back in early 2004.

Yes, the long-term evaluation of the "success" of a multi-level predictive system with varying spans and various precisions of predictions and varying and unreliable reward functions is similarly unreliable and inconsistent. There's no objective "best trajectory" globally, only local ones, for selected time span with selected precision and selected rewards, moment by moment. The agent can arbitrary change the selected spans, rewards, drives and compute completely different summed rewards and thus make different decisions which are all "rational" and "best".

Right, curiosity and predicting seems the most stable and common among different goals and different trajectories e.g. studying and improving in different fields of interest or mastering a skill.

As of philosophy - I'd read and study a bunch of books due to my curiosity, but I can't afford the focus and time, I got even more distracted than with CogAlg; they are planned for a time after reading/cognitive accellerators are developed.

Recursive code generation - if the algorithm suits recursion, it's easier and more obvious and elegant to be done with recursion. So recursion per se is not scary or hard.

На ср, 26.09.2018 г., 2:52 Boris Kazachenko notifications@github.com написа:

TRACKING

I meant any of all possible - tracking of everything that's desirable, of course not displaying every variable in the same time.

Also in an an automated and scripted way, probably animated as well, with saved states, instead of pumping until breakpoints, etc. That would get more important when the simulations become larger - should we wait for an hour to replicate an error, or when the variables get even more deeply nested - dig into endless trees by clicking deeper and deeper.

The user should be able to query anything more easily and see whatever she wants with less efforts.

You won't know what sort of tracking is needed until you start designing the code.

RATIONAL CODE DESIGN

I see some of it. It's defined in your text, but for a start it might be easier if it could be induced from the code.

I'd word it for now (mundanely, better when coded) as a generative traversal of a combinatorial space of variables and basic operation. Some of the variables are limits, or "terminal" (you even use that term). When they are traversed, that's a conclusion of the pass and is producing a new element. It could be either an operation or a variable (derivative, pattern; function as well - code level. In this view I see the formation of function, segmentation of processing, as a part of the that meta-algorithm that generates the code of your algorithm.

Different variables and functions have to be connected, there's a flow of assignments.

I assume, recalling your notes, another principle is applying the same operation(s) recursively over the newly generated representation.

I remember you've said "iteratively" and then suggested that you mean "recursively", which IMO was/is confusing:

It's both, and more.

Current frame functions are only iterative, they perform same operations on a sequence of inputs.

Line_POC and ultimate 1st level frame or sequence algorithms are recursive, with conditional re-input of their outputs.

Ultimate hierarchical algorithm will also need recursive code generation, because level's outputs have higher-order syntax than it's inputs.

To process this higher-order syntax, next-level algorithm must be augmented with higher-order functions, and this augmentation should be recursive per level.

As of rational - it depends how you define rational... In some philosophy schools rational is cognitive, something about concepts and generalized input, while irrational is driven or linked to any of the emotions (which vary), i.e. not cognitive. In that regard yours is "rational" for yourself, but in general IMO everything that an agent does according to its own goals,..

In the latter sense, "rational" could be current or predictive.

Current means maximizing a sum of rewards for all of subject's drives, * their current intensity.

But that's pointless because decisions are made for the future and intensity of the drives changes all the time.

So, it helps to predict how that intensity will change, and that prediction itself will change it too.

And if you predict far enough, then only one drive will survive: curiosity.

Because everything else is stupid, finite, soon to be obsolete biology.

So, the two of your meanings of "rational" will converge.

None of that is meant to feed your philosophy habit :).

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/boris-kz/CogAlg/issues/10#issuecomment-424539001, or mute the thread https://github.com/notifications/unsubscribe-auth/AWSP2C3PNqnh22R8J8ghnlgEpoczqxcbks5uesG_gaJpZM4W0XYx .

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/boris-kz/CogAlg/issues/10#issuecomment-424539001, or mute the thread https://github.com/notifications/unsubscribe-auth/AWSP2C3PNqnh22R8J8ghnlgEpoczqxcbks5uesG_gaJpZM4W0XYx .

[boris-kz]

Todor, I just folded term_seg into formblob. Now I am getting an error on line 115: P, buff_, P, frame = scanP(x-1, P, P, buff, P, frame) # scans higher-line Ps for contiguity "need more than two values to unpack" I can't figure what that refers to?

On Wed, Sep 26, 2018 at 1:55 PM Todor Arnaudov notifications@github.com wrote:

Working with the code - this kind of software obviously goes with studying (observing) the code anyway, its purpose is for studying/understanding the code better and easier, both static and dynamic analysis, and generation and design. The aim is eventually to be able to generate your code from another meta-model and to adjust such a model - it would reflect the "understanding" of the algorithm.

Stop with these remarks, please... :) My way of work and what's more convenient for me are not yours and probably won't be. That's supposed to be obvious by the fact that you're a "generalist" whatever it is, while I consider myself a "renaissance person" and other terms like "юнак" in my extension of Bulgarian called "Yunashki dialect".

Our interests intersect at the AGI crossroad, they should intersect at some level of representation, but we arrived at the crossroad from different highways thus our engines and vehicles may be different.

...

The rationality discussion reminds me of a "seminal" paper of mine on NLU and Reinforcement Learning back in early 2004.

Yes, the long-term evaluation of the "success" of a multi-level predictive system with varying spans and various precisions of predictions and varying and unreliable reward functions is similarly unreliable and inconsistent. There's no objective "best trajectory" globally, only local ones, for selected time span with selected precision and selected rewards, moment by moment. The agent can arbitrary change the selected spans, rewards, drives and compute completely different summed rewards and thus make different decisions which are all "rational" and "best".

Right, curiosity and predicting seems the most stable and common among different goals and different trajectories e.g. studying and improving in different fields of interest or mastering a skill.

As of philosophy - I'd read and study a bunch of books due to my curiosity, but I can't afford the focus and time, I got even more distracted than with CogAlg; they are planned for a time after reading/cognitive accellerators are developed.

Recursive code generation - if the algorithm suits recursion, it's easier and more obvious and elegant to be done with recursion. So recursion per se is not scary or hard.

На ср, 26.09.2018 г., 2:52 Boris Kazachenko notifications@github.com написа:

TRACKING

I meant any of all possible - tracking of everything that's desirable, of course not displaying every variable in the same time.

Also in an an automated and scripted way, probably animated as well, with saved states, instead of pumping until breakpoints, etc. That would get more important when the simulations become larger - should we wait for an hour to replicate an error, or when the variables get even more deeply nested - dig into endless trees by clicking deeper and deeper.

The user should be able to query anything more easily and see whatever she wants with less efforts.

You won't know what sort of tracking is needed until you start designing the code.

RATIONAL CODE DESIGN

I see some of it. It's defined in your text, but for a start it might be easier if it could be induced from the code.

I'd word it for now (mundanely, better when coded) as a generative traversal of a combinatorial space of variables and basic operation. Some of the variables are limits, or "terminal" (you even use that term). When they are traversed, that's a conclusion of the pass and is producing a new element. It could be either an operation or a variable (derivative, pattern; function as well - code level. In this view I see the formation of function, segmentation of processing, as a part of the that meta-algorithm that generates the code of your algorithm.

Different variables and functions have to be connected, there's a flow of assignments.

I assume, recalling your notes, another principle is applying the same operation(s) recursively over the newly generated representation.

I remember you've said "iteratively" and then suggested that you mean "recursively", which IMO was/is confusing:

It's both, and more.

Current frame functions are only iterative, they perform same operations on a sequence of inputs.

Line_POC and ultimate 1st level frame or sequence algorithms are recursive, with conditional re-input of their outputs.

Ultimate hierarchical algorithm will also need recursive code generation, because level's outputs have higher-order syntax than it's inputs.

To process this higher-order syntax, next-level algorithm must be augmented with higher-order functions, and this augmentation should be recursive per level.

As of rational - it depends how you define rational... In some philosophy schools rational is cognitive, something about concepts and generalized input, while irrational is driven or linked to any of the emotions (which vary), i.e. not cognitive. In that regard yours is "rational" for yourself, but in general IMO everything that an agent does according to its own goals,..

In the latter sense, "rational" could be current or predictive.

Current means maximizing a sum of rewards for all of subject's drives, * their current intensity.

But that's pointless because decisions are made for the future and intensity of the drives changes all the time.

So, it helps to predict how that intensity will change, and that prediction itself will change it too.

And if you predict far enough, then only one drive will survive: curiosity.

Because everything else is stupid, finite, soon to be obsolete biology.

So, the two of your meanings of "rational" will converge.

None of that is meant to feed your philosophy habit :).

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/boris-kz/CogAlg/issues/10#issuecomment-424539001, or mute the thread < https://github.com/notifications/unsubscribe-auth/AWSP2C3PNqnh22R8J8ghnlgEpoczqxcbks5uesG_gaJpZM4W0XYx

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/boris-kz/CogAlg/issues/10#issuecomment-424539001, or mute the thread < https://github.com/notifications/unsubscribe-auth/AWSP2C3PNqnh22R8J8ghnlgEpoczqxcbks5uesG_gaJpZM4W0XYx

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/boris-kz/CogAlg/issues/10#issuecomment-424810942, or mute the thread https://github.com/notifications/unsubscribe-auth/AUAXGYRor67Xum_lfNpgPf6DCMMJTpAlks5ue7-NgaJpZM4W0XYx .

[Twenkid]

The right side and left side number of variables don't match. However the "scanp" has to be defined before calling, above form_p.

For that reason I think Py possibly tries to read the right side or the argument list as a tuple, not as a function, returning a tuple.

Thus it may work just by moving scan_p before form_p (I could check it myself later).

На чт, 27.09.2018 г., 5:13 Boris Kazachenko notifications@github.com написа:

Todor, I just folded term_seg into formblob. Now I am getting an error on line 115: P, buff_, P, frame = scanP(x-1, P, P, buff, P, frame) # scans higher-line Ps for contiguity "need more than two values to unpack" I can't figure what that refers to?

On Wed, Sep 26, 2018 at 1:55 PM Todor Arnaudov notifications@github.com wrote:

Working with the code - this kind of software obviously goes with studying (observing) the code anyway, its purpose is for studying/understanding the code better and easier, both static and dynamic analysis, and generation and design. The aim is eventually to be able to generate your code from another meta-model and to adjust such a model - it would reflect the "understanding" of the algorithm.

Stop with these remarks, please... :) My way of work and what's more convenient for me are not yours and probably won't be. That's supposed to be obvious by the fact that you're a "generalist" whatever it is, while I consider myself a "renaissance person" and other terms like "юнак" in my extension of Bulgarian called "Yunashki dialect".

Our interests intersect at the AGI crossroad, they should intersect at some level of representation, but we arrived at the crossroad from different highways thus our engines and vehicles may be different.

...

The rationality discussion reminds me of a "seminal" paper of mine on NLU and Reinforcement Learning back in early 2004.

Yes, the long-term evaluation of the "success" of a multi-level predictive system with varying spans and various precisions of predictions and varying and unreliable reward functions is similarly unreliable and inconsistent. There's no objective "best trajectory" globally, only local ones, for selected time span with selected precision and selected rewards, moment by moment. The agent can arbitrary change the selected spans, rewards, drives and compute completely different summed rewards and thus make different decisions which are all "rational" and "best".

Right, curiosity and predicting seems the most stable and common among different goals and different trajectories e.g. studying and improving in different fields of interest or mastering a skill.

As of philosophy - I'd read and study a bunch of books due to my curiosity, but I can't afford the focus and time, I got even more distracted than with CogAlg; they are planned for a time after reading/cognitive accellerators are developed.

Recursive code generation - if the algorithm suits recursion, it's easier and more obvious and elegant to be done with recursion. So recursion per se is not scary or hard.

На ср, 26.09.2018 г., 2:52 Boris Kazachenko notifications@github.com написа:

TRACKING

I meant any of all possible - tracking of everything that's desirable, of course not displaying every variable in the same time.

Also in an an automated and scripted way, probably animated as well, with saved states, instead of pumping until breakpoints, etc. That would get more important when the simulations become larger - should we wait for an hour to replicate an error, or when the variables get even more deeply nested - dig into endless trees by clicking deeper and deeper.

The user should be able to query anything more easily and see whatever she wants with less efforts.

You won't know what sort of tracking is needed until you start designing the code.

RATIONAL CODE DESIGN

I see some of it. It's defined in your text, but for a start it might be easier if it could be induced from the code.

I'd word it for now (mundanely, better when coded) as a generative traversal of a combinatorial space of variables and basic operation. Some of the variables are limits, or "terminal" (you even use that term). When they are traversed, that's a conclusion of the pass and is producing a new element. It could be either an operation or a variable (derivative, pattern; function as well - code level. In this view I see the formation of function, segmentation of processing, as a part of the that meta-algorithm that generates the code of your algorithm.

Different variables and functions have to be connected, there's a flow of assignments.

I assume, recalling your notes, another principle is applying the same operation(s) recursively over the newly generated representation.

I remember you've said "iteratively" and then suggested that you mean "recursively", which IMO was/is confusing:

It's both, and more.

Current frame functions are only iterative, they perform same operations on a sequence of inputs.

Line_POC and ultimate 1st level frame or sequence algorithms are recursive, with conditional re-input of their outputs.

Ultimate hierarchical algorithm will also need recursive code generation, because level's outputs have higher-order syntax than it's inputs.

To process this higher-order syntax, next-level algorithm must be augmented with higher-order functions, and this augmentation should be recursive per level.

As of rational - it depends how you define rational... In some philosophy schools rational is cognitive, something about concepts and generalized input, while irrational is driven or linked to any of the emotions (which vary), i.e. not cognitive. In that regard yours is "rational" for yourself, but in general IMO everything that an agent does according to its own goals,..

In the latter sense, "rational" could be current or predictive.

Current means maximizing a sum of rewards for all of subject's drives, * their current intensity.

But that's pointless because decisions are made for the future and intensity of the drives changes all the time.

So, it helps to predict how that intensity will change, and that prediction itself will change it too.

And if you predict far enough, then only one drive will survive: curiosity.

Because everything else is stupid, finite, soon to be obsolete biology.

So, the two of your meanings of "rational" will converge.

None of that is meant to feed your philosophy habit :).

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/boris-kz/CogAlg/issues/10#issuecomment-424539001, or mute the thread <

https://github.com/notifications/unsubscribe-auth/AWSP2C3PNqnh22R8J8ghnlgEpoczqxcbks5uesG_gaJpZM4W0XYx

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/boris-kz/CogAlg/issues/10#issuecomment-424539001, or mute the thread <

https://github.com/notifications/unsubscribe-auth/AWSP2C3PNqnh22R8J8ghnlgEpoczqxcbks5uesG_gaJpZM4W0XYx

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/boris-kz/CogAlg/issues/10#issuecomment-424810942, or mute the thread < https://github.com/notifications/unsubscribe-auth/AUAXGYRor67Xum_lfNpgPf6DCMMJTpAlks5ue7-NgaJpZM4W0XYx

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/boris-kz/CogAlg/issues/10#issuecomment-424933682, or mute the thread https://github.com/notifications/unsubscribe-auth/AWSP2MNco0Ux0PAKTos1if-25AxyD5RSks5ufDRLgaJpZM4W0XYx .

[boris-kz]

The order in which functions are defined makes no difference, as long as they are defined before execution. My frame() functions have always been defined bottom-up, and it worked.

On Thu, Sep 27, 2018 at 4:48 AM Todor Arnaudov notifications@github.com wrote:

The right side and left side number of variables don't match. However the "scanp" has to be defined before calling, above form_p.

For that reason I think Py possibly tries to read the right side or the argument list as a tuple, not as a function, returning a tuple.

Thus it may work just by moving scan_p before form_p (I could check it myself later).

На чт, 27.09.2018 г., 5:13 Boris Kazachenko notifications@github.com написа:

Todor, I just folded term_seg into formblob. Now I am getting an error on line 115: P, buff_, P, frame = scanP(x-1, P, P, buff, P, frame) # scans higher-line Ps for contiguity "need more than two values to unpack" I can't figure what that refers to?

On Wed, Sep 26, 2018 at 1:55 PM Todor Arnaudov <notifications@github.com

wrote:

Working with the code - this kind of software obviously goes with studying (observing) the code anyway, its purpose is for studying/understanding the code better and easier, both static and dynamic analysis, and generation and design. The aim is eventually to be able to generate your code from another meta-model and to adjust such a model - it would reflect the "understanding" of the algorithm.

Stop with these remarks, please... :) My way of work and what's more convenient for me are not yours and probably won't be. That's supposed to be obvious by the fact that you're a "generalist" whatever it is, while I consider myself a "renaissance person" and other terms like "юнак" in my extension of Bulgarian called "Yunashki dialect".

Our interests intersect at the AGI crossroad, they should intersect at some level of representation, but we arrived at the crossroad from different highways thus our engines and vehicles may be different.

...

The rationality discussion reminds me of a "seminal" paper of mine on NLU and Reinforcement Learning back in early 2004.

Yes, the long-term evaluation of the "success" of a multi-level predictive system with varying spans and various precisions of predictions and varying and unreliable reward functions is similarly unreliable and inconsistent. There's no objective "best trajectory" globally, only local ones, for selected time span with selected precision and selected rewards, moment by moment. The agent can arbitrary change the selected spans, rewards, drives and compute completely different summed rewards and thus make different decisions which are all "rational" and "best".

Right, curiosity and predicting seems the most stable and common among different goals and different trajectories e.g. studying and improving in different fields of interest or mastering a skill.

As of philosophy - I'd read and study a bunch of books due to my curiosity, but I can't afford the focus and time, I got even more distracted than with CogAlg; they are planned for a time after reading/cognitive accellerators are developed.

Recursive code generation - if the algorithm suits recursion, it's easier and more obvious and elegant to be done with recursion. So recursion per se is not scary or hard.

На ср, 26.09.2018 г., 2:52 Boris Kazachenko notifications@github.com написа:

TRACKING

I meant any of all possible - tracking of everything that's desirable, of course not displaying every variable in the same time.

Also in an an automated and scripted way, probably animated as well, with saved states, instead of pumping until breakpoints, etc. That would get more important when the simulations become larger - should we wait for an hour to replicate an error, or when the variables get even more deeply nested - dig into endless trees by clicking deeper and deeper.

The user should be able to query anything more easily and see whatever she wants with less efforts.

You won't know what sort of tracking is needed until you start designing the code.

RATIONAL CODE DESIGN

I see some of it. It's defined in your text, but for a start it might be easier if it could be induced from the code.

I'd word it for now (mundanely, better when coded) as a generative traversal of a combinatorial space of variables and basic operation. Some of the variables are limits, or "terminal" (you even use that term). When they are traversed, that's a conclusion of the pass and is producing a new element. It could be either an operation or a variable (derivative, pattern; function as well - code level. In this view I see the formation of function, segmentation of processing, as a part of the that meta-algorithm that generates the code of your algorithm.

Different variables and functions have to be connected, there's a flow of assignments.

I assume, recalling your notes, another principle is applying the same operation(s) recursively over the newly generated representation.

I remember you've said "iteratively" and then suggested that you mean "recursively", which IMO was/is confusing:

It's both, and more.

Current frame functions are only iterative, they perform same operations on a sequence of inputs.

Line_POC and ultimate 1st level frame or sequence algorithms are recursive, with conditional re-input of their outputs.

Ultimate hierarchical algorithm will also need recursive code generation, because level's outputs have higher-order syntax than it's inputs.

To process this higher-order syntax, next-level algorithm must be augmented with higher-order functions, and this augmentation should be recursive per level.

As of rational - it depends how you define rational... In some philosophy schools rational is cognitive, something about concepts and generalized input, while irrational is driven or linked to any of the emotions (which vary), i.e. not cognitive. In that regard yours is "rational" for yourself, but in general IMO everything that an agent does according to its own goals,..

In the latter sense, "rational" could be current or predictive.

Current means maximizing a sum of rewards for all of subject's drives, * their current intensity.

But that's pointless because decisions are made for the future and intensity of the drives changes all the time.

So, it helps to predict how that intensity will change, and that prediction itself will change it too.

And if you predict far enough, then only one drive will survive: curiosity.

Because everything else is stupid, finite, soon to be obsolete biology.

So, the two of your meanings of "rational" will converge.

None of that is meant to feed your philosophy habit :).

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <https://github.com/boris-kz/CogAlg/issues/10#issuecomment-424539001 , or mute the thread <

https://github.com/notifications/unsubscribe-auth/AWSP2C3PNqnh22R8J8ghnlgEpoczqxcbks5uesG_gaJpZM4W0XYx

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/boris-kz/CogAlg/issues/10#issuecomment-424539001, or mute the thread <

https://github.com/notifications/unsubscribe-auth/AWSP2C3PNqnh22R8J8ghnlgEpoczqxcbks5uesG_gaJpZM4W0XYx

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/boris-kz/CogAlg/issues/10#issuecomment-424810942, or mute the thread <

https://github.com/notifications/unsubscribe-auth/AUAXGYRor67Xum_lfNpgPf6DCMMJTpAlks5ue7-NgaJpZM4W0XYx

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/boris-kz/CogAlg/issues/10#issuecomment-424933682, or mute the thread < https://github.com/notifications/unsubscribe-auth/AWSP2MNco0Ux0PAKTos1if-25AxyD5RSks5ufDRLgaJpZM4W0XYx

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/boris-kz/CogAlg/issues/10#issuecomment-425010981, or mute the thread https://github.com/notifications/unsubscribe-auth/AUAXGYuBEpQCwx2nHR9UKexiVZlqG0Z_ks5ufJDzgaJpZM4W0XYx .

[Twenkid]

OK, I'll check it out.

[Twenkid]

I think it's because of that early return in scanP:

 else:     # no x overlap between _P and next P: _P is included in unique blob segment:
            ini = 1
            if y > rng * 2 + 1:  # beyond 1st line of _fork_ Ps, else: blob segment ini only
                if len(_fork_[0]) == 1:
                    #try:
                        if _fork_[0][0][4][0] == 1:  # _fork roots, see if ini = 1, second [] is a fixed-id _P container
                            _P[0] = form_seg(_P[0], _fork_[0][0], _x)  # _P is added to blob segment at _fork_[0]
                            ini = 0  # no initialization
                            return ini, fork_
                    #except:

A tuple of two is returned, but the left-side requires 4 elements.

My error message: (Py 3.6.1)

File "D:\Py\cog\frame1.py", line 115, in formP P, buff_, P, frame = scanP(x-1, P, P, buff, P, frame) # scans higher-line Ps for contiguity ValueError: not enough values to unpack (expected 4, got 2)

[boris-kz]

Thanks Todor! That return was a mistake, I added it because pycharm showed these variables as unused, but not anymore.

Now, I have the same problem with roots and fork again: they are always > 0 at y > 5...

On Thu, Sep 27, 2018 at 2:49 PM Todor Arnaudov notifications@github.com wrote:

I think it's because of that early return in scanP:

else: # no x overlap between _P and next P: _P is included in unique blob segment: ini = 1 if y > rng * 2 + 1: # beyond 1st line of fork Ps, else: blob segment ini only if len(fork[0]) == 1:

try:

                   if _fork_[0][0][4][0] == 1:  # _fork roots, see if ini = 1, second [] is a fixed-id _P container
                       _P[0] = form_seg(_P[0], _fork_[0][0], _x)  # _P is added to blob segment at _fork_[0]
                       ini = 0  # no initialization
                       return ini, fork_
               #except:

A tuple of two is returned, but the left-side requires 4 elements.

My error message: (Py 3.6.1)

File "D:\Py\cog\frame1.py", line 115, in formP P, buff_, P, frame = scanP(x-1, P, P, buff, P, frame) # scans higher-line Ps for contiguity ValueError: not enough values to unpack (expected 4, got 2)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/boris-kz/CogAlg/issues/10#issuecomment-425202983, or mute the thread https://github.com/notifications/unsubscribe-auth/AUAXGeXFKBXpJQAuiojs3b-3R5wMv10Fks5ufR3LgaJpZM4W0XYx .

[Twenkid]

On Fri, Sep 28, 2018 at 3:52 AM Boris Kazachenko notifications@github.com wrote:

Thanks Todor! That return was a mistake, I added it because pycharm showed these variables as unused, but not anymore.

OK :)

Now, I have the same problem with roots and fork again: they are always > 0 at y > 5...

OK, I'll check that in the next session.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/boris-kz/CogAlg/issues/10#issuecomment-425202983, or mute the thread < https://github.com/notifications/unsubscribe-auth/AUAXGeXFKBXpJQAuiojs3b-3R5wMv10Fks5ufR3LgaJpZM4W0XYx

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/boris-kz/CogAlg/issues/10#issuecomment-425286296, or mute the thread https://github.com/notifications/unsubscribe-auth/AWSP2Me1HYiOmMppPC-nm040t_CRt0CGks5ufXLKgaJpZM4W0XYx .

[Twenkid]

First diagnostics:

That y > 5 relates to rng*2 + 1, the border line changes with the change of rng.

Therefore related code with this limit may be involved.

There's related code in the vertical_comp:

    min_coord = rng * 2 - 1  # min x and y for form_P input

 elif x > min_coord and y > min_coord:  # or min y is increased by x_comp on line y=0?
                _v = _m - abs(d) - ave  # _m - abs(d): projected m cancelled by negative d: d/2, + projected rdn value of overlapping dP: d/2
                vy = my + _my - abs(dy) - ave
                ders2 = _p, _d, dy + _dy, _v, vy
                dP, dP_, dbuff_, _dP_, dframe = form_P(ders2, x, dP, dP_, dbuff_, _dP_, dframe)

Also in form_P:

 if y == rng * 2:  # first line of Ps -> P_, _P_ is empty until vertical_comp returns P_:
            P_.append([P, x-1, []]) 

 if _x > ix:  # x overlap between _P and next P: _P is buffered for next scan_P_
            buff_.append([_P, _x, _fork_, roots])

That also eliminates the else: branch with len(fork)

..

I think it catches an exception when

#len(_fork_),x,_ix,y 1 812 799 41
..if y > rng * 2 + 1: 41
....if len(_fork_[0]) == 1:

But that _fork_ has no other elements and a query is made to missing indices: 
if _fork_[0][0][4][0] == 1: 

I've got code modified to log some things and some print outs. A printout with rng = 3:

rng = 2:

If I catch these exception, there's another one (line numbers may vary from yours due to additional code):

frame_of_blobs = image_to_blobs(image)
  File "frame2.py", line 316, in image_to_blobs
    ders2__, _P_, frame = vertical_comp(ders_, ders2__, _P_, frame)  # vertical pixel comparison
  File "frame2.py", line 93, in vertical_comp
    dP, dP_, dbuff_, _dP_, dframe = form_P(ders2, x, dP, dP_, dbuff_, _dP_, dframe)
  File "frame2.py", line 116, in form_P
    P_, buff_, _P_, frame = scan_P_(x-1, P, P_, buff_, _P_, frame)  # scans higher-line Ps for contiguity
  File "frame2.py", line 207, in scan_P_
    _P[0], frame = form_blob(_P[0], frame)  # blob (all connected blob segments) += blob segment at _P[0]
  File "frame2.py", line 248, in form_blob
    _roots, _root_, _blob = _seg[4]
IndexError: list index out of range

Maybe because when there's an exception, _P[0] = form_seg(... is not hit.

...

Some printouts, f2 (rng=2), f3 (=3) http://twenkid.com/cog/

[boris-kz]

First diagnostics:

That y > 5 relates to rng*2 + 1, the border line changes with the change of rng.

Therefore related code with this limit may be involved.

There's related code in the vertical_comp:

min_coord = rng * 2 - 1  # min x and y for form_P input

elif x > min_coord and y > min_coord: # or min y is increased by x_comp on line y=0? _v = _m - abs(d) - ave # _m - abs(d): projected m cancelled by negative d: d/2, + projected rdn value of overlapping dP: d/2 vy = my + _my - abs(dy) - ave ders2 = _p, _d, dy + _dy, v, vy dP, dP, dbuff_, dP, dframe = formP(ders2, x, dP, dP, dbuff_, dP, dframe)

Also in form_P:

if y == rng * 2: # first line of Ps -> P_, P is empty until verticalcomp returns P: P_.append([P, x-1, []])

In scanP if P[0][0] == _P[0][0]:, the roots = 1.

That also eliminates from comparison the matching sign patterns.

Because these ders2 s and Ps are not yet complete. y > 5 is feature, the bug is that roots and len(fork) are always > 0.

..

I think it catches an exception when

len(fork),x,_ix,y 1 812 799 41

..if y > rng * 2 + 1: 41 ....if len(fork[0]) == 1:

But that fork has no other elements and a query is made to missing indices: if fork[0][0][4][0] == 1:

This is at y == 41, you don't need to go that far, just check lines y==6 -> y==8. The problem is that x error gets bigger on deeper lines, because fork can get wider. You got this error at x == 812, which is just beyond error margin == X-200.

I've got code modified to log some things and some print outs. A printout with rng = 3:

rng = 2:

If I catch these exception, there's another one (line numbers may vary from yours due to additional code):

frame_of_blobs = image_to_blobs(image) File "frame2.py", line 316, in image_to_blobs ders2, P, frame = verticalcomp(ders, ders2, P, frame) # vertical pixel comparison File "frame2.py", line 93, in verticalcomp dP, dP, dbuff_, dP, dframe = formP(ders2, x, dP, dP, dbuff_, dP, dframe) File "frame2.py", line 116, in formP P, buff_, P, frame = scanP(x-1, P, P, buff, P, frame) # scans higher-line Ps for contiguity File "frame2.py", line 207, in scanP _P[0], frame = form_blob(_P[0], frame) # blob (all connected blob segments) += blob segment at _P[0] File "frame2.py", line 248, in form_blob _roots, root, _blob = _seg[4] IndexError: list index out of range

Maybe because when there's an exception, _P[0] = form_seg(... is not hit.

This is not the problem. The problem is that roots and len(fork) are always > 0, on lines y==6 - y==8

[Twenkid]

Strangely while adding code that wasn't changing the processing, it started to complete runs without throwing an exception. However according to the log, if roots == 0 and if len(_fork_) == 0 are not reached.

A log: f2noexc,txt http://twenkid.com/cog/f2noexc.txt

My latest addition was just copying the latest fork

 if _x > ix:  # x overlap between _P and next P: _P is buffered for next scan_P_
            print("@if _x > ix:", x,ix)
            lastFork = copy.copy(_fork_) 

For printing latest previous fork in that case of exception, however there's no exception. After the run it's []

[boris-kz]

Of course it can complete the run without doing any work. Look, I told you a bunch of time that there is no sense in running through the whole image. You can only understand the code if you follow it line-by-line or finer.

On Fri, Sep 28, 2018 at 5:23 PM Todor Arnaudov notifications@github.com wrote:

Strangely while adding code that wasn't changing the processing, it complete a run without throwing an exception. However according to the log, if roots == 0 and if len(fork) == 0 are not reached.

A log: f2noexc,txt http://twenkid.com/cog/f2noexc.txt

My last additions were just:

if _x > ix: # x overlap between _P and next P: _P is buffered for next scanP print("@if _x > ix:", x,ix) lastFork = copy.copy(fork)

For printing latest previous fork in that case of exception, however there's no exception.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/boris-kz/CogAlg/issues/10#issuecomment-425570116, or mute the thread https://github.com/notifications/unsubscribe-auth/AUAXGfRwVEGgMxxVOjL7Jj2l6jaNN8-Sks5ufpNAgaJpZM4W0XYx .

[Twenkid]

This is not the problem. The problem is that roots and len(fork) are always > 0, on lines y==6 - y==8 Then at least from what I see here:

   if _buff_:
            _P, _x, _fork_, roots = _buff_.popleft()  # load _P buffered in prior run of scan_P_, if any
        elif _P_:
            _P, _x, _fork_ = _P_.popleft()
            roots = 0  # number of Ps connected to current _P[(pri_s, I, D, Dy, V, Vy, ders2_)]
        else:
            break
        _ix = _x - len(_P[0][6])

        if P[0][0] == _P[0][0]:  # if s == _s: core sign match, + selective inclusion if contiguity eval
            fork_.append(_P)  # P-connected _Ps, appended with blob and converted to Py_ after P_ scan
            roots += 1

_P_ contains a _fork_ > 0 or/and P[0][0] == _P[0][0]: - then roots is increased.

[Twenkid]

Why they have to be different, what's the reasoning and the path in the code that is expected to be taken so that they are with the expected values. If you know that you'll know what's wrong.

[boris-kz]

There must be instances when d sign blobs are terminated, upwardly or downwardly. You can't have several lines with hundreds of blobs, and none of them terminates.

On Fri, Sep 28, 2018 at 5:30 PM Todor Arnaudov notifications@github.com wrote:

Why they have to be different, what's the reasoning and the path in the code that is expected to be taken so that they are with the expected values. If you know that you'll know what's wrong.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/boris-kz/CogAlg/issues/10#issuecomment-425571839, or mute the thread https://github.com/notifications/unsubscribe-auth/AUAXGQgLXuh6RICQCBIydj0xzoIpwPplks5ufpUOgaJpZM4W0XYx .

[boris-kz]

Another problem is that form_seg is only triggered a few times, at the very beginning of the line. So, not only the blob segments don't terminate, but they are practically never incremented either. That's probably because, beyond the start of a line, roots are always > 1.

On Fri, Sep 28, 2018 at 5:36 PM Boris Kazachenko boris.kz@gmail.com wrote:

There must be instances when d sign blobs are terminated, upwardly or downwardly. You can't have several lines with hundreds of blobs, and none of them terminates.

On Fri, Sep 28, 2018 at 5:30 PM Todor Arnaudov notifications@github.com wrote:

Why they have to be different, what's the reasoning and the path in the code that is expected to be taken so that they are with the expected values. If you know that you'll know what's wrong.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/boris-kz/CogAlg/issues/10#issuecomment-425571839, or mute the thread https://github.com/notifications/unsubscribe-auth/AUAXGQgLXuh6RICQCBIydj0xzoIpwPplks5ufpUOgaJpZM4W0XYx .

[boris-kz]

Actually, looking at the image, the top lines have all vertical patterns. So, maybe they shouldn't terminate... But they shouldn't all fork either...

On Fri, Sep 28, 2018 at 5:48 PM Boris Kazachenko boris.kz@gmail.com wrote:

Another problem is that form_seg is only triggered a few times, at the very beginning of the line. So, not only the blob segments don't terminate, but they are practically never incremented either. That's probably because, beyond the start of a line, roots are always > 1.

On Fri, Sep 28, 2018 at 5:36 PM Boris Kazachenko boris.kz@gmail.com wrote:

There must be instances when d sign blobs are terminated, upwardly or downwardly. You can't have several lines with hundreds of blobs, and none of them terminates.

On Fri, Sep 28, 2018 at 5:30 PM Todor Arnaudov notifications@github.com wrote:

Why they have to be different, what's the reasoning and the path in the code that is expected to be taken so that they are with the expected values. If you know that you'll know what's wrong.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/boris-kz/CogAlg/issues/10#issuecomment-425571839, or mute the thread https://github.com/notifications/unsubscribe-auth/AUAXGQgLXuh6RICQCBIydj0xzoIpwPplks5ufpUOgaJpZM4W0XYx .

[Twenkid]

roots is 0 if a 0 is pushed in buff, or else if buff is empty but a prior line P exists.

_P, _x, fork = P.popleft() roots = 0

Then if the sign if P[0][0] == _P[0][0]: matches, roots is always incremented.

In order to have 0 for roots in the buffer, control flow should go there:

        if _x > ix:  # x overlap between _P and next P: _P is buffered for next scan_P_
            buff_.append([_P, _x, _fork_, roots])

And roots to be 0.

So if roots is always 1, then maybe always when x > ix, if P[0][0] == _P[0][0] is also true, then the buffer is filled with initialized roots.

[boris-kz]

Yes, that's how it should work.

On Fri, Sep 28, 2018 at 6:13 PM Todor Arnaudov notifications@github.com wrote:

roots is 0 if a 0 is pushed in buff, or else if buff is empty but a prior line P exists.

_P, _x, fork = P.popleft() roots = 0

Then if the sign if P[0][0] == _P[0][0]: matches, roots is always incremented.

In order to have 0 for roots in the buffer, control flow should go there:

    if _x > ix:  # x overlap between _P and next P: _P is buffered for next scan_P_
        buff_.append([_P, _x, _fork_, roots])

And roots to be 0.

So if roots is always 1, then maybe always when x > ix, if P[0][0] == _P[0][0] is also true, then the buffer is filled with initialized roots.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/boris-kz/CogAlg/issues/10#issuecomment-425580570, or mute the thread https://github.com/notifications/unsubscribe-auth/AUAXGRMhSfFHA-9XZ6uOVcI8bsu1yNccks5ufp74gaJpZM4W0XYx .

[Twenkid]

1. Why there's an else here?

   
   
   else:
       if y == rng * 2:  # first line of Ps -> P_, _P_ is empty until vertical_comp returns P_:
           P_.append([P, x-1, []])  # empty _fork_ in the first line of _Ps, x-1: delayed P displacement
       elif x < X - 200:  # right error margin: >len(fork_P[6])?
           P_, buff_, _P_, frame = scan_P_(x-1, P, P_, buff_, _P_, frame)  # scans higher-line Ps for contiguity

Are the conditions mutually exclusive?

2. As of _fork_ - it is loaded there in Scan_P:

elif P: _P, _x, fork = P.popleft()

The call tree is:

vertical_comp->form_P->scan_P

More specifically when:

elif x > min_coord and y > min_coord: # or min y is increased by xcomp on line y=0? ... dP, dP, dbuff_, dP, dframe = formP(ders2, x, dP, dP, dbuff_, dP, dframe)

dP_ is renamed to P_

Then if signs don't match:

else: if y == rng * 2: # first line of Ps -> P_, P is empty until verticalcomp returns P: P_.append([P, x-1, []]) # empty fork in the first line of _Ps, x-1: delayed P displacement

So that's how you expect an empty fork.

Initialize the pattern:

 I, D, Dy, V, Vy, ders2_ = 0, 0, 0, 0, 0, []  # new P initialization

Then update it with p, d, ... current values from the received ders2 arguments.

Then pack the pattern into a list:

 P = [(s, I, D, Dy, V, Vy, ders2_)]

and return it:
`
    return P, P_, buff_, _P_, frame  # accumulated within line, P_ is a buffer for conversion to _P_`

Now there is the `frist _P_  in _dP_`  in vertical_comp, where more are accumulated and eventually read back:

_P, _x, fork = P.popleft()

Where _P is a dP, i.e. ders2 Then in scanp there's also: P.append([P, x, fork_])

So let's see the buffer.

In form_P, if y == rng*2, then elif x < X -200 is never checked.

Therefore form_P passes the buffer to another iteration of scan_P.

if y == rng * 2: # first line of Ps -> P_, P is empty until verticalcomp returns P: P_.append([P, x-1, []]) # empty fork in the first line of _Ps, x-1: delayed P displacement elif x < X - 200: # right error margin: >len(forkP[6])? P, buff_, P, frame = scanP(x-1, P, P, buff, P, frame) # scans higher-line Ps for contiguity

While _ix < x ... In case there is a buffer with elements, the oldest (left) items from the buffer are popped, including roots. 

Otherwise, if _buff_ is empty and the upper line container of dP is not empty, only 3 elements (not 4) are popped from the container of upper line patterns.

elif P: _P, _x, fork = P.popleft() roots = 0 # number of Ps connected to current _P[(pris, I, D, Dy, V, Vy, ders2)] else:

roots is added manually, "initialized".

That should be a creation of a "root" for a fork.

Like with the question above, are these conditions guaranteed to be mutually exclusive. I see that the patterns are "displaced" there. If they are not displaced correctly, the conditions won't be mutually exclusive. 

I'd give a general suggestion that the conditions which are checked as mutually exclusive should have more guarantees and measures that they really are mutually exclusive. 

[boris-kz]

On Fri, Sep 28, 2018 at 7:27 PM Todor Arnaudov notifications@github.com wrote:

1. Why there's an else here?

   else: if y == rng * 2: # first line of Ps -> P_, P is empty until verticalcomp returns P: P_.append([P, x-1, []]) # empty fork in the first line of _Ps, x-1: delayed P displacement elif x < X - 200: # right error margin: >len(forkP[6])? P, buff_, P, frame = scanP(x-1, P, P, buff, P, frame) # scans higher-line Ps for contiguity

Are the conditions mutually exclusive?

Yes, if lateral ders2 s sign match, P is continued, else P is terminated and a new P is initialized

1. As of fork - it is loaded there in Scan_P:

   elif P: _P, _x, fork = P.popleft()

The call tree is:

vertical_comp->form_P->scan_P

More specifically when:

elif x > min_coord and y > min_coord: # or min y is increased by xcomp on line y=0? ... dP, dP, dbuff_, dP, dframe = formP(ders2, x, dP, dP, dbuff_, dP, dframe)

dP is renamed to P

Then if signs don't match:

else: if y == rng * 2: # first line of Ps -> P_, P is empty until verticalcomp returns P: P_.append([P, x-1, []]) # empty fork in the first line of _Ps, x-1: delayed P displacement

So that's how you expect an empty fork.

Initialize the pattern:

I, D, Dy, V, Vy, ders2_ = 0, 0, 0, 0, 0, [] # new P initialization

Then update it with p, d, ... current values from the received ders2 arguments.

Then pack the pattern into a list:

P = [(s, I, D, Dy, V, Vy, ders2_)]

and return it: return P, P, buff, P, frame # accumulated within line, P_ is a buffer for conversion to P

Now there is the frist P in dP in vertical_comp, where more are accumulated and eventually read back:

_P, _x, fork = P.popleft()

Where _P is a dP, i.e. ders2 Then in scanp there's also: P.append([P, x, fork_])

So let's see the buffer.

In form_P, if y == rng*2, then elif x < X -200 is never checked.

Yes, Ps are initialized but there is no higher-line _Ps for them to scan yet.

Therefore form_P passes the buffer to another iteration of scan_P.

if y == rng * 2: # first line of Ps -> P_, P is empty until verticalcomp returns P: P_.append([P, x-1, []]) # empty fork in the first line of _Ps, x-1: delayed P displacement elif x < X - 200: # right error margin: >len(forkP[6])? P, buff_, P, frame = scanP(x-1, P, P, buff, P, frame) # scans higher-line Ps for contiguity

While _ix < x ... In case there is a buffer with elements, the oldest (left) items from the buffer are popped, including roots.

Otherwise, if buff is empty and the upper line container of dP is not empty, only 3 elements (not 4) are popped from the container of upper line patterns.

elif P: _P, _x, fork = P.popleft() roots = 0 # number of Ps connected to current _P[(pris, I, D, Dy, V, Vy, ders2)] else:

roots is added manually, "initialized".

That should be a creation of a "root".

Like with the question above, are these conditions guaranteed to be mutually exclusive. I see that the patterns are "displaced" there. If they are not displaced correctly, the conditions won't be mutually exclusive.

I'd give a general suggestion that the conditions which are checked as mutually exclusive should have more guarantees and measures that they really are mutually exclusive.

How are they not? Of course I check that they are exclusive, and displacement is in right order.

So, it's good that you traced the process so far, and everything seems to be correct.

But, form_blob and form_frame are not triggered on a top few lines, so I don't know if they work.

It might be because top margin of raccoon seems to be vertically uniform.

So, I just posted dblobs update with initial line at y == 400, could you test it please?

[Twenkid]

It might be because top margin of raccoon seems to be vertically uniform.

Sounds like overfitting confusions. I suggest at least to have a set of different images and be able to run the alg on all of them so you can see if it misses these or other lines only in specific images or similar visual statistics.

On this specific img we could replace those lines with other lines from the same image in one test and put these elsewhere in another and see what happens.

That's easily done with numpy slicing. You could also run the alg explicitly on a selected slice only to see if the bug, if one is present at all, is specifically for lines in the begginig (my first suspicion), something after initializations and first items inclusion.

So if you want to cover the entire img you may run the alg over the same image but with lan altered phase of the lines like on a desynced CRT TV.

I see that the patterns at the borders should be different due to different roots and different upper line/beginning.

So, I just posted dblobs update with initial >line at y == 400, could you test it please?

Yes, but tomorrow, I'm off to bed...

На сб, 29.09.2018 г., 3:06 Boris Kazachenko notifications@github.com написа:

On Fri, Sep 28, 2018 at 7:27 PM Todor Arnaudov notifications@github.com wrote:

1. Why there's an else here?

else: if y == rng * 2: # first line of Ps -> P_, P is empty until verticalcomp returns P: P_.append([P, x-1, []]) # empty fork in the first line of _Ps, x-1: delayed P displacement elif x < X - 200: # right error margin: >len(forkP[6])? P, buff_, P, frame = scanP(x-1, P, P, buff, P, frame) # scans higher-line Ps for contiguity

Are the conditions mutually exclusive?

Yes, if lateral ders2 s sign match, P is continued, else P is terminated and a new P is initialized

1. As of fork - it is loaded there in Scan_P:

elif P: _P, _x, fork = P.popleft()

The call tree is:

vertical_comp->form_P->scan_P

More specifically when:

elif x > min_coord and y > min_coord: # or min y is increased by xcomp on line y=0? ... dP, dP, dbuff_, dP, dframe = formP(ders2, x, dP, dP, dbuff_, dP, dframe)

dP is renamed to P

Then if signs don't match:

else: if y == rng * 2: # first line of Ps -> P_, P is empty until verticalcomp returns P: P_.append([P, x-1, []]) # empty fork in the first line of _Ps, x-1: delayed P displacement

So that's how you expect an empty fork.

Initialize the pattern:

I, D, Dy, V, Vy, ders2_ = 0, 0, 0, 0, 0, [] # new P initialization

Then update it with p, d, ... current values from the received ders2 arguments.

Then pack the pattern into a list:

P = [(s, I, D, Dy, V, Vy, ders2_)]

and return it: return P, P, buff, P, frame # accumulated within line, P_ is a buffer for conversion to P

Now there is the frist P in dP in vertical_comp, where more are accumulated and eventually read back:

_P, _x, fork = P.popleft()

Where _P is a dP, i.e. ders2 Then in scanp there's also: P.append([P, x, fork_])

So let's see the buffer.

In form_P, if y == rng*2, then elif x < X -200 is never checked.

Yes, Ps are initialized but there is no higher-line _Ps for them to scan yet.

Therefore form_P passes the buffer to another iteration of scan_P.

if y == rng * 2: # first line of Ps -> P_, P is empty until verticalcomp returns P: P_.append([P, x-1, []]) # empty fork in the first line of _Ps, x-1: delayed P displacement elif x < X - 200: # right error margin: >len(forkP[6])? P, buff_, P, frame = scanP(x-1, P, P, buff, P, frame) # scans higher-line Ps for contiguity

While _ix < x ... In case there is a buffer with elements, the oldest (left) items from the buffer are popped, including roots.

Otherwise, if buff is empty and the upper line container of dP is not empty, only 3 elements (not 4) are popped from the container of upper line patterns.

elif P: _P, _x, fork = P.popleft() roots = 0 # number of Ps connected to current _P[(pris, I, D, Dy, V, Vy, ders2)] else:

roots is added manually, "initialized".

That should be a creation of a "root".

Like with the question above, are these conditions guaranteed to be mutually exclusive. I see that the patterns are "displaced" there. If they are not displaced correctly, the conditions won't be mutually exclusive.

I'd give a general suggestion that the conditions which are checked as mutually exclusive should have more guarantees and measures that they really are mutually exclusive.

How are they not? Of course I check that they are exclusive, and displacement is in right order.

So, it's good that you traced the process so far, and everything seems to be correct.

But, form_blob and form_frame are not triggered on a top few lines, so I don't know if they work.

It might be because top margin of raccoon seems to be vertically uniform.

So, I just posted dblobs update with initial line at y == 400, could you test it please?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/boris-kz/CogAlg/issues/10#issuecomment-425597988, or mute the thread https://github.com/notifications/unsubscribe-auth/AWSP2BCqMJUuPodPXddQuaZOg56VSLcOks5ufrlxgaJpZM4W0XYx .

[Twenkid]

IndexError: invalid index to scalar variable. for if _fork_[0][0][4][0] == 1:

Traceback (most recent call last):
  File "frame3.py", line 291, in <module>
    frame_of_blobs = image_to_blobs(image)
  File "frame3.py", line 267, in image_to_blobs
    ders2__, _P_, frame = vertical_comp(ders_, ders2__, _P_, frame)  # vertical pixel comparison
  File "frame3.py", line 93, in vertical_comp
    dP, dP_, dbuff_, _dP_, dframe = form_P(ders2, x, dP, dP_, dbuff_, _dP_, dframe)
  File "frame3.py", line 114, in form_P
    P_, buff_, _P_, frame = scan_P_(x-1, P, P_, buff_, _P_, frame)  # scans higher-line Ps for contiguity
  File "frame3.py", line 156, in scan_P_
    if _fork_[0][0][4][0] == 1:  # _fork roots, see if ini = 1, second [] is a fixed-id _P container
  IndexError: invalid index to scalar variable.

[Twenkid]

The log suggests that fork has only one element and the 4-th element is scalar, not a list, thus it doesn't have an index [0]. I guess it's then not of the type that it was expected?

(<class 'IndexError'>, IndexError('invalid index to scalar variable.',), <traceback object at 0x0000017C93B26548>)
_fork_, _fork_[0]_, _fork_[0][0], _fork[0][0][4]
[[(1,
   812,
   70,
   77,
   436,
   515,
   [(70, 6, 5, 23, 26),
    (70, 5, 14, 28, 26),
    (72, 4, 16, 30, 35),
    (72, 6, 0, 32, 46),
    (73, 6, 1, 37, 47),
    (74, 5, 3, 43, 49),
    (75, 3, 5, 47, 52),
    (76, 3, 8, 45, 55),
    (76, 7, 5, 39, 60),
    (77, 15, 8, 46, 61),
    (77, 10, 12, 66, 58)])]]
[(1,
  812,
  70,
  77,
  436,
  515,
  [(70, 6, 5, 23, 26),
   (70, 5, 14, 28, 26),
   (72, 4, 16, 30, 35),
   (72, 6, 0, 32, 46),
   (73, 6, 1, 37, 47),
   (74, 5, 3, 43, 49),
   (75, 3, 5, 47, 52),
   (76, 3, 8, 45, 55),
   (76, 7, 5, 39, 60),
   (77, 15, 8, 46, 61),
   (77, 10, 12, 66, 58)])]
(1,
 812,
 70,
 77,
 436,
 515,
 [(70, 6, 5, 23, 26),
  (70, 5, 14, 28, 26),
  (72, 4, 16, 30, 35),
  (72, 6, 0, 32, 46),
  (73, 6, 1, 37, 47),
  (74, 5, 3, 43, 49),
  (75, 3, 5, 47, 52),
  (76, 3, 8, 45, 55),
  (76, 7, 5, 39, 60),
  (77, 15, 8, 46, 61),
  (77, 10, 12, 66, 58)])
436

else:     # no x overlap between _P and next P: _P is included in unique blob segment:
            ini = 1
            if y > rng * 2 + 1 + 400:  # beyond 1st line of _fork_ Ps, else: blob segment ini only
                if len(_fork_[0]) == 1:
                    try:                
                      if _fork_[0][0][4][0] == 1:  # _fork roots, see if ini = 1, second [] is a fixed-id _P container
                          _P[0] = form_seg(_P[0], _fork_[0][0], _x)  # _P is added to blob segment at _fork_[0]
                          ini = 0  # no initialization
                    except:
                           import pprint                    
                           import sys
                           print(sys.exc_info())
                           print("_fork_, _fork_[0]_, _fork_[0][0], _fork[0][0][4]")
                           pprint.pprint(_fork_)
                           pprint.pprint(_fork_[0])
                           pprint.pprint(_fork_[0][0])
                           pprint.pprint(_fork_[0][0][4])
                           exit(0)

_fork_[0][0] is that tuple:

S: scalar, L: list, T: tuple
New line means included in:

S, S, S, S, S, L,
                     T                ...  x10
                        S,S,S,S,S     

(1,
 812,
 70,
 77,
 436,
 515,
 [(70, 6, 5, 23, 26),
  (70, 5, 14, 28, 26),
  (72, 4, 16, 30, 35),
  (72, 6, 0, 32, 46),
  (73, 6, 1, 37, 47),
  (74, 5, 3, 43, 49),
  (75, 3, 5, 47, 52),
  (76, 3, 8, 45, 55),
  (76, 7, 5, 39, 60),
  (77, 15, 8, 46, 61),
  (77, 10, 12, 66, 58)])

[boris-kz]

What is x? I guess it is another marginal case, if so just increase the margin to X-250. There is a better way to handle it, but this is not a main concern right now.

On Sat, Sep 29, 2018, 7:10 AM Todor Arnaudov notifications@github.com wrote:

The log suggests that fork has only one element and the 4-th element is scalar, not a list, thus it doesn't have an index [0]. I guess it's then not of the type that it was expected?

(<class 'IndexError'>, IndexError('invalid index to scalar variable.',), <traceback object at 0x0000017C93B26548>) fork, fork[0]_, fork[0][0], _fork[0][0][4] [[(1, 812, 70, 77, 436, 515, [(70, 6, 5, 23, 26), (70, 5, 14, 28, 26), (72, 4, 16, 30, 35), (72, 6, 0, 32, 46), (73, 6, 1, 37, 47), (74, 5, 3, 43, 49), (75, 3, 5, 47, 52), (76, 3, 8, 45, 55), (76, 7, 5, 39, 60), (77, 15, 8, 46, 61), (77, 10, 12, 66, 58)])]] [(1, 812, 70, 77, 436, 515, [(70, 6, 5, 23, 26), (70, 5, 14, 28, 26), (72, 4, 16, 30, 35), (72, 6, 0, 32, 46), (73, 6, 1, 37, 47), (74, 5, 3, 43, 49), (75, 3, 5, 47, 52), (76, 3, 8, 45, 55), (76, 7, 5, 39, 60), (77, 15, 8, 46, 61), (77, 10, 12, 66, 58)])] (1, 812, 70, 77, 436, 515, [(70, 6, 5, 23, 26), (70, 5, 14, 28, 26), (72, 4, 16, 30, 35), (72, 6, 0, 32, 46), (73, 6, 1, 37, 47), (74, 5, 3, 43, 49), (75, 3, 5, 47, 52), (76, 3, 8, 45, 55), (76, 7, 5, 39, 60), (77, 15, 8, 46, 61), (77, 10, 12, 66, 58)]) 436

else: # no x overlap between _P and next P: _P is included in unique blob
segment:
ini = 1
if y > rng * 2 + 1 + 400: # beyond 1st line of *fork* Ps, else: blob
segment ini only
if len(*fork*[0]) == 1:
try:
if *fork*[0][0][4][0] == 1: # _fork roots, see if ini = 1, second [] is a
fixed-id _P container
_P[0] = form_seg(_P[0], *fork*[0][0], _x) #

*P is added to blob segment at fork[0] ini = 0 # no initialization except:
import pprint import sys print(sys.exc_info()) print("fork, fork[0]*,
*fork*[0][0], _fork[0][0][4]")
pprint.pprint(*fork*)
pprint.pprint(*fork*[0])
pprint.pprint(*fork*[0][0])
pprint.pprint(*fork*[0][0][4])
exit(0)

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<https://github.com/boris-kz/CogAlg/issues/10#issuecomment-425636979>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AUAXGXQlc87GEuItX45hIEmXJWaWglbKks5uf1UtgaJpZM4W0XYx>
.

[Twenkid]

x was 811 with the margin 200 x,y: 811 408

With margin 250 (X-250), x,y: 762 414

[boris-kz]

Ok. I guess there are long patterns in that area, you can either increase the margin or initialize fork.

On Sat, Sep 29, 2018, 7:27 AM Todor Arnaudov notifications@github.com wrote:

x was 811 with the margin 200 x,y: 811 408

With margin 250 (X-250), x,y: 762 414

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/boris-kz/CogAlg/issues/10#issuecomment-425637835, or mute the thread https://github.com/notifications/unsubscribe-auth/AUAXGS8pFYwBfc09C9TK1ZRMsfMaiZkCks5uf1krgaJpZM4W0XYx .

[Twenkid]

Margin seems not to help, just the point is moving to the left.

(<class 'IndexError'>, IndexError('invalid index to scalar variable.',), <traceback object at 0x00000226DECDEA08>)
margin, x,y; _fork_, _fork_[0]_, _fork_[0][0], _fork[0][0][4]
500 519 411
[[(1,
   529,
   138,
   111,
   1015,
   1162,
   [(127, 31, 32, 194, 272),
    (125, 56, 27, 221, 275),
    (133, 43, 31, 294, 289),
    (144, 8, 21, 306, 326)])]]
[(1,
  529,
  138,
  111,
  1015,
  1162,
  [(127, 31, 32, 194, 272),
   (125, 56, 27, 221, 275),
   (133, 43, 31, 294, 289),
   (144, 8, 21, 306, 326)])]
(1,
 529,
 138,
 111,
 1015,
 1162,
 [(127, 31, 32, 194, 272),
  (125, 56, 27, 221, 275),
  (133, 43, 31, 294, 289),
  (144, 8, 21, 306, 326)])
1015
(<class 'IndexError'>, IndexError('invalid index to scalar variable.',), <traceback object at 0x0000018E93DD0EC8>)
margin, x,y; _fork_, _fork_[0]_, _fork_[0][0], _fork[0][0][4]
600 418 409
[[(0,
   687,
   -973,
   -811,
   -831,
   207,
   [(179, -132, -12, 94, 364),
    (185, -244, -156, -84, 181),
    (152, -262, -198, -230, 25),
    (107, -234, -224, -245, -125),
    (64, -101, -221, -366, -238)])]]
[(0,
  687,
  -973,
  -811,
  -831,
  207,
  [(179, -132, -12, 94, 364),
   (185, -244, -156, -84, 181),
   (152, -262, -198, -230, 25),
   (107, -234, -224, -245, -125),
   (64, -101, -221, -366, -238)])]
(0,
 687,
 -973,
 -811,
 -831,
 207,
 [(179, -132, -12, 94, 364),
  (185, -244, -156, -84, 181),
  (152, -262, -198, -230, 25),
  (107, -234, -224, -245, -125),
  (64, -101, -221, -366, -238)])
-831

D:\Py\cog>python frame3.py
(<class 'IndexError'>, IndexError('invalid index to scalar variable.',), <traceback object at 0x0000021A6FC92CC8>)
margin, x,y; _fork_, _fork_[0]_, _fork_[0][0], _fork[0][0][4]
800 219 408
[[(0,
   365,
   -434,
   -465,
   -583,
   -331,
   [(89, -42, 38, -94, 91),
    (118, -178, -181, -165, -31),
    (96, -163, -215, -150, -187),
    (62, -51, -107, -174, -204)])]]
[(0,
  365,
  -434,
  -465,
  -583,
  -331,
  [(89, -42, 38, -94, 91),
   (118, -178, -181, -165, -31),
   (96, -163, -215, -150, -187),
   (62, -51, -107, -174, -204)])]
(0,
 365,
 -434,
 -465,
 -583,
 -331,
 [(89, -42, 38, -94, 91),
  (118, -178, -181, -165, -31),
  (96, -163, -215, -150, -187),
  (62, -51, -107, -174, -204)])
-583

[Twenkid]

margin = 1000 as well :)

(<class 'IndexError'>, IndexError('invalid index to scalar variable.',), <traceback object at 0x000001BC7128CE08>)
margin, x,y; _fork_, _fork_[0]_, _fork_[0][0], _fork[0][0][4]
1000 20 407
[[(1,
   511,
   554,
   475,
   161,
   476,
   [(61, 23, -13, -95, 26),
    (60, 84, 65, -158, -6),
    (63, 152, 137, -133, -20),
    (79, 165, 169, 19, 30),
    (109, 105, 114, 219, 163),
    (139, 25, 3, 309, 283)])]]
[(1,
  511,
  554,
  475,
  161,
  476,
  [(61, 23, -13, -95, 26),
   (60, 84, 65, -158, -6),
   (63, 152, 137, -133, -20),
   (79, 165, 169, 19, 30),
   (109, 105, 114, 219, 163),
   (139, 25, 3, 309, 283)])]
(1,
 511,
 554,
 475,
 161,
 476,
 [(61, 23, -13, -95, 26),
  (60, 84, 65, -158, -6),
  (63, 152, 137, -133, -20),
  (79, 165, 169, 19, 30),
  (109, 105, 114, 219, 163),
  (139, 25, 3, 309, 283)])
161

[Twenkid]

How exactly to initialize it? With just fork_ = [] as in the top of the function,

 if _x > ix:  # x overlap between _P and next P: _P is buffered for next scan_P_
            buff_.append([_P, _x, _fork_, roots])
        else:     # no x overlap between _P and next P: _P is included in unique blob segment:
            ini = 1
            if y > rng * 2 + 1 + 400:  # beyond 1st line of _fork_ Ps, else: blob segment ini only
                if len(_fork_[0]) == 1:
                    fork_ = [] 

Then it encounters:

    if len(_fork_[0]) == 1:
IndexError: list index out of range

Accessing a missing index.

[boris-kz]

No, where seg is initialized, in If ini == 1, add extended syntax to fork. I think.. Sorry, I am on a cell phone.

On Sat, Sep 29, 2018, 7:56 AM Todor Arnaudov notifications@github.com wrote:

How exactly to initialize it? With just fork_ = [] as in the top of the function,

if _x > ix: # x overlap between P and next P: P is buffered for next scan_P buff.append([_P, _x, fork, roots]) else: # no x overlap between _P and next P:

P is included in unique blob segment: ini = 1 if y > rng 2 + 1 + 400: # beyond 1st line of fork Ps, else: blob segment ini only if len(fork[0]) == 1: fork* = []

Then it encounters:

if len(fork[0]) == 1:

IndexError: list index out of range

Accessing a missing index.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/boris-kz/CogAlg/issues/10#issuecomment-425639382, or mute the thread https://github.com/notifications/unsubscribe-auth/AUAXGb7SHl-291N3czA0QThGt9FzRUYiks5uf1_1gaJpZM4W0XYx .

[Twenkid]

On Sat, Sep 29, 2018 at 3:36 PM Boris Kazachenko notifications@github.com wrote:

No, where seg is initialized, in If ini == 1

This:

if ini == 1: # blob segment [P, Py, ave_x, Dx, root, fork] is initialized by not-included _P at its id: ave_x = _x - len(_P[0][6]) // 2 _P[0] = [_P[0], [_P[0]], ave_x, 0, [roots, [], (0,0,0,0,0,0,0,ave_x,0,0)], fork] # replacing fork[len(fork)] = _P[0]

, add extended syntax to fork.

What does it mean?

On Sat, Sep 29, 2018, 7:56 AM Todor Arnaudov notifications@github.com wrote:

How exactly to initialize it? With just fork_ = [] as in the top of the function,

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/boris-kz/CogAlg/issues/10#issuecomment-425639382, or mute the thread < https://github.com/notifications/unsubscribe-auth/AUAXGb7SHl-291N3czA0QThGt9FzRUYiks5uf1_1gaJpZM4W0XYx

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/boris-kz/CogAlg/issues/10#issuecomment-425641719, or mute the thread https://github.com/notifications/unsubscribe-auth/AWSP2KzjVXX33mjiUB_I6kRLQHd_6p3Hks5uf2k5gaJpZM4W0XYx .

[boris-kz]

So, what happens here is that fork[0] is a P, not a seg.

P hasn't been replaced by seg by scanP because that P was within error margin on a prior line.

That's why error is shifting left when you increase error margin: it applies to prior line too.

So, I got rid of error margin and added scanP for incomplete Ps at x = X-1, at the end of form_P.

But I still got that error at y==410 and x==1021: _P[0] is P instead of seg.

Same on y==415 and probably on deeper lines too.

Which is the only time I had roots = 0 and form_blobs got triggered. It's giving me some errors, still working it out.

But this is not significant, these are marginal cases, I can just add try-except-break.

More problematically, roots == 1 -> form_seg is still triggered only couple times at the start of each line,

and roots == 0 -> form_blob only for incomplete (marginal) Ps, this is some kind of a bug.

On Sat, Sep 29, 2018 at 1:00 PM Todor Arnaudov notifications@github.com wrote:

On Sat, Sep 29, 2018 at 3:36 PM Boris Kazachenko <notifications@github.com

wrote:

No, where seg is initialized, in If ini == 1

This:

if ini == 1: # blob segment [P, Py, ave_x, Dx, root, fork] is initialized by not-included _P at its id: ave_x = _x - len(_P[0][6]) // 2 _P[0] = [_P[0], [_P[0]], ave_x, 0, [roots, [], (0,0,0,0,0,0,0,ave_x,0,0)], fork] # replacing fork[len(fork)] = _P[0]

, add extended syntax to fork.

What does it mean?

On Sat, Sep 29, 2018, 7:56 AM Todor Arnaudov notifications@github.com wrote:

How exactly to initialize it? With just fork_ = [] as in the top of the function,

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/boris-kz/CogAlg/issues/10#issuecomment-425639382, or mute the thread <

https://github.com/notifications/unsubscribe-auth/AUAXGb7SHl-291N3czA0QThGt9FzRUYiks5uf1_1gaJpZM4W0XYx

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/boris-kz/CogAlg/issues/10#issuecomment-425641719, or mute the thread < https://github.com/notifications/unsubscribe-auth/AWSP2KzjVXX33mjiUB_I6kRLQHd_6p3Hks5uf2k5gaJpZM4W0XYx

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/boris-kz/CogAlg/issues/10#issuecomment-425659872, or mute the thread https://github.com/notifications/unsubscribe-auth/AUAXGaJfoKKFhAyaB2ykWcyl_Mby5Je8ks5uf6ckgaJpZM4W0XYx .

[boris-kz]

So, fixed a few bugs and added explicit L = len(ders2_) in each P, for clarity and consistency Then noticed that L is always n ders2 -1. What's going on here? This might be related to the fact that roots and len(fork) is always > 0.

On Sat, Sep 29, 2018 at 8:49 PM Boris Kazachenko boris.kz@gmail.com wrote:

So, what happens here is that fork[0] is a P, not a seg.

P hasn't been replaced by seg by scanP because that P was within error margin on a prior line.

That's why error is shifting left when you increase error margin: it applies to prior line too.

So, I got rid of error margin and added scanP for incomplete Ps at x = X-1, at the end of form_P.

But I still got that error at y==410 and x==1021: _P[0] is P instead of seg.

Same on y==415 and probably on deeper lines too.

Which is the only time I had roots = 0 and form_blobs got triggered. It's giving me some errors, still working it out.

But this is not significant, these are marginal cases, I can just add try-except-break.

More problematically, roots == 1 -> form_seg is still triggered only couple times at the start of each line,

and roots == 0 -> form_blob only for incomplete (marginal) Ps, this is some kind of a bug.

On Sat, Sep 29, 2018 at 1:00 PM Todor Arnaudov notifications@github.com wrote:

On Sat, Sep 29, 2018 at 3:36 PM Boris Kazachenko < notifications@github.com> wrote:

No, where seg is initialized, in If ini == 1

This:

if ini == 1: # blob segment [P, Py, ave_x, Dx, root, fork] is initialized by not-included _P at its id: ave_x = _x - len(_P[0][6]) // 2 _P[0] = [_P[0], [_P[0]], ave_x, 0, [roots, [], (0,0,0,0,0,0,0,ave_x,0,0)], fork] # replacing fork[len(fork)] = _P[0]

, add extended syntax to fork.

What does it mean?

On Sat, Sep 29, 2018, 7:56 AM Todor Arnaudov notifications@github.com wrote:

How exactly to initialize it? With just fork_ = [] as in the top of the function,

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://github.com/boris-kz/CogAlg/issues/10#issuecomment-425639382 , or mute the thread <

https://github.com/notifications/unsubscribe-auth/AUAXGb7SHl-291N3czA0QThGt9FzRUYiks5uf1_1gaJpZM4W0XYx

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/boris-kz/CogAlg/issues/10#issuecomment-425641719, or mute the thread < https://github.com/notifications/unsubscribe-auth/AWSP2KzjVXX33mjiUB_I6kRLQHd_6p3Hks5uf2k5gaJpZM4W0XYx

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/boris-kz/CogAlg/issues/10#issuecomment-425659872, or mute the thread https://github.com/notifications/unsubscribe-auth/AUAXGaJfoKKFhAyaB2ykWcyl_Mby5Je8ks5uf6ckgaJpZM4W0XYx .

[Twenkid]

OK. What's "L is always n ders2 -1" ? (As well as "add extended syntax to fork")?

[boris-kz]

(number of ders2s) -1. It should be (number of ders2s) Add syntax: convert P to seg, I did that by including final scanP in form_P

On Sun, Sep 30, 2018 at 4:00 PM Todor Arnaudov notifications@github.com wrote:

OK. What's "L is always n ders2 -1" ? (As well as "add extended the syntax to fork")?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/boris-kz/CogAlg/issues/10#issuecomment-425747375, or mute the thread https://github.com/notifications/unsubscribe-auth/AUAXGeFeDC63iUgEyQymPYQC3S_HlwNMks5ugSLXgaJpZM4W0XYx .

[Twenkid]

And now using average. _P[0] = form_seg(_P[0], _fork_[0][0], _ave_x)

That with the number - 1 - sounds like missing some +1 somewhere, like the first element.

Counting and the border cases are a general issue in software which must be watched.

One must be careful whether it starts from 0 or 1, whether iteration includes the last element or not etc., when the counter is incremented and is it in the right time, also when there's a skip/continue/break that's a possible source for bugs in while-loops due to forgotten or inadequate increment of the counter or comparison of the termination condition.

[Twenkid]

So "add syntax" means a function from the hierarchy in the header to call its neighbour higher level function?

    1Le, line y:    x_comp(p_): lateral pixel comparison -> tuple of derivatives ders ) array ders_
    2Le, line y- 1: y_comp(ders_): vertical pixel comp -> 2D tuple ders2 ) array ders2_ 
    3Le, line y- 1+ rng*2: form_P(ders2) -> 1D pattern P ) P_  
    4Le, line y- 2+ rng*2: scan_P_(P, _P) -> _P, fork_, root_: downward and upward connections between Ps of adjacent lines 
    5Le, line y- 3+ rng*2: form_segment(_P, segment) -> segment: merge vertically-connected Ps into non-forking blob segments
    6Le, line y- 4+ rng*2+ segment depth: term_segment, form_blob -> blob: merge terminated connected segments into blob

[boris-kz]

P[0] starts as P in form_P and is converted to seg in _forks by scanP L = len(ders2), this should not return len(ders2) - 1

On Sun, Sep 30, 2018 at 4:16 PM Todor Arnaudov notifications@github.com wrote:

So "add syntax" means a function from the hierarchy in the header to call its neighbour higher level function?

1Le, line y:    x_comp(p_): lateral pixel comparison -> tuple of derivatives ders ) array ders_
2Le, line y- 1: y_comp(ders_): vertical pixel comp -> 2D tuple ders2 ) array ders2_
3Le, line y- 1+ rng*2: form_P(ders2) -> 1D pattern P ) P_
4Le, line y- 2+ rng*2: scan_P_(P, _P) -> _P, fork_, root_: downward and upward connections between Ps of adjacent lines
5Le, line y- 3+ rng*2: form_segment(_P, segment) -> segment: merge vertically-connected Ps into non-forking blob segments
6Le, line y- 4+ rng*2+ segment depth: term_segment, form_blob -> blob: merge terminated connected segments into blob

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/boris-kz/CogAlg/issues/10#issuecomment-425748535, or mute the thread https://github.com/notifications/unsubscribe-auth/AUAXGSLAs7eq08eksAoMenY3rUR1Fycrks5ugSaVgaJpZM4W0XYx .

[Twenkid]

You mean this old code?:

def form_seg(P, seg, last_x):  # continued or initialized blob segment is incremented by attached _P
    s, I, D, Dy, V, Vy, ders2_ = P  # s is identical, ders2_ is a replacement
    (s, Ls, Is, Ds, Dys, Vs, Vys), Py_, _x, xD, root, fork_ = seg  # fork_ assigned at ini only, roots at form_blob?

    x = last_x - len(ders2_) // 2
    xd = x - _x  # conditional full comp(x) and comp(S): internal vars are secondary?
    xD += xd  # for segment normalization and orientation eval, | += |xd| for curved max_L norm, orient?
    Ls += len(ders2_)  # ders2_ in P buffered in Py_

That now sounds as the Alg has once expected that len(ders2_) was > 0 (1), but it was 0, so Ls+=0 hasn't modified anything.