Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

For discussion: operator attributes - associativity, chainity and ability to short-circuit

by rsFalse (Chaplain)
on Jan 13, 2021 at 20:47 UTC ( #11126869=perlmeditation: print w/replies, xml ) Need Help??

Hello.
Perl 5.32 (year 2020) introduced a new ability of binary comparison operators. Now they can be chained! ( https://perldoc.perl.org/5.32.0/perldelta#Chained-comparisons-capability ).
And perldoc describes this new usage in:
* https://perldoc.perl.org/perlop#Operator-Precedence-and-Associativity
* https://perldoc.perl.org/perlop#Relational-Operators
* https://perldoc.perl.org/perlop#Equality-Operators

There are some short-circuiting operators in Perl from before 5.32 version: &&, ||, //, and, or (not xor).

What is difference between associativity and chainity?
I suggest to distinguish these two attributes of operators as follows: associativity only sets a direction of operations; chainity sets an ability to 'communicate' between consecutive operators, in other words - a later operator can influence the behaviour of a former operator.

Then I suggest to improve a table of Perl operators by introducing two more columns: chainity (ability to chain) and ability to short-circuit.
This will help to newcomers and beginners! I have often used these tables of operators from perlcheat and from beginning of the perlop:https://perldoc.perl.org/perlop#Operator-Precedence-and-Associativity, because it takes time to remember precedence and direction of associativity. Two new attributes in the table will be more usable than a searching of them through the whole long perlop document.
In the current table of attributes I find only one column, which contains values: nonassoc, left, right, chained, chain/na. Chained implies associativity, but it lefts its direction undefined, e.g. in the line: "chained     < > <= >= lt gt le ge" newcomer doesn't know direction. We know - it is left-assoc.

Perl is difficult to memorize and it has long learning curve because of its archaity and many many rules with many exceptions, which makes a life easier, but makes learning/memorizing - difficult. So tables/cheatsheets are useful to have near a hand. E.g. operators 'or' and 'xor' seem similar by their appearance and by their category (both are logical operators), but one has an ability to short-circuit and another - hasn't. This was a surprise for me. Upd.The surprise was not about short-circuit, but about returning last evaluated value.

I can't test a new perl 5.32 now (upd. perlbrew isn't working /upd.*, and there are no online IDEs where I could find a new version: all use older versions, including WebPerl:https://webperl.zero-g.net/democode/index.html which uses 5.28).
But I hope that I will be correct when talking further about new abilities of comparison operators.

So, first of all I guess that new version outputs different results for these two lines of codes:
2 < 4 < 3 and ( 2 < 4 ) < 3. In the first example the chaining of operators occurs and in the second example - ordinary comparisons occurs. First outputs - 0/'', second - 1. Am I wrong? Here parentheses cut a chain of operators: one operator doesn't see another. If second behaves same as first then it would be backwards incompatible.

Only some examples of chained comparisons: "1 < 3 <= 3 > 0 le 1 gt 0 ---> 1", "1 < 2 < ... < 9 ---> 1", "1 ne 2 ne 1 ---> 1".

How can we describe a behaviour of chained comparison operators?
I suggest the following way. If an operator "sees" another operator towards the direction of associativity (i.e. it is chained to it), then it changes it behaviour (btw. becomes overloaded) - it compares both operands and in case of TRUE returns right operand (once evaluated), and in case of FALSE - returns 0/''. This description allows the last operator to be not chained, so it will behave as usual comparison op (TRUE - 1, FALSE - 0/'').

Chainity implies (requires) associativity, as ability to short-circuit does, but chaining does not imply an ability to short-circuit and vice versa, so I suggest to keep these two attributes separately. Maybe in a future perl such will occur.
By the way, operators  &&, ||, //, and, or are short-circuiting, but they are not chained (i.e. we can put parentheses in left-assoc pattern to "blind" consecutive operators and result will not change).

Also I have an idea (I don't believe that it is good, but I leave it here if someone wants to discuss). That: writer could choose by himself if he wants his operator to look to the next operator (i.e. to make a chain). One way could be to prepend '&' before an operator. So then $A &< $B &> $C < $D should work as a chain (note no '&' at the last operator).

Once more about tables. From perlop it is unknown which 'equality' operators can be chained and which can not. This needs a clarification.


Here I'll leave some links to older topics (by me), which can be somehow related to this one:
Pls more operators, e.g. <&&=
'xor' operator is not a sibling to 'or' and 'and'?


UPDATE:
Here is my suggestion of an expanded table (which is a bit incomplete, but I want to show an idea). Note that vertical lines mean that some operators are the same precedence but divided into separate lines:
ASSOC. COND. SHORT-C. CHAINS OP. left terms and list operators (leftward +) left -> nonassoc ++ -- right ** right ! ~ \ and unary + and - left =~ !~ left * / % x left + - . left << >> nonassoc named unary operators LEFT no yes yes < > <= >= lt gt le ge | LEFT no yes yes == != eq ne ~~ | LEFT no no no <=> cmp nonassoc isa left & left | ^ left yes yes no && left yes yes no || // nonassoc .. ... right yes no no ?: right = += -= *= etc. goto last next red +o dump left , => nonassoc list operators (rightward) right not left yes yes no and | left yes yes no or | left no no no xor

Upd. Also created a documentation issue asking to expand this table of attributes -- https://github.com/Perl/perl5/issues/18574.

(*upd. perlbrew failed to install from its download page, but later I found it in Software manager and installed.)
  • Comment on For discussion: operator attributes - associativity, chainity and ability to short-circuit
  • Select or Download Code

Replies are listed 'Best First'.
Re: For discussion: operator attributes - associativity, chainity and ability to short-circuit
by Don Coyote (Hermit) on Jan 16, 2021 at 17:11 UTC

    Hello rsFalse

    Perl documentation is written for various levels of Perl hacker.

    Those already confident with programming generally want a quick overview so they can establish how Perl differs from a language they are already well acquainted with. It is fairly common to see descriptions of how Perl does not behave like C in certain situations. This is true of operators especially.

    There are also persons whom are at a high level in other disciplines and have heard that some modules in Perl are very well suited to their purpose. A good example would be Biologists using BioInformatics. They need to know enough to get done what they need for their particular task. At this point the Module Documentation (POD) should be providing suitably usable examples for that level of user.

    Then there are just the hackers, like myself, using the Documentation to learn, along with other resources such as Manuals, contributing to Forums, watching/attending Conferences and so on.

    For the general hacker, ideas such as associativity and precedence can certainly be confusing and do have a learning curve. In the documentation it says that associativity works in similar way to how it works in math. Then precedence enters the equation. And now it seems transitivity or inequality have crashed the party in the hope of forming some relationships.

    Another theme that appears to crop up is that of Perl 5 Documentation unscrupulously objectifying itself. Though this is more of a personal bugbear, I have to admit the use of terminology such as Class for Namespace and Pointers for References within the Documentation is a little misleading/sloppy. Naturally, colloquially using terminology that you are used to is going to occur all around the place, which is completely understandable, as we all do that to some extent.

    Such an approach can be useful for introductory and explanative purposes, the drawback being assumptions travel with the learning. Sure in class we can overlook low-level complexities, for the purpose of communicating the high-level idioms. But after a while the documentation starts reading like a manual for another language.

    Still, regarding the chaining of operators, the documentation is clear about the operators that now have this capability being relational. In the big picture of things, this is the kind of thing that you might do for a particular purpose. As such the user is more than likely aware of the properties of relationships they are studying.

    You provide some arithmetical examples of how chaining might be implemented in some users program. However the string relations also chain now, have you considered how this might be useful for say deciding grammatical order of a sentence based on particular inflections? (lol just made that up, but, for example, I could well imagine people wanting to reinvent unicode using a differnt underlying system). Collation tends to be quite systematic, and again one of the goals of Perl is to be as understandable written as it would be to speak with someone.

    Without labouring the point, Perl arrived at us from a heavy influence of the Humanities, as such it stands out from the mainstream language definitions that tend to be derived from mathematical perspectives. Certainly we should be careful to preserve such perspectives.

    Learning any language is always going to have a curve, sometimes you are going to write code that is complicated to read, maintain. Surely simplifying Documentation goes a way towards reducing that curve, but when learning, the emphasis should be on writing more code, or rather, writing more well commented code.

    In terms of introducing new operators. There are a number of ways in which a user can define operations at a high-level. A straightforward way to start would be to write a subroutine that implements such operations. Then develop from there. Another alternative is to keep in mind that Perl is becoming a family. Raku as far as I am aware, has user-defined operations as standard.

    At this time, I would say it is more productive to focus on ensuring the Documentation is in its best format for all levels. Often, being able to effectively ligature the Documentation to the practice is a quarter or more the fun of learning.

    In a roundabout way, I am saying there could be scope for improving the operator precedence/associativity list. But, I would also say it does already do what it needs to. Creating a table maybe isnt quite justified on its own, just to highlight a slight update in the way a particular group of operators now has an additional capability. The beauty of this kind of thing is that the operators will more likely appear to just work as someone would expect them to first use around, a little better now than they did previously.

    If you wanted to outline how it might look once it was updated, maybe post a short/quick tutorial of how chaining works, including how an updated precedence list might look.


    Where is my lib? Where. Is. My. Lib?
Re: For discussion: operator attributes - associativity, chainity and ability to short-circuit
by Don Coyote (Hermit) on Jan 29, 2021 at 20:57 UTC

    Hello again rsFalse. You got me to thinking.

    Having had another look, I think I see what is happening. Basically, if I am percieving correctly, you are taking return values from different events to be different things.

    However, the nature of this update has also caught my intruige. So informally I've been looking at this in this way.

    Work In Progress as at Fri 29 Jan 2021 pls be patient.

    The return value of the comparison operator is a boolean 1 or 0. Although I would need to check the zero return may be undef which then transforms to 0 used as a string or number. But in practice, it can be considered as evaluating in the perl boolean sense. This means that it tseted for truthiness.

    before we consider what this means for chainified operations lets take a quick look at a typical comparison operator usage. Lets take a constant and compare it to a variable that increases from being lesser to being greater than the constant. That is $kappa starts at 0 and increases through to 3. And $mu which remains constant at 2. We print a list that tells us whether the comparison returns true or false.

    #!perl -T -w use strict; #use wtf8; my ($kappa,$mu) = (0,2); print "Is $kappa lesser than $mu ?:\n"; printf "%8s%s%-4s%s\n",'$kappa',' < ','$mu','-> boolean context'; my $bool = $kappa < $mu; printf "%8d%s%-4d%s%d\n","$kappa",' < ',"$mu",'-> ', $bool; while( ++$kappa ){ # prefix increment $bool = $kappa < $mu; printf "%8d%s%-4d%s%d\n",$kappa,' < ',$mu, '-> ',$bool; last if $kappa == 3; } __END__ #OUTPUT $kappa < $mu -> boolean context 0 < 2 -> 1 1 < 2 -> 1 2 < 2 -> 0 3 < 2 -> 0

    So what is happening is that the operator returns truthiness. However, perl still needs to access the variables $kappa and $mu to make the comparison during each loop. So during each loop, perl accesses, (looks at) the scalar variables then makes the comparison using our chosen comparison operator. Then returns whether the comparison equates to being true or false, 1 or 0 respectively. This is known as boolean context, which is a sub-context of scalar context in perl.

    Context is one of the fundamental concepts within perl 5, and its fairly straightforward once you understand it. Most of the time you are using context without realising. Let me quickly describe how context is working using the while loop I have introduced here. Now to make the while loop work as I desired I needed to understand that the while condition evaluates in scalar context. Basically While loops continue running while the condition is true, which in perl means the return value is neither numerically 0 nor undefined. So I had to make sure that the first time the loop evalutes $kappa it did not evaluate to the number 0 or undefined. This is why you will often see constructs such as while(my $v = defined( shift( @array ) ) ){ print $v; }. So, without getting too complicated, I make sure $kappa returns 1 in the while condition and then exit the loop from within, by using the last statement on the condition that $kappa reaches 3.

    Otherwise this does not work, the while condition evaluates false on first run and so skips running the while code block.

    ($kappa,$mu) = (0,2); print "Is $kappa lesser than $mu ?:\n"; printf "%8s%s%-4s%s\n",'$kappa',' < ','$mu','-> boolean context'; $bool = $kappa < $mu; printf "%8d%s%-4d%s%2d\n",$kappa,' < ',$mu, '-> ',$bool; while( $kappa++ ){ # postfix increment $bool = $kappa < $mu; printf "%8d%s%-4d%s%2d\n",$kappa,' < ',$mu, '-> ',$bool; last if $kappa == 3; } printf "Where is my table?\n"; __END__ #OUTPUT Is 0 lesser than 2 ?: $kappa < $mu -> boolean context 0 < 2 -> 1 Where is my table?

    The comparison operator does not return the value. If we want to get the value for comparison we are evaluating we have to do this in two steps. That is just how this operator works, other operators return scalar values, or lists, or booleans, which is documented in the relevant documentation for that operation. So to get the value we use the boolean return value to split the branch to return the value we want using for example an if condition.

    Like While, if evaluates in scalar context, but just the once, and then returns the relevant code block. Perl accessing the variable to carry out the comparison is not the same thing as returning a value once the comparison has been evaluated. And it is this accessng the variable to carry out the operation which is being explained in the documentation for how chained comparison operators are evaluated. The return value is still boolean, just on a chain of boolean comparison operators rather than on a single boolean comparison operator.

    To return a value we use two steps; Evaluate the comparison for truthiness, then return a value ourselves dependant on that truthiness.

    ($kappa,$mu) = (0,2); printf "%s\n",'$kappa < $mu -> boolean -> value we ask perl to return' +; $bool = $kappa < $mu; my $ret_value; if( $kappa < $mu ){ # if( $bool ) $ret_value = sprintf "%-8s%d", '$kappa: ',$kappa; }else{ $ret_value = sprintf "%-8s%d", '$mu: ',$mu; } printf "%8d%s%-4d%s%-11d%s%s\n",$kappa,' < ',$mu,' -> ',$bool,'-> ',$r +et_value; while( ++$kappa ){ $bool = $kappa < $mu; if( $kappa < $mu ){ # if( $bool ) $ret_value = sprintf "%-8s%d", '$kappa: ',$kappa; }else{ $ret_value = sprintf "%-8s%d", '$mu: ',$mu; } printf "%8d%s%-4d%s%-11d%s%s\n",$kappa,' < ',$mu,' -> ',$bool,'-> ',$ +ret_value; last if $kappa == 3; } __END__ $kappa < $mu -> boolean -> value we ask perl to return 0 < 2 -> 1 -> $kappa: 0 1 < 2 -> 1 -> $kappa: 1 2 < 2 -> 0 -> $mu: 2 3 < 2 -> 0 -> $mu: 2

    To evaluate a chainified comparison perl needs to access some of the variables more than once before making the camparison. What the documentation in perlop describes is how perl does this in the two differing cases of when there is a simple scalar variable and when there is an expression to evaluate. So the idea of short circuiting would only work in specific cases such as when all the comparison operators in the chain are the same. Then when one of the sub evaluations returns false, the whole statement can be considered false. But this would not work generally, as you suggest, on a chain of operations that involves multiple different comparison operators. In general, that is not to say certain variations of operators chained would not reduce to an ability to shortcut depending on whether it was truly boolean of course.

    Revise SectionEssentially what chaining of operators now allows us to do is to write.

    while( $kappa < $mu ){ $ret_value = $kappa }

    Revise Section end

    perhaps I dont really want to create a huge table with all the possibilities laid out. Maybe I just want to test the conditions when the comparison is true.

    print qq{\n}; ($kappa,$mu) = (0,15); $bool = $kappa < $mu; if( $kappa < $mu ){ # if( $bool ) $ret_value = sprintf "%-8s%d", '$kappa: ',$kappa; }else{ $ret_value = sprintf "%-8s%d", '$mu: ',$mu; } printf "%8d%s%-4d%s%-11d%s%s\n",$kappa,' < ',$mu,' -> ',$bool,'-> ',$r +et_value; __END__ $kappa < $mu -> boolean -> value we ask perl to return 0 < 15 -> 1 -> $kappa: 0

    On my first comparison i know the comparison returns true. however I just want to show wat happens when the statement is false. I could just reverse the operator or the operands, but for whatever reason I am unable to do that. So I use the anti operation of While, Until, to increment my variable to a value that suits the condition. And then run my evaluating program on my required value.

    print qq{\n}; $kappa++ until( $kappa > $mu ); $bool = $kappa < $mu; if( $kappa < $mu ){ # if( $bool ) $ret_value = sprintf "%-8s%d", '$kappa: ',$kappa; }else{ $ret_value = sprintf "%-8s%d", '$mu: ',$mu; } printf "%8d%s%-4d%s%-11d%s%s\n",$kappa,' < ',$mu,' -> ',$bool,'-> ',$r +et_value; __END__ $kappa < $mu -> boolean -> value we ask perl to return 16 < 15 -> 0 -> $mu: 15

    This time I know the reverse is true, and my table only has the values for which I am interested in, rather than for all of the intervening values. Prior to chaining if I wanted to do this with more values I would have needed to use the relevant logical operators for my specification.

    So one place this might come in handy is evaluating relations. Here is a simple contrived example that evaluates two permutations from six of a relation between addition of two numbers ad which of those numbers is larger. The point is that prior to chaining we will need to use the logical operators between the comparison operators. In theory chaining will now allow us to just enter the comparison relation in the until. However as oyu can see form this simple example, you will still need to calculate all the logic that you wish your program to convey.

    # An approach to coding the proof for Distribution rule # for Summation and Union over the Natural Realm # re MF:C:155 my($nu,$lhs,$rhs); ($kappa,$mu,$nu) = (3,4,5); if( $kappa < $mu and $mu < $nu ){ print "Evaluating relation when \$kappa:$kappa < \$mu:$mu < \$nu:$nu +\n"; $lhs = $kappa + ( $mu < $nu ? $nu : $mu ); $rhs = ( $kappa + $mu ) < ( $kappa + $nu ) ? $kappa + $nu : $kappa + + $mu ; print "\$lhs:$lhs = \$kappa:$kappa + \$nu:$nu\n"; print "\$rhs:$rhs = \$kappa:$kappa + \$nu:$nu\n"; print "Evaluation of relation ", $lhs == $rhs ? 'succeeded' : 'faile +d'; print qq{\n}; } until( $kappa > $mu and $mu > $nu ){ $mu *= $mu unless $mu > $nu; $kappa *= $kappa unless $kappa > $mu; # print "\$kappa:$kappa \$mu:$mu \$nu:$nu\n"; } #print "\$kappa:$kappa > \$mu:$mu > \$nu:$mu" #now we have interchanged the values not the operators if( $nu < $mu and $mu < $kappa ){ print "Evaluating relation when \$nu:$nu < \$mu:$mu < \$kappa:$kappa +\n"; $lhs = $nu + ( $mu > $kappa ? $mu : $kappa ); # $rhs = ( $nu > $mu ? $nu : $mu ) + ( $nu < $kappa ? $nu : $kappa ) +; $rhs = ( $nu + $mu ) > ( $nu + $kappa ) ? $nu + $mu : $nu + $kappa + ; print "\$lhs:$lhs = \$kappa:$kappa + \$mu:$mu\n"; print "\$rhs:$rhs = \$kappa:$kappa + \$mu:$mu\n"; print "Evaluation of relation ", $lhs == $rhs ? 'succeeded' : 'faile +d'; print qq{\n}; } __END__ Evaluating relation when $kappa:3 < $mu:4 < $nu:5 $lhs:8 = $kappa:3 + $nu:5 $rhs:8 = $kappa:3 + $nu:5 Evaluation of relation succeeded Evaluating relation when $nu:5 < $mu:16 < $kappa:81 $lhs:86 = $kappa:81 + $mu:16 $rhs:86 = $kappa:81 + $mu:16 Evaluation of relation succeeded

    Actually those if statements dont really need to be there, and by wrap the until in a subroutine, we may be able to do all the permutation logic programmatically...

    this example is a work in progress, as I would like to develop the full relation proof. However there is enough here to satisfy the explanation of chaining, so it is published in its present format as wip (est. a week or less providing logic is sound.), along with a chaining example for the bleaders. And to make sure I have understood chaining properly, and that it is implemented as suggested.

    What should be noted here is that while we are essentially hardcoding the relations as we expect them to turn out, we are programmatically altering the values to fit each subsequent permutation, which we could of course hardcode too, but wheres the fun in that?

    So lets do the six permutations and then see if we can reduce them into a permutating program of a couple of subroutines.

    REVISE SECTION: SOMETHINGS NOT QUITE RIGHT HERE

    Apparantley all lhs and rhs cases should be of the form ( k + m ) or ( k + n ). ANd it would appear I have fixed the permutations to produce symmetrical output, rather than testing the same relation on each permutation.To Fix

    An approach to the proof of the Distribution Rule for Summation and Union over the Natural Realm wrt MF(C):155 Prof.NJW

    print qq{\nAn approach to the proof of the Distribution Rule for\n}; print qq{Summation and Union over the Natural Realm wrt MF(C):155 P.NJ +W\n}; # An approach to coding the proof for Distribution rule # for Summation and Union over the Natural Realm # re MF:C:155 #my($nu,$lhs,$rhs); ($kappa,$mu,$nu) = (3,4,5); until( $kappa < $mu and $mu < $nu ){ # skips this, already satisfied $mu *= $mu unless $mu > $nu; $kappa *= $kappa unless $kappa > $mu; print "\$kappa:$kappa \$mu:$mu \$nu:$nu\n"; } print "\nEvaluating relation (P1) when \$kappa:$kappa < \$mu:$mu < \$n +u:$nu\n"; $lhs = $kappa + ( $mu < $nu ? $nu : $mu ); $rhs = ( $kappa + $mu ) < ( $kappa + $nu ) ? $kappa + $nu : $kappa + + $mu ; print "\$lhs:$lhs = \$kappa:$kappa + \$nu:$nu\n"; print "\$rhs:$rhs = \$kappa:$kappa + \$nu:$nu\n"; print "Evaluation of relation ", $lhs == $rhs ? 'succeeded' : 'failed' +; print qq{\n}; until( $kappa < $nu and $nu < $mu ){ $mu *= $mu unless $mu > $nu; $nu *= $nu unless $nu > $kappa; # print "\$kappa:$kappa \$nu:$nu \$mu:$mu\n"; } print "\nEvaluating relation when (P2) \$kappa:$kappa < \$nu:$nu < \$m +u:$mu\n"; $lhs = $kappa + ( $mu < $nu ? $nu : $mu ); $rhs = ( $kappa + $mu ) < ( $kappa + $nu ) ? $kappa + $nu : $kappa + + $mu ; print "\$lhs:$lhs = \$kappa:$kappa + \$mu:$mu\n"; print "\$rhs:$rhs = \$kappa:$kappa + \$mu:$mu\n"; print "Evaluation of relation ", $lhs == $rhs ? 'succeeded' : 'failed' +; print qq{\n}; until( $mu < $kappa and $kappa < $nu ){ $nu *= $nu unless $nu > $kappa; $kappa *= $kappa unless $kappa > $mu; # print "\$mu:$mu \$kappa:$kappa \$nu:$nu\n"; } print "\nEvaluating relation (P3) when \$mu:$mu < \$kappa:$kappa < \$n +u:$nu\n"; $lhs = $mu + ( $kappa < $nu ? $nu : $kappa ); $rhs = ( $mu + $kappa ) < ( $mu + $nu ) ? $mu + $nu : $mu + $kappa ; print "\$lhs:$lhs = \$mu:$mu + \$nu:$nu\n"; print "\$rhs:$rhs = \$mu:$mu + \$nu:$nu\n"; print "Evaluation of relation ", $lhs == $rhs ? 'succeeded' : 'failed' +; print qq{\n}; until( $mu < $nu and $nu < $kappa ){ $kappa *= $kappa unless $kappa > $nu; $nu *= $nu unless $nu > $mu; # print "\$mu:$mu \$nu:$nu \$kappa:$kappa\n"; } print "\nEvaluating relation (P4) when \$mu:$mu < \$nu:$nu < \$kappa:$ +kappa\n"; $lhs = $mu + ( $kappa < $nu ? $nu : $kappa ); $rhs = ( $mu + $kappa ) < ( $mu + $nu ) ? $mu + $nu : $mu + $kappa ; print "\$lhs:$lhs = \$mu:$mu + \$nu:$nu\n"; print "\$rhs:$rhs = \$mu:$mu + \$nu:$nu\n"; print "Evaluation of relation ", $lhs == $rhs ? 'succeeded' : 'failed' +; print qq{\n}; until( $nu < $kappa and $kappa < $mu ){ $mu *= $mu unless $mu > $kappa; $kappa *= $kappa unless $kappa > $nu; # print "\$nu:$nu \$kappa:$kappa \$mu:$mu\n"; } print "\nEvaluating relation (P5) when \$nu:$nu < \$kappa:$kappa < \$m +u:$mu\n"; $lhs = $nu + ( $mu > $kappa ? $mu : $kappa ); $rhs = ( $nu + $mu ) > ( $nu + $kappa ) ? $nu + $mu : $nu + $kappa ; print "\$lhs:$lhs = \$kappa:$kappa + \$mu:$mu\n"; print "\$rhs:$rhs = \$kappa:$kappa + \$mu:$mu\n"; print "Evaluation of relation ", $lhs == $rhs ? 'succeeded' : 'failed' +; print qq{\n}; until( $nu < $mu and $mu < $kappa ){ $kappa *= $kappa unless $kappa > $mu; $mu *= $mu unless $mu > $nu; # print "\$nu:$nu \$mu:$mu \$kappa:$kappa\n"; } print "\nEvaluating relation (P6) when \$nu:$nu < \$mu:$mu < \$kappa:$ +kappa\n"; $lhs = $nu + ( $mu > $kappa ? $mu : $kappa ); $rhs = ( $nu + $mu ) > ( $nu + $kappa ) ? $nu + $mu : $nu + $kappa ; print "\$lhs:$lhs = \$kappa:$kappa + \$mu:$mu\n"; print "\$rhs:$rhs = \$kappa:$kappa + \$mu:$mu\n"; print "Evaluation of relation ", $lhs == $rhs ? 'succeeded' : 'failed' +; print qq{\n\n};

    output

    An approach to the proof of the Distribution Rule for Summation and Union over the Natural Realm wrt MF(C):155 P.NJW Evaluating relation (P1) when $kappa:3 < $mu:4 < $nu:5 $lhs:8 = $kappa:3 + $nu:5 $rhs:8 = $kappa:3 + $nu:5 Evaluation of relation succeeded Evaluating relation when (P2) $kappa:3 < $nu:5 < $mu:16 $lhs:19 = $kappa:3 + $mu:16 $rhs:19 = $kappa:3 + $mu:16 Evaluation of relation succeeded Evaluating relation (P3) when $mu:16 < $kappa:81 < $nu:625 $lhs:641 = $mu:16 + $nu:625 $rhs:641 = $mu:16 + $nu:625 Evaluation of relation succeeded Evaluating relation (P4) when $mu:16 < $nu:625 < $kappa:6561 $lhs:6577 = $mu:16 + $nu:625 $rhs:6577 = $mu:16 + $nu:625 Evaluation of relation succeeded Evaluating relation (P5) when $nu:625 < $kappa:6561 < $mu:65536 $lhs:66161 = $kappa:6561 + $mu:65536 $rhs:66161 = $kappa:6561 + $mu:65536 Evaluation of relation succeeded Evaluating relation (P6) when $nu:625 < $mu:65536 < $kappa:43046721 $lhs:43047346 = $kappa:43046721 + $mu:65536 $rhs:43047346 = $kappa:43046721 + $mu:65536 Evaluation of relation succeeded

    REVISE SECTION END: SOMETHINGS NOT QUITE RIGHT HERE All the relations have not succeeded!!

    All relations succeeded (hopefully) and so we can see the Distribution Rule for Summation and Union over the Natural Realm holds, at least for all permutations of ordering three distinct values.

    ToDo put the repeated code into subroutines. Evaluate when values are also equal, as this only evaluates at strictly distinct values. Also need to update the comparison subroutine to evaluate using the new chaining ability of operators with a bleading edge version of perl. Lets hope it does what we think it does.

      Hello. Thank you for interesting read with mathematics included!

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://11126869]
Approved by GrandFather
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (3)
As of 2022-09-25 20:44 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    I prefer my indexes to start at:




    Results (116 votes). Check out past polls.

    Notices?