[red_trumpet]

Your paper didn't pass my smell test at all, tbh. For example the formula you write about "product" and "coproduct" in section 3 is literally identical (as "=" is symmetric). In section 4.2 you write "the product is the standard tensor product" with a formula that doesn't at all involve the map m: A \otimes A \to A. The formula you write is the induced product on A \otimes A, assuming that you already have a product on A. The formula for "coproduct" is just an example[1] of a coproduct, not every coproduct has to look that way.

[1] https://en.wikipedia.org/wiki/Coalgebra#Examples

[keithalewis]

Same here. Sloppily written with very little content. If the author can't take the time to proofread his own paper why should anyone else waste their time?

[adamnemecek]

Ok read the Persi Diaconis one https://arxiv.org/abs/1206.3620.

You are right, it can be more polished but also it covers quite a lot and it was surprisingly hard to fit it all in.

The main response I have been getting though is "I won't believe this until I see the implementation" so I have been concentrating on that.

[jurynulifcation]

adamnemecek has posted too many comments and is in cooldown phase, but he's asked me to post this comment: "It's the programmers equal sign. I think that the surrounding text provides a decent explanation what the deal is.

You are right, there's a missing sentence fragment, "standard tensor product that satisfies the property...".

Read the Diaconis paper. "

--- This isn't a sock puppet and I hope this isn't against site rules. I just wanted to try and help facilitate good discussion. I think trumpet brought up some interesting criticisms and felt Adam had a legitimate interest in responding ASAP.

[LudwigNagasena]

> It's the programmers equal sign.

That doesn’t seem to make any sense.

[adamnemecek]

I'm saying there's a difference between equal sign that defines something and equal sign that declares a relation.

[red_trumpet]

Sure. In mathematics this is why we often use ":=" for definitions, or we indicate in the surrounding text that the next equation is a definition. That would be helpful.

But even then, you cannot define "C" as "C \otimes C", because the right hand side only makes sense if "C" is already defined. And in math you cannot define something twice. As soon as you defined something, it stays the same in the given context.

[adamnemecek]

It's a type signature, not a formula. Cs are not values.

Think of it as a signature in say Rust

fn coproduct(in: C) -> (C, C)

Also you were talking about my knowledge of Hopf algebras, this is not knowledge of Hopf algebra but quibbling about things that are pretty clear from context.

[LudwigNagasena]

I don't know what prerequisite knowledge is implied for that paper, but for someone who had to dabble in theoretical econometric and ML papers during my graduate studies it is absolutely not clear what is going on. In my experience, a paper written in such fashion where you don't even define what objects you are working with wouldn't even pass as an acceptable undergraduate paper.

For example, if someone works with a probability space (Ω, F, P), they would state so very clearly in their paper even though it is quite obvious from the notation that it is supposed to be a probability space.

Similarly, if someone writes "Given a symmetric monoidal category C with tensor product ⊗...", it is understandable what is going on, or at least it is understandable what I should look up. But in that paper I have no idea how I am supposed to interpret "C", "⊗" and "=" in such a way that the formulas make sense.

> It's a type signature, not a formula. C is not values.

I am not sure what distinction you are trying to draw, but surely any sequence of symbols that adheres to a given formal grammar is a (well-formed) formula; and surely if by value you mean a mathematical object, types and type signatures are values.

[scatters]

It seems fine to me, although maybe it's backwards. Add a prime to the RHS, perhaps.