Talk:Kaprekar numbers: Difference between revisions

← Older edit

Talk:Kaprekar numbers (view source)

Revision as of 17:58, 24 October 2020

3,741 bytes removed , 3 years ago

m

→‎Just for fun: added a new talk section.

Anonymous user

rosettacode>Gerard Schildberger

Revision as of 23:38, 21 September 2012 (view source) rosettacode>Lhignight (Responded to Paddy3118 about code change criteria) ← Older edit		Latest revision as of 17:58, 24 October 2020 (view source) rosettacode>Gerard Schildberger m (→‎Just for fun: added a new talk section.)
(28 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)