Talk:Kaprekar numbers

Java count missing

Just add (and show), the count of how many there are <1million and you will have completed the stretch goal! --Paddy3118 14:07, 7 June 2011 (UTC)

I had actually added it as a test because I saw the other examples do it, but for some reason I didn't read it as a requirement so I took it out. Mornings are hard. --Mwn3d 14:47, 7 June 2011 (UTC)

:-)
--Paddy3118 17:29, 7 June 2011 (UTC)

Why the complexity?

The wikipedia page says "Let X be a non-negative integer. X is a Kaprekar number for base b if there exist non-negative integers n, A, and positive number B satisfying ...". In other words A can be zero. Why do we have to have a bunch of text claiming that A cannot be zero but A can be an empty string and that it is meaningful to add an empty string to a number? (Can't we just take advantage of the fact that leading zero digits do not change the value of a number?) --Rdm 20:56, 7 June 2011 (UTC)

To me the text "However a conceptual single split at the very end or before the first digit that produces one empty string does have the empty string counted" means that A can be zero. Unless I'm confused about what A and B are. --Mwn3d 22:30, 7 June 2011 (UTC)

Consider 100*100 = 10000 which could be split as 100 + 00. Now the 00 is disallowed. Compare that with 1*1 = 1 which is a K-number. For this to be a k-number then it must be expressed as either 1 plus no digists to the right or no digits to the left + 1. Either way no digits is treated as a positive integer of value zero but any string of one or more noughts is expressly forbidden.

Having 1 in the series seemed to add that complexity that needed explaining in my mind. --Paddy3118 23:14, 7 June 2011 (UTC)

It has to do with the way that the splitting is done mathematically, i.e., ${\mathit {N}}=A+B$ and $N^{2}=A\times 10^{x}+B$ where $10^{x}>B>0$; in the case of $\mathrm {1}$, it becomes possible to use ${\mathit {A}}=0$. This only works for that value; nothing larger is equal to itself when squared and zero is inadmissible by the constraint on ${\mathit {B}}$. Trust a mathematician to fluff the operation of splitting a number-string and introduce an unwanted special case! –Donal Fellows 23:48, 7 June 2011 (UTC)

I was reading the expressions, but the implication just fazed me. I had a mental block about the 1 case, even when it was explained more explicitely. Gosh, I'm not getting senile? er, I'll change that ? to ! --Paddy3118 09:05, 8 June 2011 (UTC)

Which sounds better?

What should we say, "split into parts" or "split once into whole number components made of groups of neighbouring digits from within the number"?

We are splitting into the number into numeric values the belong to the set of "whole numbers" aren't we? Or is there a misunderstanding here?

"split into parts" sounds too vague to me.

--Markhobley 16:06, 8 June 2011 (UTC)

If I had to change it from what we have now I'd say "split into two parts". The way it is now seems fine to me especially with the examples in the description. Since the number is specified as an integer, I don't think we need to add "whole number" noise. --Mwn3d 16:16, 8 June 2011 (UTC)

Right. The "whole numbers" verbage avoids the issue of explaining that chains of zeros do not fulfil the criteria, (although we would probably still need to keep that as a note to remind the task implementers.) --Markhobley 16:22, 8 June 2011 (UTC)

"Whole numbers", to me, includes 0 so I don't think that works that way. Is "whole numbers" an official mathematical set like "natural numbers"? Maybe say "split in to two positive parts"? --Mwn3d 16:33, 8 June 2011 (UTC)

Generally zero is not considered to be a whole number, but there are people who would disagree. We could use the term "integers greater than or equal to one" --Markhobley 19:40, 8 June 2011 (UTC)

FWIW zero is positive, but not a whole number, so "positive parts" would be no clearer IMHO, I would also call them numerical components, rather than parts, because 12 can be split into parts of sizes 8 and 4, but 1 and 2 are its numerical components. --Markhobley 19:45, 8 June 2011 (UTC)

OK 0 cannot be positive because then no one would need to call anything "non-negative" ([1] [2] [3]). The phrase "string representation" earlier in the first sentence avoids the "split" definition you're thinking of. And once again, the examples following the language reinforce the wording. --Mwn3d 19:58, 8 June 2011 (UTC)

Promoting to full task status

As the resolution of any of the discussions above in unlikely to change the fundamental task goals, and we have several correct examples.--Paddy3118 20:07, 8 June 2011 (UTC)

I say yes. Go! --Markhobley 20:11, 8 June 2011 (UTC)

C++ sample code

I'm tempted to change all the "long" type to "long long" in the C++ sample code, because it would fail on 32 bit system as is. --Ledrug 17:08, 14 June 2011 (UTC)

That change seems fine since the output goes up pretty high anyway. Does that just mean they used a 64-bit machine? --Mwn3d 17:17, 14 June 2011 (UTC)

What 'long' means depends on the compiler, but it's typically defined to be the longest native integer type, while 'long long' is (I think) defined to be 64-bit. Someone correct me if I'm wrong. I'll change the code anyhow, because it overflows with 32 bit long for sure. --Ledrug 17:25, 14 June 2011 (UTC)

On every C and C++ compiler I've used on a 64-bit OS (so, GNU on Linux and MSVC/MSVC++ on Windows), 'long' is 32-bits. 'long long' is 64-bits. I don't know about, e.g. SPARC64, though. That's why you get things like uint32_t from stdint.h or DWORD from Windows.h. --Michael Mol 18:05, 14 June 2011 (UTC)

It's always sort of confusing to me anyway. For reference, see http://www.unix.org/whitepapers/64bit.html, which also has a table for integer types. It's true that if you worry about the exact length, use exactly defined types instead of the compiler native ones. --Ledrug 18:28, 14 June 2011 (UTC)

If 53 bits is enough (and I think it is, here), you might also consider using double. --Rdm 20:01, 14 June 2011 (UTC)

Heh, tried double, seg faulted. I'm not very motivated to see what's happening--probably that atol()--so I'll just leave it as is. --Ledrug 21:44, 14 June 2011 (UTC)

What's up with the people modifying the C++ code, previously (before long to long long) it returned wrong numbers, now it simply never returns on 32 bit system with g++ 4.5. Also maybe we should promote testing sample code with full warnings on: g++ gives signedness mismatch warning on line 20. --Ledrug 23:02, 15 June 2011 (UTC)

Would someone modify the code to work for a happy medium and then state on the task page that the C++ code is fragile w.r.t 32/64 bit systems and where the fragility lies? It sounds like it is an issue that should be taken into account when comparing that particular C++ code with other languages.

Come to think of it, maybe other similar languages might state why they don't have an issue? Or maybe there is a separate task here: "Do something that is otherwise straight-forward but needs slightly different code, or will not work on both 32 and 64 bit X86 systems and/or up-to-date, widely used, but different versions of compilers/interpreters"? --Paddy3118 05:06, 16 June 2011 (UTC)

Indentation...

Can we please don't adjust someone else's code indentation just because it's different from yours... --Ledrug 20:21, 14 June 2011 (UTC)

I appreciate that it can be annoying when people touch your code, but it's a wiki. You're going to have to get used to it. My code is changed regularly. Sometimes for the better. Sometimes it's simply changed but not really improved, in my opinion. Unless you want to get involved in edit wars all the time, you're going to have to relax about it. In your case, I honestly thought that the huge indent was accidental. Otherwise I would have left it alone. Fwend 21:23, 14 June 2011 (UTC)

K&R 8 space tab is typical BSD style, I'm not sure why you'd think it's accidental. And I didn't mind someone changine my code, but changing purely because of the code indentation is prone to start an edit war, please don't get too used to it (and I didn't revert your edit, did I?). --Ledrug 21:32, 14 June 2011 (UTC)

You might try leaving the original indentation if it is consistent and "reasonable"; and adjusting to the existing style when making small edits, (helps with the diffs). If you make a large change then probably relax the rules about changing styles? --Paddy3118 04:21, 15 June 2011 (UTC)