Talk:Steady squares: Difference between revisions
Content deleted Content added
Line 23: | Line 23: | ||
: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).--[[User:Nigel Galloway|Nigel Galloway]] ([[User talk:Nigel Galloway|talk]]) 12:46, 21 December 2021 (UTC) |
: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).--[[User:Nigel Galloway|Nigel Galloway]] ([[User talk: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). --[[User:Petelomax|Pete Lomax]] ([[User talk:Petelomax|talk]]) 14:53, 21 December 2021 (UTC) |
Revision as of 14:54, 21 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). --Pete Lomax (talk) 14:53, 21 December 2021 (UTC)