Thanks Daniel. These are the first 2 parts, there will be about 4 or 5 more. Do you think my style of math writing is suitable for publication, or do I need to change it?
I like that it’s very concise and readable, and wouldn’t want that to get lost—too many math papers are very dry! I do think, though, that a bit more formality would make mathematical readers more comfortable and confident in your results.
I would move the “note on language” to a preliminaries/definitions section. Though it’s nice that the first section is accessible to non-mathy people, don’t think that’s the way to go for publication. Defining terms like “computer program” and “source code” precisely before using them would look more trustworthy, and using the Kleene construction explicitly in all sections, instead of referring to quine techniques, seems better to me.
I probably wouldn’t mention coding style or comments unless your formalism for programs explicitly allows them.
I found it confusing that while A and B are one type of object, C and D are totally different. I think it’s also more conventional to use capital letters for sets and lowercase letters for individual objects.
This paper touches on many similar topics, and I think it balances precision and readability very well; maybe you can swipe some notation and structure ideas from there?
Nice work!
Thanks Daniel. These are the first 2 parts, there will be about 4 or 5 more. Do you think my style of math writing is suitable for publication, or do I need to change it?
I like that it’s very concise and readable, and wouldn’t want that to get lost—too many math papers are very dry! I do think, though, that a bit more formality would make mathematical readers more comfortable and confident in your results.
I would move the “note on language” to a preliminaries/definitions section. Though it’s nice that the first section is accessible to non-mathy people, don’t think that’s the way to go for publication. Defining terms like “computer program” and “source code” precisely before using them would look more trustworthy, and using the Kleene construction explicitly in all sections, instead of referring to quine techniques, seems better to me.
I probably wouldn’t mention coding style or comments unless your formalism for programs explicitly allows them.
I found it confusing that while A and B are one type of object, C and D are totally different. I think it’s also more conventional to use capital letters for sets and lowercase letters for individual objects.
This paper touches on many similar topics, and I think it balances precision and readability very well; maybe you can swipe some notation and structure ideas from there?
Link request: When linking to arXiv, please link to the abstract, not directly to the PDF.
Will do.
Thanks for your suggestions! They all seem very reasonable to me and I’ll do a rewriting pass.