Talk:Steady squares: Difference between revisions
m Thanks to Pete Lomax |
Why not 1001 or 900625? |
||
Line 28: | Line 28: | ||
::is a triple-zero-fill, and I've found examples all the way up to (a quite random) 548 digit n with a 1096 digit square. --[[User:Petelomax|Pete Lomax]] ([[User talk:Petelomax|talk]]) 15:49, 21 December 2021 (UTC) |
::is a triple-zero-fill, and I've found examples all the way up to (a quite random) 548 digit n with a 1096 digit square. --[[User:Petelomax|Pete Lomax]] ([[User talk:Petelomax|talk]]) 15:49, 21 December 2021 (UTC) |
||
:::Pete you were right.My first thought was, there where only a finite set of steady squares.<br>Thanks for showing, that prepending 1..x zeros ( and increasing Pot10 the same way ) to n, which is generating a stead square, lets n*n still be a steady square.<br>I am happy for not writing "proof" ;-) --[[User:Horst.h|Horst.h]] ([[User talk:Horst.h|talk]]) 10:32, 22 December 2021 (UTC) |
:::Pete you were right.My first thought was, there where only a finite set of steady squares.<br>Thanks for showing, that prepending 1..x zeros ( and increasing Pot10 the same way ) to n, which is generating a stead square, lets n*n still be a steady square.<br>I am happy for not writing "proof" ;-) --[[User:Horst.h|Horst.h]] ([[User talk:Horst.h|talk]]) 10:32, 22 December 2021 (UTC) |
||
==Why not 1001 or 900625== |
|||
Consideration of this question leads to an improvement of the algorithm. Consider a number of the form g<sub>2</sub>g<sub>1</sub>g<sub>0</sub>. |
|||
Uncontentiously I assert that g<sub>0</sub> is 1, 5 or 6. Prepending n=0..9 to each and squaring these to obtain xg<sub>1</sub>g<sub>0</sub> and filtering for g<sub>1</sub>=n, I obtain 01, 25, 76 which are candidates for the next iteration. Note that using n=0 for g<sub>0</sub>=5 excludes 05 because 0 does not equal 2 and that it is only necessary to check g1 against n. Extending for g<sub>3</sub> makes the candidate list 001, 625, and 376. At g<sub>4</sub> interestingly 0625 is included because g<sub>4</sub> in 390625 passes g<sub>4</sub>=n for n=0. Note 00625 will fail at the next iteration, thus eliminating 900625. |
|||
Considering g<sub>0</sub>=1 and g<sub>n-1</sub>..g<sub>1</sub>=0 |
|||
<pre> |
|||
101* 201* 1001* |
|||
101 201 1001 |
|||
----- --- ---- |
|||
101+ 201+ 1001+ |
|||
10100 20200 1001000 |
|||
----- ----- ------- |
|||
10201= 20401= 1002001= |
|||
</pre> |
|||
Then g<sub>n</sub> is always 2n%10 which never equals n.--[[User:Nigel Galloway|Nigel Galloway]] ([[User talk:Nigel Galloway|talk]]) 14:15, 23 December 2021 (UTC) |
Revision as of 14:16, 23 December 2021
Reduce search range by observation of the results
By taking a look at the results,I tried to search for results by prepending a digit to n.
And there comes the solution:By prepending a digit to n, than n*n must end in n to be a steady square.
So only solutions of one digit before can be solutions.
<lang pascal>
function CalcSquare(n:LongInt;Pot10:byte);
//pot10 is 10^(count of digits of n -1)
//prepend one digit to n
var
dgt: LongInt;
begin
//ex.: n= 5,Pot10 = 1, dgt= 2;-> n2= (2*10*1+5)^2 = 625 For dgt := 1 to 9 do begin // n= 5 , dgt= 2*10 -> n2= 625 n2 = sqr(dgt*10*Pot10+n); n2 = dgt*dgt*100*Pot10*Pot10+2*dgt*10*pot10*n+n*n;
// term: dgt*dgt*100*Pot10*Pot10+2*dgt*10*pot10*n// always has ends in Pot10+1 "0" digits // so n*n must end in n, to be a steady square
end;
</lang>
- Note also that it must end in 1,5 or 6 (not 0 as any number ending in 0 squared ends with twice as many zeros).--Nigel Galloway (talk) 12:46, 21 December 2021 (UTC)
- Ah, you beat me to it (I posted my Phix entry before reading this). I was hopeful, as you (Horst) seem to suggest, that we only have to look at the k-1 digit solutions on each iteration, and that way maybe even find all possible such numbers there could ever be, that is if any iteration found none we'd be done, but alas zero-fill totally spanners that illusion (eg 90625 off the back of 625). Oh, unless I've missed a logical reason why it is not worth checking (eg) 1001 or (say) 900625... Then again the series could be and probably is infinite anyway. --Pete Lomax (talk) 14:53, 21 December 2021 (UTC)
- Nevermind that last bit:
1000557423423230896109004106619977392256259918212890625^2 = 10011151575673345586...92256259918212890625 (109 digits)
- is a triple-zero-fill, and I've found examples all the way up to (a quite random) 548 digit n with a 1096 digit square. --Pete Lomax (talk) 15:49, 21 December 2021 (UTC)
- Pete you were right.My first thought was, there where only a finite set of steady squares.
Thanks for showing, that prepending 1..x zeros ( and increasing Pot10 the same way ) to n, which is generating a stead square, lets n*n still be a steady square.
I am happy for not writing "proof" ;-) --Horst.h (talk) 10:32, 22 December 2021 (UTC)
- Pete you were right.My first thought was, there where only a finite set of steady squares.
- is a triple-zero-fill, and I've found examples all the way up to (a quite random) 548 digit n with a 1096 digit square. --Pete Lomax (talk) 15:49, 21 December 2021 (UTC)
Why not 1001 or 900625
Consideration of this question leads to an improvement of the algorithm. Consider a number of the form g2g1g0. Uncontentiously I assert that g0 is 1, 5 or 6. Prepending n=0..9 to each and squaring these to obtain xg1g0 and filtering for g1=n, I obtain 01, 25, 76 which are candidates for the next iteration. Note that using n=0 for g0=5 excludes 05 because 0 does not equal 2 and that it is only necessary to check g1 against n. Extending for g3 makes the candidate list 001, 625, and 376. At g4 interestingly 0625 is included because g4 in 390625 passes g4=n for n=0. Note 00625 will fail at the next iteration, thus eliminating 900625.
Considering g0=1 and gn-1..g1=0
101* 201* 1001* 101 201 1001 ----- --- ---- 101+ 201+ 1001+ 10100 20200 1001000 ----- ----- ------- 10201= 20401= 1002001=
Then gn is always 2n%10 which never equals n.--Nigel Galloway (talk) 14:15, 23 December 2021 (UTC)