libera/#commonlisp - IRC Chatlog
Search
8:13:51
flip214
Help, please. What's the difference between these forms? (intersection r l) (remove-if-not (lambda (l) (member l r)) l)
8:14:14
flip214
r and l are lists of structures; the first form returns the expected 10 results, the second only 6 values.
8:43:38
pjb
(let ((r '(1 2 3 4 1 2 3)) (l '(3 4 5 6 4 5))) (values (intersection r l) (remove-if-not (lambda (l) (member l r)) l))) #| --> (3 4 3) ; (3 4 4) |#
8:44:56
pjb
What is missing is only (defun seq-equal (a b) (and (subsetp a b) (subsetp b a))) ; perhaps more efficiently.
8:44:58
gin
Need some advice with this code: https://plaster.tymoon.eu/view/2558 - I am comparing two approaches here. (1) ex-1: A single LET for all lexical variables. (2) ex-2: Multiple nested LETs for defining lexical variables only where they are needed.
8:45:39
pjb
a set-equal function would make it more concrete that there's a set type based on list, like subst and copy-tree make it clear there's a tree type based on lists.
8:47:07
gin
pjb: If I assume compiler can optimize things out, then I can stick with ex-1 where a single LET contains all lexical variables, couldn't I?
8:47:55
beach
gin: It is not a question of compiler optimizations. It is a matter of how much code the person reading your code has to consider for an occurrence of the variable.
8:47:57
gin
beach: thanks! I was thinking that too. But then does it bother anyone that it may lead to multiple nested-LETs making the code harder to parse with eyes? Or is that not a valid concern?
8:52:28
gin
beach: thanks! I have mentioned in comments at the top that I am making a contrived example to compare my LET-approaches. could not make a more sensible example. I understand that LOOP COLLECT is appropriate here and COUNT is not required.
8:54:04
_death
gin: the nested LETs make it easier to pull the forms out into their own function, for example.. they also make it easier for the reader to know the value of the bindings, considering the alternative is a variable that changes over time
8:54:26
beach
(loop for article in articles for newline-position = (position #\Newline article) collect (subseq article 0 newline-position)) with appropriate newlines inserted.
8:57:34
beach
gin: A general rule of programming is that a function should do one single thing. The computation of the length makes the function do two things, which is not good.
8:58:26
beach
gin: You might see that more easily if you consider this function as also computing the reverse of the list, the Fibonacci number of the length, etc.
9:05:08
beach
So you must already know those rules, i.e., minimize the scope to make life easier for the person reading your code, and make each function do one thing.
9:31:40
gin
thanks shka. Is that true in general too? does it take constant time for any proper sequence?
9:34:01
beach
gin: If you think about how lists are represented, you can see that it has to traverse every CONS cell as shka is saying, so there is no way it can be O(1).
9:36:39
beach
gin: And if you don't know how lists are represented, it is time to learn that part. Otherwise, may things will likely confuse you in the future.
9:38:06
beach
... like why (defun push-it (element list) (push element list)) won't "work" as expected.
9:40:04
beach
shka: Indeed. But a significant number of newbies here don't seem to find it useful to read about things like that.
16:05:47
lisp123
Any good resources to learn algorithms when working with trees and also searching / traversing across trees & nodes?
16:07:52
beach
Aho Hopcroft Ullman, "The Design and Analysis of Computer Algorithms" is the classic text.
16:08:57
beach
Apparently, they also wrote "Data Structures and Algorithms" later. I haven't read that one.
16:09:54
beach
Be careful with any old book on data structures and algorithms. I estimate around half of published books get a simple thing like binary search wrong.
16:11:27
beach
Publishing houses will print and sell anything you are willing to write, and they fired all the copy editors decades ago.
16:11:49
beach
Apress seems to be the exception. They recruit qualified editors to screen the material.
16:12:04
lisp123
Yeah, their business models are coming under fire a lot (especially for technical books)
16:12:27
jackdaniel
there is an interesting book that touches this topic in polish "przejęzyczenie" (misspell) - it is a set of interviews with well known translators
16:15:12
beach
Speaking of which, the reason "Lisp in Small Pieces" is better in its English version, is that the translator is also an experienced editor. The original publishing house doesn't have staff like that as far as I know.
16:17:05
beach
As far as I remember, it was just the original text. He later wrote a revised French version, but I don't know more about it.
16:17:44
beach
Though, the translation was made interactively, i.e., they met on a regular basis to discuss the material, so it is not a "blind" translation.
16:19:07
beach
But the translator had knowledge of Lisp, so was able to introduce improvements because of that as well.
16:22:13
jcowan
jackdaniel: I saw a list of Russian surnames somewhere that look scary even to Russians because they are of (remote) Polish origin:
16:23:27
jcowan
Not as clever as the English title, which shows how flexible (twisty) English actually is
16:24:00
beach
hendursaga: No, I am familiar with the French one because I used it in a course, and with the English one because I know the translator.
16:24:27
jcowan
jackdaniel: Here's a few of them: "Yastrzhembsky (the diplomat), Krzhizhanovsky (the writer), and even Przhevalsky (of the horse)."
16:27:11
jackdaniel
I think that Russian nicknames are written in cirillic :) that would be Jastrzębski (Hawk-ski), Chrzanowski (horserasish-ski) and Przewalski (bulldoze-ski); sorry for bringing offtopic :)