Like math and quantum mechanics and relativity, you don't understand it, you just get used to it.

Well, at least c++ doesn't have clopen sets

@DavidZ hey thats a heavy thing to say, cmon theres lots of common ground in here... :| ... think its science itself that tends to get (over)specialized, compartmentalized, fragmented...

@BernardMeurer Understatement.

@DavidZ That crowd appears not to be present, at the present.

@BernardMeurer there's nothing wrong with clopen sets

there are spaces in which each set is clopen

^ I retract my statement.

Topology is hardly differential geometry

@DanielSank Back at the crib?

@ChrisWhite I'm baaaaaasically a python-first person and I understand pointers just fine. In fact, in Python everything is a reference, so it's not hard to understand pointers.

@BernardMeurer Si.

@DanielSank pointers make me brainfart

working on cappy

@BernardMeurer Wat? Why?

fuuuuuuuuu

You work on Linux kernel.

Aren't there pointers there?

@DanielSank I get them, I just brainfart

@DanielSank Though I do think people who understand pointers are going to have an easier time understanding how Python works than people who don't

@DavidZ How it works, like, how the Python C code works under the hood?

@DanielSank Plenty of pointers there

incidentally I'm a Python person who loves pointers

@DanielSank No, he means how to use the language I believe

@BernardMeurer Well yeah I'd agree with that too.

@DanielSank Not necessarily that, I mean understanding the behavior of argument passing in Python

Not that it's really that complicated, I think

@DavidZ Indeed.

@DavidZ Well, it can be. A discouraging number of folks are not properly instructed as the to the difference between mutable and immutable data.

Incidentally, I'm grappling with python 3's asyncio just now.

Strings are always immutable in Python

I had that hammered on my head when I was starting

I believe I have learned that the Protocol API is crap.

@BernardMeurer Yes, this is true. As are tuples.

@DanielSank What's the issue?

Well, yeah, anything can get complicated, but overall I think argument passing in Python is relatively straightforward

@DavidZ Weeeelllllll.....

Here's a fun example:

Oh god

Here it comes

def func(x, y):
    <whatever>

Suppose I provide this function in a library.

We're all probably used to seeing people call the function like this:

func(4, 5)

However, did you know you can do this:

func(y=5, x=4)

I didn't know until recently that you can do that even if the args don't have default values.

I was somehow mislead to think that only args with defaults were "named parameters" while the rest are positional.

This is a reasonable thing to think given that you can only put args with defaults after all the so-called "positional args".

So here's the problem:

We can never re-name the variables in this function!

We would break everyone's code.

@DanielSank Yep. That's the weird part.

@DanielSank That helps a bunch in making sure you got the right values going in the right args

@BernardMeurer Indeed.

But it also means that you need to think of the variable names as part of the function's signature!

The names are an absolutely critical part of the interface.

Yep. It's one of those things

This is absolutely not the case in C.

Sure. But this is only a problem if you expect functions to follow C-like semantics, where the names of local variables don't matter.

@DanielSank Which means thinking hard about names from the very beginning. A good practice, but not something to dump on a beginner.

While this isn't probably what @DavidZ was talking about when he mentioned argument passing, it is a very important and often neglected aspect of python.

@dmckee I completely disagree. The beginner absolutely must be informed of this.

@dmckee a good practice indeed, tired of names like a,b,c,d as variables

And yet I recommend python for beginners because it does so mnay things right by default.

Well... I'm pretty sure I learned that very early on. I don't know if I'd call it "often neglected".

@DanielSank I'm with you, beginners should know this

@dmckee IMHO the thing python does automatically is "build", i.e. there is no build step.

This is really nice for the beginner.

@DanielSank It really depends how 'beginner' you are talking about. I don't want them worrying about naming when they are trying to understand the behavior of assignment in imperative programming.

Unfortunately, this also means that beginners learn to debug by running their program and reading the Exception messages instead of doing sane things like learning to use a compiler and/or writing tests.

And, yeah, so people trip on that.

I like python. It's incredibly useful.

@DanielSank I still struggle with testing to be honest

@BernardMeurer I spent years with a few others getting my group to adopt real testing.

It has transformed our group. We're more efficient now and people like contributing to code more.

@DanielSank I dispute the assumption that using a compiler is better debugging than reading exception messages

@DanielSank Pesky physicists

@DavidZ Then you've never had a program run for an hour and then fail at a syntax error.

Testing is very useful and underutilized, for sure, but that's a language-agnostic problem.

@DanielSank I know that pain

> that's a language-agnostic problem

false

@DanielSank Indeed I never have. That doesn't change my view

With python you spend half your tests doing exactly what a compiler does.

@DavidZ o_O

@DanielSank no, that's false

@DavidZ Have you ever worked on a multi-person software project in python?

My experience is that people (rightfully) right tests which text nothing beyond "does this even run?".

@DanielSank Not exactly what a compiler does

@DanielSank I've contributed to some libraries, but I'm not sure if that's what you mean

otherwise we wouldn't need tests in C++ which isn't the case

@BernardMeurer Right. I said half the tests.

Ah, I read half an hour

@DanielSank Using a compiler doesn't prevent those tests from being necessary.

@DavidZ In python it's worth writing tests which run over a small data set just to make sure the code is syntax-error-free.

@DavidZ Yes, it does.

No it doesn't

Ok, I guess we're done here.

It prevents some tests from being done

Japan was awesome!

I recommend Kamkochi and Kyoto.

@DanielSank Did you catch some Pokemon?

@DanielSank The same tests also check for many other errors. Syntax errors are only a small fraction of what you're testing for.

@BernardMeurer Nah, not playing it.

@DanielSank ok, if you say so

@DanielSank LAME

@DavidZ Fine, it's small fraction. Still there.

I'm telling you, if you don't have the debugger running and you run some long simulation, but hit a syntax error at the end, you've just wasted an hour that a compiler would have saved you.

Now, motivated by this, you start writing tests where you run your sim end-to-end with a small data set just to make sure it works at all.

...I guess you should do that in compiled languages too though...

Ok let's say that it's still a good idea to write end-to-end "does it work" tests, but that in python they're way more necessary than in e.g. Java.

I hate Java

Never have done collaborative level programming in python, I only have habits from compiled languages.

For big work I recommend:

* Unit test on low level facilities

* maybe some integration test for modules that must work closely together

* regression tests on small sample data sets

@BernardMeurer something for you

Plus nightly builds. Both on the head and on a stable line that is for people not active in the development.

@0celo7?

And I love to write units test for bugs. Find bug. Write a test to prove that it is doing it wrong. Check in the test. Fix the bug. Run the test to prove that it is now doing it right and you haven't broken anything else. Check in the fix. Drink beer.

@0celo7 Ah, the book reference :)

@dmckee I find the bug and skip to the last step, is that okay?

Well, it's a way to get through the day without going insane, but remember what happens when you try to hit the Ballmer peak.

@dmckee I love that one!

@DanielSank I haz question. If you have two entangled qubits, they can lose that entanglement right? If that happens how can you re-entangle them?

What

LOL

it makes zero sense to real people

Yeah, because clopen sets are a bastion of sense for everyone

1-800-DANIEL-SANK

Sigh, what's wrong with clopen sets

clopen sets just count the number of connected pieces you have

The fact that open and closed are not defined as excluding opposites is what's wrong

what would you call it?

there's no confusion if you understand the definitions

Idk, Open and jew-like?

or closed and hakjsdf?

or skadjfh and owiurt?

Whatever

what

did you read my MSE post

I worked on that for a long time

I'm quite proud

@0celo7 I got lost on the beginning and left it alone

nube

Pushed for a random XKCD and got one I had forgotten: xkcd.com/622

@dmckee Lol wtf

@BernardMeurer You're asking two questions.

Yes, entanglement can be lost.

To entangle two quantum things, they must interact physically.

Of course, not all interactions lead to entanglement, but most do.

@BernardMeurer See here.

So everytime you lose entanglement it's a huge pain in the ass? Or is re-entangling easy?

@ACuriousMind @Danu and whoever else knows about quantum mechanics, I'd appreciate a check that I got the latter example in this post correct.

@BernardMeurer The fact that entanglement is short lived is the biggest part of why building a quantum computer is hard.

So yes, it's a huge pain in the ass.

However!

Great minds discovered that quantum information can be error corrected.

It is not at all obvious that this is possible.

If not for that, universal quantum computing would likely not be practically possible.

@DanielSank ALL I HEAR IS PROMISES

How will I ever build my wife-finding AI like this?

In other words, if you only lose some entanglement, you can get it back at the cost of having to remove entropy from your computer.

@BernardMeurer You won't. Just go to the bar.

@DanielSank Why's removing entropy bad?

@DanielSank No can do

@BernardMeurer It's not, but you usually need a power source to do it.

No big deal.

I see, I see

Nice stuff

The essential ingredient in quantum error correction is that with a multi-body system, you can measure some degrees of freedom without measuring all of them.

Therefore, you can check whether something went wrong without actually measuring the logic state of the qubit.

It's kinda similar to if you could tell whether a bit flipped, but not what it's initial state was.

...but that's not a great analogy.

Funky

What the hell's a density matrix?

@DanielSank So what's the "latter example"? :P

Oh god I just got invited to a RISK game

I'll murder someone

$\rho = \sum | n \rangle \langle n |$

@Danu I mean the "large system" part.

@Danu Did the CD get there correctly?

@BernardMeurer If I give you a quantum system with three particles in an entangled state, you can write a wave function for it.

@BernardMeurer Excellent. Been listening to it all day

However, if I hide one of the three particles and you only have the other two, they won't behave like a normal quantum state and you can't write a wave function.

You have to use this thingy called a density matrix.

@Danu Glad you liked it :)

@DanielSank Ah, I see

@DanielSank You mean I should check your three-particle reduced matrix?

@BernardMeurer I think the py3 Protocol lib is dumb.

@ACuriousMind More or less. Also that the arguments about the multi-spin rotation are right.

Basically, I'd like to make sure that the example is correct. I've been looking for a simple way to demonstrate decoherence when a single spin "goes missing" for quite a while. My original example (used in thesis) was to a three-spin Bell state. The trouble there is that the reader has to know why Bell states are interesting.

@DanielSank Why so?

@BernardMeurer Because it uses callbacks instead of coroutines.

It's not a big deal, just slightly annoying.

@DanielSank That's lame

Aren't coroutines just generators with magic?

@BernardMeurer Uhhh

Yeah I suppose.

@DanielSank youtube.com/…

@DanielSank I think the example is correct. What I'd remark is that one can get the impression that you choose very special states at which you stop the interaction with the environment to then show that the angle dependence has vanished.

@ACuriousMind The angle dependence of the measurement vanishes.

The interaction time/angle is fixed, yes.

@BernardMeurer ???

@DanielSank They're a cool jazz band

@BernardMeurer Yeah.

I just wanted to share that :v

@BernardMeurer Thanks!

:)

@DanielSank Their stuff is on the Gdrive

@0celo7 Thanks

@DanielSank Yes. What I mean is that in this case, the decohereed state eventually returns to its original state if left undisturbed, doesn't it? I.e. the example is a nice illustration of how decohoerence works, but "true" decoherence still has another aspect (I guess it's just the large number of variables in the environment) that prohibits states once decohered to "become coherent again"?

@BernardMeurer I should do some exercises in the Brazilian book

@0celo7 You should shave first

What

@ACuriousMind You're asking why some decoherence happens with an exponential time dependence and never reverses?

Yes, it's because of the large number of degrees of freedom involved.

I wouldn't call that "true" decoherence though.

Okay, that's what I wanted to make sure. Then I think your example (and the post) is very good and correct!

@ACuriousMind Thanks for the check. Much appreciated.

@DanielSank I could call it "'"true"'" decoherence ;P

@BernardMeurer what about my facial hair

@ACuriousMind hahahahahaha

@ACuriousMind lol

@BernardMeurer are you watching through my webcam or something?

@0celo7 Yes

Ok what am I doing right now?

Looking at the computer

What was I holding up

Do Carmo

do Carmo is at home, I don't have it with me

:)

@ACuriousMind ahhhh

If $M=\coprod_{i=1}^\infty M_i$, why is $H^q(M)=\prod H^q(M_i)$ but $H^q_c(M)=\bigoplus H^q(M_i)$

Is it because in the compact case you can't have forms with an infinite number of disjoint supports?

no way to get a finite subcover

@0celo7 yes

@ACuriousMind Ok, that was easy, but now I have a hard core algebra question

why is the dual of a direct sum a product

but not the other way around

Oh

Because the Hom-functor behaves a bit strangely with limits.

...

you know that's not helpful...

I know but it gives me time to think of a way to put it for you :P

Fair enough.

Well, the answer will involve universal properties

As long as you can write them down again, I think it will be fine.

@BernardMeurer How many times I said how many times?

9 now?

The dual of $X$ is defined as $\mathrm{Hom}(X,\mathbb{R})$, right?

@ACuriousMind Sure.

Okay. So is $\mathrm{Hom}(-,\mathbb{R})$ co- or contravariant?

Good question. Let me figure that out

I'm going to guess contravariant for the same reason the cotangent functor is.

Yes, given a map $f: X\to Y$ we can turn a map $Y\to\mathbb{R}$ into a map $X\to\mathbb{R}$ by applying $f$ first, but not the other way around.

So it's contravariant, aka reverses all arrows

I know what a contrav. functor is.

You might recall that the arrows in the universal properties of the product and the sum are exactly opposite - the product has projections out of it, and the sum has inclusions into it

Yes.

What the heck Bott & Tu don't prove Poincare duality on noncompact manifolds

So this is the reason it turns the sum into a product - it reverses all the arrows, and turns the u.p. of the sum into the u.p. of the product. Or rather, that's the reason that if there's an identity for sum and product, we should expect them to turn into product and sum under contravariant functors.

However, a priori a functor has no obligation to preserve sums/products at all

An identity?

@0celo7 I mean an identity like $F(\bigoplus M_i) = \prod_i F(M_i)$.

@ACuriousMind Ah.

So why doesn't it work in reverse?

Well, as I said, a priori there's no reason it should work at all

Why doesn't your argument work in reverse?

Ahhh, I expressed it badly

I have not yet given an argument for $\mathrm{Hom}(\oplus M_i,\mathbb{R}) = \prod \mathrm{Hom}(M_i,\mathbb{R})$

I have only given an argument for why we should expect a $\prod$ and not a $\bigoplus$ on the r.h.s..

@BernardMeurer GET HYPED

@0celo7 Don't care

@ACuriousMind Oh, right

Now, you need to explicitly verify that $\mathrm{Hom}(\bigoplus_i M_i,\mathbb{R})$ fulfills the u.p. of the r.h.s. to show that the equality holds.