Junction Algebra
Included in my 'On junctions' message were some questions that have not been directly answered. I simplify and expand them here. Here I use === to mean 'is the same as'. (I am not sure which of == or === should be used.) 1) Is the following true for an any junction? any( ... , any('foo','bar')) === any(...,'foo','bar') If yes, then if an 'any' junction is contained in an outer 'any', the inner 'any' can be factored out? 2) Also, is the following true for nested 'all' junctions? viz. all(... , all('foo', 'bar')) === all(...,'foo','bar') 3) Conjecture: The following is true of all junction types, eg., junc(..., junc(...)) === junc(..., ...) 4) Are there any transformations of other nested junctions? Richard
Re: Junction Algebra
On Sat, Mar 28, 2009 at 02:08:22PM +0300, Richard Hainsworth wrote: > 3) Conjecture: The following is true of all junction types, eg., > junc(..., junc(...)) === junc(..., ...) The conjecture is false for one/none junctions: one(0, one(1, 1)) # true one(0, 1, 1) # false none(0, none(0, 0)) # false none(0, 0, 0) # true I'm still considering the any/all cases. Pm
Re: Junction Algebra
On Sat, Mar 28, 2009 at 10:19:31AM -0500, Patrick R. Michaud wrote: > On Sat, Mar 28, 2009 at 02:08:22PM +0300, Richard Hainsworth wrote: > > 3) Conjecture: The following is true of all junction types, eg., > > junc(..., junc(...)) === junc(..., ...) > > The conjecture is false for one/none junctions: > > one(0, one(1, 1)) # true > one(0, 1, 1) # false Boy, I typoed that one. I meant to write: one(1, one(1, 1)) # true one(1, 1, 1)# false Pm
Re: Junction Algebra
Richard Hainsworth conjectured: > 1) Is the following true for an any junction? > any( ... , any('foo','bar')) === any(...,'foo','bar') > > If yes, then > if an 'any' junction is contained in an outer 'any', the inner 'any' can be > factored out? Yes. More precisely, an 'any' that is directly nested inside another 'any' can be flattened. By "directly", I mean with no intervening levels of non-'any' junctions. That is, not like: any(...,all(...,any('foo', 'bar'))) > 2) Also, is the following true for nested 'all' junctions? viz. > all(... , all('foo', 'bar')) === all(...,'foo','bar') Yes, with a similiar "directly" caveat, as above. > 3) Conjecture: The following is true of all junction types, eg., > junc(..., junc(...)) === junc(..., ...) No. As Patrick so ably pointed out, this is not true for 'one' nor for 'none' Damian
Re: Junction Algebra
Here's another useful one: any($x) eqv all($x) eqv one($x) eqv $x but: none($x) !eqv $x That is, applying any, all, or one to a one-item list produces the equivalent to a single item. For an empty list: any() eqv all() eqv (). But what about one() and none()? -- Jonathan "Dataweaver" Lang
Re: Junction Algebra
On Mon, 30 Mar 2009, Jon Lang wrote: > Here's another useful one: > > any($x) eqv all($x) eqv one($x) eqv $x > > but: > > none($x) !eqv $x > > That is, applying any, all, or one to a one-item list produces the > equivalent to a single item. For an empty list: any() eqv all() eqv > (). But what about one() and none()? It seems to me that "one" is out of step with the "scalarness" of junctions; it implies that you have to look for two things, firstly that there is some value in the eigenstates that satisfies whatever condition, and secondly that every other value does not. I suspect that the confusion arises because the original intention would have been to have something along the lines of: none === !any something === !all except that "one" doesn't fit the bill as "something". But back to the original question, since "none" is just a funny spelling for "!any", their mutual combination can be flattened accordingly: none($a, any($b, $c)) == none($a, $b, $c) And (given a suitable interpretation of a monadic "none"): all($a, none($b, $c)) == all($a, none($b), none($c)) Question: Or in general, it doesn't matter how many times you mention a simple scalar in an expression, it always has the same value, so that ( $a <= $x <= $b ) == ( $a <= $x && $x <= $b ) always holds true. However I suspect that if $x = any(-1, +1) this may no longer be the case. This would certainly be false: ( $a <= any(-1,+1) <= $b ) == ( $a <= any(-1,+1) && any(-1,+1) <= $b ) Consider if $a and $b are both 0 ... For this to work it seems that the auto-threading logically must reach back to the point where the junction is created, or at least to be tied to the identity of the junction in some way. Which latter would imply that any($a, $b) !== any($a, $b) There must be a logical way out, but how? Any other comments? What about: $x = any(-1,+1); $x < $x and die; # must not happen (same eigenstate must # be used on both sides of '<' ?) $x < $x.eigenstates.any() or die; # matches for "-1 < +1" -Martin
Re: Junction Algebra
On Mon, Mar 30, 2009 at 9:44 PM, Martin D Kealey wrote: > This would certainly be false: > > ( $a <= any(-1,+1) <= $b ) == ( $a <= any(-1,+1) && any(-1,+1) <= $b ) Clearly, the RHS is true for $a == $b == 0, but I'm not sure the LHS shouldn't also be. Isn't it just syntactic sugar for the RHS? Logically, you might want it to mean something like ∃$x: $x == any(-1,+1) && $a <= $x && $x <= $b, but I don't think it does. -- Mark J. Reed
Re: Junction Algebra
On Mon, 30 Mar 2009, Mark J. Reed wrote: > > ( $a <= any(-1,+1) <= $b ) == ( $a <= any(-1,+1) && any(-1,+1) <= $b > > ) > > Clearly, the RHS is true for $a == $b == 0, but I'm not sure the LHS > shouldn't also be. Isn't it just syntactic sugar for the RHS? I suspect not. Rather I think that $a <= any(-1,+1) <= $b corresponds to $tmp = any(-1,+1); $a <= $tmp <= $b and thence to $tmp = any(-1,+1); $a <= $tmp && $tmp <= $b The more I think about this, the more I come to the conclusion that a junction should appear to have a uniform (single) value in each "eigenthread". > Logically, you might want it to mean something like ∃$x: $x == any(-1,+1) > && $a <= $x && $x <= $b, but I don't think it does. I think that flows fairly cleanly from the Junction-isa-Object implementation, and the way that references are taken. This is not going to play well with subexpression folding: junctions have to be considered "unclean", in that two junctions must not be merged even if they're immutable and indistinguishable (except for object identity). $a = any($x, $y); $b = any($x, $y); assert $a !== $b; Earlier Moritz suggested that one could modify an external object from within the eigenthreads to accumulate the list of eigenstates, in defiance of having the !eigenstates() method private. That's almost reasonable, but it assumes that eigenthreads don't work on separate snapshot copies of the world, and that those snapshots aren't discarded after their results are flattened by the junctive operator. -Martin