Assignment by reference may cause overwritten values from aliased copies

[Twenkid]

https://github.com/boris-kz/CogAlg/blob/527a66491b03067cc194795d8e476ed33f417b3c/frame_dblobs.py#L146

I can't run or track it now and don't know if that's the case but that's a common source of bugs. The initial value that is correct may be overwritten by an aliased copy of the same reference by reassignments.

[boris-kz]

I know that, Todor. BTW, you said that variables' id is lost when they are packed into tuples, my tests show otherwise. Do you have any reference?

I just updated:

• got rid of extra list comprehension in hP,
• got rid of top single-element hP[], that was for easy assignment but very confusing,
• replaced seg -> hP assignment with ln171-172 and ln177-178: del(hP[:]) # blob segment [segvars, Py, ave_x, Dx, root, fork] is initialized at not-included hP: hP += _P, [(_P, ave_x, 0)], ave_x, 0, [roots, [], (0,0,0,0,0,0,0,0,0)], fork # also replaces fork[len(fork)]

It runs, but fork is still always > 0, and roots (fork[0][4][0]) always

1

On Tue, Oct 9, 2018 at 12:19 AM Todor Arnaudov notifications@github.com wrote:

https://github.com/boris-kz/CogAlg/blob/527a66491b03067cc194795d8e476ed33f417b3c/frame_dblobs.py#L146

I can't run or track it now and don't know if that's the case but that's a common source of bugs. The initial value that is correct may be overwritten by an aliased copy of the same reference by reassignments.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/boris-kz/CogAlg/issues/14, or mute the thread https://github.com/notifications/unsubscribe-auth/AUAXGbftHhMliqrI7JLldDl1JVQn8IXwks5ujCPhgaJpZM4XQktA .

[Twenkid]

I think I've made some test showing something like that, but it's too deep in the discussions, I don't know. Tuples are immutable, while their originally referenced components are mutable, which is perverse IMO.

L = [1,2,3] x = 44 y = 99 t = (L,x,y) id(t) 2605355037320 id(x) 1960491136 a,x1,y1 = t id(x1) 1960491136 #The same x=567 #Assigned a new value - becomes a new variable id(x) 2605355069200 #new id a,x2,y2 = t x2 33 id(x2) 1960491136 #The old one remains in the tuple

[Twenkid]

I wrote some code to track ids and see these forks.

https://github.com/Twenkid/CogAlg/blob/master/frame_dblobs_track.py

You said it run, but in my setup it breaks at:

After about 6800 logged forks (different branches hit):

python f3.py
too many values to unpack (expected 7)
<class 'ValueError'>
too many values to unpack (expected 7)
  File "f3.py", line 264, in scan_P_
    hP, frame = form_blob(hP, frame)  # blob (all connected blob segments) += blob segment at hP
  File "f3.py", line 309, in form_blob
    (s, Ls, Is, Ds, Dys, Vs, Vys), Py_, x, xd, root, fork_ = seg  # s, root are ignored
ForkLog 6768

The last logged line is that branch:

6767: if roots == 0 id=2109825995208,x=1024,_x=1019, y=410 fork=#>0#

That's out of bounds (1023)?

...

Two logs:

http://twenkid.com/cog/

Of the _fork_at the respective branches in scan_P_, one file with the content of the forks, one which only shows if they're empty [] or #>0#.

The simplest way to track how given fork grows is by a code editor such as Notepad++, also a browser, select a number or Ctrl+F and it will mark the other lines with it.

As can be seen from the log with the contents (big file), the fork content grows rapidly after the period of [].

I may write something that shows all occasions of each unique id.

[boris-kz]

Thanks, I thought "if len(hP) == 6" would prevent these marginal cases, but the len mismatch was actually in the first tuple of hP. I fixed it in new update. Still, there is a bug that seems to increment roots and fork somewhere outside of scanP. I have cases with roots == 1 at y==5 but not greater. Which is weird because y shouldn't matter, roots are initialized at 0 on each line, in ln188.

I will look into tracking, but right now I am focused on basic principles, mainly how to define projected match through its ratios.

On Thu, Oct 11, 2018 at 7:37 AM Todor Arnaudov notifications@github.com wrote:

I wrote some code to track ids and see these forks.

https://github.com/Twenkid/CogAlg/blob/master/frame_dblobs_track.py

You said it runs, but in my setup it breaks at:

After about 6800 logged forks (different branches hit):

python f3.py too many values to unpack (expected 7) <class 'ValueError'> too many values to unpack (expected 7) File "f3.py", line 264, in scanP hP, frame = form_blob(hP, frame) # blob (all connected blob segments) += blob segment at hP File "f3.py", line 309, in formblob (s, Ls, Is, Ds, Dys, Vs, Vys), Py, x, xd, root, fork_ = seg # s, root are ignored ForkLog 6768

The last logged line is that branch:

6767: if roots == 0 id=2109825995208,x=1024,_x=1019, y=410 fork=#>0#

That's out of bounds (1023)?

...

Two logs:

http://twenkid.com/cog/

Of the _fork_at the respective branches in scanP, one file with the content of the forks, one which only shows if they're empty [] or #>0#.

The simplest way to track how given fork grows is by a code editor such as Notepad++, also a browser, select a number or Ctrl+F and it will mark the other lines with it.

As can be seen from the log with the contents (big file), the fork content grows rapidly after the period of [].

I may write something that shows all occasions of each unique id.

[image: f1] https://user-images.githubusercontent.com/23367640/46800644-02f60700-cd61-11e8-9c04-e9dcfc9dc2e6.png [image: f2] https://user-images.githubusercontent.com/23367640/46800646-02f60700-cd61-11e8-9950-c03da66215a7.png [image: f3] https://user-images.githubusercontent.com/23367640/46800812-844d9980-cd61-11e8-812f-128f9178bf14.png

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

[Twenkid]

OK, I'll continue the tracking line so that it gets located. It'a good hint that it happens abruptly after y=5, that's supposed to be 2*rng+1 (I remember it changed accordingly with changing rng in a previous debug session), thus that is the beginning of a new range, after the "containers" are not empty anymore.

It "smells" like it's something about a list or something being not empty or non zero so maybe about some initialization before scan_p which is changed after a complete rng (now talking without referring to specific code).

На чт, 11.10.2018 г., 16:19 Boris Kazachenko notifications@github.com написа:

Thanks, I thought "if len(hP) == 6" would prevent these marginal cases, but the len mismatch was actually in the first tuple of hP. I fixed it in new update. Still, there is a bug that seems to increment roots and fork somewhere outside of scanP. I have cases with roots == 1 at y==5 but not greater. Which is weird because y shouldn't matter, roots are initialized at 0 on each line, in ln188.

I will look into tracking, but right now I am focused on basic principles, mainly how to define projected match through its ratios.

On Thu, Oct 11, 2018 at 7:37 AM Todor Arnaudov notifications@github.com wrote:

I wrote some code to track ids and see these forks.

https://github.com/Twenkid/CogAlg/blob/master/frame_dblobs_track.py

You said it runs, but in my setup it breaks at:

After about 6800 logged forks (different branches hit):

python f3.py too many values to unpack (expected 7) <class 'ValueError'> too many values to unpack (expected 7) File "f3.py", line 264, in scanP hP, frame = form_blob(hP, frame) # blob (all connected blob segments) += blob segment at hP File "f3.py", line 309, in formblob (s, Ls, Is, Ds, Dys, Vs, Vys), Py, x, xd, root, fork_ = seg # s, root are ignored ForkLog 6768

The last logged line is that branch:

6767: if roots == 0 id=2109825995208,x=1024,_x=1019, y=410 fork=#>0#

That's out of bounds (1023)?

...

Two logs:

http://twenkid.com/cog/

Of the _fork_at the respective branches in scanP, one file with the content of the forks, one which only shows if they're empty [] or #>0#.

The simplest way to track how given fork grows is by a code editor such as Notepad++, also a browser, select a number or Ctrl+F and it will mark the other lines with it.

As can be seen from the log with the contents (big file), the fork content grows rapidly after the period of [].

I may write something that shows all occasions of each unique id.

[image: f1] < https://user-images.githubusercontent.com/23367640/46800644-02f60700-cd61-11e8-9c04-e9dcfc9dc2e6.png

[image: f2] < https://user-images.githubusercontent.com/23367640/46800646-02f60700-cd61-11e8-9950-c03da66215a7.png

[image: f3] < https://user-images.githubusercontent.com/23367640/46800812-844d9980-cd61-11e8-812f-128f9178bf14.png

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

.

— 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/14#issuecomment-428951924, or mute the thread https://github.com/notifications/unsubscribe-auth/AWSP2ET7A3D_SjrKTNgJyyZ-ppwOED7lks5uj0VGgaJpZM4XQktA .

[boris-kz]

Not abruptly, y==5 is the first line for scanP, with initialized P. But it shouldn't matter for roots, they are always initialized in new P_.

On Thu, Oct 11, 2018, 10:52 AM Todor Arnaudov notifications@github.com wrote:

OK, I'll continue the tracking line so that it gets located. It'a good hint that it happens abruptly after y=5, that's supposed to be 2*rng+1 (I remember it changed accordingly with changing rng in a previous debug session), thus that is the beginning of a new range, after the "containers" are not empty anymore.

It "smells" like it's something about a list or something being not empty or non zero so maybe about some initialization before scan_p which is changed after a complete rng (now talking without referring to specific code).

На чт, 11.10.2018 г., 16:19 Boris Kazachenko notifications@github.com написа:

Thanks, I thought "if len(hP) == 6" would prevent these marginal cases, but the len mismatch was actually in the first tuple of hP. I fixed it in new update. Still, there is a bug that seems to increment roots and fork somewhere outside of scanP. I have cases with roots == 1 at y==5 but not greater. Which is weird because y shouldn't matter, roots are initialized at 0 on each line, in ln188.

I will look into tracking, but right now I am focused on basic principles, mainly how to define projected match through its ratios.

On Thu, Oct 11, 2018 at 7:37 AM Todor Arnaudov <notifications@github.com

wrote:

I wrote some code to track ids and see these forks.

https://github.com/Twenkid/CogAlg/blob/master/frame_dblobs_track.py

You said it runs, but in my setup it breaks at:

After about 6800 logged forks (different branches hit):

python f3.py too many values to unpack (expected 7) <class 'ValueError'> too many values to unpack (expected 7) File "f3.py", line 264, in scanP hP, frame = form_blob(hP, frame) # blob (all connected blob segments) += blob segment at hP File "f3.py", line 309, in formblob (s, Ls, Is, Ds, Dys, Vs, Vys), Py, x, xd, root, fork_ = seg # s, root are ignored ForkLog 6768

The last logged line is that branch:

6767: if roots == 0 id=2109825995208,x=1024,_x=1019, y=410 fork=#>0#

That's out of bounds (1023)?

...

Two logs:

http://twenkid.com/cog/

Of the _fork_at the respective branches in scanP, one file with the content of the forks, one which only shows if they're empty [] or #>0#.

The simplest way to track how given fork grows is by a code editor such as Notepad++, also a browser, select a number or Ctrl+F and it will mark the other lines with it.

As can be seen from the log with the contents (big file), the fork content grows rapidly after the period of [].

I may write something that shows all occasions of each unique id.

[image: f1] <

https://user-images.githubusercontent.com/23367640/46800644-02f60700-cd61-11e8-9c04-e9dcfc9dc2e6.png

[image: f2] <

https://user-images.githubusercontent.com/23367640/46800646-02f60700-cd61-11e8-9950-c03da66215a7.png

[image: f3] <

https://user-images.githubusercontent.com/23367640/46800812-844d9980-cd61-11e8-812f-128f9178bf14.png

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

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

.

— 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/14#issuecomment-428951924, or mute the thread < https://github.com/notifications/unsubscribe-auth/AWSP2ET7A3D_SjrKTNgJyyZ-ppwOED7lks5uj0VGgaJpZM4XQktA

.

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

[boris-kz]

The only difference is that at y==5 scan_P gets P from form_P, and at y>5 it gets it from prior line of scan_P_s.

On Thu, Oct 11, 2018, 12:19 PM Boris Kazachenko boris.kz@gmail.com wrote:

Not abruptly, y==5 is the first line for scanP, with initialized P. But it shouldn't matter for roots, they are always initialized in new P_.

On Thu, Oct 11, 2018, 10:52 AM Todor Arnaudov notifications@github.com wrote:

OK, I'll continue the tracking line so that it gets located. It'a good hint that it happens abruptly after y=5, that's supposed to be 2*rng+1 (I remember it changed accordingly with changing rng in a previous debug session), thus that is the beginning of a new range, after the "containers" are not empty anymore.

It "smells" like it's something about a list or something being not empty or non zero so maybe about some initialization before scan_p which is changed after a complete rng (now talking without referring to specific code).

На чт, 11.10.2018 г., 16:19 Boris Kazachenko notifications@github.com написа:

Thanks, I thought "if len(hP) == 6" would prevent these marginal cases, but the len mismatch was actually in the first tuple of hP. I fixed it in new update. Still, there is a bug that seems to increment roots and fork somewhere outside of scanP. I have cases with roots == 1 at y==5 but not greater. Which is weird because y shouldn't matter, roots are initialized at 0 on each line, in ln188.

I will look into tracking, but right now I am focused on basic principles, mainly how to define projected match through its ratios.

On Thu, Oct 11, 2018 at 7:37 AM Todor Arnaudov < notifications@github.com> wrote:

I wrote some code to track ids and see these forks.

https://github.com/Twenkid/CogAlg/blob/master/frame_dblobs_track.py

You said it runs, but in my setup it breaks at:

After about 6800 logged forks (different branches hit):

python f3.py too many values to unpack (expected 7) <class 'ValueError'> too many values to unpack (expected 7) File "f3.py", line 264, in scanP hP, frame = form_blob(hP, frame) # blob (all connected blob segments) += blob segment at hP File "f3.py", line 309, in formblob (s, Ls, Is, Ds, Dys, Vs, Vys), Py, x, xd, root, fork_ = seg # s, root are ignored ForkLog 6768

The last logged line is that branch:

6767: if roots == 0 id=2109825995208,x=1024,_x=1019, y=410 fork=#>0#

That's out of bounds (1023)?

...

Two logs:

http://twenkid.com/cog/

Of the _fork_at the respective branches in scanP, one file with the content of the forks, one which only shows if they're empty [] or

>0#.

The simplest way to track how given fork grows is by a code editor such as Notepad++, also a browser, select a number or Ctrl+F and it will mark the other lines with it.

As can be seen from the log with the contents (big file), the fork content grows rapidly after the period of [].

I may write something that shows all occasions of each unique id.

[image: f1] <

https://user-images.githubusercontent.com/23367640/46800644-02f60700-cd61-11e8-9c04-e9dcfc9dc2e6.png

[image: f2] <

https://user-images.githubusercontent.com/23367640/46800646-02f60700-cd61-11e8-9950-c03da66215a7.png

[image: f3] <

https://user-images.githubusercontent.com/23367640/46800812-844d9980-cd61-11e8-812f-128f9178bf14.png

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

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

.

— 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/14#issuecomment-428951924, or mute the thread < https://github.com/notifications/unsubscribe-auth/AWSP2ET7A3D_SjrKTNgJyyZ-ppwOED7lks5uj0VGgaJpZM4XQktA

.

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

[Twenkid]

Well, in my new run with tracking I see cases with roots == 1 in bigger line numbers.

18: if P[0]==_P[0] roots+=1; fork_id=2406943766152,  _fork_=[], roots=1, id_roots=1960490112,  x=22,_x=20, y=405
173: BEFORE P_.append([P, x, fork_, 0]: ; fork_id=2406943836744,  _fork_=[], roots=1, id_roots=1960490112,  x=151,_x=159, y=405
117507: if P[0]==_P[0] roots+=1; fork_id=2407009875080,  _fork_=#>0#, roots=1, id_roots=1960490112,  x=809,_x=805, y=474

See fork3_exc files in the /cog link shared above.

The program breaks after an exception of list index out of range regarding seg in form_blob.

Traceback (most recent call last):
  File "f4.py", line 332, in <module>
    frame_of_blobs = image_to_blobs(image)
  File "f4.py", line 308, in image_to_blobs
    ders2__, _P_, frame = vertical_comp(ders_, ders2__, _P_, frame)  # vertical pixel comparison
  File "f4.py", line 102, in vertical_comp
    dP, dP_, dbuff_, _dP_, dframe = form_P(ders2, x, dP, dP_, dbuff_, _dP_, dframe)
  File "f4.py", line 133, in form_P
    P_, buff_, hP_, frame = scan_P_(x - 1, P, P_, buff_, hP_, frame)  # scans higher-line Ps for contiguity
  File "f4.py", line 204, in scan_P_
    hP, frame = form_blob(hP, frame)  # blob (all connected blob segments) += blob segment at hP
  File "f4.py", line 236, in form_blob
    _roots, _root_, _blob = _seg[4]  # if len(seg[0]) == 6, or all displaced forks, if any?
IndexError: list index out of range

Traceback (most recent call last):
  File "f4.py", line 334, in <module>
    frame_of_blobs = image_to_blobs(image)
  File "f4.py", line 310, in image_to_blobs
    ders2__, _P_, frame = vertical_comp(ders_, ders2__, _P_, frame)  # vertical pixel comparison
  File "f4.py", line 102, in vertical_comp
    dP, dP_, dbuff_, _dP_, dframe = form_P(ders2, x, dP, dP_, dbuff_, _dP_, dframe)
  File "f4.py", line 133, in form_P
    P_, buff_, hP_, frame = scan_P_(x - 1, P, P_, buff_, hP_, frame)  # scans higher-line Ps for contiguity
  File "f4.py", line 204, in scan_P_
    hP, frame = form_blob(hP, frame)  # blob (all connected blob segments) += blob segment at hP
  File "f4.py", line 253, in form_blob
    if len(_seg[5]):  # _fork_
IndexError: list index out of range

That "+400" magic number is not recommended style, use a constant.

Your code is generic and it shouldn't cause such bugs, but If you're still using an obsolete Py, please upgrade.

[Twenkid]

These are the last lines regarding fork and roots in scan_P before the exception:

249568: if P[0]==_P[0] roots+=1 fork_id=1834914676232   _fork_=#>0# roots=0 id_roots=1960490080 x=998   x=1004  y=549
249569: BEFORE P_.append([P, x, fork_, 0]:  fork_id=1834914676232   _fork_=#>0# roots=1 id_roots=1960490112 x=998   x=1004  y=549
249570: if _buff_   fork_id=1834914675656   _fork_=#>0# roots=2 id_roots=1960490144 x=1000  x=998   y=549
249571: if y > rng * 2 + 1 + 400:   fork_id=1834914675656   _fork_=#>0# roots=2 id_roots=1960490144 x=1000  x=998   y=549
249572: if _buff_   fork_id=1834914675848   _fork_=#>0# roots=1 id_roots=1960490112 x=1000  x=1000  y=549
249573: if P[0]==_P[0] roots+=1 fork_id=1834914675848   _fork_=#>0# roots=1 id_roots=1960490112 x=1000  x=1000  y=549
249574: if _buff_   fork_id=1834914676232   _fork_=#>0# roots=1 id_roots=1960490112 x=1000  x=1004  y=549
249575: elif hP_    fork_id=1834914676616   _fork_=#>0# roots=0 id_roots=1960490080 x=1000  x=1007  y=549
249576: if P[0]==_P[0] roots+=1 fork_id=1834914676616   _fork_=#>0# roots=0 id_roots=1960490080 x=1000  x=1007  y=549
249577: BEFORE P_.append([P, x, fork_, 0]:  fork_id=1834914676616   _fork_=#>0# roots=1 id_roots=1960490112 x=1000  x=1007  y=549
249578: if _buff_   fork_id=1834914675848   _fork_=#>0# roots=2 id_roots=1960490144 x=1003  x=1000  y=549
249579: if y > rng * 2 + 1 + 400:   fork_id=1834914675848   _fork_=#>0# roots=2 id_roots=1960490144 x=1003  x=1000  y=549
249580: if _buff_   fork_id=1834914676232   _fork_=#>0# roots=1 id_roots=1960490112 x=1003  x=1004  y=549
249581: if P[0]==_P[0] roots+=1 fork_id=1834914676232   _fork_=#>0# roots=1 id_roots=1960490112 x=1003  x=1004  y=549
249582: if _buff_   fork_id=1834914676616   _fork_=#>0# roots=1 id_roots=1960490112 x=1003  x=1007  y=549
249583: BEFORE P_.append([P, x, fork_, 0]:  fork_id=1834914676616   _fork_=#>0# roots=1 id_roots=1960490112 x=1003  x=1007  y=549
249584: if _buff_   fork_id=1834914676232   _fork_=#>0# roots=2 id_roots=1960490144 x=1013  x=1004  y=549
249585: if _buff_   fork_id=1834914676616   _fork_=#>0# roots=1 id_roots=1960490112 x=1013  x=1007  y=549
249586: if P[0]==_P[0] roots+=1 fork_id=1834914676616   _fork_=#>0# roots=1 id_roots=1960490112 x=1013  x=1007  y=549
249587: elif hP_    fork_id=1834914713736   _fork_=#>0# roots=0 id_roots=1960490080 x=1013  x=1010  y=549
249588: elif hP_    fork_id=1834914713992   _fork_=#>0# roots=0 id_roots=1960490080 x=1013  x=1016  y=549
249589: if P[0]==_P[0] roots+=1 fork_id=1834914713992   _fork_=#>0# roots=0 id_roots=1960490080 x=1013  x=1016  y=549
249590: elif hP_    fork_id=1834914714440   _fork_=#>0# roots=0 id_roots=1960490080 x=1013  x=1021  y=549
249591: BEFORE P_.append([P, x, fork_, 0]:  fork_id=1834914714440   _fork_=#>0# roots=0 id_roots=1960490080 x=1013  x=1021  y=549
249592: if _buff_   fork_id=1834914676232   _fork_=#>0# roots=2 id_roots=1960490144 x=1016  x=1004  y=549
249593: if P[0]==_P[0] roots+=1 fork_id=1834914676232   _fork_=#>0# roots=2 id_roots=1960490144 x=1016  x=1004  y=549
249594: if y > rng * 2 + 1 + 400:   fork_id=1834914676232   _fork_=#>0# roots=3 id_roots=1960490176 x=1016  x=1004  y=549
249595: if _buff_   fork_id=1834914676616   _fork_=#>0# roots=2 id_roots=1960490144 x=1016  x=1007  y=549
249596: if y > rng * 2 + 1 + 400:   fork_id=1834914676616   _fork_=#>0# roots=2 id_roots=1960490144 x=1016  x=1007  y=549
249597: BEFORE P_.append([P, x, fork_, 0]:  fork_id=1834914676616   _fork_=#>0# roots=2 id_roots=1960490144 x=1016  x=1007  y=549
249598: if _buff_   fork_id=1834914713736   _fork_=#>0# roots=0 id_roots=1960490080 x=1018  x=1010  y=549
249599: if y > rng * 2 + 1 + 400:   fork_id=1834914713736   _fork_=#>0# roots=0 id_roots=1960490080 x=1018  x=1010  y=549
249600: if roots == 0:  fork_id=1834914713736   _fork_=#>0# roots=0 id_roots=1960490080 x=1018  x=1010  y=549

[boris-kz]

Yes, these are all marginal cases, I don't want to worry about that for now. My main concern is excessive roots and fork, there must be instances of 0 and 1. BTW, I can get all that from pycharm, use watches if that's more convenient.

On Fri, Oct 12, 2018 at 10:56 AM Todor Arnaudov notifications@github.com wrote:

These are the last lines regading fork and roots in scan_P before the exception:

249568: if P[0]==_P[0] roots+=1 fork_id=1834914676232 fork=#>0# roots=0 idroots=1960490080 x=998 x=1004 y=549 249569: BEFORE P.append([P, x, fork_, 0]: fork_id=1834914676232 fork=#>0# roots=1 id_roots=1960490112 x=998 x=1004 y=549 249570: if buff fork_id=1834914675656 fork=#>0# roots=2 id_roots=1960490144 x=1000 x=998 y=549 249571: if y > rng 2 + 1 + 400: fork_id=1834914675656 fork=#>0# roots=2 id_roots=1960490144 x=1000 x=998 y=549 249572: if buff fork_id=1834914675848 fork=#>0# roots=1 id_roots=1960490112 x=1000 x=1000 y=549 249573: if P[0]==_P[0] roots+=1 fork_id=1834914675848 fork=#>0# roots=1 id_roots=1960490112 x=1000 x=1000 y=549 249574: if buff fork_id=1834914676232 fork=#>0# roots=1 idroots=1960490112 x=1000 x=1004 y=549 249575: elif hP fork_id=1834914676616 fork=#>0# roots=0 id_roots=1960490080 x=1000 x=1007 y=549 249576: if P[0]==_P[0] roots+=1 fork_id=1834914676616 fork=#>0# roots=0 idroots=1960490080 x=1000 x=1007 y=549 249577: BEFORE P.append([P, x, fork_, 0]: fork_id=1834914676616 fork=#>0# roots=1 id_roots=1960490112 x=1000 x=1007 y=549 249578: if buff fork_id=1834914675848 fork=#>0# roots=2 id_roots=1960490144 x=1003 x=1000 y=549 249579: if y > rng 2 + 1 + 400: fork_id=1834914675848 fork=#>0# roots=2 id_roots=1960490144 x=1003 x=1000 y=549 249580: if buff fork_id=1834914676232 fork=#>0# roots=1 id_roots=1960490112 x=1003 x=1004 y=549 249581: if P[0]==_P[0] roots+=1 fork_id=1834914676232 fork=#>0# roots=1 id_roots=1960490112 x=1003 x=1004 y=549 249582: if buff fork_id=1834914676616 fork=#>0# roots=1 idroots=1960490112 x=1003 x=1007 y=549 249583: BEFORE P.append([P, x, fork_, 0]: fork_id=1834914676616 fork=#>0# roots=1 id_roots=1960490112 x=1003 x=1007 y=549 249584: if buff fork_id=1834914676232 fork=#>0# roots=2 id_roots=1960490144 x=1013 x=1004 y=549 249585: if buff fork_id=1834914676616 fork=#>0# roots=1 id_roots=1960490112 x=1013 x=1007 y=549 249586: if P[0]==_P[0] roots+=1 fork_id=1834914676616 fork=#>0# roots=1 idroots=1960490112 x=1013 x=1007 y=549 249587: elif hP fork_id=1834914713736 fork=#>0# roots=0 idroots=1960490080 x=1013 x=1010 y=549 249588: elif hP fork_id=1834914713992 fork=#>0# roots=0 id_roots=1960490080 x=1013 x=1016 y=549 249589: if P[0]==_P[0] roots+=1 fork_id=1834914713992 fork=#>0# roots=0 idroots=1960490080 x=1013 x=1016 y=549 249590: elif hP fork_id=1834914714440 fork=#>0# roots=0 idroots=1960490080 x=1013 x=1021 y=549 249591: BEFORE P.append([P, x, fork_, 0]: fork_id=1834914714440 fork=#>0# roots=0 id_roots=1960490080 x=1013 x=1021 y=549 249592: if buff fork_id=1834914676232 fork=#>0# roots=2 id_roots=1960490144 x=1016 x=1004 y=549 249593: if P[0]==_P[0] roots+=1 fork_id=1834914676232 fork=#>0# roots=2 id_roots=1960490144 x=1016 x=1004 y=549 249594: if y > rng 2 + 1 + 400: fork_id=1834914676232 fork=#>0# roots=3 id_roots=1960490176 x=1016 x=1004 y=549 249595: if buff fork_id=1834914676616 fork=#>0# roots=2 id_roots=1960490144 x=1016 x=1007 y=549 249596: if y > rng 2 + 1 + 400: fork_id=1834914676616 fork=#>0# roots=2 idroots=1960490144 x=1016 x=1007 y=549 249597: BEFORE P.append([P, x, fork_, 0]: fork_id=1834914676616 fork=#>0# roots=2 id_roots=1960490144 x=1016 x=1007 y=549 249598: if buff fork_id=1834914713736 fork=#>0# roots=0 id_roots=1960490080 x=1018 x=1010 y=549 249599: if y > rng * 2 + 1 + 400: fork_id=1834914713736 fork=#>0# roots=0 id_roots=1960490080 x=1018 x=1010 y=549 249600: if roots == 0: fork_id=1834914713736 fork=#>0# roots=0 id_roots=1960490080 x=1018 x=1010 y=549

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

[Twenkid]

Excessive roots and fork? Do you mean they must be only 0 and 1 (len = 1)?

As of pycharm - I use it for development, but for getting that data, programmatically is more convenient and is the path towards automatic analysis and gen.reports.

На пт, 12.10.2018 г., 18:12 Boris Kazachenko notifications@github.com написа:

Yes, these are all marginal cases, I don't want to worry about that for now. My main concern is excessive roots and fork, there must be instances of 0 and 1. BTW, I can get all that from pycharm, use watches if that's more convenient.

On Fri, Oct 12, 2018 at 10:56 AM Todor Arnaudov notifications@github.com wrote:

These are the last lines regading fork and roots in scan_P before the exception:

249568: if P[0]==_P[0] roots+=1 fork_id=1834914676232 fork=#>0# roots=0 idroots=1960490080 x=998 x=1004 y=549 249569: BEFORE P.append([P, x, fork_, 0]: fork_id=1834914676232 fork=#>0# roots=1 id_roots=1960490112 x=998 x=1004 y=549 249570: if buff fork_id=1834914675656 fork=#>0# roots=2 id_roots=1960490144 x=1000 x=998 y=549 249571: if y > rng 2 + 1 + 400: fork_id=1834914675656 fork=#>0# roots=2 id_roots=1960490144 x=1000 x=998 y=549 249572: if buff fork_id=1834914675848 fork=#>0# roots=1 id_roots=1960490112 x=1000 x=1000 y=549 249573: if P[0]==_P[0] roots+=1 fork_id=1834914675848 fork=#>0# roots=1 id_roots=1960490112 x=1000 x=1000 y=549 249574: if buff fork_id=1834914676232 fork=#>0# roots=1 idroots=1960490112 x=1000 x=1004 y=549 249575: elif hP fork_id=1834914676616 fork=#>0# roots=0 id_roots=1960490080 x=1000 x=1007 y=549 249576: if P[0]==_P[0] roots+=1 fork_id=1834914676616 fork=#>0# roots=0 idroots=1960490080 x=1000 x=1007 y=549 249577: BEFORE P.append([P, x, fork_, 0]: fork_id=1834914676616 fork=#>0# roots=1 id_roots=1960490112 x=1000 x=1007 y=549 249578: if buff fork_id=1834914675848 fork=#>0# roots=2 id_roots=1960490144 x=1003 x=1000 y=549 249579: if y > rng 2 + 1 + 400: fork_id=1834914675848 fork=#>0# roots=2 id_roots=1960490144 x=1003 x=1000 y=549 249580: if buff fork_id=1834914676232 fork=#>0# roots=1 id_roots=1960490112 x=1003 x=1004 y=549 249581: if P[0]==_P[0] roots+=1 fork_id=1834914676232 fork=#>0# roots=1 id_roots=1960490112 x=1003 x=1004 y=549 249582: if buff fork_id=1834914676616 fork=#>0# roots=1 idroots=1960490112 x=1003 x=1007 y=549 249583: BEFORE P.append([P, x, fork_, 0]: fork_id=1834914676616 fork=#>0# roots=1 id_roots=1960490112 x=1003 x=1007 y=549 249584: if buff fork_id=1834914676232 fork=#>0# roots=2 id_roots=1960490144 x=1013 x=1004 y=549 249585: if buff fork_id=1834914676616 fork=#>0# roots=1 id_roots=1960490112 x=1013 x=1007 y=549 249586: if P[0]==_P[0] roots+=1 fork_id=1834914676616 fork=#>0# roots=1 idroots=1960490112 x=1013 x=1007 y=549 249587: elif hP fork_id=1834914713736 fork=#>0# roots=0 idroots=1960490080 x=1013 x=1010 y=549 249588: elif hP fork_id=1834914713992 fork=#>0# roots=0 id_roots=1960490080 x=1013 x=1016 y=549 249589: if P[0]==_P[0] roots+=1 fork_id=1834914713992 fork=#>0# roots=0 idroots=1960490080 x=1013 x=1016 y=549 249590: elif hP fork_id=1834914714440 fork=#>0# roots=0 idroots=1960490080 x=1013 x=1021 y=549 249591: BEFORE P.append([P, x, fork_, 0]: fork_id=1834914714440 fork=#>0# roots=0 id_roots=1960490080 x=1013 x=1021 y=549 249592: if buff fork_id=1834914676232 fork=#>0# roots=2 id_roots=1960490144 x=1016 x=1004 y=549 249593: if P[0]==_P[0] roots+=1 fork_id=1834914676232 fork=#>0# roots=2 id_roots=1960490144 x=1016 x=1004 y=549 249594: if y > rng 2 + 1 + 400: fork_id=1834914676232 fork=#>0# roots=3 id_roots=1960490176 x=1016 x=1004 y=549 249595: if buff fork_id=1834914676616 fork=#>0# roots=2 id_roots=1960490144 x=1016 x=1007 y=549 249596: if y > rng 2 + 1 + 400: fork_id=1834914676616 fork=#>0# roots=2 idroots=1960490144 x=1016 x=1007 y=549 249597: BEFORE P.append([P, x, fork_, 0]: fork_id=1834914676616 fork=#>0# roots=2 id_roots=1960490144 x=1016 x=1007 y=549 249598: if buff fork_id=1834914713736 fork=#>0# roots=0 id_roots=1960490080 x=1018 x=1010 y=549 249599: if y > rng * 2 + 1 + 400: fork_id=1834914713736 fork=#>0# roots=0 id_roots=1960490080 x=1018 x=1010 y=549 249600: if roots == 0: fork_id=1834914713736 fork=#>0# roots=0 id_roots=1960490080 x=1018 x=1010 y=549

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

.

— 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/14#issuecomment-429359885, or mute the thread https://github.com/notifications/unsubscribe-auth/AWSP2AZ38G_0o96-vG-i1YdUwW7Osmw1ks5ukLFigaJpZM4XQktA .

[boris-kz]

There must be some instances of both. Think about it, you have +/- patterns of one line overlapping +/- patterns of another line. What is the chance that there never is a single pattern that overlaps 1 or 0 same-sign patterns of lower or higher line?

On Fri, Oct 12, 2018, 11:45 AM Todor Arnaudov notifications@github.com wrote:

Excessive roots and fork? Do you mean they must be only 0 and 1 (len = 1)?

As of pycharm - I use it for development, but for getting that data, programmatically is more convenient and is the path towards automatic analysis and gen.reports.

На пт, 12.10.2018 г., 18:12 Boris Kazachenko notifications@github.com написа:

Yes, these are all marginal cases, I don't want to worry about that for now. My main concern is excessive roots and fork, there must be instances of 0 and 1. BTW, I can get all that from pycharm, use watches if that's more convenient.

On Fri, Oct 12, 2018 at 10:56 AM Todor Arnaudov < notifications@github.com> wrote:

These are the last lines regading fork and roots in scan_P before the exception:

249568: if P[0]==_P[0] roots+=1 fork_id=1834914676232 fork=#>0# roots=0 idroots=1960490080 x=998 x=1004 y=549 249569: BEFORE P.append([P, x, fork_, 0]: fork_id=1834914676232 fork=#>0# roots=1 id_roots=1960490112 x=998 x=1004 y=549 249570: if buff fork_id=1834914675656 fork=#>0# roots=2 id_roots=1960490144 x=1000 x=998 y=549 249571: if y > rng 2 + 1 + 400: fork_id=1834914675656 fork=#>0# roots=2 id_roots=1960490144 x=1000 x=998 y=549 249572: if buff fork_id=1834914675848 fork=#>0# roots=1 id_roots=1960490112 x=1000 x=1000 y=549 249573: if P[0]==_P[0] roots+=1 fork_id=1834914675848 fork=#>0# roots=1 id_roots=1960490112 x=1000 x=1000 y=549 249574: if buff fork_id=1834914676232 fork=#>0# roots=1 idroots=1960490112 x=1000 x=1004 y=549 249575: elif hP fork_id=1834914676616 fork=#>0# roots=0 id_roots=1960490080 x=1000 x=1007 y=549 249576: if P[0]==_P[0] roots+=1 fork_id=1834914676616 fork=#>0# roots=0 idroots=1960490080 x=1000 x=1007 y=549 249577: BEFORE P.append([P, x, fork_, 0]: fork_id=1834914676616 fork=#>0# roots=1 id_roots=1960490112 x=1000 x=1007 y=549 249578: if buff fork_id=1834914675848 fork=#>0# roots=2 id_roots=1960490144 x=1003 x=1000 y=549 249579: if y > rng 2 + 1 + 400: fork_id=1834914675848 fork=#>0# roots=2 id_roots=1960490144 x=1003 x=1000 y=549 249580: if buff fork_id=1834914676232 fork=#>0# roots=1 id_roots=1960490112 x=1003 x=1004 y=549 249581: if P[0]==_P[0] roots+=1 fork_id=1834914676232 fork=#>0# roots=1 id_roots=1960490112 x=1003 x=1004 y=549 249582: if buff fork_id=1834914676616 fork=#>0# roots=1 idroots=1960490112 x=1003 x=1007 y=549 249583: BEFORE P.append([P, x, fork_, 0]: fork_id=1834914676616 fork=#>0# roots=1 id_roots=1960490112 x=1003 x=1007 y=549 249584: if buff fork_id=1834914676232 fork=#>0# roots=2 id_roots=1960490144 x=1013 x=1004 y=549 249585: if buff fork_id=1834914676616 fork=#>0# roots=1 id_roots=1960490112 x=1013 x=1007 y=549 249586: if P[0]==_P[0] roots+=1 fork_id=1834914676616 fork=#>0# roots=1 idroots=1960490112 x=1013 x=1007 y=549 249587: elif hP fork_id=1834914713736 fork=#>0# roots=0 idroots=1960490080 x=1013 x=1010 y=549 249588: elif hP fork_id=1834914713992 fork=#>0# roots=0 id_roots=1960490080 x=1013 x=1016 y=549 249589: if P[0]==_P[0] roots+=1 fork_id=1834914713992 fork=#>0# roots=0 idroots=1960490080 x=1013 x=1016 y=549 249590: elif hP fork_id=1834914714440 fork=#>0# roots=0 idroots=1960490080 x=1013 x=1021 y=549 249591: BEFORE P.append([P, x, fork_, 0]: fork_id=1834914714440 fork=#>0# roots=0 id_roots=1960490080 x=1013 x=1021 y=549 249592: if buff fork_id=1834914676232 fork=#>0# roots=2 id_roots=1960490144 x=1016 x=1004 y=549 249593: if P[0]==_P[0] roots+=1 fork_id=1834914676232 fork=#>0# roots=2 id_roots=1960490144 x=1016 x=1004 y=549 249594: if y > rng 2 + 1 + 400: fork_id=1834914676232 fork=#>0# roots=3 id_roots=1960490176 x=1016 x=1004 y=549 249595: if buff fork_id=1834914676616 fork=#>0# roots=2 id_roots=1960490144 x=1016 x=1007 y=549 249596: if y > rng 2 + 1 + 400: fork_id=1834914676616 fork=#>0# roots=2 idroots=1960490144 x=1016 x=1007 y=549 249597: BEFORE P.append([P, x, fork_, 0]: fork_id=1834914676616 fork=#>0# roots=2 id_roots=1960490144 x=1016 x=1007 y=549 249598: if buff fork_id=1834914713736 fork=#>0# roots=0 id_roots=1960490080 x=1018 x=1010 y=549 249599: if y > rng * 2 + 1 + 400: fork_id=1834914713736 fork=#>0# roots=0 id_roots=1960490080 x=1018 x=1010 y=549 249600: if roots == 0: fork_id=1834914713736 fork=#>0# roots=0 id_roots=1960490080 x=1018 x=1010 y=549

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

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

.

— 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/14#issuecomment-429359885, or mute the thread < https://github.com/notifications/unsubscribe-auth/AWSP2AZ38G_0o96-vG-i1YdUwW7Osmw1ks5ukLFigaJpZM4XQktA

.

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

[Twenkid]

Of both, but only a combination 0 and 1, 00, 01, 10, 11. Any bigger number is wrong? If so, you shouldnt use roots+=1 - that is and suggests counting. (Use it if you want to detect double calls)

Better is assignment to 1.

[boris-kz]

No, the number of overlaps is not limited. Yes, roots is a counter. Just try to visualize it.

On Fri, Oct 12, 2018, 12:49 PM Todor Arnaudov notifications@github.com wrote:

Of both, but only a combination 0 and 1, 00, 01, 10, 11. Any bigger number is wrong? If so, you shouldnt use roots+=1 - that is and suggests counting. (Use it if you want to detect double calls)

Better is assignment to 1.

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

[boris-kz]

ScanP is supposed to record roots: instances of (same-x and same-sign) Ps on lower line for each higher-line P, and conversely buffer forks into fork: instances of (same-x and same-sign) _Ps on higher line for each lower-line P.

If +_P is fully x-overlapped by one +P, then its roots==1, If +_P is fully x-overlapped by one -P, then its roots==0

If +P is fully x-overlapped by one +P, then its len(fork)==1, If +P is fully x-overlapped by one -P, then its len(fork)==0,

Etc. Such instances must happen if the converse P | _P overlaps multiple same- or counter- sign P | Ps. So, you can't have instances of roots > 1 without corresponding fork having len == 1 | 0, and conversely.

On Fri, Oct 12, 2018 at 12:52 PM Boris Kazachenko boris.kz@gmail.com wrote:

No, the number of overlaps is not limited. Yes, roots is a counter. Just try to visualize it.

On Fri, Oct 12, 2018, 12:49 PM Todor Arnaudov notifications@github.com wrote:

Of both, but only a combination 0 and 1, 00, 01, 10, 11. Any bigger number is wrong? If so, you shouldnt use roots+=1 - that is and suggests counting. (Use it if you want to detect double calls)

Better is assignment to 1.

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

[Twenkid]

That's a more meaningful explanation than previous requirements, you may pin it somewhere, but I don't see some of the claims in code.

roots+=1 for sign match (either if sign is 0 or 1): if P[0] == _P[0]: So roots == 1 for two -P as well.

That "fully overlapped" isif _x > x - P[1] line, when it's hit, hP goes to buff_, i.e. _P, _x, _fork_, roots.

BTW, I noticed if P[0] == _P[0]: is hit too often. According to statistics I did:

counter, peqp 125083 62418

Half of the cycles while ini_x <= x: are with equal signs thus roots at least 1.

Etc. So, you can't have instances of roots > 1 without corresponding fork_ having len == 1 | 0, and conversely.

That's not clear. What's Etc.?

The latter: fork_ (_fork_?)should be only 1 or 0 (not bigger than 1?) or len ==1 means "not zero". In my log there are "big" len forks = 4,5,6

[boris-kz]

That's a more meaningful explanation than previous requirements,

It's just a partial condition of segment increment or blob termination, which is in the code.

you may pin it somewhere,

Maybe, but I could do that for every line of the code.

but I don't see some of the claims in code.

roots+=1 for sign match (either if sign is 0 or 1): if P[0] == _P[0]: So roots == 1 for two -P as well

How is that a contradiction? I didn't meant to list all possible cases.

That "fully overlapped" isif x > x - P[1] line, when it's hit, hP goes to buff, i.e. _P, _x, fork, roots.

No this is left-side overlap by hP. Full is both left and right.

BTW, I noticed if P[0] == _P[0]: is hit too often. According to statistics I did:

counter, peqp 125083 62418

Half of the cycles while ini_x <= x: are with equal signs thus roots at least 1.

That's how it should be. There are four possibilities: 11, 01, 10, 00. Half of them is equal sign.

Etc. So, you can't have instances of roots > 1 without corresponding fork_ having len == 1 | 0, and conversely.

That's not clear. What's Etc.?

Cases with partial overlap, I can't list them all.

The latter: fork_ (fork?)

fork_ of P becomes fork of _P at the line end, it's contents don't change.

should be only 1 or 0 (not bigger than 1?) or len ==1 means "not zero". In my log there are "big" len forks = 4,5,6

No, len can have any value. What I said is that for each roots | fork > 1, there must be some reciprocal fork | roots == 1 | 0.

[Twenkid]

should be only 1 or 0 (not bigger than 1?) or len ==1 means "not zero". In my log there are "big" len forks = 4,5,6

No, len can have any value. What I said is that for each roots | fork > 1, there must be some reciprocal fork | roots == 1 | 0.

At adjacent previous position, as initial state before the increments?

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/14#issuecomment-429537541, or mute the thread https://github.com/notifications/unsubscribe-auth/AWSP2BrlF5Yip0iaQu02iwaNE4nLIPHwks5ukdsugaJpZM4XQktA .

[boris-kz]

should be only 1 or 0 (not bigger than 1?) or len ==1 means "not zero". In my log there are "big" len forks = 4,5,6

No, len can have any value. What I said is that for each roots | fork > 1, there must be some reciprocal fork | roots == 1 | 0.

At adjacent previous position, as initial state before the increments?

At the same x, after P completes full scan of _P, or vice versa.

[boris-kz]

I meant, after P completes full scan of P, or P completes full scan of P

On Sat, Oct 13, 2018 at 8:41 AM Boris Kazachenko boris.kz@gmail.com wrote:

should be only 1 or 0 (not bigger than 1?) or len ==1 means "not zero". In my log there are "big" len forks = 4,5,6

No, len can have any value. What I said is that for each roots | fork > 1, there must be some reciprocal fork | roots == 1 | 0.

At adjacent previous position, as initial state before the increments?

At the same x, after P completes full scan of _P, or vice versa.

[boris-kz]

I said: for each roots | fork > 1, there must be some reciprocal fork | roots == 1 | 0.

It should be: for each roots | fork > 2, there must be some reciprocal fork | roots == 1 | 0.

On Sat, Oct 13, 2018 at 8:43 AM Boris Kazachenko boris.kz@gmail.com wrote:

I meant, after P completes full scan of P, or P completes full scan of P

On Sat, Oct 13, 2018 at 8:41 AM Boris Kazachenko boris.kz@gmail.com wrote:

should be only 1 or 0 (not bigger than 1?) or len ==1 means "not zero". In my log there are "big" len forks = 4,5,6

No, len can have any value. What I said is that for each roots | fork > 1, there must be some reciprocal fork | roots == 1 | 0.

At adjacent previous position, as initial state before the increments?

At the same x, after P completes full scan of _P, or vice versa.

[Twenkid]

While trying to check what happens during form_blob, I discovered the following:

• It's called 5 times until an exception, but the iteration inside for index, _seg in enumerate(fork_):is never hit until the last one, where seg doesn't have enough elements.
• When that iteration is hit, I tried to see what's inside seg and discovered that it's so huge that it can't be printed, it hangs there and if waited enough it breaks with "Memory Error" as early as the [1] element, only [0] is "normal"

  
  len(_seg)=4
  0
  (0, 1, 117, -2, 13, 196, 242, [(117, -2, 13, 196, 242)])
  1
  1019
  2
  Traceback (most recent call last):
  File "f4.py", line 262, in form_blob
  _roots, _root_, _blob = _seg[4]  # if len(seg[0]) == 6, or all displaced forks, if any?
  IndexError: list index out of range

During handling of the above exception, another exception occurred:

Traceback (most recent call last): File "f4.py", line 385, in frame_of_blobs = image_to_blobs(image) File "f4.py", line 361, in image_to_blobs ders2, P, frame = verticalcomp(ders, ders2, P, frame) # vertical pixel comparison File "f4.py", line 109, in verticalcomp dP, dP, dbuff_, dP, dframe = formP(ders2, x, dP, dP, dbuff_, dP, dframe) File "f4.py", line 147, in formP P, buff, hP, frame = scanP(x - 1, P, P, buff, hP_, frame) # scans higher-line Ps for contiguity File "f4.py", line 228, in scanP hP, frame = form_blob(hP, frame) # blob (all connected blob segments) += blob segment at hP File "f4.py", line 277, in form_blob print(j) MemoryError

[boris-kz]

At this point, form_blob is only hit in marginal error cases, so execution won't be correct anyway. I didn't block in these cases only to check that basic syntax is correct. And it's not complete, see comments after frame = form_frame. As it is now, blob doesn't include segments in indirect roots and fork_s: those mediated by primary roots and fork_s. That will have to be added. Anyway, it won't run for real until non-marginal if roots == 0: That bug needs to be fixed first.

On Sun, Oct 14, 2018 at 2:48 AM Todor Arnaudov notifications@github.com wrote:

While trying to check what happens during form_blob, I discovered the following:

• It's called 5 times until an exception, but the iteration inside for index, seg in enumerate(fork):is never hit until the last one, where seg doesn't have enough elements.
• When that iteration is hit, I tried to see what's inside seg and discovered that it's so huge that it can't be printed, it hangs there and if waited enough it breaks with "Memory Error" as early as the [1] element, only [0] is "normal"

len(_seg)=4 0 (0, 1, 117, -2, 13, 196, 242, [(117, -2, 13, 196, 242)]) 1 1019 2 Traceback (most recent call last): File "f4.py", line 262, in form_blob _roots, root, _blob = _seg[4] # if len(seg[0]) == 6, or all displaced forks, if any? IndexError: list index out of range

During handling of the above exception, another exception occurred:

Traceback (most recent call last): File "f4.py", line 385, in frame_of_blobs = image_to_blobs(image) File "f4.py", line 361, in image_to_blobs ders2, P, frame = verticalcomp(ders, ders2, P, frame) # vertical pixel comparison File "f4.py", line 109, in verticalcomp dP, dP, dbuff_, dP, dframe = formP(ders2, x, dP, dP, dbuff_, dP, dframe) File "f4.py", line 147, in formP P, buff, hP, frame = scanP(x - 1, P, P, buff, hP_, frame) # scans higher-line Ps for contiguity File "f4.py", line 228, in scanP hP, frame = form_blob(hP, frame) # blob (all connected blob segments) += blob segment at hP File "f4.py", line 277, in form_blob print(j) MemoryError

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

[Twenkid]

New tracking, watching roots.

That check: 2473: 271, len(_fork_[0]) == 6:, _fork_[0][4][0](not y) roots=1 id=1960490112 x=123 x=115 _fork_[0][4][0]=3

_fork_[0][4][0] is from 2 to 5

"if _fork_[0][4][0] == 1:" # _fork roots, see if ini = 1, never happens

roots are up to 7.

---

These magic numbers are confusing, that pop-append style is even worse, because it's impossible to always check those_fork_[0][4][0], it doesn't exist most of the time, only after something is pushed somewhere, other is popped.

More stable structures would be easier to debug.

It could be some wrong displaced assignment or it could be correct behavior of the code, but mismatching theory to the implementation.

Can you think of a specific type of input image that would produce exactly the desired patterns?

Test images which can produce completely expected output that confirms the code are desirable.

...

This type of code is particularly error prone:

 if ini == 1:               
                del (hP[:])  # blob segment [Vars, Py_, ave_x, Dx, root, _fork_] is initialized at not-included hP, replacing its fork_ refs
                hP += (_P[0:7]), [(_P, ave_x, 0)], ave_x, 0, [roots, [], (0, 0, 0, 0, 0, 0, 0, 0, 0)], _fork_

[boris-kz]

that pop-append style is even worse, because it's impossible to always check thosefork[0][4][0], it doesn't exist most of the time, only after something is pushed somewhere, other is popped.

It's possible, they still exist in hP_, etc. you just need to unfold vars in pycharm. Or use complex indexing in "watches" tab And there must be the way to trace the same object id between functions.

It could be some wrong displaced assignment or it could be correct behavior

of the code, but mismatching theory to the implementation.

This is not correct, regardless of image. Look at two lines below:

---

---

When one full | empty segment of top line partly overlaps > 2 full + empty segments below, it must fully overlap at least one of them. These fully-overlapped full | empty lower-line segments can overlap only that one top-line segment. Same for the reverse. That would be the cases of 1 | 0 forks or roots per P that I was talking about.

Can you think of a specific type of input image that would produce exactly

the desired patterns?

Test images which can produce completely expected output that confirms the code are desirable....

And unrealistic. Solving toy problems doesn't translate into general learning.

This type of code is particularly error prone:

if ini == 1: del (hP[:]) # blob segment [Vars, Py_, ave_x, Dx, root, fork] is initialized at not-included hP, replacing its fork_ refs hP += (_P[0:7]), [(_P, ave_x, 0)], ave_x, 0, [roots, [], (0, 0, 0, 0, 0, 0, 0, 0, 0)], fork

What is your alternative?

[Twenkid]

I'm unfolding, but it seems that it doesn't always exist and there must be checks for that too. tracker.rootsLog.Add(tracker.Roots("238, _P, _x, _fork_, roots = hP", _fork_[0][4][0], roots, id(roots), x, _x, y)) Code like that failed due to the 0-4-0 anywhere except in the site where it's compared in the deep if.

This is not correct, regardless of image. Look at two lines below:

---

---

Is this image correctly drawn by the code - that's another thing that has to be verified first by checking and possibly drawing the patterns.

And unrealistic. Solving toy problems doesn't translate into general learning.

It's solving the "verification problem", not "toy problem" and not "learning".

What is your alternative?

This alg is for classes with types, either manually or semi-automatically generated by a custom editor, and a custom editor in general.

To me it doesn't make sense using so long tuples (they get unreadable) also with so diverse meaning. Misalignment would be reduced or eliminated and the code will be more readable.

I guess your opinion - "clutter", blah-blah - not always and for other developers the clutter is the current style, if you like it keep it, but it's annoying to get stuck or delayed by bugs just due to hard to read or unclear and not mnemonic code.

E.g. initialization wouldn't be with these unreadable 0,0,0,0,0 but just p = Pattern(). For debugging purposes selected arguments could be altered by identifier p = Pattern(x=230) etc.

I've said that before, but the style of your code is like if it were FORTRAN, not Python.

...

Also, not regarding the tuples, the processing could be split in several passes for clarity, at least until it's debugged and there is output which is verified as "correct" so that a more entangled function's operation could be compared to the correct result.

Now you say "fork and roots should be..." but have you verified that the other variables have all correct values, too?

That could be done via some assertions on the fly (besides the forcible exception ones) or on the collected statistics.

[Twenkid]

BTW, you use that line id(roots) just to check it in the debugger, right?

0: 243, hP_.popleft(), _P, _x, _fork_, roots = hP       fork040=-1      roots=0     id=1960490080       x=9      _x=4       y=405
1: 261, if _x > x - P[1]:(P[1])     fork040=-1      roots=0     id=1960490080       x=9      _x=4       y=6
2: 243, hP_.popleft(), _P, _x, _fork_, roots = hP       fork040=-1      roots=0     id=1960490080       x=9      _x=9       y=405
3: 255, roots+=1        fork040=-1      roots=1     id=1960490112       x=9      _x=9       y=405
4: 261, if _x > x - P[1]:(P[1])     fork040=-1      roots=1     id=1960490112       x=9      _x=9       y=6
5: 243, hP_.popleft(), _P, _x, _fork_, roots = hP       fork040=-1      roots=0     id=1960490080       x=9      _x=14      y=405

I discovered that roots has 4 ids until the exception, they are evident in the first tracking lines and the latest ones. That should be counted programmatically for the general case, but currently it's obvious with a naked eye that they are several.

1960490080 1960490112 1960490144 1960490176

386937: 255, roots+=1       fork040=-1      roots=3     id=1960490176       x=1016       _x=1004        y=549
386938: 264, else...  ini=1     fork040=-1      roots=3     id=1960490176       x=1016       _x=1004        y=549
386939: 267,  seg = form_seg(_P, _fork_[0], ave_x)      fork040=-1      roots=3     id=1960490176       x=1016       _x=1004        y=549
386940: 286, if ini==1, before del hP[:]        fork040=-1      roots=3     id=1960490176       x=1016       _x=1004        y=549
386941: 238, _P, _x, _fork_, roots = hP     fork040=-1      roots=2     id=1960490144       x=1016       _x=1007        y=549
386942: 264, else...  ini=1     fork040=-1      roots=2     id=1960490144       x=1016       _x=1007        y=549
386943: 267,  seg = form_seg(_P, _fork_[0], ave_x)      fork040=-1      roots=2     id=1960490144       x=1016       _x=1007        y=549
386944: 269, if len(_fork_) == 1        fork040=-1      roots=2     id=1960490144       x=1016       _x=1007        y=549
386945: 238, _P, _x, _fork_, roots = hP     fork040=-1      roots=0     id=1960490080       x=1018       _x=1010        y=549
386946: 264, else...  ini=1     fork040=-1      roots=0     id=1960490080       x=1018       _x=1010        y=549
386947: 267,  seg = form_seg(_P, _fork_[0], ave_x)      fork040=-1      roots=0     id=1960490080       x=1018       _x=1010        y=549
386948: 286, if ini==1, before del hP[:]        fork040=-1      roots=0     id=1960490080       x=1018       _x=1010        y=549

These are the sites of their first appearances:

0: 243, **hP_.popleft(),** _P, _x, _fork_, roots = hP       fork040=-1      roots=0     id=1960490080       x=9      _x=4       y=405
4: 261**, if _x > x - P[1]**:(P[1])     fork040=-1      roots=1     id=1960490112       x=9      _x=9       y=6 (y here is x-P[1] for logger's simplicity)
30: 261, if _x > x - P[1]:(P[1])        fork040=-1      roots=2     id=1960490144       x=22         _x=20      y=7  (y here is x-P[1] for logger's simplicity)
234: 255, roots+=1      fork040=-1      roots=3     id=1960490176       x=132        _x=117     y=405

[boris-kz]

BTW, you use that line id(roots) just to check it in the debugger, right?

Yes, just something to put a breakpoint on.

I discovered that roots has 4 ids until the exception, they are evident in

the first tracking lines and the latest ones.

Does that mean their ids are recycled? The id should only change when roots is incremented.

I'm unfolding, but it seems that it doesn't always exist and there must be

checks for that too.

tracker.rootsLog.Add(tracker.Roots("238, _P, _x, fork, roots = hP",

fork[0][4][0], roots, id(roots), x, _x, y))

Code like that failed due to the 0-4-0 anywhere except in the site where

it's compared in the deep if.

They don't exist at y==405 because _fork_s are still empty. Generally, you will have empty fork when the level of forking == y - 405. But if you only want check immediate fork, any y>405 will do, except for marginal error.

Is this image correctly drawn by the code - that's another thing that has

to be verified first by checking and possibly drawing the patterns.

It obviously won't be drawn correctly, all roots and forks are > 1.

It's solving the "verification problem", not "toy problem" and not

"learning".

Ok, but it's not necessary, I already know that it's wrong. The way I design the code, it should be a lot easier to follow execution than to design artificial test cases.

What is your alternative?

This alg is for classes with types, either manually or semi-automatically

generated by a custom editor, and a custom editor in general.

To me it doesn't make sense using so long tuples (they get unreadable) also

with so diverse meaning. Misalignment would be reduced or eliminated and the code will be more readable.

I guess your opinion - "clutter", blah-blah - not always and for other

developers the clutter is the current style, if you like it keep it, but it's annoying to get stuck or delayed by bugs due to hard to unclear and not mnemonic code. E.g. initialization wouldn't be with these unreadable 0,0,0,0,0 but just p = Pattern(), only selected arguments could be altered by identifier p = Pattern(x=230) etc.

I've said that before, but the style of your code is like if it were

FORTRAN, not Python.

The alg must be designed bottom-up, regardless of language. Python is simply the most concise, readable, and broadly known language.

My style is harder to learn but easier to work with. I try to make it easier with extended comments, but they must be optional to force transition to concise code.

...

Also, not regarding the tuples, the processing could be split in several passes, at least until it's debugged and there is output which is verified as "correct" so that a more entangled function's operation could be compared to the correct result.

Ok, try to do that. I don't see any obvious split lines, beyond what I already did.

I think it's just a matter of step-by-step tracing, except that it should follow the object between functions.

Now you say "fork and roots should be..." but have you verified that the other variables have all correct values, too?

That could be done via some assertions on the fly (besides the forcible

exception ones) or on the collected statistics.

I traced P vars in formP, they seem correct and then packed into immutable tuples But then I had this problem with len(ders2) that ended up as len(ders2_) - 1, still don't know why. So, the problem is probably in using references, but they are not optional here.

[Twenkid]

На пн, 15.10.2018 г., 16:53 Boris Kazachenko notifications@github.com написа:

BTW, you use that line id(roots) just to check it in the debugger, right?

Yes, just something to put a breakpoint on.

I discovered that roots has 4 ids until the exception, they are evident in

the first tracking lines and the latest ones.

Does that mean their ids are recycled? The id should only change when roots is incremented.

According to my log yes they are recycled, firstly I thought that was a huge pattern from y=400 to 5xx and that's why it's unprintable, is that possible?

I think recycling makes sense if roots are pushed and popped, they are probably unique variables during the first calls without push-pop operations.

That 4 seems possibly related to 2rng+1, I'll try with different rng later, if that's the logic there would be 2rng unique root ids.

Is this image correctly drawn by the code - that's another thing that has

to be verified first by checking and possibly drawing the patterns.

It obviously won't be drawn correctly, all roots and forks are > 1.

But could they be such because something of the x _x L is mistaken and e.g. matching border coordinates or one pixel diff etc. (Haven't checked it)

The alg must be designed bottom-up, regardless of language. Python is simply the most concise, readable, and broadly known language.

My style is harder to learn but easier to work with. I try to make it easier with extended comments, but they must be optional to force transition to concise code.

Readability depends on the content and the style, it's retro Fortran-like due to the short idents and being numeric, it also lacks GOTO which IMO is useful for low level processing alg.

Reading comments splits focus and puts additional cogn.ovrload (working memory is limited to 7+-2 elements). Code is more readable when the commands talk for themselves and when there are as little elements (numerical too) as possible, without need of verbal NL comments.

Code involving a lot of depth of arrays, magic numbers, numeric decisions and short idents is hard to read in any language, Python here saves on semicolons and types, classes also hide the types.

Also, not regarding the tuples, the processing could be split in several passes, at least until it's debugged and there is output which is verified as "correct" so that a more entangled function's operation could be compared to the correct result.

Ok, try to do that. I don't see any obvious split lines, beyond what I already did.

Not split lines, more split logic to stages which are confirmed that are correct in intermediate sub-passes in order to reduce these if-if-if in undefined state of the alg. As long as that's possible.

I think it's just a matter of step-by-step tracing, except that it should follow the object between functions.

I traced P vars in formP, they seem correct and then packed into immutable tuples But then I had this problem with len(ders2) that ended up as len(ders2_) - 1, still don't know why. So, the problem is probably in using references, but they are not optional here.

Maybe an alternative is a global container for the patterns and accessing them via different addressing based on coordinates of the pattern and its level, and or an additional stable id, as proposed earlier, not the pys memory id.

— 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/14#issuecomment-429861172, or mute the thread https://github.com/notifications/unsubscribe-auth/AWSP2CnH9521VcgehshZGToGb35PZdjIks5ulJNZgaJpZM4XQktA .

[boris-kz]

According to my log yes they are recycled, firstly I thought that was a huge pattern from y=400 to 5xx and that's why it's unprintable, is that possible?

In principle, yes, but with this bug blobs don't even begin to form. And roots are individual line-to-line refs, even if they are part of a blob.

It obviously won't be drawn correctly, all roots and forks are > 1.

But could they be such because something of the x _x L is mistaken and e.g. matching border coordinates or one pixel diff etc. (Haven't checked it)

I don't see how, some roots and forks must be 1|0 even if patterns or their alignment is inaccurate.

Reading comments splits focus and puts additional cogn.ovrload (working memory is limited to 7+-2 elements). Code is more readable when the commands talk for themselves and when there are as little elements (numerical too) as possible, without need of verbal NL comments.

The comments are for initial learning and optional reference. There is trade-off between initial readability and ease of scanning through the code thousand times over.

Code involving a lot of depth of arrays, magic numbers, numeric decisions

and short idents is hard to read in any language,

Most of these things are not optional here.

I think it's just a matter of step-by-step tracing, except that it should follow the object between functions.

I traced P vars in formP, they seem correct and then packed into immutable tuples But then I had this problem with len(ders2) that ended up as len(ders2_) - 1, still don't know why. So, the problem is probably in using references, but they are not optional here.

Maybe an alternative is a global container for the patterns and accessing them via different addressing based on coordinates of the pattern and its level, and or an additional stable id, as proposed earlier, not the pys memory id.

I do have such container for terminated blobs: blob in frame[8], but they never terminate with this bug. hP slices in continuing blobs are all accessible through hP, although it is dynamic and forks are not unique. Anyway, id is the only thing that is stable in Python, everything else is a reference.

[boris-kz]

Uh, I just realised that L = len(ders2_) was done in formP before last ders2 append. That's why I had L == len(ders2_) - 1. Silly me.

Re roots id, it changes with each increment, so it should only be tracked after full hP scan of P_: else in ln 161: _x <= x - P[1]

On Mon, Oct 15, 2018 at 4:56 PM Boris Kazachenko boris.kz@gmail.com wrote:

According to my log yes they are recycled, firstly I thought that was a

huge pattern from y=400 to 5xx and that's why it's unprintable, is that possible?

In principle, yes, but with this bug blobs don't even begin to form. And roots are individual line-to-line refs, even if they are part of a blob.

It obviously won't be drawn correctly, all roots and forks are > 1.

But could they be such because something of the x _x L is mistaken and e.g. matching border coordinates or one pixel diff etc. (Haven't checked it)

I don't see how, some roots and forks must be 1|0 even if patterns or their alignment is inaccurate.

Reading comments splits focus and puts additional cogn.ovrload (working memory is limited to 7+-2 elements). Code is more readable when the commands talk for themselves and when there are as little elements (numerical too) as possible, without need of verbal NL comments.

The comments are for initial learning and optional reference. There is trade-off between initial readability and ease of scanning through the code thousand times over.

Code involving a lot of depth of arrays, magic numbers, numeric decisions

and short idents is hard to read in any language,

Most of these things are not optional here.

I think it's just a matter of step-by-step tracing, except that it should follow the object between functions.

I traced P vars in formP, they seem correct and then packed into immutable tuples But then I had this problem with len(ders2) that ended up as len(ders2_) - 1, still don't know why. So, the problem is probably in using references, but they are not optional here.

Maybe an alternative is a global container for the patterns and accessing them via different addressing based on coordinates of the pattern and its level, and or an additional stable id, as proposed earlier, not the pys memory id.

I do have such container for terminated blobs: blob in frame[8], but they never terminate with this bug. hP slices in continuing blobs are all accessible through hP, although it is dynamic and forks are not unique. Anyway, id is the only thing that is stable in Python, everything else is a reference.

[Twenkid]

Code involving a lot of depth of arrays, magic numbers, numeric decisions and short idents is hard to read in any language,

Most of these things are not optional here.

I don't think so, but it's not your coding style which is not surprising since you're a beginner developer.

If the code is not going after being optimal, it could be after being readable e.g. with constants and mnemonic helper functions. Current one is neither of both.

According to my log yes they are recycled, firstly I thought that was a huge pattern from y=400 to 5xx and that's why it's unprintable, is that possible?

In principle, yes, but with this bug blobs don't even begin to form. And roots are individual line-to-line refs, even if they are part of a blob. It obviously won't be drawn correctly, all roots and forks are > 1.

Well, my log doesn't think so. I'm watching the roots =0, checked in the position you asked, and these are not marginal coordinates to me (is that what you mean with marginal? not a few occasions, but at the border?).

In my log there are 8764 occasions from y=405 to y=549, seems like there are some at each line, until the exception is thrown.

http://twenkid.com/cog/roots0_16-10-2018.txt

The id is the same though, and I think there shouldn't be reference-bug here, because each time I send it with a function call to id(...) so it's a new instance: (haven't printed the ids of the id vars in the container)

(your 161 is 261 here)

tracker.rootsLog.Add(tracker.Roots("261, if _x > x - P[1]", -1, roots, id(roots), x, _x, y))

Also now I save roots in the log as a single-element numpy array, to avoid that all-by-reference confused alias-assignment. Now it seems like a nonsense to me, especially for basic scalars.

class Fork:
    def __init__(s, where, fork, id, roots, id_roots,  x, _x, y):
       ...     
      s.roots = np.array([roots])     
      s.id_roots = id_roots
      ...

Sample ones:

Line 89838: 89836: 261, if _x > x - P[1] fork040=-1 roots=0 id=1960490080 x=163 _x=169 y=439 Line 89870: 89868: 261, if _x > x - P[1] fork040=-1 roots=0 id=1960490080 x=176 _x=178 y=439 Line 89964: 89962: 261, if _x > x - P[1] fork040=-1 roots=0 id=1960490080 x=216 _x=227 y=439 Line 100686: 100684: 261, if _x > x - P[1] fork040=-1 roots=0 id=1960490080 x=466 _x=476 y=443 Line 100802: 100800: 261, if _x > x - P[1] fork040=-1 roots=0 id=1960490080 x=512 _x=516 y=443 Line 100828: 100826: 261, if _x > x - P[1] fork040=-1 roots=0 id=1960490080 x=520 _x=523 y=443 Line 144234: 144232: 261, if _x > x - P[1] fork040=-1 roots=0 id=1960490080 x=402 _x=418 y=460 Line 144256: 144254: 261, if _x > x - P[1] fork040=-1 roots=0 id=1960490080 x=413 _x=419 y=460 Line 144276: 144274: 261, if _x > x - P[1] fork040=-1 roots=0 id=1960490080 x=422 _x=427 y=460 Line 230195: 230193: 261, if _x > x - P[1] fork040=-1 roots=0 id=1960490080 x=548 _x=552 y=492 Line 230275: 230273: 261, if _x > x - P[1] fork040=-1 roots=0 id=1960490080 x=576 _x=582 y=492 Line 230291: 230289: 261, if _x > x - P[1] fork040=-1 roots=0 id=1960490080 x=582 _x=585 y=492 Line 240779: 240777: 261, if _x > x - P[1] fork040=-1 roots=0 id=1960490080 x=405 _x=406 y=496 Line 240803: 240801: 261, if _x > x - P[1] fork040=-1 roots=0 id=1960490080 x=408 _x=413 y=496 Line 240821: 240819: 261, if _x > x - P[1] fork040=-1 roots=0 id=1960490080 x=410 _x=418 y=496 Line 240855: 240853: 261, if _x > x - P[1] fork040=-1 roots=0 id=1960490080 x=419 _x=426 y=496 Line 258674: 258672: 261, if _x > x - P[1] fork040=-1 roots=0 id=1960490080 x=857 _x=864 y=502 Line 258686: 258684: 261, if _x > x - P[1] fork040=-1 roots=0 id=1960490080 x=860 _x=866 y=502

The comments are for initial learning and optional reference. There is trade-off between initial readability and ease of scanning through the code thousand times over.

Code involving a lot of depth of arrays, magic numbers, numeric decisions and short idents is hard to read in any language,

Most of these things are not optional here. I think it's just a matter of step-by-step tracing, except that it should follow the object between functions.

Well, IMO if the code is well understood and moved to check-points, it doesn't have to be scanned over and over again later.

The need for scanning is because it's not yet well understood and not converted into verbal and stable concepts.

I assume it's not acceptable (and it's not good for performance , but the current goal is to be correct), but some of the if-s would be more readable if they were functions.

If it's already clarified what a given operation is doing, it shouldn't be always "stabbing" the eyes with fr[0][4] += 5 /4, it could be given with less elements and if one doesn't understand it - she may go see the code of the function where the function is defined.

I have had "similar" low level code for doing a custom Assembly language parsing/compiling. It was more complex, but as a style initially it was like yours, because that's a natural style for adhoc programming done quickly, when you don't want to distract by forming more functions.

It consists of functions that get overly complex, low level comparisons in long and nested if-if-if-if..., some duplicating-looking code, low level numerical stuff and magic numbers.

However it got harder and harder to debug and to add features, it looked "ugly", scanning and searching through it took more time than it could, it can't be reused etc.

So one day I decided that I had enough with that mess and created mnemonic functions. It's "beautiful" to me, could be a bit better.

It doesn't have to send "visible" arguments all the time, because the functions are defined in a class.

The less +-1[/=; and the more meaningful mnemonic, the prettier and the less the working memory cognitive load at that particular context.

The low level details shouldn't be visible all the time.

DWORD AssembleCode(char* outFile) { 
    char out[4000];
    int opc, lenA;
    DWORD instrLength = 3;

    InitAssembling();       
    SkipToStart();

    while(tok!=NULL)
    {   
      SkipLabel();
      ScanAsmLine();

      opc = ReadOpcode();
      if (opc==-1) {  NextLine(); continue; }
      lenA = strlen(sA);      

     ZeroVarsDstSrcLabelDstSrc();     
     JumpInstrSetCheckLabelsA(opc, tok, sB, sC, NULL);
     SetOpcode(addrBase, opc);
     ZeroConstFlags();

     CheckConstMap(sB, sC);
     AggregateFoundFlags();
     ScanRegularUintParams();

      if (!JumpInstrSetCheckLabelsB(opc))
      {
        if (IsUnsignedInstr_U(sA, lenA, opc)) goto EndTypeTest; 
        if (IsFloatInstr_F(sA, lenA, opc))    goto EndTypeTest;
        if (IsIntInstr_I(sA, lenA, opc))      goto EndTypeTest;
        if (IsGeneralInstr_(sA, lenA, opc))   goto EndTypeTest;     
      }  

    EndTypeTest:  IsVar(sA, lenA, opc);
                      addrBase += instrLength;        
                      line++;     
                      tok = strtok (NULL, "\n");
    }     

    SaveLogs(); 

  return addrBase - addrBaseStart;
}

Maybe an alternative is a global container for the patterns and accessing them via different addressing based on coordinates of the pattern and its level, and or an additional stable id, as proposed earlier, not the pys memory id.

I do have such container for terminated blobs: blob in frame[8], but they never terminate with this bug. hP slices in continuing blobs are all accessible through hP, although it is dynamic and forks are not unique. Anyway, id is the only thing that is stable in Python, everything else is a reference.

I am afraid that if the contents is not saved with copy.deepcopy() there might be bugs as well or it'd have to be more carefully checked for aliased-modification.

Uh, I just realised that L = len(ders2_) was done in formP before last ders2 append. That's why I had L == len(ders2_) - 1. Silly me.

Re roots id, it changes with each increment, so it should only be tracked after full hP scan of P_: else in ln 161: _x <= x - P[1]

Thus my guess that you've just checked the value one cycle earlier seems right...

[Twenkid]

Ah, "else in ln 161"... So I'll check it too, that results are for the True not the else (but it's on ln 161 in my copy).

[Twenkid]

OK, in that very location, they are only marginal. The id seems still the same though.

P:\cog\roots4_exc.txt (11 hits) Line 16492: 16490: 264, else... ini=1 fork040=-1 roots=0 id=1960490080 x=1024 _x=1019 y=410 Line 22224: 22222: 264, else... ini=1 fork040=-1 roots=0 id=1960490080 x=1024 _x=1018 y=412 Line 35976: 35974: 264, else... ini=1 fork040=-1 roots=0 id=1960490080 x=1022 _x=1019 y=417 Line 62590: 62588: 264, else... ini=1 fork040=-1 roots=0 id=1960490080 x=1024 _x=1023 y=427 Line 174973: 174971: 264, else... ini=1 fork040=-1 roots=0 id=1960490080 x=1024 _x=1018 y=471 Line 188593: 188591: 264, else... ini=1 fork040=-1 roots=0 id=1960490080 x=1024 _x=1017 y=476 Line 205221: 205219: 264, else... ini=1 fork040=-1 roots=0 id=1960490080 x=1024 _x=1017 y=482 Line 215588: 215586: 264, else... ini=1 fork040=-1 roots=0 id=1960490080 x=1024 _x=1020 y=486 Line 221044: 221042: 264, else... ini=1 fork040=-1 roots=0 id=1960490080 x=1024 _x=1017 y=488 Line 364734: 364732: 264, else... ini=1 fork040=-1 roots=0 id=1960490080 x=1024 _x=1021 y=541 Line 386948: 386946: 264, else... ini=1 fork040=-1 roots=0 id=1960490080 x=1018 _x=1010 y=549

[boris-kz]

If it's already clarified what a given operation is doing, it shouldn't be always "stabbing" the eyes with fr[0][4] += 5 /4, it could be given with less elements and if one doesn't understand it - she may go see the code of the function where the function is defined.

It's not stabbing my eyes, and I hate black boxes. There isn't enough code at this point to make it a problem. But you are more than welcome to do whatever you want in your copy.

I am afraid that if the contents is not saved with copy.deepcopy() there

might be bugs as well or it'd have to be more carefully checked for aliased-modification.

It doesn't matter with this bug because reciprocal roots and fork_ are incremented in the same run of scanP, or at least with the same P and hP_. So, there is nothing deep about it.

What we need to do is detect when P | P is fully overlapped, something like: add single-element root = [roots] to make it mutable,

if x <= _x and x-L >= _x-_L: track_Pfork = id(fork_) # must be 1|0

if _x <= x and _x-_L >= x-L: track_hProot = id(root_) # must be 1|0

and then track where track_Pfork or track_hProot is incremented, for no good reason.

Thus my guess that you've just checked the value one cycle earlier seems

right...

If only you looked at the code :).

OK, in that very location, they are only marginal. The id seems still the

same though.

Doesn't matter, these cases are junk anyway.

On Tue, Oct 16, 2018 at 4:40 AM Todor Arnaudov notifications@github.com wrote:

OK, in that very location, they are only marginal. The id seems still the same though.

P:\cog\roots4_exc.txt (11 hits) Line 16492: 16490: 264, else... ini=1 fork040=-1 roots=0 id=1960490080 x=1024 _x=1019 y=410 Line 22224: 22222: 264, else... ini=1 fork040=-1 roots=0 id=1960490080 x=1024 _x=1018 y=412 Line 35976: 35974: 264, else... ini=1 fork040=-1 roots=0 id=1960490080 x=1022 _x=1019 y=417 Line 62590: 62588: 264, else... ini=1 fork040=-1 roots=0 id=1960490080 x=1024 _x=1023 y=427 Line 174973: 174971: 264, else... ini=1 fork040=-1 roots=0 id=1960490080 x=1024 _x=1018 y=471 Line 188593: 188591: 264, else... ini=1 fork040=-1 roots=0 id=1960490080 x=1024 _x=1017 y=476 Line 205221: 205219: 264, else... ini=1 fork040=-1 roots=0 id=1960490080 x=1024 _x=1017 y=482 Line 215588: 215586: 264, else... ini=1 fork040=-1 roots=0 id=1960490080 x=1024 _x=1020 y=486 Line 221044: 221042: 264, else... ini=1 fork040=-1 roots=0 id=1960490080 x=1024 _x=1017 y=488 Line 364734: 364732: 264, else... ini=1 fork040=-1 roots=0 id=1960490080 x=1024 _x=1021 y=541 Line 386948: 386946: 264, else... ini=1 fork040=-1 roots=0 id=1960490080 x=1018 _x=1010 y=549

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

[Twenkid]

What we need to do is detect when P | P is fully overlapped, something like: add single-element root = [roots] to make it mutable,

To make the id mutable?

If only you looked at the code :).

I knew it without looking, you blamed me for "philosophy" and believed that it's more likely some kind of magic.

BTW, I've tracked fork instead of fork_ (it's in the printouts, but you didn't correct me), now fixed it.

[boris-kz]

No, root_ would be mutable, with reassignment by incremented roots, but it's id will be constant.

On Tue, Oct 16, 2018, 10:52 AM Todor Arnaudov notifications@github.com wrote:

What we need to do is detect when P | P is fully overlapped, something like: add single-element root = [roots] to make it mutable,

To make the id mutable?

If only you looked at the code :).

I knew it without looking, you blamed me for "philosophy" and believed that it's more likely some kind of magic.

BTW, I've tracked fork instead of fork_ (it's in the printouts, but you didn't correct me), now fixed it.

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

[boris-kz]

root_0 = root_0 + 1 Sorry, on a cell phone.

On Tue, Oct 16, 2018, 11:47 AM Boris Kazachenko boris.kz@gmail.com wrote:

No, root_ would be mutable, with reassignment by incremented roots, but it's id will be constant.

On Tue, Oct 16, 2018, 10:52 AM Todor Arnaudov notifications@github.com wrote:

What we need to do is detect when P | P is fully overlapped, something like: add single-element root = [roots] to make it mutable,

To make the id mutable?

If only you looked at the code :).

I knew it without looking, you blamed me for "philosophy" and believed that it's more likely some kind of magic.

BTW, I've tracked fork instead of fork_ (it's in the printouts, but you didn't correct me), now fixed it.

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

[Twenkid]

Sorry I still don't get that root_0 = ... what's its purpose.

I'll probably attack the problem with a visual online step-by-step tracer which will display more info than what I saved so far and may possibly draw the patterns' spans, trees of these forks etc. which would be useful for the future as well, or may give another chance of Pycharm debugger (the former is more interesting). I have to either make progress or have a break.

[boris-kz]

It's roots[0], now roots is a just a container with constant id, while roots[0] is incremented.

I just updated dblobs with roots as a single-element list: a mutable container to track roots[0] by it's id, and ln 155-158: get id of fully overlapped Ps and hPs:

    if x <= _x and x-P[1] >= _x-_L:
        olp_fork_ = id(fork_)  # must be 1|0, track if incremented for

no good reason if _x <= x and _x-_L >= x-P[1]: olp_roots = id(roots) # must be 1|0, track if incremented for no good reason

Now we need to add test when olpfork and olp_roots[0] are incremented | changed outside of this run of scanP, because this

Also added constant ini_y as you suggested, thanks.

I knew it without looking, you blamed me for "philosophy" and

Sorry, you did mention it, among a bunch of other things, but that's not where I accused you.

BTW, I've tracked fork instead of fork_ (it's in the printouts, but you

didn't correct me), now fixed it.

It doesn't matter, fork is just a renamed fork_. You can test it for 1|0 too, after exit from while ini_x <= x:

On Tue, Oct 16, 2018 at 1:08 PM Todor Arnaudov notifications@github.com wrote:

Sorry I still don't get that root_0 = ... what's its purpose.

I'll probably attack the problem with a visual online step-by-step tracer which will display more info than what I saved so far and may possibly draw the patterns' spans, trees of these forks etc. which would be useful for the future as well, or may give another chance of Pycharm debugger (the former is more interesting). I have to either make progress or have a break.

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

[boris-kz]

The test should be something like this:

if id(fork_) == olpfork if len(fork_before_loop) != len(fork_after_loop) breakpoint

if id(roots) == olp_roots if roots[0]_before_loop != roots[0]_after_loop breakpoint

On Tue, Oct 16, 2018 at 3:37 PM Boris Kazachenko boris.kz@gmail.com wrote:

It's roots[0], now roots is a just a container with constant id, while roots[0] is incremented.

I just updated dblobs with roots as a single-element list: a mutable container to track roots[0] by it's id, and ln 155-158: get id of fully overlapped Ps and hPs:

    if x <= _x and x-P[1] >= _x-_L:
        olp_fork_ = id(fork_)  # must be 1|0, track if incremented for

no good reason if _x <= x and _x-_L >= x-P[1]: olp_roots = id(roots) # must be 1|0, track if incremented for no good reason

Now we need to add test when olpfork and olp_roots[0] are incremented | changed outside of this run of scanP, because this

Also added constant ini_y as you suggested, thanks.

I knew it without looking, you blamed me for "philosophy" and

Sorry, you did mention it, among a bunch of other things, but that's not where I accused you.

BTW, I've tracked fork instead of fork_ (it's in the printouts, but you

didn't correct me), now fixed it.

It doesn't matter, fork is just a renamed fork_. You can test it for 1|0 too, after exit from while ini_x <= x:

On Tue, Oct 16, 2018 at 1:08 PM Todor Arnaudov notifications@github.com wrote:

Sorry I still don't get that root_0 = ... what's its purpose.

I'll probably attack the problem with a visual online step-by-step tracer which will display more info than what I saved so far and may possibly draw the patterns' spans, trees of these forks etc. which would be useful for the future as well, or may give another chance of Pycharm debugger (the former is more interesting). I have to either make progress or have a break.

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

[Twenkid]

Sorry, but the version in the repository is 6 days old: https://github.com/boris-kz/CogAlg/commit/5632901498623954310de75e6eef12b2ab8a926d

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/14#issuecomment-430374731, or mute the thread https://github.com/notifications/unsubscribe-auth/AWSP2DAwwxU1SVlpOkfTGQZNvAWMK1egks5uljfAgaJpZM4XQktA .

[boris-kz]

It's the one you comment on, check master directory.

On Wed, Oct 17, 2018, 4:23 AM Todor Arnaudov notifications@github.com wrote:

Sorry, but the version in the repository is 6 days old:

https://github.com/boris-kz/CogAlg/commit/5632901498623954310de75e6eef12b2ab8a926d

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/14#issuecomment-430374731, or mute the thread < https://github.com/notifications/unsubscribe-auth/AWSP2DAwwxU1SVlpOkfTGQZNvAWMK1egks5uljfAgaJpZM4XQktA

.

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

[Twenkid]

10x

На ср, 17.10.2018 г., 14:13 Boris Kazachenko notifications@github.com написа:

It's the one you comment on, check master directory.

On Wed, Oct 17, 2018, 4:23 AM Todor Arnaudov notifications@github.com wrote:

Sorry, but the version in the repository is 6 days old:

https://github.com/boris-kz/CogAlg/commit/5632901498623954310de75e6eef12b2ab8a926d

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

.

— 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/14#issuecomment-430587737, or mute the thread https://github.com/notifications/unsubscribe-auth/AWSP2JxR6a3_zpUu410RDGtCkKyEhSTeks5ulxDHgaJpZM4XQktA .

[Twenkid]

I tried but probably the only meaningful conclusion I could make is that hP contains fork =0 in 1005 occasions out of 125083 cycles, they seem to be for "marginal" regions.

So hP and buff probably contain fork=1 or more most of the time and when it's incremented it becomes at least 2.

For example: (on cycle begin and break some of the variables are the counter for simplicity, will print them better later)

65902: 1539802357.3691869:150,WHILE_BEGIN _hP_ counter=L        fork_id=2180984258440       fork_=1     roots=0     id_roots=1960490080     x=487       _x=493      y=424       17260
65903: 1539802357.3691869:165, P[0] == _P[0] roots+1        fork_id=2180984258440       fork_=1     roots=1     id_roots=1960490112     x=487       _x=493      y=424       4
65904: 1539802357.3691869:170, if _x > x - L        fork_id=2180984258440       fork_=1     roots=1     id_roots=1960490112     x=487       _x=493      y=424       4
65905: 1539802357.3691869:201, WHILE_END        fork_id=2180984258440       fork_=1     roots=1     id_roots=1960490112     x=17260     _x=17260        y=17260 

This is appended to hP.

Then until line 73982 fork_ is at least 1 in the beginning of the cycles, that's the end of x at image line 426.

73980: 1539802357.5238936:165, P[0] == _P[0] roots+1        fork_id=2180989418824       fork_=1     roots=2     id_roots=1960490144     x=1016      _x=1023     y=426       6
73981: 1539802357.5238936:170, if _x > x - L        fork_id=2180989418824       fork_=1     roots=2     id_roots=1960490144     x=1016      _x=1023     y=426       6
73982: 1539802357.5238936:201, WHILE_END        fork_id=2180989418824       fork_=1     roots=2     id_roots=1960490144     x=19380     _x=19380        y=19380     19380
73983: 1539802357.5238936:150,WHILE_BEGIN _hP_ counter=L        fork_id=2180987504776       fork_=0     roots=0     id_roots=1960490080     x=1016      _x=1024     y=426       19381
73984: 1539802357.5238936:170, if _x > x - L        fork_id=2180987504776       fork_=0     roots=0     id_roots=1960490080     x=1016      _x=1024     y=426       6
73985: 1539802357.5238936:201, WHILE_END        fork_id=2180987504776       fork_=0     roots=0     id_roots=1960490080     x=19381     _x=19381        y=19381     19381
73986: 1539802357.5238936:204, pre_return       fork_id=2180987504776       fork_=0     roots=0     id_roots=1960490080     x=1016      _x=1024     y=426       6
73987: 1539802357.5238936:149,WHILE_BEGIN _buff_ counter=L      fork_id=2180989418376       fork_=1     roots=2     id_roots=1960490144     x=1017      _x=1011     y=426       19382
73988: 1539802357.5238936:165, P[0] == _P[0] roots+1        fork_id=2180989418376       fork_=1     roots=3     id_roots=1960490176     x=1017      _x=1011     y=426       1
73989: 1539802357.5238936:201, WHILE_END        fork_id=2180989418376       fork_=1     roots=3     id_roots=1960490176     x=19382     _x=19382        y=19382     19382
73990: 1539802357.5238936:149,WHILE_BEGIN _buff_ counter=L      fork_id=2180989418824       fork_=1     roots=2     id_roots=1960490144     x=1017      _x=1023     y=426       19383
73991: 1539802357.5238936:160, if x <= _x and x-L >= ini_x      fork_id=2180989418824       fork_=1     roots=2     id_roots=1960490144     x=1017      _x=1023     y=426       1
73992: 1539802357.5238936:170, if _x > x - L        fork_id=2180989418824       fork_=1     roots=2     id_roots=1960490144     x=1017      _x=1023     y=426       1
73993: 1539802357.5238936:201, WHILE_END        fork_id=2180989418824       fork_=1     roots=2     id_roots=1960490144     x=19383     _x=19383        y=19383     19383
73994: 1539802357.5238936:149,WHILE_BEGIN _buff_ counter=L      fork_id=2180987504776       fork_=0     roots=0     id_roots=1960490080     x=1017      _x=1024     y=426       19384
73995: 1539802357.5238936:165, P[0] == _P[0] roots+1        fork_id=2180987504776       fork_=0     roots=1     id_roots=1960490112     x=1017      _x=1024     y=426       1
73996: 1539802357.5238936:170, if _x > x - L        fork_id=2180987504776       fork_=0     roots=1     id_roots=1960490112     x=1017      _x=1024     y=426       1
73997: 1539802357.5238936:201, WHILE_END        fork_id=2180987504776       fork_=0     roots=1     id_roots=1960490112     x=19384     _x=19384        y=19384     19384
73998: 1539802357.5238936:204, pre_return       fork_id=2180987504776       fork_=0     roots=1     id_roots=1960490112     x=1017      _x=1024     y=426       1
73999: 1539802357.5238936:149,WHILE_BEGIN _buff_ counter=L      fork_id=2180989418824       fork_=1     roots=2     id_roots=1960490144     x=1023      _x=1023     y=426       19385
74000: 1539802357.5238936:160, if x <= _x and x-L >= ini_x      fork_id=2180989418824       fork_=1     roots=2     id_roots=1960490144     x=1023      _x=1023     y=426       6
74001: 1539802357.5238936:165, P[0] == _P[0] roots+1        fork_id=2180989418824       fork_=1     roots=3     id_roots=1960490176     x=1023      _x=1023     y=426       6
74002: 1539802357.5238936:170, if _x > x - L        fork_id=2180989418824       fork_=1     roots=3     id_roots=1960490176     x=1023      _x=1023     y=426       6
74003: 1539802357.5238936:201, WHILE_END        fork_id=2180989418824       fork_=1     roots=3     id_roots=1960490176     x=19385     _x=19385        y=19385     19385
74004: 1539802357.5238936:149,WHILE_BEGIN _buff_ counter=L      fork_id=2180987504776       fork_=0     roots=1     id_roots=1960490112     x=1023      _x=1024     y=426       19386
74005: 1539802357.5238936:170, if _x > x - L        fork_id=2180987504776       fork_=0     roots=1     id_roots=1960490112     x=1023      _x=1024     y=426       6
74006: 1539802357.5238936:201, WHILE_END        fork_id=2180987504776       fork_=0     roots=1     id_roots=1960490112     x=19386     _x=19386        y=19386     19386
74007: 1539802357.5238936:159,WHILE_BREAK cycle x= counter      fork_id=2180987504776       fork_=0     roots=19387     id_roots=19387      x=19387     _x=19387        y=19387     19387
74008: 1539802357.5238936:204, pre_return       fork_id=2180987504776       fork_=0     roots=1     id_roots=1960490112     x=1023      _x=1024     y=426       6
74009: 1539802357.5243924:149,WHILE_BEGIN _buff_ counter=L      fork_id=2180989418824       fork_=1     roots=3     id_roots=1960490176     x=1024      _x=1023     y=426       19388
74010: 1539802357.5243924:179,y>rng*2_break     fork_id=2180989418824       fork_=1     roots=19388     id_roots=19388      x=19388     _x=19388        y=19388     19388

fork_ seems to be zero at the end of the lines, suggesting something that's trailing through the line.

See fork6... in http://twenkid.com/cog/

[boris-kz]

I don't think statistics is much help here, Todor. We need to trace individual error cases. So, I just updated test block for that:

    if x <= _x and x-L >= ini_x:  # P is fully overlapped by _P
        if fork_:  # wrong: fork_ must be 0, can't be incremented

before this run of while ini_x <= x: olpfork = id(fork_) # breakpoint, test prior run of while if _x <= x and ini_x >= x-L: # _P is fully overlapped by P if roots[0]: # wrong: roots must be 0, can't be incremented before this run of while ini_x <= x: olp_roots = id(roots) # breakpoint, test prior run of scanP if buff: # wrong: buff must be [] olp_roots = id(roots) # breakpoint, test prior run of scanP

All of these errors happen frequently, something is wrong with transfers...

On Wed, Oct 17, 2018 at 3:14 PM Todor Arnaudov notifications@github.com wrote:

I tried but probably the only meaningful conclusion I could make is that hP contains fork =0 in 1005 occasions out of 125083 cycles, they seem to be for "marginal" regions.

So hP probably contains fork=1 most of the time and when it's incremented it becomes at least 2.

For example: (on cycle begin and break some of the variables are the counter for simplicity, will print them better later)

65902: 1539802357.3691869:150,WHILE_BEGIN hP counter=L forkid=2180984258440 fork=1 roots=0 id_roots=1960490080 x=487 _x=493 y=424 17260 65903: 1539802357.3691869:165, P[0] == _P[0] roots+1 forkid=2180984258440 fork=1 roots=1 id_roots=1960490112 x=487 _x=493 y=424 4 65904: 1539802357.3691869:170, if _x > x - L forkid=2180984258440 fork=1 roots=1 id_roots=1960490112 x=487 _x=493 y=424 4 65905: 1539802357.3691869:201, WHILE_END forkid=2180984258440 fork=1 roots=1 id_roots=1960490112 x=17260 _x=17260 y=17260

This is appended to hP.

Then until line 73982 fork_ is at least 1 in the beginning of the cycles, that's the end of x at image line 426.

73980: 1539802357.5238936:165, P[0] == _P[0] roots+1 forkid=2180989418824 fork=1 roots=2 id_roots=1960490144 x=1016 _x=1023 y=426 6 73981: 1539802357.5238936:170, if _x > x - L forkid=2180989418824 fork=1 roots=2 id_roots=1960490144 x=1016 _x=1023 y=426 6 73982: 1539802357.5238936:201, WHILE_END forkid=2180989418824 fork=1 roots=2 id_roots=1960490144 x=19380 _x=19380 y=19380 19380 73983: 1539802357.5238936:150,WHILE_BEGIN hP counter=L forkid=2180987504776 fork=0 roots=0 id_roots=1960490080 x=1016 _x=1024 y=426 19381 73984: 1539802357.5238936:170, if _x > x - L forkid=2180987504776 fork=0 roots=0 id_roots=1960490080 x=1016 _x=1024 y=426 6 73985: 1539802357.5238936:201, WHILE_END forkid=2180987504776 fork=0 roots=0 id_roots=1960490080 x=19381 _x=19381 y=19381 19381 73986: 1539802357.5238936:204, pre_return forkid=2180987504776 fork=0 roots=0 id_roots=1960490080 x=1016 _x=1024 y=426 6 73987: 1539802357.5238936:149,WHILE_BEGIN buff counter=L forkid=2180989418376 fork=1 roots=2 id_roots=1960490144 x=1017 _x=1011 y=426 19382 73988: 1539802357.5238936:165, P[0] == _P[0] roots+1 forkid=2180989418376 fork=1 roots=3 id_roots=1960490176 x=1017 _x=1011 y=426 1 73989: 1539802357.5238936:201, WHILE_END forkid=2180989418376 fork=1 roots=3 id_roots=1960490176 x=19382 _x=19382 y=19382 19382 73990: 1539802357.5238936:149,WHILE_BEGIN buff counter=L forkid=2180989418824 fork=1 roots=2 id_roots=1960490144 x=1017 _x=1023 y=426 19383 73991: 1539802357.5238936:160, if x <= _x and x-L >= ini_x forkid=2180989418824 fork=1 roots=2 id_roots=1960490144 x=1017 _x=1023 y=426 1 73992: 1539802357.5238936:170, if _x > x - L forkid=2180989418824 fork=1 roots=2 id_roots=1960490144 x=1017 _x=1023 y=426 1 73993: 1539802357.5238936:201, WHILE_END forkid=2180989418824 fork=1 roots=2 id_roots=1960490144 x=19383 _x=19383 y=19383 19383 73994: 1539802357.5238936:149,WHILE_BEGIN buff counter=L forkid=2180987504776 fork=0 roots=0 id_roots=1960490080 x=1017 _x=1024 y=426 19384 73995: 1539802357.5238936:165, P[0] == _P[0] roots+1 forkid=2180987504776 fork=0 roots=1 id_roots=1960490112 x=1017 _x=1024 y=426 1 73996: 1539802357.5238936:170, if _x > x - L forkid=2180987504776 fork=0 roots=1 id_roots=1960490112 x=1017 _x=1024 y=426 1 73997: 1539802357.5238936:201, WHILE_END forkid=2180987504776 fork=0 roots=1 id_roots=1960490112 x=19384 _x=19384 y=19384 19384 73998: 1539802357.5238936:204, pre_return forkid=2180987504776 fork=0 roots=1 id_roots=1960490112 x=1017 _x=1024 y=426 1 73999: 1539802357.5238936:149,WHILE_BEGIN buff counter=L forkid=2180989418824 fork=1 roots=2 id_roots=1960490144 x=1023 _x=1023 y=426 19385 74000: 1539802357.5238936:160, if x <= _x and x-L >= ini_x forkid=2180989418824 fork=1 roots=2 id_roots=1960490144 x=1023 _x=1023 y=426 6 74001: 1539802357.5238936:165, P[0] == _P[0] roots+1 forkid=2180989418824 fork=1 roots=3 id_roots=1960490176 x=1023 _x=1023 y=426 6 74002: 1539802357.5238936:170, if _x > x - L forkid=2180989418824 fork=1 roots=3 id_roots=1960490176 x=1023 _x=1023 y=426 6 74003: 1539802357.5238936:201, WHILE_END forkid=2180989418824 fork=1 roots=3 id_roots=1960490176 x=19385 _x=19385 y=19385 19385 74004: 1539802357.5238936:149,WHILE_BEGIN buff counter=L forkid=2180987504776 fork=0 roots=1 id_roots=1960490112 x=1023 _x=1024 y=426 19386 74005: 1539802357.5238936:170, if _x > x - L forkid=2180987504776 fork=0 roots=1 id_roots=1960490112 x=1023 _x=1024 y=426 6 74006: 1539802357.5238936:201, WHILE_END forkid=2180987504776 fork=0 roots=1 id_roots=1960490112 x=19386 _x=19386 y=19386 19386 74007: 1539802357.5238936:159,WHILE_BREAK cycle x= counter forkid=2180987504776 fork=0 roots=19387 id_roots=19387 x=19387 _x=19387 y=19387 19387 74008: 1539802357.5238936:204, pre_return forkid=2180987504776 fork=0 roots=1 id_roots=1960490112 x=1023 _x=1024 y=426 6 74009: 1539802357.5243924:149,WHILE_BEGIN buff counter=L forkid=2180989418824 fork=1 roots=3 id_roots=1960490176 x=1024 _x=1023 y=426 19388 74010: 1539802357.5243924:179,y>rng*2_break forkid=2180989418824 fork=1 roots=19388 id_roots=19388 x=19388 _x=19388 y=19388 19388

fork_ seems to be zero at the end of the lines, suggesting something that's trailing through the line.

See fork6... in http://twenkid.com/cog/

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

[Twenkid]

IMO, such comparisons are more readable if the sequence is preserved, just the directions of <> is changed, otherwise it's more confusing/takes more time reading.

if x <= _x and x - L >= ini_x:  # P is fully overlapped by _P
            if fork_:  # wrong: fork_ must be 0, can't be incremented before this run of while ini_x <= x:
                olp_fork_ = id(fork_)  # breakpoint, test prior run of while
 if x >= _x and x - L <= ini_x:  # _P is fully overlapped by P
            if roots[0]:  # wrong: roots mu

When both cases ==, both IF would be taken, both fork and roots. Is that the target behavior?

[Twenkid]

One log allowing to see values before the while cycle after any of these errors occur:

http://twenkid.com/cog/fork7_exc.txt

This is how I sample buff:

 if len(_buff_):
      hPt = _buff_[0]
      _Pt, _xt, _fork_t, rootst = hPt
      _Lt = _Pt[1]
      Lt = P[1]
      tracker.forkLog.Add(tracker.Fork("154, PRE_WHILE****", _fork_t, id(_fork_t), rootst[0], id(rootst[0]), x, _xt, y, _Lt, Lt)) # time()))
    else:
        tracker.forkLog.Add(tracker.Fork("154, PRE_WHILE**** EMPTY BUFFER ###", fork_, id(fork_), [0], 0, x, -1, y, -1,P[1]))  # time()))

However that's only the first one, if there are many cycles of while inix < … the number of patterns that are read from hP has to be counted and checked in elif hP_, I guess.

0: 154, PRE_WHILE**** EMPTY BUFFER ###      fork_id=2347159160520       fork_=0     roots=[0]       id_roots=0      x=9     _x=-1       y=405       _L=-1, L=6
1: 154, PRE_WHILE****       fork_id=2347155148104       fork_=0     roots=0     id_roots=1960490080     x=15        _x=4        y=405       _L=1, L=6
2: 154, PRE_WHILE****       fork_id=2347155147528       fork_=0     roots=1     id_roots=1960490112     x=22        _x=14       y=405       _L=5, L=7
3: 154, PRE_WHILE****       fork_id=2347155147272       fork_=0     roots=2     id_roots=1960490144     x=29        _x=20       y=405       _L=6, L=7
4: 154, PRE_WHILE****       fork_id=2347155146952       fork_=0     roots=2     id_roots=1960490144     x=34        _x=24       y=405       _L=4, L=5
5: 154, PRE_WHILE****       fork_id=2347155146184       fork_=0     roots=1     id_roots=1960490112     x=48        _x=33       y=405       _L=4, L=14
6: 154, PRE_WHILE****       fork_id=2347155189832       fork_=0     roots=2     id_roots=1960490144     x=57        _x=45       y=405       _L=12, L=9
7: 154, PRE_WHILE****       fork_id=2347155190152       fork_=0     roots=2     id_roots=1960490144     x=60        _x=50       y=405       _L=5, L=3
8: 154, PRE_WHILE****       fork_id=2347155190728       fork_=0     roots=1     id_roots=1960490112     x=64        _x=58       y=405       _L=7, L=4
9: 154, PRE_WHILE****       fork_id=2347155190984       fork_=0     roots=1     id_roots=1960490112     x=65        _x=62       y=405       _L=4, L=1
10: 178, ERROR  x <= _x and x - L >= ini_x SEE PRE_WHILE****        fork_id=2347155191240       fork_=0     roots=1     id_roots=1960490112     x=65        _x=65       y=405       _L=3, L=1
...

8590: 154, PRE_WHILE****        fork_id=2583198881736       fork_=1     roots=2     id_roots=1960490144     x=440       _x=434      y=526       _L=5, L=5
38591: 154, PRE_WHILE****       fork_id=2583198882248       fork_=2     roots=2     id_roots=1960490144     x=446       _x=439      y=526       _L=5, L=6
38592: 154, PRE_WHILE****       fork_id=2583198882568       fork_=3     roots=2     id_roots=1960490144     x=452       _x=446      y=526       _L=7, L=6
38593: 154, PRE_WHILE****       fork_id=2583198883208       fork_=2     roots=2     id_roots=1960490144     x=453       _x=463      y=526       _L=17, L=1
38594: 154, PRE_WHILE****       fork_id=2583198883208       fork_=2     roots=2     id_roots=1960490144     x=463       _x=463      y=526       _L=17, L=10
38595: 154, PRE_WHILE****       fork_id=2583198883208       fork_=2     roots=3     id_roots=1960490176     x=465       _x=463      y=526       _L=17, L=2
38596: 181, ERROR  x >= _x and x - L <= ini_x SEE PRE_WHILE****     fork_id=2583198883656       fork_=1     roots=2     id_roots=1960490144     x=465       _x=465      y=526       _L=2, L=2
38597: 154, PRE_WHILE****       fork_id=2583198883656       fork_=1     roots=3     id_roots=1960490176     x=469       _x=465      y=526       _L=2, L=4
38598: 181, ERROR  x >= _x and x - L <= ini_x SEE PRE_WHILE****     fork_id=2583198904648       fork_=2     roots=1     id_roots=1960490112     x=469       _x=469      y=526       _L=4, L=4
38599: 154, PRE_WHILE****       fork_id=2583198904648       fork_=2     roots=2     id_roots=1960490144     x=475       _x=469      y=526       _L=4, L=6
38600: 181, ERROR  x >= _x and x - L <= ini_x SEE PRE_WHILE****     fork_id=2583198904904       fork_=3     roots=1     id_roots=1960490112     x=475       _x=473      y=526       _L=4, L=6
38601: 154, PRE_WHILE****       fork_id=2583198904904       fork_=3     roots=2     id_roots=1960490144     x=479       _x=473      y=526       _L=4, L=4
38602: 154, PRE_WHILE****       fork_id=2583198905608       fork_=2     roots=2     id_roots=1960490144     x=482       _x=479      y=526       _L=6, L=3
38603: 181, ERROR  x >= _x and x - L <= ini_x SEE PRE_WHILE****     fork_id=2583198906056       fork_=2     roots=1     id_roots=1960490112     x=482       _x=480      y=526       _L=1, L=3
38604: 154, PRE_WHILE****       fork_id=2583198906056       fork_=2     roots=2     id_roots=1960490144     x=486       _x=480      y=526       _L=1, L=4
38605: 154, PRE_WHILE****       fork_id=2583198906568       fork_=2     roots=2     id_roots=1960490144     x=489       _x=486      y=526       _L=6, L=3
38606: 181, ERROR  x >= _x and x - L <= ini_x SEE PRE_WHILE****     fork_id=2583198907016       fork_=1     roots=1     id_roots=1960490112     x=489       _x=489      y=526       _L=3, L=3
38607: 154, PRE_WHILE****       fork_id=2583198907016       fork_=1     roots=2     id_roots=1960490144     x=494       _x=489      y=526       _L=3, L=5
38608: 181, ERROR  x >= _x and x - L <= ini_x SEE PRE_WHILE****     fork_id=2583198907528       fork_=1     roots=1     id_roots=1960490112     x=494       _x=494      y=526       _L=5, L=5
38609: 154, PRE_WHILE****       fork_id=2583198907528       fork_=1     roots=2     id_roots=1960490144     x=499       _x=494      y=526       _L=5, L=5
38610: 154, PRE_WHILE****       fork_id=2583198907848       fork_=3     roots=2     id_roots=1960490144     x=500       _x=502      y=526       _L=8, L=1
38611: 154, PRE_WHILE****       fork_id=2583198907848       fork_=3     roots=2     id_roots=1960490144     x=504       _x=502      y=526       _L=8, L=4
38612: 154, PRE_WHILE****       fork_id=2583198907848       fork_=3     roots=3     id_roots=1960490176     x=509       _x=502      y=526       _L=8, L=5
38613: 181, ERROR  x >= _x and x - L <= ini_x SEE PRE_WHILE****     fork_id=2583198933576       fork_=2     roots=1     id_roots=1960490112     x=509       _x=507      y=526       _L=2, L=5
38614: 154, PRE_WHILE****       fork_id=2583198908296       fork_=3     roots=3     id_roots=1960490176     x=513       _x=505      y=526       _L=3, L=4
38615: 154, PRE_WHILE****       fork_id=2583198934472       fork_=2     roots=1     id_roots=1960490112     x=518       _x=512      y=526       _L=3, L=5
38616: 154, PRE_WHILE****       fork_id=2583198934984       fork_=1     roots=2     id_roots=1960490144     x=521       _x=518      y=526       _L=6, L=3
38617: 181, ERROR  x >= _x and x - L <= ini_x SEE PRE_WHILE****     fork_id=2583198935432       fork_=2     roots=1     id_roots=1960490112     x=521       _x=521      y=526       _L=3, L=3
38618: 154, PRE_WHILE****       fork_id=2583198935432       fork_=2     roots=2     id_roots=1960490144     x=525       _x=521      y=526       _L=3, L=4
38619: 181, ERROR  x >= _x and x - L <= ini_x SEE PRE_WHILE****     fork_id=2583198935688       fork_=3     roots=1     id_roots=1960490112     x=525       _x=525      y=526       _L=4, L=4
38620: 154, PRE_WHILE****       fork_id=2583198935688       fork_=3     roots=2     id_roots=1960490144     x=528       _x=525      y=526       _L=4, L=3
38621: 181, ERROR  x >= _x and x - L <= ini_x SEE PRE_WHILE****     fork_id=2583198936328       fork_=2     roots=1     id_roots=1960490112     x=528       _x=527      y=526       _L=2, L=3
38622: 154, PRE_WHILE****       fork_id=2583198936328       fork_=2     roots=2     id_roots=1960490144     x=532       _x=527      y=526       _L=2, L=4
38623: 154, PRE_WHILE****       fork_id=2583198936840       fork_=2     roots=2     id_roots=1960490144     x=535       _x=532      y=526       _L=5, L=3
38624: 181, ERROR  x >= _x and x - L <= ini_x SEE PRE_WHILE****     fork_id=2583198949640       fork_=2     roots=1     id_roots=1960490112     x=535       _x=534      y=526       _L=2, L=3
38625: 154, PRE_WHILE****       fork_id=2583198949640       fork_=2     roots=2     id_roots=1960490144     x=540       _x=534      y=526       _L=2, L=5
38626: 181, ERROR  x >= _x and x - L <= ini_x SEE PRE_WHILE****     fork_id=2583198950536       fork_=2     roots=1     id_roots=1960490112     x=540       _x=539      y=526       _L=2, L=5
38627: 154, PRE_WHILE****       fork_id=2583198950088       fork_=2     roots=2     id_roots=1960490144     x=541       _x=537      y=526       _L=3, L=1
38628: 178, ERROR  x <= _x and x - L >= ini_x SEE PRE_WHILE****     fork_id=2583198950984       fork_=3     roots=1     id_roots=1960490112     x=541       _x=548      y=526       _L=9, L=1
38629: 154, PRE_WHILE****       fork_id=2583198950984       fork_=3     roots=1     id_roots=1960490112     x=548       _x=548      y=526       _L=9, L=7
38630: 154, PRE_WHILE****       fork_id=2583198950984       fork_=3     roots=2     id_roots=1960490144     x=552       _x=548      y=526       _L=9, L=4
38631: 181, ERROR  x >= _x and x - L <= ini_x SEE PRE_WHILE****     fork_id=2583198951432       fork_=3     roots=1     id_roots=1960490112     x=552       _x=551      y=526       _L=3, L=4
38632: 154, PRE_WHILE****       fork_id=2583198951432       fork_=3     roots=2     id_roots=1960490144     x=557       _x=551      y=526       _L=3, L=5
38633: 181, ERROR  x >= _x and x - L <= ini_x SEE PRE_WHILE****     fork_id=2583198952712       fork_=1     roots=1     id_roots=1960490112     x=557       _x=554      y=526       _L=1, L=5
38634: 154, PRE_WHILE****       fork_id=2583198952264       fork_=1     roots=2     id_roots=1960490144     x=562       _x=553      y=526       _L=2, L=5
38635: 154, PRE_WHILE****       fork_id=2583198952968       fork_=2     roots=1     id_roots=1960490112     x=567       _x=558      y=526       _L=4, L=5
38636: 154, PRE_WHILE****       fork_id=2583198962376       fork_=2     roots=1     id_roots=1960490112     x=568       _x=564      y=526       _L=4, L=1
38637: 178, ERROR  x <= _x and x - L >= ini_x SEE PRE_WHILE****     fork_id=2583198963272       fork_=1     roots=0     id_roots=1960490080     x=568       _x=568      y=526       _L=3, L=1
38638: 154, PRE_WHILE****       fork_id=2583198963272       fork_=1     roots=1     id_roots=1960490112     x=572       _x=568      y=526       _L=3, L=4
38639: 181, ERROR  x >= _x and x - L <= ini_x SEE PRE_WHILE****     fork_id=2583198963720       fork_=1     roots=1     id_roots=1960490112     x=572       _x=570      y=526       _L=2, L=4
38640: 154, PRE_WHILE****       fork_id=2583198963720       fork_=1     roots=2     id_roots=1960490144     x=578       _x=570      y=526       _L=2, L=6
38641: 181, ERROR  x >= _x and x - L <= ini_x SEE PRE_WHILE****     fork_id=2583198964232       fork_=2     roots=1     id_roots=1960490112     x=578       _x=577      y=526       _L=3, L=6
38642: 154, PRE_WHILE****       fork_id=2583198963976       fork_=2     roots=2     id_roots=1960490144     x=586       _x=574      y=526       _L=4, L=8
38643: 154, PRE_WHILE****       fork_id=2583198964680       fork_=2     roots=1     id_roots=1960490112     x=589       _x=580      y=526       _L=3, L=3
38644: 178, ERROR  x <= _x and x - L >= ini_x SEE PRE_WHILE****     fork_id=2583198965640       fork_=2     roots=0     id_roots=1960490080     x=589       _x=589      y=526       _L=5, L=3
38645: 154, PRE_WHILE****       fork_id=2583198965640       fork_=2     roots=1     id_roots=1960490112     x=592       _x=589      y=526       _L=5, L=3
38646: 181, ERROR  x >= _x and x - L <= ini_x SEE PRE_WHILE****     fork_id=2583198986632       fork_=2     roots=1     id_roots=1960490112     x=592       _x=591      y=526       _L=2, L=3
38647: 154, PRE_WHILE****       fork_id=2583198986632       fork_=2     roots=2     id_roots=1960490144     x=598       _x=591      y=526       _L=2, L=6
38648: 154, PRE_WHILE****       fork_id=2583198987336       fork_=3     roots=2     id_roots=1960490144     x=602       _x=598      y=526       _L=7, L=4
38649: 181, ERROR  x >= _x and x - L <= ini_x SEE PRE_WHILE****     fork_id=2583198987592       fork_=3     roots=1     id_roots=1960490112     x=602       _x=601      y=526       _L=3, L=4
38650: 154, PRE_WHILE****       fork_id=2583198987592       fork_=3     roots=2     id_roots=1960490144     x=605       _x=601      y=526       _L=3, L=3
38651: 154, PRE_WHILE****       fork_id=2583198988424       fork_=2     roots=2     id_roots=1960490144     x=609       _x=604      y=526       _L=3, L=4
38652: 154, PRE_WHILE****       fork_id=2583198988936       fork_=2     roots=2     id_roots=1960490144     x=613       _x=609      y=526       _L=5, L=4
38653: 181, ERROR  x >= _x and x - L <= ini_x SEE PRE_WHILE****     fork_id=2583198989384       fork_=2     roots=1     id_roots=1960490112     x=613       _x=612      y=526       _L=3, L=4

[Twenkid]

I also did a run with the debugger and take a few notes on the values.

Is it correct that the first tuple of fork_ and the first tuple in a first tuple of the following list match? The first is the pattern, then the pattern again? (It's like that for other cases, too, e.g. in P[0] == _P[0])

(0, 4, 264, -46, -69, -60, -3), [((0, 4, 264, -46, -69, -60, -3, ...

Once error case for y=405

x = 65
ini_x = 62
_x = 65
fork_ = {list} <class 'list'>: [[(1, 4, 416, 171, 149, 482, 583), [((1, 4, 416, 171, 149, 482, 583, [(100, 21, -40, 88, 159), (99, 57, 6, 80, 140), (103, 72, 86, 161, 118), (114, 21, 97, 153, 166)]), 60, 0)], 60, 0, [[2], [], (0, 0, 0, 0, 0, 0, 0, 0, 0)], []]]
 0 = {list} <class 'list'>: [(1, 4, 416, 171, 149, 482, 583), [((1, 4, 416, 171, 149, 482, 583, [(100, 21, -40, 88, 159), (99, 57, 6, 80, 140), (103, 72, 86, 161, 118), (114, 21, 97, 153, 166)]), 60, 0)], 60, 0, [[2], [], (0, 0, 0, 0, 0, 0, 0, 0, 0)], []]
 __len__ = {int} 1
 y = 405

 ...

And below:

 y=407
 ini_x = 33
 x = 45
 ini = 1

 (sign=1, L = 17, )
 hP = 0 = {tuple} <class 'tuple'>: (1, 17, 1739, 678, 676, 2184, 2513, [(60, 4, -14, -31, -25), (59, 16, 5, -43, -30), (60, 29, 22, -50, -35), (63, 44, 44, -48, -32), (68, 58, 63, -27, -16), (76, 63, 68, 13, 18), (86, 59, 55, 64, 65), (98, 52, 53, 137, 112), (105, 17, 62, 188, 138), (119, 1, 11, 179, 210), (115, 30, 42, 158, 216), (116, 52, 62, 162, 224), (122, 62, 60, 190, 256), (132, 66, 51, 239, 298), (142, 57, 53, 301, 328), (154, 39, 28, 355, 377), (164, 29, 11, 397, 409)])
1 = {int} 50
2 = {list} <class 'list'>: [[(1, 14, 1437, 719, 640, 1745, 2440), [((1, 14, 1437, 719, 640, 1745, 2440, [(55, 11, 18, -72, -9), (54, 37, 39, -95, -11), (56, 63, 63, -87, -6), (63, 73, 73, -36, 21), (75, 60, 63, 25, 72), (88, 49, 41, 57, 130), (98, 63, 45, 92, 163), (102, 56, 73, 138, 164), (119, 52, 46, 158, 246), (123, 74, 75, 190, 252), (133, 70, 70, 259, 294), (147, 49, 33, 322, 357), (159, 38, 1, 372, 383), (165, 24, 0, 422, 384)]), 41, 0)], 41, 0, [[2], [], (0, 0, 0, 0, 0, 0, 0, 0, 0)], [[(1, 12, 1291, 640, 631, 1714, 2238), [((1, 12, 1291, 640, 631, 1714, 2238, [(68, 21, 35, -29, 18), (67, 46, 51, -39, 24), (72, 65, 67, -21, 44), (80, 73, 72, 29, 77), (92, 63, 61, 98, 128), (105, 44, 48, 151, 181), (115, 37, 37, 167, 225), (122, 55, 49, 179, 250), (125, 63, 74, 207, 253), (139, 69, 45, 247, 322), (146, 71, 60, 327, 333), (160, 33, 32, 398, 383)]), 39, 0)], 39, 0, [[2], [], (0, 0, 0, 0, 0, 0, 0, 0, 0)], []], [(1, 1, 138, 31, 77, 320, 190), [((1, 1, 138, 31, 77, 320, 190, [(138, 31, 77, 320, ...
3 = {list} <class 'list'>: [1]
__len__ = {int} 4

hP_ = {deque}  
 000 = {list} <class 'list'>: [(1, 3, 299, 95, 89, 376, 340, [(97, 40, -5, 82, 119), (95, 48, 37, 145, 93), (107, 7, 57, 149, 128)]), 59, [[(1, 3, 293, 136, 40, 358, 351), [((1, 3, 293, 136, 40, 358, 351, [(96, 46, -46, 52, 129), (91, 65, 43, 117, 88), (106, 25, 43, 189, 134)]), 59, 0)], 59, 0, [[3], [], (0, 0, 0, 0, 0, 0, 0, 0, 0)], [[(1, 1, 138, 31, 77, 320, 190), [((1, 1, 138, 31, 77, 320, 190, [(138, 31, 77, 320, 190)]), 51, 0)], 51, 0, [[2], [], (0, 0, 0, 0, 0, 0, 0, 0, 0)], []], [(1, 4, 416, 171, 149, 482, 583), [((1, 4, 416, 171, 149, 482, 583, [(100, 21, -40, 88, 159), (99, 57, 6, 80, 140), (103, 72, 86, 161, 118), (114, 21, 97, 153, 166)]), 60, 0)], 60, 0, [[2], [], (0, 0, 0, 0, 0, 0, 0, 0, 0)], []]]]], [0]]
 001 = {list} <class 'list'>: [(0, 2, 230, -69, -9, 291, 333, [(115, -34, 15, 139, 172), (115, -35, -24, 152, 161)]), 61, [[(0, 9, 1381, -476, -377, 2081, 2480), [((0, 9, 1381, -476, -377, 2081, 2480, [(172, 0, -24, 437, 386), (177, -4, -41, 406, 378), (172, -31, 25, 337, 363), (177, -73, -25, 277, 334), (168, -88, -48, 195, 299), (154, -109, -65, 123, 246), (141, -106, -87, 107, 173), (120, -57, -66, 123, 154), (100, -8, -46, 76, 147)]), 53, 0)], 53, 0, [[2], [], (0, 0, 0, 0, 0, 0, 0, 0, 0)], [[(0, 5, 847, -177, -327, 1660, 1514), [((0, 5, 847, -177, -327, 1660, 1514, [(173, -15, -32, 392, 413), (177, -37, -75, 361, 351), (172, -48, -67, 307, 310), (164, -65, -77, 321, 236), (161, -12, -76, 279, 204)]), 48, 0)], 48, 0, [[2], [], (0, 0, 0, 0, 0, 0, 0, 0, 0)], []], [(0, 7, 989, -303, -134, 1459, 1743), [((0, 7, 989, -303, -134, 1459, 1743, [(148, 0, 58, 316, 259), (152, -25, 13, 286, 302), (151, -43, -12, 252, 296), (146, -47, -21, 214, 276), (138, -55, -27, 143, 265), (129, -84, -55, 123, 208), (125...

 L = 17

 (should match hP[0])
 _P <class 'tuple'>: (1, 17, 1739, 678, 676, 2184, 2513, [(60, 4, -14, -31, -25), (59, 16, 5, -43, -30), (60, 29, 22, -50, -35), (63, 44, 44, -48, -32), (68, 58, 63, -27, -16), (76, 63, 68, 13, 18), (86, 59, 55, 64, 65), (98, 52, 53, 137, 112), (105, 17, 62, 188, 138), (119, 1, 11, 179, 210), (115, 30, 42, 158, 216), (116, 52, 62, 162, 224), (122, 62, 60, 190, 256), (132, 66, 51, 239, 298), (142, 57, 53, 301, 328), (154, 39, 28, 355, 377), (164, 29, 11, 397, 409)])

_x = 50

L = 5
P = {tuple}  
 0 = {int} 0
 1 = {int} 5
 2 = {int32} 695
 3 = {int32} -218
 4 = {int32} -40
 5 = {int32} 1026
 6 = {int32} 991
 7 = {list} <class 'list'>: [(151, -57, 23, 222, 228), (159, -81, -28, 210, 172), (138, -51, -36, 200, 197), (128, -29, -14, 213, 190), (119, 0, 15, 181, 204)]
 __len__ = {int} 8

 buff_ = {deque}  
 __len__ = {int} 0
 maxlen = {NoneType} None

 fork_ = {list}  
 0 = {list} <class 'list'>: [(0, 4, 264, -46, -69, -60, -3), [((0, 4, 264, -46, -69, -60, -3, [(66, -3, 0, -7, 24), (68, -17, -18, -17, 10), (67, -18, -28, -18, -13), (63, -8, -23, -18, -24)]), 31, 0)], 31, 0, [[2], [], (0, 0, 0, 0, 0, 0, 0, 0, 0)], [[(0, 5, 349, -119, -77, -139, 12), [((0, 5, 349, -119, -77, -139, 12, [(75, -15, -4, 4, 39), (75, -29, -18, -20, 16), (72, -33, -26, -38, -5), (66, -29, -19, -40, -17), (61, -13, -10, -45, -21)]), 32, 0)], 32, 0, [[3], [], (0, 0, 0, 0, 0, 0, 0, 0, 0)], [[(0, 2, 151, -26, -2, 32, 1), [((0, 2, 151, -26, -2, 32, 1, [(72, -14, 10, 17, 7), (79, -12, -12, 15, -6)]), 25, 0)], 25, 0, [[2], [], (0, 0, 0, 0, 0, 0, 0, 0, 0)], []], [(0, 4, 290, -34, 13, 54, 42), [((0, 4, 290, -34, 13, 54, 42, [(74, -7, 1, 22, 18), (74, -15, 0, 15, 8), (73, -12, -2, 20, 4), (69, 0, 14, -3, 12)]), 31, 0)], 31, 0, [[1], [], (0, 0, 0, 0, 0, 0, 0, 0, 0)], []], [(0, 5, 847, -177, -327, 1660, 1514), [((0, 5, 847, -177, -327, 1660, 1514, [(173, -15, -32, 392, 413), (177, -37, -75, 361, 3...
 __len__ = {int} 1

[boris-kz]

No, these are 3 separate but not exclusive error cases.

On Thu, Oct 18, 2018, 2:24 AM Todor Arnaudov notifications@github.com wrote:

IMO, such comparisons are more readable if the sequence is preserved, just the directions of <> is changed, otherwise it's more confusing/takes more time reading that it's just reversed.

if x <= _x and x - L >= ini_x: # P is fully overlapped by P if fork: # wrong: fork_ must be 0, can't be incremented before this run of while ini_x <= x: olpfork = id(fork_) # breakpoint, test prior run of while if x >= _x and x - L <= ini_x: # _P is fully overlapped by P if roots[0]: # wrong: roots mu

When both cases ==, both IF would be taken, both fork and roots. Is that the target behavior?

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