G = blob.params[-1] not [1] (L) in eval_layer rdn+= ...

[Twenkid]

In intra_blob_debug. G is the last item in the blob.params tuple, so it should be accessed via blob.params[-1] as used in intra_blob_root:

if blob.params[-1] > ave_blob * 2: # G > fixed costs of comp_angle

In eval_layer, the comment refers to G ([-1]), while the code reads L ([1])

     rdn += 1 * (olp / blob.params[1])  # rdn += 1 * (olp / G): redundancy to previous + stronger overlapping blobs, * branch cost ratio?

        if val > ave * blob.params[1] * rdn + ave_blob:  # val > ave * G * rdn + fix_cost: extend master blob syntax: += branch syntax
            for sub_blob in blob.sub_blob_:  # sub_blobs are angle blobs

                sub_vals = branch(sub_blob, typ)  # branch-specific

https://github.com/boris-kz/CogAlg/blob/1ce8aa2c3e4bdcc0259ce2a8c6e83b6a1143a83e/frame_2D_alg/intra_blob_debug.py#L91

[boris-kz]

Sorry, the code is out of date, current structure is:

Each blob may start a Dert_tree: array of horizontal slices across

derivation tree:

blob = Y, X, Derts, derts_  # contain Dert (Ly, L, I, Dx, Dy, G) and

dert (i, dx, dy, g) per each higher slice tree = Derts, slice_ # Ly, L, I, Dx, Dy, G in Dert, in Derts, are summed over all slices.

where each slice consists of two layers:
angle_layer = Derts, ablob_  # ablobs, refer to sub blobs:
xtype_layer = Derts, xblob_  # summed mixed-type sub blobs

xblob_ contains (but not subdivided into) sub_blob_s per ablob
each sub_blob may head it's own tree, and xblobs also have a type id,

determined by type def: ga_sign? ( Ga? der_blobs(a)) : G -Ga? der_blobs(i) : G - G -Ga? rng_blobs(i)?

On Fri, Mar 22, 2019 at 8:21 AM Todor Arnaudov notifications@github.com wrote:

In intra_blob_debug. G is the last item in the blob.params tuple, so it should be accessed via blob.params[-1] as used in intra_blob_root:

if blob.params[-1] > ave_blob * 2: # G > fixed costs of comp_angle

In eval_layer, the comment refers to G ([-1]), while the code reads L ([1])

 rdn += 1 * (olp / blob.params[1])  # rdn += 1 * (olp / G): redundancy to previous + stronger overlapping blobs, * branch cost ratio?

    if val > ave * blob.params[1] * rdn + ave_blob:  # val > ave * G * rdn + fix_cost: extend master blob syntax: += branch syntax
        for sub_blob in blob.sub_blob_:  # sub_blobs are angle blobs

            sub_vals = branch(sub_blob, typ)  # branch-specific

https://github.com/boris-kz/CogAlg/blob/1ce8aa2c3e4bdcc0259ce2a8c6e83b6a1143a83e/frame_2D_alg/intra_blob_debug.py#L91

— 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/25, or mute the thread https://github.com/notifications/unsubscribe-auth/AUAXGWFUjreGY1y_Eg1ZuzrqijiFarkbks5vZMrEgaJpZM4cDdFN .

[Twenkid]

Nice - it's getting interesting when new structures start to flourish rapidly.

In what times could you talk next week?

На пт, 22.03.2019 г., 14:58 Boris Kazachenko notifications@github.com написа:

Sorry, the code is out of date, current structure is:

Each blob may start a Dert_tree: array of horizontal slices across derivation tree:

blob = Y, X, Derts, derts # contain Dert (Ly, L, I, Dx, Dy, G) and dert (i, dx, dy, g) per each higher slice tree = Derts, slice # Ly, L, I, Dx, Dy, G in Dert, in Derts, are summed over all slices.

where each slice consists of two layers: anglelayer = Derts, ablob # ablobs, refer to sub blobs: xtypelayer = Derts, xblob # summed mixed-type sub blobs

xblob_ contains (but not subdivided into) sub_blob_s per ablob each sub_blob may head it's own tree, and xblobs also have a type id, determined by type def: ga_sign? ( Ga? der_blobs(a)) : G -Ga? der_blobs(i) : G - G -Ga? rng_blobs(i)?

On Fri, Mar 22, 2019 at 8:21 AM Todor Arnaudov notifications@github.com wrote:

In intra_blob_debug. G is the last item in the blob.params tuple, so it should be accessed via blob.params[-1] as used in intra_blob_root:

if blob.params[-1] > ave_blob * 2: # G > fixed costs of comp_angle

In eval_layer, the comment refers to G ([-1]), while the code reads L ([1])

rdn += 1 (olp / blob.params[1]) # rdn += 1 (olp / G): redundancy to previous + stronger overlapping blobs, * branch cost ratio?

if val > ave blob.params[1] rdn + ave_blob: # val > ave G rdn + fix_cost: extend master blob syntax: += branch syntax for sub_blob in blob.subblob: # sub_blobs are angle blobs

sub_vals = branch(sub_blob, typ) # branch-specific

https://github.com/boris-kz/CogAlg/blob/1ce8aa2c3e4bdcc0259ce2a8c6e83b6a1143a83e/frame_2D_alg/intra_blob_debug.py#L91

— 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/25, or mute the thread < https://github.com/notifications/unsubscribe-auth/AUAXGWFUjreGY1y_Eg1ZuzrqijiFarkbks5vZMrEgaJpZM4cDdFN

.

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

[Twenkid]

Something like that? Where means a pointer and () could point to (another tree).

(I know I may have misinterpreted some of the relations)

[boris-kz]

Yes, mostly. But derts is separate from Derts and it doesn't include deeper Derts. Y, X, Derts, derts is actually only basic blob, deeper recursion will replace derts_ with subblob, then with two layers, then with slice_, and Derts params will be summed from all the elements. I will post an update later today. I can talk any day ~7|8 AM - 11 AM or 3 PM - 10 PM, Boston time.

On Fri, Mar 22, 2019 at 1:51 PM Todor Arnaudov notifications@github.com wrote:

Something like that? Where means a pointer and () could point to (another tree).

[image: image] https://user-images.githubusercontent.com/23367640/54842740-65bdd800-4cdb-11e9-8a1c-39925e533f58.png

(I know I may have misinterpreted some of the relations)

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

[Twenkid]

OK. I'll see the code tomorrow, until then:

[boris-kz]

i just posted it, blob structure is in the top comment. I removed distinction between angle layers and x layers, all blobs now have type id. Also, derts_ is preserved, although it is redundant to derts_s in sub_blobs, thus could be replaced by sub_blobs. Added Derts per subblob and Derts per layer_, although it feels like overkill.

On Fri, Mar 22, 2019 at 4:24 PM Todor Arnaudov notifications@github.com wrote:

OK. I'll see the code tomorrow, until then:

[image: image] https://user-images.githubusercontent.com/23367640/54850861-f226c580-4cf0-11e9-87b2-d29d2e462f3b.png

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

[Twenkid]

Thanks, that's more clear. I don't see yet what exactly is meant by "the horizontal slices across derivation tree", though - selected Ps? "layers =
Derts, layer_, # array of horizontal slices across derivation tree per root blob, optional"

Referring to the summary by Khan from January: https://github.com/boris-kz/CogAlg/commit/ee56f9e099dd8db3a265de5bdeae369941edeac6#commitcomment-31997841

I assume that the "derivation tree" is that whole sequence of evolving structures: primary derivatives per pixel, Ps, seg, blob and then these new layers etc.

As of the slices. Aren't the Segs already containing "slices" - Ps and stacks of slices? Khan explicitly suggested the term slice: "segment contains Ps, which are like slices".

I reviewed old notes from an year ago and recalled that the general notions were already there: blob, segment, forks, roots, including mentions of slices and "axis". I've marked that the latter was defined as the line of the middle point of the blob, with respective derivative Dx (not current dx for the gradient). In current version axis is only mentioned in the header of intra_blob.

What about the axes now?

I noted that now there are calculations (normalization) to the local coordinate system per blobs in the overlap() function, relative to the "box" per compared blob - x0,xn; y0,yn.

What I can assume about the slices is that these would be selection of such "slices", i.e. Ps with additional selection, added discontinuity (syntax, depth in the structure); or possibly the Ps could be now cut vertically as well, according to some axis?

Overlap

Regarding the boxes and the overlap, is it something like that? If my interpretation of the "blob" is correct:

(Only one connection per line (continuous), it shouldn't have "holes" - I guess they would appear if there were at least two connections to the upper line, thus the "hole" would be in between).

...

Redundancy

When the box map is inverted, comparisons would be applied over the pixels which are not part of the blob, but inside the box, which may cover a lot more than the actual Ps.

The overlap & redundancy calculations are because these regions would be compared/processed by both blobs? There's a "race condition" and these coordinates at the low level would be mapped to two hierarchies and that's why the formulas have to "compensate" (or interact)?

[boris-kz]

Thanks, that's more clear. I don't see yet what exactly is meant by "the horizontal slices across derivation tree", though - selected Ps? "layers = Derts, layer_, # array of horizontal slices across derivation tree per root blob, optional"

This is derivation tree produced by recursive intra_blob, each layer / slice is an array sub_blobs formed by co-evaluated branches. See eval_layer() in intra_blob()

Referring to the summary by Khan from January: ee56f9e

commitcomment-31997841

https://github.com/boris-kz/CogAlg/commit/ee56f9e099dd8db3a265de5bdeae369941edeac6#commitcomment-31997841

I assume that the "derivation tree" is that whole sequence of evolving structures: primary derivatives per pixel, Ps, seg, blob and then these new layers etc.

As of the slices. Aren't the Segs already containing "slices" - Ps and stacks of slices? Khan explicitly suggested the term slice: "segment contains Ps, which are like slices".

No, this is from intra_blob only. I replaced slice by layer as formal name here, slice is only suggestive now.

I reviewed old notes from an year ago and recalled that the general notions

were already there: blob, segment, forks, roots, including mentions of slices and "axis". I've marked that the latter was defined as the line of the middle point of the blob, with respective derivative Dx (not current dx for the gradient). In current version axis is only mentioned in the header of intra_blob.

What about the axes now?

I noted that now there are calculations (normalization) to the local coordinate system per blobs in the overlap() function, relative to the "box" per compared blob - x0,xn; y0,yn.

What I can assume is that these would be selection of such "slices", i.e. Ps with additional selection, added discontinuity (syntax, depth in the structure); or possibly the Ps could be now cut vertically as well, according to some axis?

No, axes in Khanh usage are numpy terms, it's not related to my usage as blob linear regression axes.

Overlap

Regarding the boxes and the overlap, is it something like that? If my interpretation of the "blob" is correct:

[image: image] https://user-images.githubusercontent.com/23367640/54869892-818eb000-4da7-11e9-81a1-909dabab5bf2.png

(Only one connection per line (continuous), it shouldn't have "holes" - I guess they would appear if there were at least two connections to the upper line, thus the "hole" would be in between).

No, overlap as computed in intra_blob is when different types of blobs are covering the same pixels.

...

Redundancy

When the box map is inverted, comparisons would be applied over the pixels which are not part of the blob, but inside the box, which may cover a lot more than the actual Ps.

The overlap & redundancy calculations are because these regions would be compared/processed by both blobs? There's a "race condition" and these coordinates at the low level would be mapped to two hierarchies and that's why the formulas have to "compensate" (or interact)?

No, redundancy is computed pixel-wise, as number of different representations (blobs) of the same pixels.

Khanh, could you answer about maps? Do we still need to use them or it's all dert_ s now?

[boris-kz]

Ok, I just posted update with some refinements and expanded comments. Next I need to add separate branch() and eval_layer() for angleval. Right now, comp_angle is evaluated per blob, it should be per whole layer. But we really need better bandwidth, otherwise you will never catch up.

On Sat, Mar 23, 2019 at 3:43 PM Boris Kazachenko boris.kz@gmail.com wrote:

Thanks, that's more clear. I don't see yet what exactly is meant by "the horizontal slices across derivation tree", though - selected Ps? "layers = Derts, layer_, # array of horizontal slices across derivation tree per root blob, optional"

This is derivation tree produced by recursive intra_blob, each layer / slice is an array sub_blobs formed by co-evaluated branches. See eval_layer() in intra_blob()

Referring to the summary by Khan from January: ee56f9e

commitcomment-31997841

https://github.com/boris-kz/CogAlg/commit/ee56f9e099dd8db3a265de5bdeae369941edeac6#commitcomment-31997841

I assume that the "derivation tree" is that whole sequence of evolving structures: primary derivatives per pixel, Ps, seg, blob and then these new layers etc.

As of the slices. Aren't the Segs already containing "slices" - Ps and stacks of slices? Khan explicitly suggested the term slice: "segment contains Ps, which are like slices".

No, this is from intra_blob only. I replaced slice by layer as formal name here, slice is only suggestive now.

I reviewed old notes from an year ago and recalled that the general

notions were already there: blob, segment, forks, roots, including mentions of slices and "axis". I've marked that the latter was defined as the line of the middle point of the blob, with respective derivative Dx (not current dx for the gradient). In current version axis is only mentioned in the header of intra_blob.

What about the axes now?

I noted that now there are calculations (normalization) to the local coordinate system per blobs in the overlap() function, relative to the "box" per compared blob - x0,xn; y0,yn.

What I can assume is that these would be selection of such "slices", i.e. Ps with additional selection, added discontinuity (syntax, depth in the structure); or possibly the Ps could be now cut vertically as well, according to some axis?

No, axes in Khanh usage are numpy terms, it's not related to my usage as blob linear regression axes.

Overlap

Regarding the boxes and the overlap, is it something like that? If my interpretation of the "blob" is correct:

[image: image] https://user-images.githubusercontent.com/23367640/54869892-818eb000-4da7-11e9-81a1-909dabab5bf2.png

(Only one connection per line (continuous), it shouldn't have "holes" - I guess they would appear if there were at least two connections to the upper line, thus the "hole" would be in between).

No, overlap as computed in intra_blob is when different types of blobs are covering the same pixels.

...

Redundancy

When the box map is inverted, comparisons would be applied over the pixels which are not part of the blob, but inside the box, which may cover a lot more than the actual Ps.

The overlap & redundancy calculations are because these regions would be compared/processed by both blobs? There's a "race condition" and these coordinates at the low level would be mapped to two hierarchies and that's why the formulas have to "compensate" (or interact)?

No, redundancy is computed pixel-wise, as number of different representations (blobs) of the same pixels.

Khanh, could you answer about maps? Do we still need to use them or it's all dert_ s now?

[Twenkid]

But we really need better bandwidth, otherwise you will never catch up.

I agreed, Boris, just not today, maybe these days. I don't want to waste that little spark of focus without some contribution. However an initial "code exposure" is needed anyway.

As of the overlap comparison. Wouldn't something like the inter-blob box comparison be applied in the future inter_blob function? Also are such blobs with that coordinate coverage possible?

Regarding the latest updates, one thing which I think needs to be more clear is more explicit terminology distinction and mapping in the explanations of "higher layer/lower layer, above/below", as for example "+1 Dert per higher layer".

It's supposed to be clear in the code, but it's for guiding the code development and IMO the initial impression is confusing.

In frame_blobs.py it is explained that each pattern processes a higher and lower line, y starts at 0 and is scanned sequentially, thus "above" is something with < y, which is created earlier, prior.

However in the current case it could be according to the traversal/creation of the blobs, because it's a "layer", not just a line (maybe it's also above in y as well).

Is the higher layer the root from which the sub_blobs (layers) emerge? Or the layers which are created after traversal are "higher"? +1 suggests that something is added (thus - after the beginning, like a higher order).

The new branches of a tree are usually drawn "below" as "deeper" (lower, below) the root.

The number of the level (steps, depth) however is a "higher" number, while the branches and leaves are likely to be visualized as "lower level" - "going deeper".

[boris-kz]

I don't want to waste that little spark of focus without some contribution.

Focus is not a fixed resource that you save for the winter. It develops with practice.

As of the overlap comparison. Wouldn't something like the inter-blob box comparison be applied in the future inter_blob function?

Box overlap is is to compute redundancy, in inter_blob comp boxes won't need to overlap. But yes, box comp will be good for rough proximity estimate.

Also are such blobs with that coordinate coverage possible?

Possible? They are supposed to be real.

Regarding the latest updates, one thing which I think needs to be more clear is more explicit terminology distinction and mapping in the explanations of "higher layer/lower layer, above/below", as for example "+1 Dert per higher layer".

Yes, I will keep expanding comments. But there are trade-offs, it may get hard to see the forest for the trees.

In frame_blobs.py it is explained that each pattern processes a higher and lower line, y starts at 0 and is scanned sequentially, thus "above" is something with < y, which is created earlier, prior.

However in the current case it could be according to the traversal/creation of the blobs, because it's a "layer", not just a line (maybe it's also above in y as well).

Yes, the layers here consist of sub_blobs, formed by recursive calls to eval_layer in intra_blob. Higher means prior, as frame_blobs, but It's not related to y.

Is the higher layer the root from which the sub_blobs (layers) emerge?

Each sub_blob may also be a root blob for a sub_tree, so it's Derts will represent higher (prior) + current layers. Same for Derts per sub_layer, but more selectively: only positive sub_blobs' params are summed in corresponding Dert. BTW, I will change sub_layer to low_layer for clarity.

Or the layers which are created after traversal are "higher"? +1 suggests

that something is added (thus - after the beginning, like a higher order).

+1 dert per layer above root blob in sub_blobs

so it is added to Dert per current-layer sub_blob logically, but not chronologically

The new branches of a tree are usually drawn "below" as "deeper" (lower,

below) the root.

Yes, that's how I mean it.

—

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

[Twenkid]

I don't want to waste that little spark of focus without some contribution.

Focus is not a fixed resource that you save for the winter. It develops with practice.

Unfortunately mine is a capricious and wild beast - hard to tame.

Also are such blobs with that coordinate coverage possible?

Possible? They are supposed to be real.

Is that yes - the picture is of legitimate blobs?

As of the overlap comparison. Wouldn't something like the inter-blob box comparison be applied in the future inter_blob function?

Box overlap is is to compute redundancy, in inter_blob comp boxes won't need to overlap. But yes, box comp will be good for rough proximity estimate.

They don't need, but could they? My example was regarding cases where long "tentacles" of one blob cover and surround another blob, for example a semi-contour patterns, it has to be open from one of its sides. A grasping hand's silhouette, seen from the sides, would look like that.

Would such a picture, if with low contrast (same intensity given the input resolution), pass as one blob?

The box, as computed, captures the bounding box, the extreme ends. Therefore it would cover the area of any included blob, if I understand it correctly.

Regarding the latest updates, one thing which I think needs to be more

clear is more explicit terminology distinction and mapping in the explanations of "higher layer/lower layer, above/below", as for example "+1 Dert per higher layer".

Yes, I will keep expanding comments. But there are trade-offs, it may get hard to see the forest for the trees.

Well, I believe the summaries, introductions and the more general directions and principles for helping the readers avoid that trap.

In frame_blobs.py it is explained that each pattern processes a higher and lower line, y starts at 0 and is scanned sequentially, thus "above" is something with < y, which is created earlier, prior.

However in the current case it could be according to the traversal/creation of the blobs, because it's a "layer", not just a line (maybe it's also above in y as well).

Yes, the layers here consist of sub_blobs, formed by recursive calls to eval_layer in intra_blob. Higher means prior, as frame_blobs, but It's not related to y.

OK

Is the higher layer the root from which the sub_blobs (layers) emerge?

Each sub_blob may also be a root blob for a sub_tree, so it's Derts will represent higher (prior) + current layers. Same for Derts per sub_layer, but more selectively: only positive sub_blobs' params are summed in corresponding Dert. BTW, I will change sub_layer to low_layer for clarity.

OK.

Or the layers which are created after traversal are "higher"? +1 suggests

that something is added (thus - after the beginning, like a higher order).

+1 dert per layer above root blob in sub_blobs

so it is added to Dert per current-layer sub_blob logically, but not chronologically

The new branches of a tree are usually drawn "below" as "deeper" (lower,

below) the root.

Yes, that's how I mean it.

OK

—

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

.

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

[boris-kz]

Focus is not a fixed resource that you save for the winter. It develops with practice.

Unfortunately mine is a capricious and wild beast - hard to tame.

You know how to tame it, but don't want to. Addictions is a bitch.

Is that yes - the picture is of legitimate blobs?

Yes, blob is a contiguous area of same-sign core parameter. But there is no overlap in your pictures

Box overlap is is to compute redundancy, in inter_blob comp boxes won't need to overlap. But yes, box comp will be good for rough proximity estimate.

They don't need, but could they?

Yes

My example was regarding cases where long "tentacles" of one blob cover and surround another blob, for example a semi-contour patterns, it has to be open from one of its sides. A grasping hand's silhouette, seen from the sides, would look like that.

Would such a picture, if with low contrast (same intensity given the input resolution), pass as one blob?

No

The box, as computed, captures the bounding box, the extreme ends. Therefore it would cover the area of any included blob, if I understand it correctly.

Box overlap is only initial filter for computing blob overlap, it doesn't actually compute blob overlap.

Yes, I will keep expanding comments. But there are trade-offs, it may get hard to see the forest for the trees.

Well, I believe the summaries, introductions and the more general directions and principles for helping the readers avoid that trap.

I keep adding these summaries, etc. My ratio of comments to code is > 10 Just posted another update, some revisions, more comments, changed intra_blob branch() to make comp_angle conditional on eval_layer, etc.

—

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

[Twenkid]

Is that an overlap? (A complete inclusion of a blob within another blob's box)

Well, I believe the summaries, introductions and the more general directions and principles for helping the readers avoid that trap. I keep adding these summaries, etc. My ratio of comments to code is > 10

OK

Just posted another update, some revisions, more comments, changed intra_blob branch() to make comp_angle conditional on eval_layer, etc.

That changed line?:

was: val_ += [(val_angle, 0, sub_blob), (val_deriv, 1, sub_blob), (val_range, 2, sub_blob)]
now: val_ += [(val_angle, 0, ablob), (val_deriv, 1, ablob), (val_range, 2, ablob)]

if typ == 0:
        master_blob(blob, comp_angle)
        for ablob in blob.sub_blob[1]:

Maybe blob. sub_blobs[1]? (not sub_blob), according to

frame[1].append(nt_blob(typ=0, sign=s, Y=Y, X=X, Ly=Ly, L=L,
                                Derts = [(I, Dy, Dx, G)],
                                derts_ = [dert__],  # extend all elements
                                sub_blobs = ([(0,0,0,0,0,0)], []), # [(Ly, L, I, Dy, Dx, G)], sub_blob_
                                 (...)

(Thinking out loud) Then it is supposed to have a higher layer, so Derts could be sampled at[-2]:

         I, Dx, Dy, G = ablob.Derts[-2]   # Derts include params of all higher layers
        A, Dxa, Dya, Ga = ablob.Derts[-1]; L = ablob.L

Then va_angle repeats the latest gradient, while val_deriv and then val_range are "interactions" of current angle and previous x Derts' gradients, some sort of comparison should be done over the selected patterns.

            val_angle = Ga  # value of comp_ga -> gga, eval comp_angle(dax, day), next layer / aga_blob
            val_deriv = ((G + ave * L) / ave * L) * -Ga  # relative G * -Ga: angle match, likely edge
            val_range = G - val_deriv  # non-directional G: likely d reversal, distant-pixels match

Also probably blob.sub_blobs? Or reverting to subblob as a naming convention.

if val > ave * blob.Derts[-1][-1] * rdn + ave_blob:  # val > ave * G * rdn + fixed cost of master_blob per branch
            for sub_blob in blob.sub_blob_:  # sub_blobs are angle blobs

The transition of some of the parameters to the "global" blob's scope and making them labeled (instead of params[index]....) is good for readability and one index less, since these "params" would just have these fixed types and meaning, but won't be of modifiable types or meta- parameters.

frame[1].append(nt_blob(typ=0, sign=s, Y=Y, X=X, Ly=Ly, L=L,
                                Derts = [(I, Dy, Dx, G)],

What do you mean with the note:

# or replace:
 # Derts <- sub_blobs <- low_layers, root params are not selective?
 # then add depth = 0|1|2: levels of derts_?

Overwriting Derts with sub_blobs, low_layers and using depth as a flag for their meaning, because root params are not selective? (Not used for further branching.)

If so, wouldn't that be a loss of data? I believe more redundancy is better for now, if I'm not mistaken you also mention it somewhere.

The redundant representations could be more generative and some repetitions may be suggestive, that's how patterns are recognized.

In general I think overwriting is more confusing for readability. A depth parameter would suggest which step of the overwrite is, but this is yet another index and redirection. Cognitive-wise to me it seems that distinct locations are remembered more easily and would be more easily kept "present" together in the focus, thus suggesting comparison and generalization.

[boris-kz]

[image: image] https://user-images.githubusercontent.com/23367640/54907914-5e6f1800-4eef-11e9-876e-bcffb46990c6.png

Is that an overlap? (A complete inclusion of a blob within another blob's box)

It's a box overlap, but not blob overlap. The former is just an initial test for computing the latter.

Just posted another update, some revisions, more comments, changed

intra_blob branch() to make comp_angle conditional on eval_layer, etc.

That changed line?:

was: val_ += [(val_angle, 0, sub_blob), (val_deriv, 1, sub_blob), (val_range, 2, subblob)] now: val += [(val_angle, 0, ablob), (val_deriv, 1, ablob), (val_range, 2, ablob)]

No

if typ == 0: master_blob(blob, comp_angle) for ablob in blob.sub_blob[1]:

Yes, compangle estimated value is now merged into layer-wide val, which is evaluated in eval_layer. Before, It was evaluated only branch, independently of other potentially overlapping branches in a layer.

Maybe blob. sub_blobs[1]?

This is subblob:

according to

frame[1].append(ntblob(typ=0, sign=s, Y=Y, X=X, Ly=Ly, L=L, Derts = [(I, Dy, Dx, G)], derts = [dert__], # extend all elements sub_blobs = ([(0,0,0,0,0,0)], []), # [(Ly, L, I, Dy, Dx, G)], subblob (...)

(Thinking out loud) Then it is supposed to have a higher layer, so Derts could be sampled at[-2]:

     I, Dx, Dy, G = ablob.Derts[-2]   # Derts include params of all higher layers
    A, Dxa, Dya, Ga = ablob.Derts[-1]; L = ablob.L

Then va_angle repeats the latest gradient, while val_deriv and then val_range are "interactions" of current angle and previous x Derts' gradients, some sort of comparison should be done over the selected patterns.

        val_angle = Ga  # value of comp_ga -> gga, eval comp_angle(dax, day), next layer / aga_blob
        val_deriv = ((G + ave * L) / ave * L) * -Ga  # relative G * -Ga: angle match, likely edge
        val_range = G - val_deriv  # non-directional G: likely d reversal, distant-pixels match

This is mixed-branch evaluation, it hasn't changed. I only changed comp_angle from secondary branch to top-level alternative branch.

Also probably blob.sub_blobs? Or reverting to subblob as a naming convention.

subblob is still there, but packed in sub_blobs

if val > ave blob.Derts[-1][-1] rdn + ave_blob: # val > ave G rdn + fixed cost of master_blob per branch for sub_blob in blob.subblob: # sub_blobs are angle blobs

Actually, I forgot to update that, it should be:

if val > ave blob.L rdn + ave_blob: # val > ave blob_area rdn + fixed cost of master_blob per branch

for sub_blob in blob.sub_blob[1]:  # sub_blob_ of any type

What do you mean with the note:

or replace:

Derts <- sub_blobs <- low_layers, root params are not selective?

then add depth = 0|1|2: levels of derts_?

Overwriting Derts with sub_blobs, low_layers and using depth as a flag for their meaning, because root params are not selective? (Not used for further branching.)

Right, good that you noticed it.

If so, wouldn't that be a loss of data? I believe more redundancy is better for now, if I'm not mistaken you also mention it somewhere.

There is no loss, it's just that instead of blob-level Derts we will have sub_blob - level Derts, that's only subdividing the same data. sub_blobs <- low_layers is different, sub_blobs is not subdivided. On the opposite, multiple sub_blobs will be packed into deeper layers, and their Derts will be merged.

The redundant representations could be more generative and some repetitions

may be suggestive, that's how patterns are recognized.

But redundancies must traced, which is more confusing.

In general I think overwriting is more confusing for readability. A depth parameter would suggest which step of the overwrite is, but this is yet another index and redirection.

It reflects logic of the process, which must be understood anyway. Structures formed by conditional recursion must have variable depth, which should be made explicit. This is a very general principle, important to understand for future extension of the alg.

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

[Twenkid]

On Monday, March 25, 2019, Boris Kazachenko notifications@github.com wrote:

[image: image] https://user-images.githubusercontent.com/23367640/54907914-5e6f1800- 4eef-11e9-876e-bcffb46990c6.png

Is that an overlap? (A complete inclusion of a blob within another blob's box)

It's a box overlap, but not blob overlap. The former is just an initial test for computing the latter.

Could you draw sample blob overlap, inter- and intra-?

Just posted another update, some revisions, more comments, changed

intra_blob branch() to make comp_angle conditional on eval_layer, etc.

That changed line?:

was: val_ += [(val_angle, 0, sub_blob), (val_deriv, 1, sub_blob), (val_range, 2, subblob)] now: val += [(val_angle, 0, ablob), (val_deriv, 1, ablob), (val_range, 2, ablob)]

No

if typ == 0: master_blob(blob, comp_angle) for ablob in blob.sub_blob[1]:

Yes, compangle estimated value is now merged into layer-wide val, which is evaluated in eval_layer. Before, It was evaluated only branch, independently of other potentially overlapping branches in a layer.

Maybe blob. sub_blobs[1]?

This is subblob:

according to

frame[1].append(ntblob(typ=0, sign=s, Y=Y, X=X, Ly=Ly, L=L, Derts = [(I, Dy, Dx, G)], derts = [dert__], # extend all elements sub_blobs = ([(0,0,0,0,0,0)], []), # [(Ly, L, I, Dy, Dx, G)], subblob (...)

(Thinking out loud) Then it is supposed to have a higher layer, so Derts could be sampled at[-2]:

I, Dx, Dy, G = ablob.Derts[-2] # Derts include params of all higher layers A, Dxa, Dya, Ga = ablob.Derts[-1]; L = ablob.L

Then va_angle repeats the latest gradient, while val_deriv and then val_range are "interactions" of current angle and previous x Derts' gradients, some sort of comparison should be done over the selected patterns.

val_angle = Ga # value of comp_ga -> gga, eval comp_angle(dax, day), next layer / aga_blob val_deriv = ((G + ave L) / ave L) -Ga # relative G -Ga: angle match, likely edge val_range = G - val_deriv # non-directional G: likely d reversal, distant-pixels match

This is mixed-branch evaluation, it hasn't changed. I only changed comp_angle from secondary branch to top-level alternative branch.

Also probably blob.sub_blobs? Or reverting to subblob as a naming convention.

subblob is still there, but packed in sub_blobs

if val > ave blob.Derts[-1][-1] rdn + ave_blob: # val > ave G rdn + fixed cost of master_blob per branch for sub_blob in blob.subblob: # sub_blobs are angle blobs

Actually, I forgot to update that, it should be:

if val > ave blob.L rdn + ave_blob: # val > ave blob_area rdn + fixed cost of master_blob per branch

for sub_blob in blob.sub_blob[1]: # subblob of any type

What do you mean with the note:

or replace:

Derts <- sub_blobs <- low_layers, root params are not selective?

then add depth = 0|1|2: levels of derts_?

Overwriting Derts with sub_blobs, low_layers and using depth as a flag for their meaning, because root params are not selective? (Not used for further branching.)

Right, good that you noticed it.

If so, wouldn't that be a loss of data? I believe more redundancy is better for now, if I'm not mistaken you also mention it somewhere.

There is no loss, it's just that instead of blob-level Derts we will have sub_blob - level Derts, that's only subdividing the same data. sub_blobs <- low_layers is different, sub_blobs is not subdivided. On the opposite, multiple sub_blobs will be packed into deeper layers, and their Derts will be merged.

In general I think overwriting is more confusing for readability. A depth

parameter would suggest which step of the overwrite is, but this is yet another index and redirection.

It reflects logic of the process, which must be understood anyway.

OK

Structures formed by conditional recursion must have variable depth, which should be made explicit. This is a very general principle, important to understand for future extension of the alg.

Tracking depth explicitly is OK, similar to len(...)-checks for lists, but more direct. If there are overwrites at the same variable identifier and there is different semantics after each level (in the same recursive function) and the conditions for different recursion outcomes depend on the current depth, then some parameter/flag would be just required.

In the other path without overwrites, the length of the other structures, initially empty, is checked in an appropriate order for conditional branching of the code.

I agree that the overwrite is more "elegant" and in a longer run when it is powerful enough to generate code and structures, the initial would be only the root placeholders, they would be generic and/or containers as with the underscore lists.

BTW I noticed that you've started to use function pointers, for hypot_g. One step closer to meta code. At some point the function pointers of comparison operators may become parameters of the patterns.

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

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

[boris-kz]

Could you draw sample blob overlap, inter- and intra-?

It's very simple, overlap is the number of pixels covered by both blobs

There is no loss, it's just that instead of blob-level Derts we will have

sub_blob - level Derts, that's only subdividing the same data. sub_blobs <- low_layers is different, sub_blobs is not subdivided. On the opposite, multiple sub_blobs will be packed into deeper layers, and their Derts will be merged.

In general I think overwriting is more confusing for readability. A depth

parameter would suggest which step of the overwrite is, but this is yet another index and redirection.

It reflects logic of the process, which must be understood anyway.

OK

Actually, only sub_blobs flag may be needed, then it's sub_blobs = [sub_blobs] by default. Because then the depth of lower layers will increase sequentially with their index.

Structures formed by conditional recursion must have variable depth, which

should be made explicit. This is a very general principle, important to understand for future extension of the alg.

I agree that the overwrite is more "elegant" and in a longer run when it is powerful enough to generate code and structures, the initial would be only the root placeholders, they would be generic and/or containers as with the underscore lists.

Good

BTW I noticed that you've started to use function pointers, for hypot_g. One step closer to meta code.

Did you mean in master_blob(), generic_branch()? That was Khanh' idea.

At some point the function pointers of comparison operators may become parameters of the patterns.

Don't see why, patterns are passive data, they only need type indicators for functions that formed them. Because subsequent function types depend on evaluation, it's not predetermined.

[boris-kz]

Overlap is only possible if blobs are of different types.

On Mon, Mar 25, 2019, 10:02 AM Boris Kazachenko boris.kz@gmail.com wrote:

Could you draw sample blob overlap, inter- and intra-?

It's very simple, overlap is the number of pixels covered by both blobs

There is no loss, it's just that instead of blob-level Derts we will have

sub_blob - level Derts, that's only subdividing the same data. sub_blobs <- low_layers is different, sub_blobs is not subdivided. On the opposite, multiple sub_blobs will be packed into deeper layers, and their Derts will be merged.

In general I think overwriting is more confusing for readability. A depth

parameter would suggest which step of the overwrite is, but this is yet another index and redirection.

It reflects logic of the process, which must be understood anyway.

OK

Actually, only sub_blobs flag may be needed, then it's sub_blobs = [sub_blobs] by default. Because then the depth of lower layers will increase sequentially with their index.

Structures formed by conditional recursion must have variable depth, which

should be made explicit. This is a very general principle, important to understand for future extension of the alg.

I agree that the overwrite is more "elegant" and in a longer run when it is powerful enough to generate code and structures, the initial would be only the root placeholders, they would be generic and/or containers as with the underscore lists.

Good

BTW I noticed that you've started to use function pointers, for hypot_g. One step closer to meta code.

Did you mean in master_blob(), generic_branch()? That was Khanh' idea.

At some point the function pointers of comparison operators may become parameters of the patterns.

Don't see why, patterns are passive data, they only need type indicators for functions that formed them. Because subsequent function types depend on evaluation, it's not predetermined.

[Twenkid]

On Monday, March 25, 2019, Boris Kazachenko notifications@github.com wrote:

Overlap is only possible if blobs are of different types.

Thanks, OK. I meant visually, specific cases.

On Mon, Mar 25, 2019, 10:02 AM Boris Kazachenko boris.kz@gmail.com wrote:

Could you draw sample blob overlap, inter- and intra-?

It's very simple, overlap is the number of pixels covered by both blobs

I know that it is this:

olp = np.logical_and(map1, map2).sum()  # compute number of

overlapping pixels return olp

BTW I noticed that you've started to use function pointers, for hypot_g.

One step closer to meta code.

Did you mean in master_blob(), generic_branch()? That was Khanh' idea.

Yes.

At some point the function pointers of comparison operators may become

parameters of the patterns.

Don't see why, patterns are passive data, they only need type indicators for functions that formed them. Because subsequent function types depend on evaluation, it's not predetermined.

It is true that technically type indication would do the same, with conditions and calls to the respective functions (if they already existed and are not generated in the low level code by the algorithm). This practically serve like "function pointers", similar to switch-case in C-like languages.

It's true also that sufficiently general/exhaustive/complete low level code for pattern exploration and analysis and their representation works like "code generation" when these representations of the patterns are traversed/parsed - the content, instructions of the generated code are the structures and the way they are traversed.

Explicit function pointers may be useful for readability and modularity in some cases (no if type=... but just call)

I agree that it is not required for now, but it is cool in general and provides some useful aspects of classes, polymorphism-like behavior, without all the syntactic overhead of full classes.

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

[boris-kz]

Thanks, OK. I meant visually, specific cases.

Just cross your fingers, the crossing is the overlap.

[Twenkid]

Hi Boris. Is it convenient to talk on Skype about the current problems you're working on tomorrow, 15:xx-16:xx Boston time?

[boris-kz]

Sure, ~15:00?

On Sun, Mar 31, 2019 at 5:41 PM Todor Arnaudov notifications@github.com wrote:

Hi Boris. Is it convenient to talk on Skype about the current problems you're working on tomorrow, 15:xx-16:xx Boston time?

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

[Twenkid]

Great, that's 22h mine AFAIK to https://time.is/Boston (Now it's 23:47 my time.) I could talk now, too, but I think it's better to prepare for tomorrow.

[boris-kz]

Actually, it's 17:50 in Boston now, so 22h will be 16h Boston. Talk to you at 16h?

On Sun, Mar 31, 2019 at 5:47 PM Todor Arnaudov notifications@github.com wrote:

Great, that's 22h mine AFAIK to https://time.is/Boston (Now it's 23:47 my time.) I could talk now, too, but I think it's better to prepare for tomorrow.

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

[Twenkid]

Sorry, 23:47 was wrong, it was 0:47 - I've checked a wrong watch which I haven't updated to Summer time. Both are OK, better earlier, I'll write here again tomorrow.

[boris-kz]

ok, let's plan on 15h for now.

On Sun, Mar 31, 2019 at 5:58 PM Todor Arnaudov notifications@github.com wrote:

Sorry, 23:47 was wrong, it was 0:47 - I've checked a wrong watch which I haven't updated to Summer time. Both are OK, better earlier, I'll write here again to adjust it when it's convenient.

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

[Twenkid]

OK

[Twenkid]

Hi Boris, I'm online.

[Twenkid]

@khanh93vn Hi Khan (I couldn't add a comment in your repository, that's why I write here)

I've been watching the updates, and just noticed this:

In comp_angle:

  if len(dert) < 6:           # check if angle exists in dert
        ncomp, dy, dx = dert[3]

If the len is => 6 it would mean that the type of the dert is not appropriate, a higher order one? To pass it should have 4 variables?

[khanh93vn]

Hi Tosh,

a dert might be compared 2 times so I appended computed angle into it for later use, if that's the case, dert's length is increased to 6: y, x, i, (ncomp, dy, dx), g.

But after the latest discussion, we decided that angle of all derts are computed before comparison. Structure of derts are also altered. I'm current;y working on it right now.

[Twenkid]

Thanks. As of the fluidity of current code - OK, I see and watch the code.

BTW, I again think of developing tools with a GUI for displaying structures and relations in the code, generating code etc. and for storing, making visible the stable part of the algorithm and some general visualisations. I will see will it happen, though, but as I expose myself to the already developed code, I notice more clearly the more general structures as of adding variable, do iteration over existing ones from the previous step by unpacking it using the structure from the prev.step etc. which is a candidate for some alternative more higher level and more notation.

On Saturday, April 6, 2019, Khanh Nguyen notifications@github.com wrote:

Hi Tosh,

a dert might be compared 2 times so I appended computed angle into it for later use, if that's the case, dert's length is increased to 6: y, x, i, (ncomp, dy, dx), g.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub

[boris-kz]

Use. Your. Brain.

On Sat, Apr 6, 2019 at 6:51 AM Todor Arnaudov notifications@github.com wrote:

Thanks. As of the fluidity of current code - OK, I see. BTW, I again think of developing tools with a GUI for displaying structures and relations in the code, generating code etc.

On Saturday, April 6, 2019, Khanh Nguyen notifications@github.com wrote:

Hi Tosh,

a dert might be compared 2 times so I appended computed angle into it for later use, if that's the case, dert's length is increased to 6: y, x, i, (ncomp, dy, dx), g.

And s? (These are 5)

But after the latest discussion, we decided that angle of all derts are computed before comparison. Structure of derts are also altered. I'm current;y working on it right now.

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

.

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

[Twenkid]

That's the natural step of understanding the code, see above (I initially sent accidently unfinished message).

[boris-kz]

The code doesn't fall from the sky.

On Sat, Apr 6, 2019 at 7:01 AM Todor Arnaudov notifications@github.com wrote:

That's the natural step of understanding the code, see above (I initially sent accidently unfinished message).

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

[Twenkid]

Yes, it falls from generative structures which besides the low level code (for the final output like var+=1) include a higher level code and verbs like iterate, accumulate, traverse, extend with a variable (adding L, adding Ly, adding ....), select pattern from a list, sort by a key, choose (traverse) operator, compare, check a condition of sign and split, open a pattern (initialize a structure with a given number of variables and their type (flat, tuples of type ..., List, numpy array)... then close the pattern (terminate) - this is done when parsing code as well, like parsing a function or a data structure etc.

On Saturday, April 6, 2019, Boris Kazachenko notifications@github.com wrote:

The code doesn't fall from the sky.

On Sat, Apr 6, 2019 at 7:01 AM Todor Arnaudov notifications@github.com wrote:

That's the natural step of understanding the code, see above (I initially sent accidently unfinished message).

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

— 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/25#issuecomment-480495080, or mute the thread https://github.com/notifications/unsubscribe-auth/AWSP2MzU8dN9n-1A8PDTR5sFd0vZe9Dlks5veH7JgaJpZM4cDdFN .

[boris-kz]

You got it backwards, "generative structures" is the code, designed to implement principles explained in the intro. Try actually writing it, that will change your perspective.

On Sat, Apr 6, 2019 at 11:00 AM Todor Arnaudov notifications@github.com wrote:

Yes, it falls from generative structures which besides the low level code (for the final output like var+=1) include a higher level code and verbs like iterate, accumulate, traverse, extend with a variable (adding L, adding Ly, adding ....), select pattern from a list, sort by a key, choose (traverse) operator, compare, check a condition of sign and split, open a pattern (initialize a structure with a given number of variables and their type (flat, tuples of type ..., List, numpy array)... then close the pattern (terminate) - this is done when parsing code as well, like parsing a function or a data structure etc.

On Saturday, April 6, 2019, Boris Kazachenko notifications@github.com wrote:

The code doesn't fall from the sky.

On Sat, Apr 6, 2019 at 7:01 AM Todor Arnaudov notifications@github.com wrote:

That's the natural step of understanding the code, see above (I initially sent accidently unfinished message).

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

— 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/25#issuecomment-480495080, or mute the thread < https://github.com/notifications/unsubscribe-auth/AWSP2MzU8dN9n-1A8PDTR5sFd0vZe9Dlks5veH7JgaJpZM4cDdFN

.

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

[Twenkid]

The generative structures I'm talking about are abstract, either in your brain, the intro or induced by observing the code and generalizing the repetitive patterns in the code domain and data structures. If you understand it so that you could code it manually you should be able to automate the redundant parts, it gets tedious and-or repetitive. The code is more suggestive than the principles, text rather confuses too much. Also there is no feedback which could eventually direct (as adjusting something, varying around). What directs now for the code domain are rather the patterns in the code.

On Saturday, April 6, 2019, Boris Kazachenko notifications@github.com wrote:

You got it backwards, "generative structures" is the code, designed to implement principles explained in the intro.

Try actually writing it, that will change your perspective.

On Sat, Apr 6, 2019 at 11:00 AM Todor Arnaudov notifications@github.com

wrote:

Yes, it falls from generative structures which besides the low level code (for the final output like var+=1) include a higher level code and verbs like iterate, accumulate, traverse, extend with a variable (adding L, adding Ly, adding ....), select pattern from a list, sort by a key, choose (traverse) operator, compare, check a condition of sign and split, open a pattern (initialize a structure with a given number of variables and their type (flat, tuples of type ..., List, numpy array)... then close the pattern (terminate) - this is done when parsing code as well, like parsing a function or a data structure etc.

On Saturday, April 6, 2019, Boris Kazachenko notifications@github.com wrote:

The code doesn't fall from the sky.

On Sat, Apr 6, 2019 at 7:01 AM Todor Arnaudov < notifications@github.com> wrote:

That's the natural step of understanding the code, see above (I initially sent accidently unfinished message).

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

— 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/25#issuecomment-480495080, or mute the thread < https://github.com/notifications/unsubscribe-auth/ AWSP2MzU8dN9n-1A8PDTR5sFd0vZe9Dlks5veH7JgaJpZM4cDdFN

.

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

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