randall@ncr-sd.UUCP (10/03/87)
Running the short dc routine below to find the gcd of two numbers appears to work for small numbers. The command line is: %dc gcd r & s are passing parameters, returned in lowest terms initiate by: l7x ====================================================== [lx_1*sx]s1[ly_1*sy]s2[lyszlxsylzsx]s3[1sz]s4 [lxly%szlysxlzsy1lz>5lz0=6lz1=4]s5[lxsz]s6 [lrsxlssylx0>1ly0>2lxly>3l5xlrlz/srlslz/ss]s7 ?sr?ssl7x [r,s in lowest terms:]Pc [r= ]Plrpc [s= ]Plspc q ====================================================== When r & s are about 100 digits or so in length, an error message appears: %Segmentation fault (core dumped) What is wrong? Is the stack being recursively called until it overflows? I see nothing wrong in the subroutine above. Can anyone find out what is the problem and let me know? (e-mail is preferable) Is this a bug in dc? I am working with rational points on cubic surfaces, and need to have this problem fixed, to investigate the action of the chord-tangent process on creating new E(Q) pairs of the infinite birational pairs group. reply to: Randall.Rathbun@thor.SanDiego.NCR.COM or randall@thor.sandiego.NCR.COM thanks sincerely - Randall
bobm@rtech.UUCP (Bob McQueer) (11/28/87)
The pyramid dc does seem to have some problems here, also.
I've noticed that it does not interpret the "f" command correctly.
A little investigation shows that it takes "a" through "f" to be
hexadecimal digits, WHATEVER base you happen to be using. This screws
up the "c" command also. eg:
45 67 89 f
results in four numbers on the stack and no output. The top will be 15.
I wound up verifying that dc was supposed to work the way I thought it
was by using it on an ULTRIX box. For what it's worth, I sent a note
to our support people here, so they could send Pyramid a bug report. I
don't know if they did or not.
{amdahl, sun, mtxinu, hoptoad, cpsc6a}!rtech!bobm