PARI's commands

[science_man_88]

Originally Posted by science_man_88

This talks of the string range option. I'm trying to use it with a variable x as the starting position and only go as far as the length of the S2 variable further. This is so I can the whole length vector version of S2 to something the same length (instead of looping through each letter), if it gets found then my effort goes to working on the problems of replacing.

edit:

I realized that the vector option was an option but then I still fail to make it work.

I look to have it working now, as to the replace this might be fun if S2 and S3 aren't the same length.

edit:

FaR(S1,S2,S3)=aa=eval(Vec(S1));for(x=1,#aa-length(S2)+1,if(vecextract(aa,vector(length(S2),n,x+n-1))==eval(Vec(S2)),print1(S3);x=x+length(S2)-1,if(x==(#aa-length(S2)+1),for(y=x,#aa,print1(aa[x])),
print1(aa[x]))))

is my best for right now, it still prints 0 when it doesn't match it seems.

[Batalov]

Found a bug in pari's interpreter. I thought I was going mad -- double checked the code 20 times... Turned out to be an interpreter bug*.

Here's the self-contained code (it has to do with PE problem 196):

n=5678027;s=0;forstep(p=n*(n-1)/2+4,n*(n+1)/2-1,[2,4],if(isprime(p),\
  if(p%6==1,a1=isprime(p+n-1);a3=isprime(p+n+1);if(a1&&(a3||isprime(p-2)||isprime(p+n+n))||(a3&&isprime(p+n+n+2)),s+=p),\
  a1=isprime(p+n+1);a2=isprime(p-n+1);if((a2&&(a1||isprime(p-n*2+4)))||(a1&&(isprime(p+2)||isprime(p+n+n+2))),s+=p) )));s
%8 = 71089179309899646

n=5678027;s=0;forstep(p=n*(n-1)/2+4,n*(n+1)/2-1,[2,4],if(isprime(p),\
  if(p%6==1,a1=isprime(p+n-1);a3=isprime(p+n+1);if(a1&&(a3||isprime(p-2)||isprime(p+n+n))||(a3&&isprime(p+n+n+2)),s+=p),\
  a1=isprime(p+n+1);a2=isprime(p-n+1);if(a2&&(a1||isprime(p-n*2+4))||(a1&&(isprime(p+2)||isprime(p+n+n+2))),s+=p) )));s
%10 = 53760184371086923

The only difference is extra parens around "a2&&(a1||isprime(p-n*2+4))" which is joined by ||, so that shouldn't matter, but it does. /sigh/

*Granted that this was an old stable version 2.3.5 which I'd used for years.
I'll check if this is still a bug in 2.5.4, and if it is, will report to them. No, it has been fixed!

EDIT: No it hasn't! 2.5.4 still produces wrong results in a slightly different condition set for the second half of the problem. Works if you wrap every single expression in parens, even in something like (a&&b)||(c&&d)||(e&&f). Will report.

[LaurV]

v2.5.0: (which I am currently using)

(11:21:57) gp > n=5678027;s=0;forstep(p=n*(n-1)/2+4,n*(n+1)/2-1,[2,4],if(isprime(p),\
  if(p%6==1,a1=isprime(p+n-1);a3=isprime(p+n+1);if(a1&&(a3||isprime(p-2)||isprime(p+n+n))||(a3&&isprime(p+n+n+2)),s+=p),\
  a1=isprime(p+n+1);a2=isprime(p-n+1);if((a2&&(a1||isprime(p-n*2+4)))||(a1&&(isprime(p+2)||isprime(p+n+n+2))),s+=p) )));s
%1 = 79697256800321526
(11:23:07) gp > n=5678027;s=0;forstep(p=n*(n-1)/2+4,n*(n+1)/2-1,[2,4],if(isprime(p),\
  if(p%6==1,a1=isprime(p+n-1);a3=isprime(p+n+1);if(a1&&(a3||isprime(p-2)||isprime(p+n+n))||(a3&&isprime(p+n+n+2)),s+=p),\
  a1=isprime(p+n+1);a2=isprime(p-n+1);if(a2&&(a1||isprime(p-n*2+4))||(a1&&(isprime(p+2)||isprime(p+n+n+2))),s+=p) )));s
%2 = 79697256800321526
(11:23:57) gp >

Are you sure is not something related to the partial evaluation of boolean expressions? ("default" settings?)

[Batalov]

Try these equivalent expressions:
1. fully dressed with parens (Ugh!)

n=7208785;s=0;
forstep(p=n*(n-1)/2+5,n*(n+1)/2-1,[2,4],if(!isprime(p),next);\
  if(p%6==1,a3=isprime(p-n+1);a4=isprime(p+n-1);if((a3&&(a4||isprime(p-n-n+2)))||(a4&&isprime(p-2)),s+=p);next);\
  a1=isprime(p-n+1);a4=isprime(p+n+1);a5=isprime(p+n-1);\
    if((a1&&(a4||a5||isprime(p-n-n+2)||isprime(p-n-n+4)))||\
    ((a4&&(a5||isprime(p+2)))||(a5&&isprime(p+n+n))),s+=p) );s

and
2. One condition is left naked:

n=7208785;s=0;
forstep(p=n*(n-1)/2+5,n*(n+1)/2-1,[2,4],if(!isprime(p),next);\
  if(p%6==1,a3=isprime(p-n+1);a4=isprime(p+n-1);if((a3&&(a4||isprime(p-n-n+2)))||a4&&isprime(p-2),s+=p);next);\
  a1=isprime(p-n+1);a4=isprime(p+n+1);a5=isprime(p+n-1);\
    if((a1&&(a4||a5||isprime(p-n-n+2)||isprime(p-n-n+4)))||\
    ((a4&&(a5||isprime(p+2)))||(a5&&isprime(p+n+n))),s+=p) );s

3. try undressing more clauses from (a&&b)||(c&&d)||(e&&f) into
(a&&b)||(c&&d)||(e&&f)
(a&&b)||c&&d||e&&f
a&&b||c&&d||e&&f
==> totally random results!

[chalsall]

Originally Posted by Batalov

Try these equivalent expressions:

It's Friday night (or Saturday morning; depending on where one finds themselves), and rather than getting laid some of us are finding bugs in software (and having fun doing so).

And to think some others think we're a bit "nerdy"....

[Batalov]

Gotta get me a genie to half my age, and then we could talk about priorities! ;-)

Currently, I am more concerned about AST/ALT ratios and with philosophical questions like "Do I prefer to follow Tony S. with a heart attack if I don't take my statins or do I want to follow David E. with failed liver if I do take my statins?" Getting laid is a little bit down the list at this time.

Seriously though, today, after a month off of (prescription) drugs, AST and ALT are both back to normal, but CHL is way up. Crap, crap, crap!

[LaurV]

Originally Posted by Batalov

==> totally random results!

No, no, that is what I am trying to explain to you.

Because of "partial evaluation" involved in pari (and in C also), of the boolean expressions, and because in pari the && and || have the same priority (both are class 0, see the section 2.4.2 in the user manual, as opposite for example to MQL, where || is more prioritar than &&, which is a bit counterintuitive, but if you think about what MQL is for, it makes sense), the expressions are NOT equivalent. Pari stops evaluating the boolean expressions when the value is certain. For example, in "a || b && c", when you partial evaluate it, this is always true if "a" is true, if you evaluate it from the left (like pari says it does, in the docs) and is always false if "c" is false and you evaluate it from the right, but you can't say nothing about "b", it depends where do you pair it (how do you associate). There is no bug here, you set your pari to fully evaluate boolean expressions, left to right, or better (and safer) use parenthesis!

On the default installation, this is NORMAL, even with full evaluation:

(11:23:57) gp > for(a=0,1,for(b=0,1,for(c=0,1,print(a" "b" "c"  |  "a&&b||c" <-> ",(a&&b)||c))))
0 0 0  |  0 <-> 0
0 0 1  |  1 <-> 1
0 1 0  |  0 <-> 0
0 1 1  |  1 <-> 1
1 0 0  |  0 <-> 0
1 0 1  |  1 <-> 1
1 1 0  |  1 <-> 1
1 1 1  |  1 <-> 1
(12:17:19) gp > for(a=0,1,for(b=0,1,for(c=0,1,print(a" "b" "c"  |  "a||b&&c" <-> ",a||(b&&c)))))
0 0 0  |  0 <-> 0
0 0 1  |  0 <-> 0
0 1 0  |  0 <-> 0
0 1 1  |  1 <-> 1
1 0 0  |  0 <-> 1
1 0 1  |  1 <-> 1
1 1 0  |  0 <-> 1
1 1 1  |  1 <-> 1
(12:17:48) gp >

for records, this is version 2.5

[Batalov]

Originally Posted by LaurV

...(and in C also)...

Incorrect for C. In C, the rules of precedence are clear, never mind partial evaluation (partial evaluation goes without saying or else all programs would be twice as long).

For Pari, I see what you are saying. Indeed, they lumped both operations in the same precedence. This is an awful, naughty catch. I am very surprised that they didn't assign the same precedence to * and +, then. (but they didn't! thank god for that). So they are right to call this a "calculator". Like windows calc: 1+2*3, in "Simple" and "Scientific" modes. It is 9 and 7. Disgusting.

&& to || is like * to +.

But then again, with programmers, you can never be sure how they will parse your statement. It is like in the anecdote where the wife instructs the programmer: "At the grocery, buy two cabbages and if they have eggs buy a dozen." The programmer returns with a dozen cabbages!

[LaurV]

Originally Posted by Batalov

But then again, with programmers, you can never be sure how they will parse your statement. It is like in the anecdote where the wife instructs the programmer: "At the grocery, buy two cabbages and if they have eggs buy a dozen." The programmer returns with a dozen cabbages!

That was a system malfunction... How the programmer decided if the cabbages have eggs? Anyhow, the result is wrong in all cases: if no eggs, he should come with two cabbages. If someone had eggs (the grocery, the cabbage, the seller, whatever), then the guy should return with 14 cabbages...

[LaurV]

Originally Posted by Batalov

Incorrect for C

Correct for C. I was referring to partial evaluation only. I brought the "precedence" into discussion only later, specifically writing "in pari" for a second time in the same sentence! As in "in pari the && and || have the same priority". The reference to C was only to clarify for you what I mean by "partial evaluation", as I know you can handle C very well. The fact that partial evaluation and total evaluation give same results when a single operation is used, (like only &&, or only ||, but not both) has nothing to do with C or with pari, it is just a consequence of the property of the operation itself (change that to xor, and everything changes!). When the precedences are different, you practically have a single operation (because you solve the most priory operation first), but when the precedence is the same, you mix the operations. In this respect, pari has no bug: everything works as in the specs (user manual). Use parenthesis!

[Batalov]

The more I think about this Pari implementation, the more I get the feeling that today I looked in the abyss.

Let's think about this: why is it that every language (clearly, except Pari !!) has a clear distinction of priorities between these two operations (&& and ||, or say, in python or SQL - "and" and "or")? Look them up, from Fortran to ruby, to SQL, from java to C-bemol-diez. Because logical operators implement logic, and there cannot be anything more basic than logic. You don't fsck with logic!

Ok, Let's consider a&&(b||c) vs a||(b&&c) regardless of order, that is the same as (b||c)&&a vs (b&&c)||a. What is the main difference? Never mind lazy evaluation or side-effects (when a,b,c are mutable objects and you sandwich operators into logic, like if(++c && (++a==0 || ++b==0)) or in Perl-style, where $p is assumed to be a ref to an array, $p->[3]-- if($p && @$p>3 && $p->[3]>1) ). No, let's consider plain logic evaluation with a, b, and c defined and immutable objects with an associated defined logic value. If it is plain, and there are no side-effects, there is no difference between partial and full evaluation - the truth value will be the same, only the compute time is saved.

But even though a&&(b||c) = a&&b || a&&c,
in contrast a||(b&&c) = a || b&&c, period.

So the operator precedence is not something you assign at a whim or out of laziness, it is imposed by logic that you are supposed to implement.

Finally, with Pari, what's even more horrible that the results are variable between versions. I could be conditionally fine with just the implementation by the rule: "in our Pari world, we evaluate left from right all precedence 0 operators (which are && and ||) and that's final." But it's not! The results of the above snippets are all randomly different between different Pari binaries that I have fetched. I am deeply saddened.