User talk:Ledrug

From Rosetta Code
Revision as of 12:10, 27 October 2012 by Nigel Galloway (talk | contribs) (If as you say you want to reopen this discussion then please add somthing to it here. If you have nothing to add then neither have I.)

Common Lisp Implementation

If as you say you want to reopen this discussion then please add somthing to it here. If you have nothing to add then neither have I. 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. --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. --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. --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.--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. --Larry Hignight 22:42, 23 September 2012 (UTC)

"I didn't change the logic."
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. --Larry Hignight 22:42, 23 September 2012 (UTC)

"Note that BASE and BASE-1 are not variables they are constants."
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 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 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. --Larry Hignight 22:42, 23 September 2012 (UTC)

"A mute point now as ledrug has done tha task properly."
Yeah, it's kind of a shame that someone broke it though. --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.--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. --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.--Nigel Galloway 11:38, 1 October 2012 (UTC)

How on earth is something that doesn't work CORRECTLY a better idea! And for the record, Ledrug replaced YOUR version, not mine. --Larry Hignight 08:24, 4 October 2012 (UTC)

Well, joining the fray. First, the message left on my user talk page by one genius:

Please leave this code alone until you can demonstrate an understanding of this problem. Your second attempt at this is an improvement over your first naive attempt, but still not as interesting as this. Maybe I shall seperate the Casting_out_nines from the Kaprecar part: <lang clisp>(let ((kk (* N N))) (do ((B Base (* B Base))) ()(let (( nr (/ (* N (- B N)) (- B 1)))) (if (< 0 nr) (let ((q (floor (- N nr)))) (if (= kk (+ nr (* q B)))</lang> (unsigned, left by User:Nigel Galloway)

I'll make a few comments, but won't discuss it any more after that, since that would be obviously futile.

  1. I don't know what kind of antique lisp machine you have installed in your basement, but your code does not compile on either SBCL or Clisp. Maybe geniuses shan't be bothered by such trifles.
  2. Your code, once made compile with SBCL (change that do (...) () to do (...) (nil), does exactly the samething mathematically: raise a power of a base repeately, until either it splits the square of n with the right sum, or it's too large. Except you are doing it in a convoluted way, using non-integer methods on integers, and ends up with something literally 100 times slower then my edit you reverted (on SBCL that is, I don't know about your antique lisp machine).
  3. You had one good idea of checking congruence, and a whole lot of terrible ones: being thoughtless in dealing with datatypes (pow and log on integers in C++, / and floor in Lisp); being sloppy in performance tuning (your "v.fast" C++ code isn't all that fast); being vengeful (paddy_cnt?); being narcissistic (own name as variable?); being inconsiderate to code readers (what kind of person posts unindented Lisp?); and generally being an all-around dick.
Thank you for admiring me as the most beautiful youth in the world! In this section I have detected ehoes of Echo 'twix you and your Acolyte, but as in the myth I must reject your sexual advances. I think it is going to take more than me seeing my own reflection to appreciate the inner goodness of either of you two clowns.--Nigel Galloway 13:32, 13 October 2012 (UTC)
  1. Your sarcasm in the lisp code was neither subtle nor funny. You give British humor a bad name.

You are probably not stupid, but it's safe to say you are not the smartest person on RC, by a long shot. And smart people around here tend to have good manners, unlike you or I. Stop treating yourself like you are the one true genius, and try to do something that's helpful to people instead of showing off, OK? (my guess: probably not. Oh well.) --Ledrug 00:10, 4 October 2012 (UTC)

Well said. He is clearly more interested in being a pompous dick then contributing quality code to RC. --Larry Hignight 08:24, 4 October 2012 (UTC)
There are no stupid people only differently logical. I look forward to seeing this list of rosettacode contributers arranged by smartness that they propose. I assume they exclude themselves from it as judges, and including them would be laughable. The good news for ledrug is that on my list of differently logical contributers, from which I exclude myself as judge, he has been replaced by his new acolyte as first clown.--Nigel Galloway 11:08, 11 October 2012 (UTC)

Again ledrug why so angry? I didn't revert your edit, it is a good solution, I left it there and reinstated my solution which you deleted, as, indeed, it was you who deleted Larry's solution. There are three approaches to this problem which I have identified:

1) a naive approach which loops over all numbers testing each fully for Kaprekarness (your first solution);
2) a more sophiscated method which still loops over all numbers but implements a filter based on casting out nines which quickly eliminates seven nineths of the numbers (your second solution, thank you for praising my idea);
3) realizing the nature of the uneliminated numbers it is possible to identify the residual sets to which possible Kaprekar numbers belong and generate them (which my solution does).

I therefore asked you not to delete it, and I said please! I asked you to understand the difference before you changed it, which you may. Agian I would say politely, I said please. Again I thank you for your praise for that which you judge to be my good idea, though of course without accepting your magesterium regarding the quality of any of my ideas.

I use Franz Allegro 9, do you want me to pass your comments 'kind of antique lisp machine you have installed in your basement' on to them? Also the version I use is case sensitive, so your use of t and T to disguish when you want t to mean true and T to mean boolean causes my rather advanced lip machine to identify T as an unbound variable, but I just quietly change it without impuning either you, SBCL, or CLisp.

Finally I have no reason to be vengeful to Paddy, I don't even feel vengeful towards you! He asked that the impementation include a count of the Kaprekars as requested in the task description, and I obliged. I named the count after him as my terrible vengence, I don't see it.--Nigel Galloway 12:12, 4 October 2012 (UTC)

Conflict Resolution?

Hi guys, I and probably others have been lurking on this issue that doesn't seem to be getting closer to a solution. I am not a Lisp expert, but would like to see some resolution.

How about a limited debate? Nigel, Ledrug and Larry should continue the debate for no longer than, say next Monday - others can add their opinions too but the idea being to leave behind reasoned areguments why their view should prevail. Come Tuesday others should read the reasoned arguments and make up their own minds with the page updated to fit the best reasoned point. Or Mike Mol could become a benevolent dictator on Tuesday and just state *the* resolution, to be followed by all.

- Or not. If someone has another idea ...? --Paddy3118 13:26, 4 October 2012 (UTC)

Don't worry about my side, I've said what I wanted to say, and am not getting back into it. Though I'm pessimistic about everyone eventually agreeing to a reasonable resolution: I wouldn't have flat out called someone a self-important dick if past experience showed that he could be reasoned with or that he did have a bit of sincerity when exhibiting his knowledge in spelling the word "please". I'd like to be wrong on this, but I won't hold my breath. --Ledrug 05:59, 5 October 2012 (UTC)
I wrote a list of reasons concerning when I think it is appropriate to change existing code and why I changed Nigel's version (his 7/9/2012 submission) to which he responded with "A lot of hot air for somthing that doesn't exist!" ignoring ALL of my points and implying that I should have fixed his version: "I was going to restore my version and let you change it". I feel that the criteria that I previously listed are still valid, and despite what Nigel might claim, there are major issues with his version (in terms of Lisp constructs, idioms and formatting) which is why I removed his version, and not because I was being vengeful, as he stated below. His submission is badly written and should be removed. It is that simple. If Nigel would like to change the version written by Ledrug, I feel that he should write a list of valid reasons which can be debated. If the reasons are sound and agreeable, then he be allowed to modify Ledrug's version with one caveat: All of Nigel's Common Lisp submissions have been extremely poorly written and indicative of someone who does not care to either learn or write proper Lisp code, so the submission should be vetted here, on the talk page, before he is allowed to post it on the task page. --Larry Hignight 03:49, 8 October 2012 (UTC)
Ledrug replaced your version at 04:55, 19 September 2012, I responded to your explanation at 18:44, 19 September 2012 (UTC). I accepted that you had undone the changes and explained why I had made them. No mention of 'hot air', the response finished with A mute point now as ledrug has done tha task properly. You made a long response on 23 September. 26th September I responded with "A lot of hot air for somthing that doesn't exist!". If you thought, and I agree with you, that "Ledrug (had already) submitted a single version that was faster than mine (Larry), well-written, and worked for all number bases" what is there to discuss. You have agreed that he replaced your version to "reduce code; simplify; speed up; conform to task and extra". Does this not imply that your code needed improving? Only if you resurect and improve your (rubbish?) version is the subject interesting. I have responded to the issue you have raised regarding my current submission below.--Nigel Galloway 12:44, 9 October 2012 (UTC)
Nigel, the code that Ledrug contributed was beneficial because it worked in additional number bases and was faster than my submission. The code that you submitted looked like something a drunk C programmer would have written while doing a first experiment with CL. Not only was it horribly written CL, it clearly did not work correctly: Any number consisting of only nines is a Kaprekar number (in case you didn't get the memo). Please don't confuse the rubbish that you submitted with something that completed the task because it clearly did not solve it. --Larry Hignight 04:28, 16 October 2012 (UTC)

I can identify three issues, none requiring any particular Lisp knowledge to resolve:

Issue the first

Sorry Paddy, you are probably going to have to pass the first to Michael. It is really a matter of editorial policy under what circumstances it is acceptable on rosetta code to call someone a "pompous dick" (if it is acceptable, how far may I go in responding?). Either way I can take it, boys will be boys. I don't know why ledrug chose to vomit over rosetta code, he seems to think his bile is reason, and to be suprised that it doesn't have the effect on me he thinks it should.

Issue the second

As Larry says "Anyone can view the history". Let's do so.

(cur | prev) 23:12, 19 September 2012? Ledrug (Talk | contribs)? m (84,428 bytes) (?Common Lisp: improve silly logic) (undo)
(cur | prev) 04:55, 19 September 2012? Ledrug (Talk | contribs)? (84,438 bytes) (?Common Lisp: reduce code; simplify; speed up; conform to task and extra) (undo)
(cur | prev) 00:12, 19 September 2012? Lhignight (Talk | contribs)? (88,507 bytes) (?Common Lisp: Updated the description of the 'fast' implementation.) (undo)
(cur | prev) 23:54, 18 September 2012? Lhignight (Talk | contribs)? (88,429 bytes) (Undo revision 140330 by Nigel Galloway (talk)) (undo)
(cur | prev) 23:52, 18 September 2012? Lhignight (Talk | contribs)? (90,240 bytes) (Undo revision 140337 by Paddy3118 (talk)) (undo)
(cur | prev) 23:50, 18 September 2012? Lhignight (Talk | contribs)? (90,151 bytes) (Undo revision 140331 by Nigel Galloway (talk)) (undo)
(cur | prev) 23:47, 18 September 2012? Lhignight (Talk | contribs)? (90,293 bytes) (Undo revision 140336 by Nigel Galloway (talk) See the CL section of the talk page for further discussion) (undo)
(cur | prev) 11:38, 9 July 2012? Nigel Galloway (Talk | contribs)? (79,959 bytes) (?Common Lisp) (undo)

I made a change to Larry's Common Lisp implemantation to make it work on 9 July 2012.

Nigel, my version did work. Your changes did NOT work and I wrote a number of bullets points addressing the issues with your version, which you chose to ignore, and instead responded to these valid concerns in an arrogant and pompous manner. You had the opportunity to respond to my criticism of your naming conventions, unnecessary use of globals (and later constants), use of setq, improper use of multiple-value-bind, poor readability/use of abrstaction, and other issues, including the FACT that your code FAILED to identify 9,999,999 as a Karprekar number. Instead, YOU chose to dismiss all of these valid concerns by stating that I was full of "hot air" and further suggest that the proper thing would have been for me to have fixed your version. --Larry Hignight 03:49, 8 October 2012 (UTC)

This stood until 18 September 2012, when Larry unidid the changes returning the implementation to a less than working solution.

Again, I undid your changes because the version that you posted was INCORRECT and BADLY WRITTEN Common Lisp. Your reference to my version as being 'less than a working solution' is another example of the bullshit comments that you continuously make in a vain attempt to deflect valid criticism of your submissions. --Larry Hignight 03:49, 8 October 2012 (UTC)

Ledrug completely replaced Larry's solution with a working example on 19 September 2012. For some reason Larry thinks I broke his solution and says "And for the record, Ledrug replaced YOUR version, not mine.". I think Larry is simply wrong in fact.

Nigel, YOU originally replaced my version starting this whole mess. Here is the precise order of events:
  • June 21 -- I (Larry) added a 2nd fast version that was quite a bit faster, easier to read, used additional Lisp forms AND only worked in base-10 (which is why I left the original version).
    • Both vesions were correct.
  • July 3 -- I (Larry) added the 'modular arithmetic filter' and additional output to the fast version that I had submitted.
  • July 9 -- You (Nigel) made three changes updates to my version; I was busy at the time had didn't have time to review your changes.
  • July 9 -- Paddy removed our names from the comment log.
  • Sept 18 -- After reviewing your version, which I found to be both incorrect and badly written, I undid you changes and posted why on the talk page.
    • You responded with the "hot air" comment and stated I should have fixed your code.
Again wrong in fact. Ledrug replaced your version at 04:55, 19 September 2012, I responded to your explanation at 18:44, 19 September 2012 (UTC). I accepted that you had undone the changes and explained why I had made them. No mention of 'hot air', the response finished with A mute point now as ledrug has done tha task properly. You made a long response on 23 September. 26th September I responded with "A lot of hot air for somthing that doesn't exist!". If you thought, and I agree with you, that "Ledrug (had already) submitted a single version that was faster than mine (Larry), well-written, and worked for all number bases" what is there to discuss. Only if you resurect and improve your version is the subject interesting--Nigel Galloway 13:05, 8 October 2012 (UTC)
  • later, Ledrug submitted a single version, which he later updated with the mod filter, that was faster than mine, well-written, and worked for all number bases.
    • I believe Ledrug's current version is the best CL implementation of the task and should be the only version UNLESS someone using the code change criteria has valid reasons for changing it. --Larry Hignight 03:49, 8 October 2012 (UTC)
Why only one version? There are four ways to implement this task.--Nigel Galloway 13:05, 8 October 2012 (UTC)
Your current version does not work. I have attempted to compile it on three Lisp implementations to date. Submit something that is well written CL code that compiles on standard CL implementations and then we can discuss whether or not an additional version is warranted. --Larry Hignight 04:28, 16 October 2012 (UTC)

The problem is that ledrug replaced Larrys solution to, in ledrug's description "reduce code; simplify; speed up; conform to task and extra improve silly logic". This has made Larry angry, I think with the wrong person.

This is not true at all. First, you are the only person that I have been angry with due to your dismissive and insulting comments. Second, it is clear that Ledrug's 'silly logic' comment was in reference to a loop condition that he had written. --Larry Hignight 03:49, 8 October 2012 (UTC)

I would prefer that ledrug did not so overwrite someone elses work, but Larry seemed more interested in pointless abuse of me than improving and justifying his solution. Anyway I had a better idea.

Unbelievable. I wrote valid criticisms about the CORRECTNESS and READABILITY of the changes that YOU made to my submission. Something that you seem incapable of responding to in a professional manner. --Larry Hignight 03:49, 8 October 2012 (UTC)
Larry, how old are you? You have accepted that "Ledrug submitted a single version, which he later updated with the mod filter, that was faster than mine, well-written, and worked for all number bases." You have agreed that he replaced your version to "reduce code; simplify; speed up; conform to task and extra". Does this not imply that your code needed improving? I am not interested in your critisism of me, though when it degenerates to "Well said. He is clearly more interested in being a pompous dick then contributing quality code to RC" I don't think it is acceptable.--Nigel Galloway 13:05, 8 October 2012 (UTC)
I called you a pompous dick AFTER you started dismissing valid criticisms with smart ass remarks, confusing the issue with lies on this talk page and then writing unwarranted comments on someone's user page. If you don't like being called a dick, then stop acting like a dick. It's pretty simple, really. Regarding your latest lie and attempt at confusing the issue, "You have agreed that he replaced your version to 'reduce code; simplify; speed up; conform to task and extra'," I never said that Ledrug's version reduced my code, simplified my code, or agreed to anything on this page. Ledrug's change comments were (once again) comments about his code. He improved his code. You should consider doing the same. --Larry Hignight 04:28, 16 October 2012 (UTC)

Issue the third

I have identified 3 approaches to this task: 

   1) a naive approach which loops over all numbers testing each fully for Kaprekarness; 
   2) a more sophiscated method which still loops over all numbers but implements a filter based on casting out nines which quickly eliminates seven nineths of the numbers; 
   3) realizing the nature of the uneliminated numbers it is possible to identify the residual sets to which possible Kaprekar numbers belong and generates them.

ledrug's solution was of the first ilk, my better idea was to implemented a solution of the third. ledrug responded by upgrading his solution to type 2 and overwrote my solution with his. I recovered my solution and left ledrug's second solution in tact. He says's "then my edit you reverted" (sic), perhaps he didn't check the changes and thought I had deleted his - I had not. I may work further on this solution. I have noticed that the first 2 Kaprekars are in ran and that the test is simpler when it only needs to identify Kaprekars larger than Base. I have asked ledrug to leave this solution in place. I think he will comply even though he thinks saying please is bad manners. Larry didn't leave it, but I just put that down to vengence, the only reason he supplied is that ledrug has taught him to swear. I have supplied two good C++ solutions, but have not deleted the origional rather slow version. Ledrug has now implemented a fourth method, without deleting any one elses. Is that not better? --Nigel Galloway 13:15, 7 October 2012 (UTC)

Testing Common Lisp Contributions

Just to confirm my suspicions about the quality of Nigel's CL submissions, I decided to test both Ledrug and Nigel's current versions:

  • Ledrug's version:
    • Compiled on both CLISP and LispWorks without requiring any changes
    • Was extremely fast; In fact, it was faster than Nigel's 'vfast' C++ version for n = 1 million (.85s vs 1.20s)
      • The C++ compilation done with MinGW. The CL compilation with LispWorks. I did not set the compiler to optimize in either case.
  • Nigel's version:
    • Does not compile on CLISP: exit clause in DO must be a list
    • Does not compile on LispWorks: NIL does not match (SYSTEM::END-TEST-FORM &REST SYSTEM::RESULT-FORMS)
The following is tha ANSI specification fon NIL
1.4.1.4.4 NIL

nil has a variety of meanings. It is a symbol in the common-lisp package with the name "NIL", it
is boolean (and generalized boolean) false, it is the empty list, and it is the name of the empty
type (a subtype of all types).

Within Common Lisp, nil can be notated interchangeably as either NIL or (). By convention, the
choice of notation offers a hint as to which of its many roles it is playing.

Notations for NIL
For Evaluation? 	Notation 	Typically Implied Role
    Yes 	          nil    	use as a boolean.
    Yes 	         'nil   	use as a symbol.
    Yes         	 '()    	use as an empty list
    No                 	  nil      	use as a symbol or boolean.
    No          	  ()    	use as an empty list.
From which I and my "antique lisp machine ... installed in your (my) basement" conclude that () may be used as an empty list. Apparently your advanced implementations don't, but this is Lisp for you.--Nigel Galloway 12:14, 9 October 2012 (UTC)
'() can be used as an empty list on all Common Lisp implementations including SBCL, Clisp and LispWorks. Try again. --Larry Hignight 04:28, 16 October 2012 (UTC)

I'm sure that Nigel will respond to these results in his usual manner: "that is hot air", "all of your implementations are flawed; Mine is the only true Common Lisp", "Surely, you must have my version and Ledrug's version mixed up", or even the classic "Why didn't you just fix my code!" Who knows... I'm sure that it will be amusing though. Therefore, I encourage everyone with a working CL implementation to attempt to compile both versions and post your results. --Larry Hignight 07:45, 8 October 2012 (UTC)

Always happy to exceed expectations. If it is amusing you want, let me put another nail in British humour: Do you know the definition of a Yankee?; A bit like a quickie but he does it himself.--Nigel Galloway 11:12, 10 October 2012 (UTC)
Yeah, that wasn't up to your usual standards. --Larry Hignight 04:28, 16 October 2012 (UTC)

Levenshtein distance C code

I Just noticed that you posted a recursive C solution for Levenshtein distance. Could you maybe explain (here or in/near the example) what the variables mean in that solution? I tried to come up with a recursive solution in Java myself, but it didn't work out so well. If at all possible could you maybe just give some pseudocode for the recursive algorithm? --Mwn3d 20:25, 20 June 2011 (UTC)

The recursion function has 4 parameters: s, string 1; ls: length of s; t: string 2; lt length of t. Basically, <lang>function levenschtein(s, t)
   if length(s) = 0: return length(t)
   if length(t) = 0: return length(s)
   if s[0] = t[0]  : return levelschtein(s[1 .. end], t[1 .. end])

   len1 := levelschtein(s, t[1 .. end]) + 1
   len2 := levelschtein(s[1 .. end], t) + 1
   len3 := levelschtein(s[1 .. end], t[1 .. end]) + 1
   return min(len1, len2, len3)

</lang>where s[0] meaning first char in string s; s[1 .. end] meaning s without first char. (heh this reads just like the C code. I suck at pseudo code.) --Ledrug 20:39, 20 June 2011 (UTC)

Oh duh. C strings. Forgot about passing around lengths separately. So this says if either string is empty, return the length of the other string (because you just insert or delete all of the other string). If the first chars are the same, nothing needs to happen so just ignore them. Otherwise try deleting one char (len1), inserting one char (len2), or essentially making the first chars the same (as len3 but count the move this time), and return the minimum distance from those. OK I think I got it. Thanks for that. It's really close to what I was thinking of when I tried to do it, but this makes much more sense. I'll try to translate it soon. --Mwn3d 20:50, 20 June 2011 (UTC)
Any chance you might add this to the tasks talk page? I'll be adding a (memoized) version of this in the Python section. Thanks. --Paddy3118 21:45, 20 June 2011 (UTC)
But the wikipedia solution is the memoized version, though? --Ledrug 22:26, 20 June 2011 (UTC)
Hi, there are no recursive calls here. --Paddy3118 05:15, 21 June 2011 (UTC)
Yeah I know, I meant if you memoize the results and convert recursion to iteration, they are exactly the same algorithm. I guess recursive version expresses the idea better, maybe. --Ledrug 05:18, 21 June 2011 (UTC)

Hough transform C code

Rather than adding {{incorrect}}, it's probably more appropriate to just fix the code. Also, while I definitely appreciate the expertise and perspective I've seen you bringing to many areas across the wiki, calling code out as a 'shame', particularly in the page body itself, is inappropriate. Since the code implements the task, it's technically correct. If you'd like to raise suggested fixes (without implementing them yourself), you should raise them in the talk pages, as you've been doing elsewhere. --Michael Mol 01:10, 23 June 2011 (UTC)

Point 3 was minor, the key issue was the black artifact at bottom and the processing order. Yes I shouldn't called it a shame, sorry. I was looking at coding it, but I need to simple down the lib requirement first. --Ledrug 01:14, 23 June 2011 (UTC)
That "shame code" wanted to be a as close as possible translation of the Tcl code, that could have been useful in comparing (languages), and if such a translation had bugs, it could have been fixed; any other non-technical word (and especially subjective one) can be left out or put elsewhere as a mean of starting a hopefully useful (teach and learn) discussion about interesting "facts", if there are any. For what is worth, I refrain from replacing working code just for my aesthetic beliefs and even for what I know or think could be "best practices" without considering carefully the reasons or trying to inherit as much as possible (by the code, or by the wiki, e.g. consider the PNM related tasks). --ShinTakezou 17:15, 21 May 2012 (UTC)
And the argument is even stronger when there are no "artifact" to be fixed, just taste. I don't even understand "self-commenting" like "good luck printing out your token stack as a table: there isn't one.". If there is something unclear in the task that you've noticed, write in the talk page. --ShinTakezou 17:21, 21 May 2012 (UTC)
If you have a better solution (or different idiomatic solution, or an explicit translation, though those don't tend to last very long in the face of interested parties), put it side-by-side next to the existing code. I see that the original C code was replaced. Don't get offended; if you like, add your vision of the code next to the current version and move on. Yes, I realize Ledrug didn't do this last June. He was also new to the site, and there's very little codified in terms of RC netiquette, and what uncodified netiquette exists is flexible to the needs of the circumstance. --Michael Mol 16:20, 22 May 2012 (UTC)

Welcome

Not going to drop the boilerplate greeting; I need to update it, I think. However, I've seen you as one of a few particularly active new users in the last few months, you've been getting a feel for the wiki and its habits, and it's pretty cool. Keep it up! :) --Michael Mol 01:11, 23 June 2011 (UTC)

Thanks! --Ledrug
You ever going to get around to populating your user page, perhaps with {{mylang}}? :P --Michael Mol 02:54, 13 August 2011 (UTC)

Deathstar

Your ascii based deathstar solution is truly excellent. :-)

Last Fridays

Hi, your C code for "Last Fridays" is quite complicated. Maybe some explanations about the calculation done (or comments in the code) would be a good idea, don't you think? Blue Prawn 21:13, 9 November 2011 (UTC)

There are only 5 statements in the code, one of which deals with command line args, two others calculate leap years. I'm not sure, what kind of comments would be helpful and not redundant? --Ledrug 01:26, 10 November 2011 (UTC)
Where did this line come from?:

<lang c>w = y * 365 + (y - 1) / 4 - (y - 1) / 100 + (y - 1) / 400 + 6;</lang>

I understand that it is math and what multiplication is, but I don't know how it is relevant. --Mwn3d 01:43, 10 November 2011 (UTC)
That's the number of days between Jan 0th of year y and some unspecified past date. All we need is that that number modulo 7 gives day of week of Jan 0th, y AD. --Ledrug 02:09, 10 November 2011 (UTC)
Is "Jan 0th" just Dec 31 of the previous year? Where did the formula come from? --Mwn3d 02:21, 10 November 2011 (UTC)
it is a formula that takes leap years into account: a year has 365 days, except every 4 years (y-1)/4, when it has 366, so those need to be added. but, every 100 years is not a leap year (y-1)/100, so those need to be subtracted again, and then every 400 years is a leap year again so (y-1)/400 needs to be added back. it is pretty straightforward once analyzed. i don't know what the +6 at the end is for though.--eMBee 03:22, 10 November 2011 (UTC)
Jan 0th is the day before Jan 1st, it doesn't quite matter what that means, as long as, say, Jan 0th + 10 days = Jan 10th. The "+6" to the number of days is so that the number modulo 7 gives the day of week, it just so happens that it's 6. --Ledrug 05:05, 10 November 2011 (UTC)

Galton

Could you please post the output image for your solution. Thanks. (See talk, my error). --Dgamey 03:31, 15 November 2011 (UTC)

AutoHotkey image

I'm interested in how you got the AutoHotkey image on Yin_and_yang to upload to Rosetta Code; when I tried it wouldn't work. In fact, even now when I download the file from imgur and attempt to upload it, it still fails, showing the "supported file types" in red. Perhaps it's the browser? I use Google Chrome... This would really be a help; I've had problems with it in the past. While we're on the topic, would it be OK to upload the large image as well? (Second Image in the imgur link.) If it's too large, I could simply run the AHK script again with a smaller width and height parameter. --Crazyfirex 03:20, 19 November 2011 (UTC)

I don't really know why one can or cannot upload an image, but I did convert your blobs from indexed mode to grayscale before uploading, maybe that has something to do with it. I have replaced the image with your bigger verseion now (I had javascript disabled the first time I followed the link, so didn't see it there at all). If you think it's too big, set a size parameter on it like this: [[file:yin-yang-ahk.png|right|150px]]. --Ledrug 03:28, 19 November 2011 (UTC)
Well, it's smaller than both the PicoLisp and ALGOL's ASCII outputs, and it doesn't disrupt the code, so I don't think anyone will object to the size. What tool did you use to convert them? Maybe I can use it in the future. In any case, thanks for uploading it. --Crazyfirex 03:40, 19 November 2011 (UTC)
I used GIMP to convert it. Imagemagick might work, too (however, if it did, there would be no reason for this conversion since MediaWiki uses it internally to scale images). --Ledrug 03:49, 19 November 2011 (UTC)
Well here we go again... I solved http://rosettacode.org/wiki/Colour_pinstripe/Display with AutoHotkey, and the wiki won't let me upload a screenshot. Interestingly enough, I didn't make the image with AHK, but with Prt Scr + Paint. Would you be so kind as to upload this? http://i.imgur.com/0qquS.png ...I feel so needy
Done. Check the task page to see if you are ok with the format. --Ledrug 02:58, 10 December 2011 (UTC)
We still have a workaround for the image upload problem. It's weird but it seems to work. Also I think disabling Javascript in your browser makes it work. --Mwn3d 03:56, 10 December 2011 (UTC)
Beggars can't be choosers. It looks fine to me. (Also, I like the comment. If you think it looks trippy now, run the script and see it in fullscreen at native resolution. O.O) --Crazyfirex 04:29, 10 December 2011 (UTC)
I wouldn't know: I never had problem uploading bitmap images. You probably want to talk to Crazyfirex instead. --Ledrug 04:07, 10 December 2011 (UTC)
That's interesting. I'll try it on the next task. Thanks. --Crazyfirex 04:29, 10 December 2011 (UTC)
Turning off javascript works. Thank you very much! I tested it at Constrained_random_points_on_a_circle. --Crazyfirex 03:31, 11 December 2011 (UTC)

Zebra puzzle

Cudos for catching this! :) I remembered to fix the one thing but forgot about the other... Cheers. WillNess 06:41, 3 December 2011 (UTC)

Amazon links

The amazon links do carry commission for RC, but I agree they shouldn't be required for tasks unless necessary. Obviously, if the Amazon links harm the the site's utility to any of RC's class of visitors, they're inappropriate. Still, I'd like to see them available as additional resources references, where they're useful. --Michael Mol 03:57, 24 December 2011 (UTC)

I sort of expected that, that's why I left the Amazon link alone. For the specific task, the book authors' page has a link to Amazon, while it's hard to go from Amazon to that page. Most users interested in that task probably only need some context instead of the whole book, so a way to read a single chapter should be useful. --Ledrug 04:26, 24 December 2011 (UTC)

Lisp in the style of the C++ generator

Please leave this code alone until you can demonstrate an understanding of this problem. Your second attempt at this is an improvement over your first naive attempt, but still not as interesting as this. Maybe I shall seperate the Casting_out_nines from the Kaprecar part: <lang clisp>(let ((kk (* N N))) (do ((B Base (* B Base))) ()(let (( nr (/ (* N (- B N)) (- B 1)))) (if (< 0 nr) (let ((q (floor (- N nr)))) (if (= kk (+ nr (* q B)))</lang>

Retrieved from "https://rosettacode.org/wiki/User_talk:Ledrug?oldid=189826"