# Map vs list comprehension

**URL:** https://discourse.julialang.org/t/map-vs-list-comprehension/916
**Category:** General Usage
**Created:** [December 13, 2016, 12:50pm UTC](https://discourse.julialang.org/t/map-vs-list-comprehension/916 "2016-12-13T12:50:07Z")
**Posts on this page:** 1
**Showing post:** 9

<div class="post-metadata">

### Author: ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)
#### Post date: [December 23, 2016, 3:04pm UTC](https://discourse.julialang.org/t/map-vs-list-comprehension/916/9 "2016-12-23T15:04:00Z")

</div>

> [@Evizero](#):
>
> I suspect (but don’t actually know) that one reason for Int64 to provide a getindex implementation is to make broadcast work in a general way.

No, `broadcast` doesn’t need this (in 0.6, it works on arbitrary “scalar” types that don’t have `getindex`).

I think that largely this is the Matlab legacy; in Matlab, numbers are “really” 1x1 matrices internally, and it is quite common to write functions that are supposed to work on either scalars or arrays of numbers in order to vectorize. To simplify the process of writing such generic scalar/vector code, you can access numbers as if they were 0-dimensional arrays in Julia.

I think that a lot of the need for this should be gone now with 0.5’s dot-call syntax: in the cases where you would previously have written a generic vector/scalar function, you should now just write the scalar function `f(x)`, and then apply it to arrays `A` with `f.(A)`. This is not only easier, it is also faster because it can fuse with other elementwise operations and the result can be assigned in-place with `.=`.

See also: [make numbers non-iterable? · Issue #7903 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/issues/7903)

---

_[View the full topic](https://discourse.julialang.org/t/map-vs-list-comprehension/916)._