4 ms·

The second example in the first section is a bit misleading. They say that to create a column matrix, ie. an (n, 1) matrix, the syntax is [1 2 3]' but tha

The second example in the first section is a bit misleading. They say that to create a column matrix, ie. an (n, 1) matrix, the syntax is [1 2 3]' but that will give you the (lazy) hermitian adjoint of the column vector, not a column matrix. julia> [1 2 3]' isa Matrix false Instead, if you really need a true (n, 1) matrix you should 1) not use adjoint because that will also take complex conjugates (unless that's what you wanted) and 2) use collect to turn the lazy transpose (or adjoint) into a true matrix julia> collect(transpose([1 2 3])) 3×1 Array{Int64,2}: 1 2 3 However, you almost never need to do this sort of thing and you should be fine using either transpose on a row vector or just using a real column vector. Also, near the end they talk about closures but don't actually show any closures unless one is to assume the code snippets they're showing are actually inside a function body themselves.

throwawaymath 7y ago
Good catch, that's an odd mistake. I would assume the author knows the adjoint isn't equal to the transpose unless the matrix is real. If you only ever work in R then technically that'd be fine (though notationally awkward). But that's not a good habit to keep since it would introduce pretty insidious bugs if you ever take the adjoint of a complex matrix intending to take the transpose.
- ChrisRackauckas 7y ago
  But in mathematical derivations, when does a transpose which is not an adjoint ever show up? In many derivations we write transpose knowing that it would be the adjoint if complex numbers are used. That's at least true for most of applied mathematics, statistics, physics, etc.
  - eigenspace 7y ago
    My point at least was just that it’s a bad idea to use adjoint to construct a column matrix since in that case you likely didn’t intend to take an adjoint, you just wanted a certain shape. There’s no math or physics equation here with objects transforming under an adjoint representation, it’s just a constructor.
  - patrick5415 7y ago
    Yes, one may keep that in mind when working something on scratch paper. But when it’s possible for things to be complex, the standard notation is something like A^. In my opinion, it is rather sloppy to write A^T and expect the reader to substitute for the complex case. I can’t remeber where at the moment, but I have definitely seen derivations when the authors explicitly wanted A^T on a complex matrix.
    - carlmr 7y ago
      You have to escape your star A^* .
hyperion2010 7y ago
That python "closure" is a big fat lie too due to python's late binding. Depending on the context in which that code is being defined it may or may not work as expected. The only guaranteed way to ensure that a free variable in python function scope (it's not a closure) does not change is to pass it explicitly as a default value. a = 1 def function(x, a=a): return x + a That will work in loops. Otherwise what you are really writing is a = 1 def function(x): return x + the_last_value_a_obtains_in_this_scope a = 2 assert function(1) == 3
- h8hawk 7y ago
  The same is true with Julia: julia> a = 1 1 julia> function foo(x) x+ a end foo (generic function with 1 method) julia> foo(2) 3 julia> a = 2 2 julia> foo(2) 4
- mehrdadn 7y ago
  > That python "closure" is a big fat lie too due to python's late binding. What? It's not a big fat lie, it's the exact truth. The same truth you'd get in any language, even Scheme: > (define a 1) > (define (f) a) > (f) 1 > (define a 2) > (f) 2 That's just how closures work...
  - dnautics 7y ago
    It's not categorically how closures work, it's just that in python (and most other languages, including julia), you bind to effectively "a pointer to the value". In FP paradigm, you typically bind to "the value at function creation time". In many cases, the "FP paradigm" is very sensible and makes closures safe to work with and easy to reason about, especially in contexts where concurrently running processes could alter the memory underneath you. iex(1)> a = 1 1 iex(2)> f = fn x -> x + a end #Function<7.91303403/1 in :erl_eval.expr/5> iex(3)> f.(1) 2 iex(4)> a = 2 2 iex(5)> f.(1) 2
    - pdexter 7y ago
      Elixir doesn't have mutable variables though. Is there any language that has mutable variables and closes over the value of a variable and not a "pointer to the value"?

throwawaymath 7y ago

Good catch, that's an odd mistake. I would assume the author knows the adjoint isn't equal to the transpose unless the matrix is real. If you only ever work in R then technically that'd be fine (though notationally awkward). But that's not a good habit to keep since it would introduce pretty insidious bugs if you ever take the adjoint of a complex matrix intending to take the transpose.

ChrisRackauckas 7y ago
But in mathematical derivations, when does a transpose which is not an adjoint ever show up? In many derivations we write transpose knowing that it would be the adjoint if complex numbers are used. That's at least true for most of applied mathematics, statistics, physics, etc.
- eigenspace 7y ago
  My point at least was just that it’s a bad idea to use adjoint to construct a column matrix since in that case you likely didn’t intend to take an adjoint, you just wanted a certain shape. There’s no math or physics equation here with objects transforming under an adjoint representation, it’s just a constructor.
- patrick5415 7y ago
  Yes, one may keep that in mind when working something on scratch paper. But when it’s possible for things to be complex, the standard notation is something like A^. In my opinion, it is rather sloppy to write A^T and expect the reader to substitute for the complex case. I can’t remeber where at the moment, but I have definitely seen derivations when the authors explicitly wanted A^T on a complex matrix.
  - carlmr 7y ago
    You have to escape your star A^* .

hyperion2010 7y ago

That python "closure" is a big fat lie too due to python's late binding. Depending on the context in which that code is being defined it may or may not work as expected. The only guaranteed way to ensure that a free variable in python function scope (it's not a closure) does not change is to pass it explicitly as a default value. a = 1 def function(x, a=a): return x + a That will work in loops. Otherwise what you are really writing is a = 1 def function(x): return x + the_last_value_a_obtains_in_this_scope a = 2 assert function(1) == 3

h8hawk 7y ago
The same is true with Julia: julia> a = 1 1 julia> function foo(x) x+ a end foo (generic function with 1 method) julia> foo(2) 3 julia> a = 2 2 julia> foo(2) 4
mehrdadn 7y ago
> That python "closure" is a big fat lie too due to python's late binding. What? It's not a big fat lie, it's the exact truth. The same truth you'd get in any language, even Scheme: > (define a 1) > (define (f) a) > (f) 1 > (define a 2) > (f) 2 That's just how closures work...
- dnautics 7y ago
  It's not categorically how closures work, it's just that in python (and most other languages, including julia), you bind to effectively "a pointer to the value". In FP paradigm, you typically bind to "the value at function creation time". In many cases, the "FP paradigm" is very sensible and makes closures safe to work with and easy to reason about, especially in contexts where concurrently running processes could alter the memory underneath you. iex(1)> a = 1 1 iex(2)> f = fn x -> x + a end #Function<7.91303403/1 in :erl_eval.expr/5> iex(3)> f.(1) 2 iex(4)> a = 2 2 iex(5)> f.(1) 2
  - pdexter 7y ago
    Elixir doesn't have mutable variables though. Is there any language that has mutable variables and closes over the value of a variable and not a "pointer to the value"?