I have noticed that very many Haskell elementary functions and operators (second-level functions) do the very same jobs as those of the late great language APL, like map, like zipwith, like foldl which used to be noted / and scan which used to be noted backslash, like max and min which used to be elementary operations denoted by Greek letters. I am wondering whether like notations should be made admissible in Haskell. I for one would make any scalar-value-only functions mappable onto lists and arrays as long as no ambiguity arise, and also on any entity where fmap is defined. A point immediately after the scalar dyadic function would make it zip with the next entity : fibs = fibs +.(Drop fibs). I would use (+) // for foldl add and (+)\\ for scan.
I came up with a different way of getting the natural numbers: nat = 0 : map (+1) nat Is there a disadvantage to using this way? Does it have a greater time complexity?
That's really neat, actually! I don't think there is any downside to this definition. The time complexity should be the same, since every new term built by the map function is lazily evaluated. The thunks created might be a tiny bit bigger (I'm not sure though).
We evaluate them one at a time SInce time isn't infinite real lists will terminate unless something is broken We evaluate them as we need them instead of all of them at once This actually solves the problem you are mentioning rather than creating them
How Haskell calling window com object like Excel? Here is example of odbc & SQL client. sirocco.hatenadiary.org/entry/20100418/1271569324 This example seems using package *hcom*
-- 4:12 Using foldr for infinite lists is possible. But you have to use an irrefutable pattern (~) for the accumulator parameter: chunksOf n = foldr fn [[]] . zip [1..] where fn (i,x) ~(inner:outer) | i `mod` n == 0 = [x]:inner:outer | otherwise = (x:inner): outer segmentAfter p = foldr fn [[]] where fn x ~(inner:outer) | p x = [x]:inner:outer | otherwise = (x:inner): outer
all about infinity is only math construct what is not in the real life, we have only big or small numbers. we should consider time is also not divided in the infinite small time parts, knowns as planck time, the planck time is the smallest amount of time
Correction: At 2:55 the correct definition for odds is "odds = filter (\x -> mod x 2 == 1) nat".
Shouldn't the anonymous function for map also have an \x?
Great video series! One nitpick: The naive recursive implementation of fib doesn't grow quadratic, but exponential.
Yes :) Just like Fibonacci numbers themselves, because the naive impl is exactly like finger counting.
Indeed, with the base being Fibonacci constant raised to n.
Thanks a lot for making these videos, Philipp. They really help me to become a better FP developer.
Glad I could help! :)
Yes! Thank you for the "WHY" ... the Application portion.
At 6:29 "has quadratic time complexity" is not correct: it's actually exponential (2**n) which is even worse ... a lot!
I have noticed that very many Haskell elementary functions and operators (second-level functions) do the very same jobs as those of the late great language APL, like map, like zipwith, like foldl which used to be noted / and scan which used to be noted backslash, like max and min which used to be elementary operations denoted by Greek letters. I am wondering whether like notations should be made admissible in Haskell. I for one would make any scalar-value-only functions mappable onto lists and arrays as long as no ambiguity arise, and also on any entity where fmap is defined. A point immediately after the scalar dyadic function would make it zip with the next entity : fibs = fibs +.(Drop fibs). I would use (+) // for foldl add and (+)\\ for scan.
-- regular haskell:
fibs = 0:1:fibs +. tail fibs
where (+.) = zipWith (+)
yeah, as Mick said, just define your own operators
I came up with a different way of getting the natural numbers:
nat = 0 : map (+1) nat
Is there a disadvantage to using this way? Does it have a greater time complexity?
That's really neat, actually!
I don't think there is any downside to this definition. The time complexity should be the same, since every new term built by the map function is lazily evaluated. The thunks created might be a tiny bit bigger (I'm not sure though).
A slight improvement may be:
nats = 0 : map succ nats
@@philipphagenlocher, how about:
nats = [1,2..]
evenNats = [2,4..]
oddNats = [1,3..]
I am sorry but how can we use drop function with infinite list if we cannot evaluate end of the list?
We evaluate them one at a time
SInce time isn't infinite real lists will terminate unless something is broken
We evaluate them as we need them instead of all of them at once
This actually solves the problem you are mentioning rather than creating them
How Haskell calling window com object like Excel? Here is example of odbc & SQL client.
sirocco.hatenadiary.org/entry/20100418/1271569324
This example seems using package *hcom*
-- 4:12 Using foldr for infinite lists is possible. But you have to use an irrefutable pattern (~) for the accumulator parameter:
chunksOf n = foldr fn [[]] . zip [1..]
where fn (i,x) ~(inner:outer)
| i `mod` n == 0 = [x]:inner:outer
| otherwise = (x:inner): outer
segmentAfter p = foldr fn [[]]
where fn x ~(inner:outer)
| p x = [x]:inner:outer
| otherwise = (x:inner): outer
A simple implementation of Fibonacci
fib = t 0 1 where t n1 n2 = n1: (t n2 $ n1 + n2)
all about infinity is only math construct what is not in the real life, we have only big or small numbers. we should consider time is also not divided in the infinite small time parts, knowns as planck time, the planck time is the smallest amount of time