Rosetta Code

Talk:Kaprekar numbers: Difference between revisions

Page Discussion

Talk:Kaprekar numbers (view source)

Revision as of 17:58, 24 October 2020

8,088 bytes removed ,  3 years ago
m
→‎Just for fun: added a new talk section.
m (→‎Just for fun: added a new talk section.)
 
(24 intermediate revisions by 4 users not shown)
Line 142:
For fun I tried reversing the digits in the squared number (e.g. using "5203" as the "squared number" for 55 instead of "3025") to see if there would be any pattern in the new results. There were some overlaps for numbers that were all repeating digits. I didn't see anything notable. I got 17 rakerpak (kaprekar backwards....get it?) each for base 10 and 17. The code isn't notable either (just add a bit to one line to reverse the string representation of the squared number). I thought it would be kinda neat to think about. --[[User:Mwn3d|Mwn3d]] 15:16, 8 August 2011 (UTC)
 
 
----
== ooRexx ==
 
I tried this for ooRexx
Had to change # to n
Line 148 ⟶ 150:
It works with Numeric Digits 14
--[[User:Walterpachl|Walterpachl]] 14:53, 29 June 2012 (UTC)
 
 
== Common Lisp Implementation ==
 
Let me start by saying that I feel the criteria that should be used to modify existing code are the following:
*Correctness
*Fulfilling additional tasks / generality
*Improved readability
*Use of a programming languages idioms - For example, in CL the use of multiple return values is preferred to say setting multiple global variables.
*Improved performance
*(Note: There may be some special situations missing from this list)
 
Using these criteria, I modified the original CL implementation mainly because I thought that I could improve the readability by using more Lisp language features like multiple return values. In short, I felt like I was reading a C program written in Lisp: The original code isn't 'Lispy'. Later, I made some changes to the basic algorithm that substantially improved the performance (and even later came across the CO9 technique which again substantially improved performance). Because the original version supports additional number bases, I decided to add a separate fast version and retain the older, more general, version. Recently, [[Nigel Galloway]] added support for all number bases to the 'fast implementation'. Based on the criteria above, I would normally find this to be an improvement, however, the code again resembles a C implementation written in Lisp (especially with the global bindings of BASE and BASE-1) and the performance has also decreased substantially. My version is able to finish the first 1 million Kaprekar numbers in ~9.1 seconds; The new version finishes in ~124 seconds. Memory usage and garbage collection also increased by an order of magnitude.
 
Because the new version lacks additional generality beyond the 'slow version', decreases readability and the use of Lisp idioms, and is substantially slower than the previous version, I've decided to revert the changes made by Nigel. I added this talk section to explain my rationale for making the revision. --[[User:Lhignight|Larry Hignight]] 23:40, 18 September 2012 (UTC)
: Hi Lhignight, its good to see your criteria - I hope they are in decreasing order of importance for the general task, as optimising for speed can detract from the other concerns if done to excess - especially if a task can be 'adequately' fulfilled without it. Although you could add another implementation that was faster and leave a more idiomatic example alone. --[[User:Paddy3118|Paddy3118]] 16:08, 19 September 2012 (UTC)
:: Fleshing this out a bit more, in terms of the order of importance, I consider correctness to be the most important criteria, performance the least (unless specifically mentioned in the task), and the remaining criteria are about equal in my opinion. In most programming languages, improved readability and use of language idioms are often highly correlated (at least among experienced users of the language). Performance is a nice bonus item, but if it detracts from any of the other criteria, it should be added as a separate task assuming that it is correct and significantly faster: 5% faster, skip it; 5x faster, add it. --[[User:Lhignight|Larry Hignight]] 23:38, 21 September 2012 (UTC)
 
Hi Larry, what implementation of common lisp are you using? I only replaced a function number of digits, which calculated the number of digits by dividing by 10 until less than 10 with floor (log N / log Base) which is a reasonable way to determine the number of digits in a number. This should be faster unless your implementation has no reasonable log function. Note that BASE and BASE-1 are not variables they are constants. I didn't change the logic. A mute point now as ledrug has done tha task properly.--[[User:Nigel Galloway|Nigel Galloway]] 18:44, 19 September 2012 (UTC)
: Hi Nigel, I did the initial testing using CLISP. I've since tested both versions using LispWorks, which improved your times substantially, but it is still noticeably slower. I'll separate out your other points so that you can respond to each comment directly. --[[User:Lhignight|Larry Hignight]] 22:42, 23 September 2012 (UTC)
 
"I didn't change the logic."<br>Perhaps you didn't intend to change the logic, but your version fails to identify 9,999,999 and 99,999,999 as Kaprekar numbers whereas mine correctly identifies them, so yes, you did change the logic. --[[User:Lhignight|Larry Hignight]] 22:42, 23 September 2012 (UTC)
 
"Note that BASE and BASE-1 are not variables they are constants."<br>While I applaud the additional mathematical insight that you provided, I'm concerned that you don't have very much experience as a Lisp developer and should probably refrain from modifying existing Lisp solutions. For example, the CLHS explicitly states that [http://www.lispworks.com/documentation/HyperSpec/Body/s_setq.htm setq] is used with variables "other than a constant variable." In addition to BASE and BASE-1 not being constants, which isn't what you didn't want in the first place, there are a number of other issues:
*In CL, the standard method for defining a constant is the [http://www.lispworks.com/documentation/HyperSpec/Body/m_defcon.htm defconstant] form. It is also the convention in CL to name constants with leading and trailing + characters (eg +base+).
*The unnecessary use of dynamically scoped variables is discouraged. The preferred method for incorporating base would have been to define it as an optional function parameter with a default value of 10.
*The manner in which you replaced the num-digits macro resulted in code that was less readable. In my version, it was very clear when the number of digits were being calculated because I used an abstraction to separate this calculation from the function. You eliminated a useful abstraction.
*For some reason, you replaced the let* form with the lh and rh values with a multiple-value-bind form. I really have no idea why you would do this.
*I'm not sure why you feel that two calls to log followed by floor() and adding 1 would be faster than a loop that runs in theta(log n) time. --[[User:Lhignight|Larry Hignight]] 22:42, 23 September 2012 (UTC)
 
"A mute point now as ledrug has done tha task properly."<br>Yeah, it's kind of a shame that someone broke it though. --[[User:Lhignight|Larry Hignight]] 22:42, 23 September 2012 (UTC)
 
A lot of hot air for somthing that doesn't exist! I did not break the origional solution, I made it solve the task. Obviously in a way that doesn't suit you. In place of personal abuse you might have changed it to suit you and solve the task. Returning it to a version which doesn't solve the task was not helpful. I was going to restore my version and let you change it, but I'll leave it to you to restore and correct if you think it adds anything. I have a much better idea.--[[User:Nigel Galloway|Nigel Galloway]] 10:40, 26 September 2012 (UTC)
:YOUR version is not CORRECT. Anyone can view the history, try the examples above, and see this is true. I left untouched a slower version that solved the 'Extra extra credit' task, which you seem to be obsessed with for some reason. Why you would expect anyone to fix an incorrect, slower, less readable, and less lispy version of your software, when better versions already existed, is way beyond me. --[[User:Lhignight|Larry Hignight]] 01:17, 30 September 2012 (UTC)
Now with +SCARY CAPITALS+! I dont't expect anyone to do anything, it was merely a suggestion that you 'put up or shut up'. I modified your solution so that it worked, with sample output provided. If it didn't work for large numbers (ouside the scope of the task) it is probably because your log algorithms are inaccurate. You changed it back to your solution, which doesn't solve the task. Your situation is that ledrug didn't like your solution and has replaced it with his. If you have nothing to put up on the task page then all this is just hot air. None of your comments and insults have indicated that which you wish me to do about your situation. As I said I have a better idea, which I have placed on the task page.--[[User:Nigel Galloway|Nigel Galloway]] 11:38, 1 October 2012 (UTC)
Retrieved from "https://rosettacode.org/wiki/Special:MobileDiff/187748...187773"