Re: Thoughts about Version 3

[ Follow Ups ] [ Post Followup ] [ My Message Board ] [ FAQ ]

Posted by Phil M on August 19, 2003 at 10:38:41:

In Reply to: Thoughts about Version 3 posted by David on August 19, 2003 at 07:20:04:

Sounds good, though I'm thinking a linearly represented nested structure might be better than one that's a pure data tree. It can be parsed to tree form where it counts, but can also be effectively be snipped at /one/ point (with the appropriate tendency to avoid cutting increasing depths of

Similar single snips of a tree is possible, of course. For a tree represented (badly) by the nesting "A(B(CD))E" or (equally bad) diagram:

C - D
|
B - ^
|
A - ^ - E

Snipping such that you have "A(B(CD))E" (and imagine replacing with a complementary structure represented in lower-case) gives you:

c - d
|
b - ^

A - ^ - E ( is snip-point)

Looks good, but as well as maintaining group "B(CD)" you're also effectively creating group "A(?)E" ("?" is any group, or even none). That could give good results of course, but may not help variety. I can think of plusses and minuses.

Snipping once in the nesting representation, for example "A(B(CD))E" (where the snip has the luck to get itself within one layer of nesting/tree/whatever) would give a different appearence to the tree that might take more work to accomplish (my assumption, given that I'm not up on the latest theory and normally use tree structures without the intention of prining) but look like:

!
! c - d
! |
B ! ^
!
A - ! - e
!

("!" is cut-line, obscuring the normal tree symbols of "^", "|" and "-", but they're in the same place as before. I decided to bend the cut rather than shift the (cd) branch representation, but you get the idea. :)

Also, this should solve problem about length, as you can combine the factors relating to the "snip resitance" for both source entities and then, when you've worked out an equitable (and randomly overriden) solution you can combine the two. The method I have in mind would maintain the the tree depths either side of the 'fracture' (if you're undertaking to split an item at a certain location, you don't want to be fussy about matching up the two bits artificially) but would allow identically deep trans-split sections to merge, i.e.:

From: A(B(CD))E + a((bcd))e
To: A(B(Cd))E + a((bcD))E

If there's a level similarity but a sub-group difference, then there's actually more variation to structure:

From: A(BC)(DE)F + a(bcde)f
To: A(BC)(de)f + a(bc)(DE)F

...or else:

From: A(BC)(DE)F + a(bcde)f
To: A(BC)(de)f + a(bcDE)F

... or even:

From: A(BC)(DE)F + a(bcde)f
To: A(BCde)f + a(bc)(DE)F

Note that splits are identically placed w.r.t. words (here individual alphabetic characters) but can be shuffled w.r.t nesting/level indicators (parenthises) in the intra-word gap.

Thre three last examples all take "humanly readable" ABCDEF and abcdef and create ABCdef and abcDEF, but they will have different reproductive legacies to invisibly pass onto their descendants.

You get the idea, even if I'm totally wrong or have even made a typo or two... :)

BTW, I haven't been voting as much as I'd like. I'm going to spend some time rectifying that later, and do my bit for advancement to the 0.5 megavote milestone/millstone... :)

Follow Ups:

Ooops (squared Phil M 10:45:11 8/19/2003 (1)
- Re: Ooops (squared Phil 03:46:02 8/20/2003 (0)
Ooops whitespace monster guzzled my formatting Phil M 10:42:19 8/19/2003 (0)

Post a Followup

Name:
E-Mail:

Subject:

Comments:
: Sounds good, though I'm thinking a linearly represented nested structure might be better than one that's a pure data tree. It can be parsed to tree form where it counts, but can also be effectively be snipped at /one/ point (with the appropriate tendency to avoid cutting increasing depths of : Similar single snips of a tree is possible, of course. For a tree represented (badly) by the nesting "A(B(CD))E" or (equally bad) diagram: : C - D : | : B - ^ : | : A - ^ - E : Snipping such that you have "A<snip>(B(CD))<snip>E" (and imagine replacing with a complementary structure represented in lower-case) gives you: : c - d : | : b - ^ : <!> : A - ^ - E (<!> is snip-point) : Looks good, but as well as maintaining group "B(CD)" you're also effectively creating group "A(?)E" ("?" is any group, or even none). That could give good results of course, but may not help variety. I can think of plusses and minuses. : Snipping once in the nesting representation, for example "A(B<snip>(CD))E" (where the snip has the luck to get itself within one layer of nesting/tree/whatever) would give a different appearence to the tree that might take more work to accomplish (my assumption, given that I'm not up on the latest theory and normally use tree structures without the intention of prining) but look like: : ! : ! c - d : ! | : B ! ^ : ! : A - ! - e : ! : ("!" is cut-line, obscuring the normal tree symbols of "^", "|" and "-", but they're in the same place as before. I decided to bend the cut rather than shift the (cd) branch representation, but you get the idea. :) : Also, this should solve problem about length, as you can combine the factors relating to the "snip resitance" for both source entities and then, when you've worked out an equitable (and randomly overriden) solution you can combine the two. The method I have in mind would maintain the the tree depths either side of the 'fracture' (if you're undertaking to split an item at a certain location, you don't want to be fussy about matching up the two bits artificially) but would allow identically deep trans-split sections to merge, i.e.: : From: A(B(C<snip>D))E + a((bc<snip>d))e : To: A(B(C<join>d))E + a((bc<join>D))E : If there's a level similarity but a sub-group difference, then there's actually more variation to structure: : From: A(BC)<snip>(DE)F + a(bc<snip>de)f : To: A(BC)<join>(de)f + a(bc)<join>(DE)F : ...or else: : From: A(BC)(<snip>DE)F + a(bc<snip>de)f : To: A(BC)(<join>de)f + a(bc<join>DE)F : ... or even: : From: A(BC<snip>)(DE)F + a(bc<snip>de)f : To: A(BC<join>de)f + a(bc<join>)(DE)F : Note that splits are identically placed w.r.t. words (here individual alphabetic characters) but can be shuffled w.r.t nesting/level indicators (parenthises) in the intra-word gap. : Thre three last examples all take "humanly readable" ABCDEF and abcdef and create ABCdef and abcDEF, but they will have different reproductive legacies to invisibly pass onto their descendants. : You get the idea, even if I'm totally wrong or have even made a typo or two... :) : BTW, I haven't been voting as much as I'd like. I'm going to spend some time rectifying that later, and do my bit for advancement to the 0.5 megavote milestone/millstone... :)

Optional Link URL:
Link Title:
Optional Image URL:

[ Follow Ups ] [ Post Followup ] [ My Message Board ] [ FAQ ]