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.

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.

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.

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.

You have to escape your star A^* .

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

> 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...

Fair enough, I think my complaint is more about the fact that closures and python are not accompanied by a safety net the way they are in some other languages, that doesn't make them not closures, it just makes them a less useful abstraction (I've basically given up on using anything other than full objects and list comprehensions in python due to the countless subtle and often silent irregularities in how a form behaves when used in different contexts).

Your example is true at the top level in scheme, but semantics in top (REPL) are different (at least in Racket [0, 1]). In a source file you have to explicitly use set! to mutate a so it is harder to shoot yourself in the foot. In theory the implementation of closures is the same, but in python's case you are free to mutate yourself into unexpected situations. Whereas I'm actually not even sure it is possible to construct a situation in scheme (not at the top level) where you could induce a situation similar to the one in python.

0. https://gist.github.com/samth/3083053 1. https://groups.google.com/d/msg/racket-users/0BLHm18YUkc/BwQ...

In all brutal honestly I think you just need to realize this is just you being upset at having shot yourself in the foot at some point (don't worry, we've all done it) and then trying to blame it on closures somehow, in this case by saying this makes them a "less useful abstraction". In all honesty, no, it just doesn't. It makes them more useful. If I can make an analogy, it's a bit like saying bicycles should only have fixed gears as a "safety net" because you've broken or slipped your variable gears in the past and now you've just learned to take a car or train if you want to go faster than first gear. I mean, that's definitely one way to live your life, but most people don't do it that way... they just realize their mistakes are a natural artifact of being in the learning process and instead of abolishing gears, they keep practicing more so that they eventually get the muscle memory to use their vehicle properly and don't have to think about this problem every time. That's the way to solve the problem for good -- so you can avoid the downsides while reaping the benefits at the same time.

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

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"?

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