Talk:Dot product: Difference between revisions

map-based zipWith
(map-based zipWith)
Line 65:
:And, thanks! --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 19:36, 27 February 2016 (UTC)
 
:: Thanks – that seems sensible – On zip and zipWidthzipWith implementations, the ones that I am used to return a result with the length of the shorter input, which has the advantage I think, of allowing them to be both well-defined and a little more robust - reducing the range of values which will bottom out, and allowing for cases where the short match is specifically what's sought. The Haskell prelude zipWidth, for example is:
::<lang Haskell>zipWith :: (a->b->c) -> [a]->[b]->[c]
zipWith _f [] _bs = []
Line 73:
::: Hmm.... from my point of view, "robust" in the context of "programmer interaction" means: "easily describable" and "useful". But you also want to bubble problems up to the programmer. And, in my experience, "mis-matched lengths" is almost always a problem. If the programmer really wanted the shortest of the two, it's easy enough to discard the unwanted elements from the longer list.
::: Not sure about the larger issue, though -- I can see both sides of this and haven't made up my mind. --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 21:25, 27 February 2016 (UTC)
::::Not sure how that looks – I've adjusted zipWidthzipWith to return undefined when array lengths vary (it certainly does simplify the top level of dotProduct), and for the moment I've left the earlier code in place, and just reframed its characterisation. [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 22:08, 27 February 2016 (UTC)
::::(and, just now, swapping in your zipWith - which is much cleaner and more pleasing)[[User:Hout|Hout]] ([[User talk:Hout|talk]]) 00:41, 28 February 2016 (UTC)
9,655

edits