Return the SUM of numeric elements in a nested list using LISP. If there are no numeric elements return an empty list/NIL
Examples:
(6 3 -2 5 (4 2 -3) 4) should return 19
(1 2 3 (-4 5) a b c) should return 7
Asking other people to do your homework for you is almost never a good way of learning anything.
But here's an answer, which is written in a Lisp (Racket) and which does show how you ought to go about solving this problem, and also (I think) demonstrates some nice ways of thinking about problems like this ... but which you almost certainly can't cut and paste.
Note that this does not quite agree with the requirements given: which is supposed to return a non-numeric value for a list with no numbers in it. That breaks a recursive algorithm like this, since the empty list is a list with no numbers in it. So this does something more sensible. Making this answer implement the requirements is left as an exercise to the student.
(define (sum-nested-list l)
(let sum-nested-list-loop ([thing l]
[running-total 0])
(match thing
['()
;; We're done if we've run out of list
running-total]
[(list* (? number? x) r)
;; A list whose first element is a number: add it to the running total
;; and carry on on the rest of the list
(sum-nested-list-loop r (+ running-total x))]
[(list* (? list? x) r)
;; A list whose first element is a nested list: recurse into the
;; nested list
(sum-nested-list-loop r (sum-nested-list-loop x running-total))]
[(list* _ r)
;; A list whose first element is not a number or a nested list:
;; carry on on the rest of the list
(sum-nested-list-loop r running-total)]
[_
;; Not a list at all: explode
(error 'sum-numeric-list "what?")])))
(defun flat-sum (tree)
(let ((count 0))
(tree-equal tree tree :test (lambda (left right)
(if (numberp left)
(incf count left) t)))
count))
1> (flat-sum '(1 2 3 (-4 5) a b c))
7
I feel I'm writing functions needlessly for the following operation of setting several derived columns sequentially:
(defn add-cols[d]
(do
(setv (get d "col0") "0")
(setv (get d "col1") (np.where (> 0 (get d "existing-col")) -1 1))
(setv (get d "col2") (* (get d "col1") (get d "existing-col")))
d
))
The above is neither succinct nor easy to follow. I'd appreciate any help with converting this pattern to a macro. I'm a beginner with macros but am thinking of creating something like so :
(pandas-addcols d
`col0 : "0",
`col1 : (np.where ( > 0 `existing-col) -1 1),
`col2 : (* `col1 `existing-col))
Would appreciate any help or guidance on the above. The final form of the macro can obviously be different too. Ultimately the most repetitive bit is the multiple "setv" and "get" calls and maybe there are more elegant a generic ways to remove those calls.
A little syntactic sugar that can help is to use a shorter name for get and remove the need to quote the string literal. Here's a simple version of $ from this library. Also, Hy's setv already lets you provide more than one target–value pair.
(import
[numpy :as np]
[pandas :as pd])
(defmacro $ [obj key]
(import [hy [HyString]])
`(get (. ~obj loc) (, (slice None) ~(HyString key))))
(setv
d (pd.DataFrame (dict :a [-3 1 3] :b [4 5 6]))
($ d col0) 0
($ d col1) (np.where (> 0 ($ d a)) -1 1))
I have the following lemma in why3:
lemma trivial:
forall a : array 'a, b : array 'a.
array_eq_sub a b 0 0
This seems like it would be the base case behavior, but apparently isn't. Any ideas on why this isn't working?
UPDATE
I was able to reduce the issue to a single missing lemma:
lemma array_eq_2:
forall a : array 'a, b : array 'a.
map_eq_sub a.elts b.elts 0 0 -> array_eq_sub a b 0 0
This seems trivial as well, given the definition of array_eq_sub as specified in the documentation. Why can't my prover find a solution?
After struggling with this issue, I decided to take a look at the why3 source code. I found a definition which was different from what was documented:
predicate array_eq_sub (a1 a2: array 'a) (l u: int) =
a1.length = a2.length /\ 0 <= l <= a1.length /\ 0 <= u <= a1.length /\
map_eq_sub a1.elts a2.elts l u
In short, the lengths of the arrays have to be equal in order for a portion of them to be equal. This was different than what was documented, and I suspect may be causing many theorems to be unsound.
What is the difference between
a: [b 1]
; and
a: [b: 1]
both give the same results for
> a/b
1
they differ for a/1 though.
When do you use what? And the 2nd is a set, what is the 1st?
the 2nd is a set, what is the 1st?
You can get answers by looking at the type:
>> type? first [b 1]
== word!
>> type? first [b: 1]
== set-word!
What is the difference
When you use the expression a/b you are writing something that acts like a SELECT statement, looking up "any word type" matching b in the block indicated by a, then returning the item after it in the block.
Red follows heritage from Rebol--defaulting path selections to be the "non-strict" form of SELECT, which uses a "non-strict" form of equality
>> (first [a:]) = (first [a]) ;-- default comparison
true
>> select [b 1] (quote b)
== 1
>> select [b: 1] (quote b)
== 1
To get the strict behavior of telling the difference, you need to use the /CASE refinement (in the sense of "case-sensitive"):
>> (first [a:]) == (first [a]) ;-- strict comparison
true
>> select/case [b: 1] (quote b)
== none
>> select/case [b: 1] (quote b:)
== 1
Red seems to be at least a little more consistent about this than R3-Alpha, for instance honoring the equality of 1% and 0.01:
>> 1% = 0.01
== true ;-- both R3-Alpha and Red
>> select [0.01 "test"] 1%
== "test" ;-- in Red
>> select [0.01 "test"] 1%
== none ;-- in R3-Alpha
But it shows that there's a somewhat dodgy history behind equality semantics.
When do you use what?
Good question. :-/ Notation-wise in your source, you should use that which you feel most naturally fits what you want to express. If you think a SET-WORD! is appropriate then use it, otherwise use a WORD!. Implementation-wise, there are some nuances that are beyond the scope of a simple answer (locals gathering in FUNCTION, for instance). If you know something will ultimately need to be transformed into an assignment, it may be helpful to use SET-WORDs.
Path evaluation is sketchy, in my opinion. It arose as a syntactic convenience, but then produced a cross product of behaviors for every type being selected from every other type. And that's to say nothing of the variance in how functions work (what would x: :append/dup/only/10/a mean?)
Small example: PATH! behavior in Rebol used a heuristic where if you are evaluating a path it will act as a PICK if the path component is an integer:
>> numbers: [3 2 1]
>> pick numbers 3
== 1 ;-- because the 3rd element is a 1
>> select numbers 3
== 2 ;-- because 2 comes after finding a 3
>> numbers/3
== 1 ;-- acts like PICK because (...)/3 uses an INTEGER!
...but as above, it will act like a SELECT (non-strict) if the thing being chosen is a WORD!:
>> words: [a b c]
>> select words 'a
== b ;-- because b is the thing after a in the block
>> pick words 'a
;-- In Rebol this is an error, Red gives NONE at the moment
>> words/a
== b ;-- acts like SELECT because (...)/a uses a WORD!
So the difference between SELECT and PICK accounts for that difference you're seeing.
It gets weirder for other types. Paths are definitely quirky, and could use a grand unifying theory of some sort.
And the 2nd is a set, what is the 1st?
It seems you are looking at both [b 1] and [b: 1] as code, but they are actually just data. More precisely, they are lists of two elements: a word! or set-word! value followed by an integer! value.
a/b is a syntactic sugar for select a 'b, which retrieves the value following 'b word (using a find call internally). For convenience, the searching for 'b also matches other word types:
red>> find [:b] 'b
== [:b]
red>> find [/b] 'b
== [/b]
red>> find ['b] 'b
== ['b]
red>> find [b] 'b
== [b]
As a side note, remember that a lit-word will evaluate to a word, which is sometimes referred by the "word-decaying" rule:
red>> 'b
== b
/case refinement for find and select will apply a stricter matching, ensuring that the types are also the same. Though, you obviously cannot use it with path notation, you would need to replace the path with a select/case call instead.
So, both are giving the same result for a/b, because both will return the value following b word (regardless of his "word sub-type"):
red>> [b 1] = [b: 1] ;-- loose comparison, used by `find` and `select`.
== true
red>> [b 1] == [b: 1] ;-- strict comparison, used by `find/case` and `select/case`.
== false
they differ for a/1 though.
Integer values have specific semantics in paths. They act as sugar for pick, so a/1 is equivalent to pick a 1. You can also force that behavior other words referring to integers in paths, by making them get-word! values:
red>> c: 1
== 1
red>> a: [b 123]
== [b 1]
red>> a/:c
== b
red>> a: [b: 123]
== [b: 123]
red>> a/:c
== b:
red>> c: 2
== 2
red>> a/:c
== 123
Read more about paths from Rebol Core Manual: http://www.rebol.com/docs/core23/rebolcore-16.html#section-2.10
When do you use what?
For a/b vs a/1 usage, it depends if you want to achieve a select or a pick operation.
For [b 1] vs [b: 1], it depends on the later use of the block. For example, if you are constructing a block for serving as an object or map specification, then the set-word form is a better fit:
red>> a: [b:]
== [b:]
red>> append a 123
== [b: 123]
red>> c: object a
== make object! [
b: 123
]
Also, you should use the set-word form each time you imply a "key/value" relationship, it makes your intent clearer for yourself and other readers as well.
I wanted to test foldl vs foldr. From what I've seen you should use foldl over foldr when ever you can due to tail reccursion optimization.
This makes sense. However, after running this test I am confused:
foldr (takes 0.057s when using time command):
a::a -> [a] -> [a]
a x = ([x] ++ )
main = putStrLn(show ( sum (foldr a [] [0.. 100000])))
foldl (takes 0.089s when using time command):
b::[b] -> b -> [b]
b xs = ( ++ xs). (\y->[y])
main = putStrLn(show ( sum (foldl b [] [0.. 100000])))
It's clear that this example is trivial, but I am confused as to why foldr is beating foldl. Shouldn't this be a clear case where foldl wins?
Welcome to the world of lazy evaluation.
When you think about it in terms of strict evaluation, foldl looks "good" and foldr looks "bad" because foldl is tail recursive, but foldr would have to build a tower in the stack so it can process the last item first.
However, lazy evaluation turns the tables. Take, for example, the definition of the map function:
map :: (a -> b) -> [a] -> [b]
map _ [] = []
map f (x:xs) = f x : map f xs
This wouldn't be too good if Haskell used strict evaluation, since it would have to compute the tail first, then prepend the item (for all items in the list). The only way to do it efficiently would be to build the elements in reverse, it seems.
However, thanks to Haskell's lazy evaluation, this map function is actually efficient. Lists in Haskell can be thought of as generators, and this map function generates its first item by applying f to the first item of the input list. When it needs a second item, it just does the same thing again (without using extra space).
It turns out that map can be described in terms of foldr:
map f xs = foldr (\x ys -> f x : ys) [] xs
It's hard to tell by looking at it, but lazy evaluation kicks in because foldr can give f its first argument right away:
foldr f z [] = z
foldr f z (x:xs) = f x (foldr f z xs)
Because the f defined by map can return the first item of the result list using solely the first parameter, the fold can operate lazily in constant space.
Now, lazy evaluation does bite back. For instance, try running sum [1..1000000]. It yields a stack overflow. Why should it? It should just evaluate from left to right, right?
Let's look at how Haskell evaluates it:
foldl f z [] = z
foldl f z (x:xs) = foldl f (f z x) xs
sum = foldl (+) 0
sum [1..1000000] = foldl (+) 0 [1..1000000]
= foldl (+) ((+) 0 1) [2..1000000]
= foldl (+) ((+) ((+) 0 1) 2) [3..1000000]
= foldl (+) ((+) ((+) ((+) 0 1) 2) 3) [4..1000000]
...
= (+) ((+) ((+) (...) 999999) 1000000)
Haskell is too lazy to perform the additions as it goes. Instead, it ends up with a tower of unevaluated thunks that have to be forced to get a number. The stack overflow occurs during this evaluation, since it has to recurse deeply to evaluate all the thunks.
Fortunately, there is a special function in Data.List called foldl' that operates strictly. foldl' (+) 0 [1..1000000] will not stack overflow. (Note: I tried replacing foldl with foldl' in your test, but it actually made it run slower.)
Upon looking at this problem again, I think all current explanations are somewhat insufficient so I've written a longer explanation.
The difference is in how foldl and foldr apply their reduction function. Looking at the foldr case, we can expand it as
foldr (\x -> [x] ++ ) [] [0..10000]
[0] ++ foldr a [] [1..10000]
[0] ++ ([1] ++ foldr a [] [2..10000])
...
This list is processed by sum, which consumes it as follows:
sum = foldl' (+) 0
foldl' (+) 0 ([0] ++ ([1] ++ ... ++ [10000]))
foldl' (+) 0 (0 : [1] ++ ... ++ [10000]) -- get head of list from '++' definition
foldl' (+) 0 ([1] ++ [2] ++ ... ++ [10000]) -- add accumulator and head of list
foldl' (+) 0 (1 : [2] ++ ... ++ [10000])
foldl' (+) 1 ([2] ++ ... ++ [10000])
...
I've left out the details of the list concatenation, but this is how the reduction proceeds. The important part is that everything gets processed in order to minimize list traversals. The foldr only traverses the list once, the concatenations don't require continuous list traversals, and sum finally consumes the list in one pass. Critically, the head of the list is available from foldr immediately to sum, so sum can begin working immediately and values can be gc'd as they are generated. With fusion frameworks such as vector, even the intermediate lists will likely be fused away.
Contrast this to the foldl function:
b xs = ( ++xs) . (\y->[y])
foldl b [] [0..10000]
foldl b ( [0] ++ [] ) [1..10000]
foldl b ( [1] ++ ([0] ++ []) ) [2..10000]
foldl b ( [2] ++ ([1] ++ ([0] ++ [])) ) [3..10000]
...
Note that now the head of the list isn't available until foldl has finished. This means that the entire list must be constructed in memory before sum can begin to work. This is much less efficient overall. Running the two versions with +RTS -s shows miserable garbage collection performance from the foldl version.
This is also a case where foldl' will not help. The added strictness of foldl' doesn't change the way the intermediate list is created. The head of the list remains unavailable until foldl' has finished, so the result will still be slower than with foldr.
I use the following rule to determine the best choice of fold
For folds that are a reduction, use foldl' (e.g. this will be the only/final traversal)
Otherwise use foldr.
Don't use foldl.
In most cases foldr is the best fold function because the traversal direction is optimal for lazy evaluation of lists. It's also the only one capable of processing infinite lists. The extra strictness of foldl' can make it faster in some cases, but this is dependent on how you'll use that structure and how lazy it is.
I don't think anyone's actually said the real answer on this one yet, unless I'm missing something (which may well be true and welcomed with downvotes).
I think the biggest different in this case is that foldr builds the list like this:
[0] ++ ([1] ++ ([2] ++ (... ++ [1000000])))
Whereas foldl builds the list like this:
((([0] ++ [1]) ++ [2]) ++ ... ) ++ [999888]) ++ [999999]) ++ [1000000]
The difference in subtle, but notice that in the foldr version ++ always has only one list element as its left argument. With the foldl version, there are up to 999999 elements in ++'s left argument (on average around 500000), but only one element in the right argument.
However, ++ takes time proportional to the size of the left argument, as it has to look though the entire left argument list to the end and then repoint that last element to the first element of the right argument (at best, perhaps it actually needs to do a copy). The right argument list is unchanged, so it doesn't matter how big it is.
That's why the foldl version is much slower. It's got nothing to do with laziness in my opinion.
The problem is that tail recursion optimization is a memory optimization, not a execution time optimization!
Tail recursion optimization avoids the need to remember values for each recursive call.
So, foldl is in fact "good" and foldr is "bad".
For example, considering the definitions of foldr and foldl:
foldl f z [] = z
foldl f z (x:xs) = foldl f (z `f` x) xs
foldr f z [] = z
foldr f z (x:xs) = x `f` (foldr f z xs)
That's how the expression "foldl (+) 0 [1,2,3]" is evaluated:
foldl (+) 0 [1, 2, 3]
foldl (+) (0+1) [2, 3]
foldl (+) ((0+1)+2) [3]
foldl (+) (((0+1)+2)+3) [ ]
(((0+1)+2)+3)
((1+2)+3)
(3+3)
6
Note that foldl doesn't remember the values 0, 1, 2..., but pass the whole expression (((0+1)+2)+3) as argument lazily and don't evaluates it until the last evaluation of foldl, where it reaches the base case and returns the value passed as the second parameter (z) wich isn't evaluated yet.
On the other hand, that's how foldr works:
foldr (+) 0 [1, 2, 3]
1 + (foldr (+) 0 [2, 3])
1 + (2 + (foldr (+) 0 [3]))
1 + (2 + (3 + (foldr (+) 0 [])))
1 + (2 + (3 + 0)))
1 + (2 + 3)
1 + 5
6
The important difference here is that where foldl evaluates the whole expression in the last call, avoiding the need to come back to reach remembered values, foldr no. foldr remember one integer for each call and performs a addition in each call.
Is important to bear in mind that foldr and foldl are not always equivalents. For instance, try to compute this expressions in hugs:
foldr (&&) True (False:(repeat True))
foldl (&&) True (False:(repeat True))
foldr and foldl are equivalent only under certain conditions described here
(sorry for my bad english)
For a, the [0.. 100000] list needs to be expanded right away so that foldr can start with the last element. Then as it folds things together, the intermediate results are
[100000]
[99999, 100000]
[99998, 99999, 100000]
...
[0.. 100000] -- i.e., the original list
Because nobody is allowed to change this list value (Haskell is a pure functional language), the compiler is free to reuse the value. The intermediate values, like [99999, 100000] can even be simply pointers into the expanded [0.. 100000] list instead of separate lists.
For b, look at the intermediate values:
[0]
[0, 1]
[0, 1, 2]
...
[0, 1, ..., 99999]
[0.. 100000]
Each of those intermediate lists can't be reused, because if you change the end of the list then you've changed any other values that point to it. So you're creating a bunch of extra lists that take time to build in memory. So in this case you spend a lot more time allocating and filling in these lists that are intermediate values.
Since you're just making a copy of the list, a runs faster because it starts by expanding the full list and then just keeps moving a pointer from the back of the list to the front.
Neither foldl nor foldr is tail optimized. It is only foldl'.
But in your case using ++ with foldl' is not good idea because successive evaluation of ++ will cause traversing growing accumulator again and again.
Well, let me rewrite your functions in a way that difference should be obvious -
a :: a -> [a] -> [a]
a = (:)
b :: [b] -> b -> [b]
b = flip (:)
You see that b is more complex than a. If you want to be precise a needs one reduction step for value to be calculated, but b needs two. That makes the time difference you are measuring, in second example twice as much reductions must be performed.
//edit: But time complexity is the same, so I wouldn't bother about it much.