Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

P ne to NP

45 views
Skip to first unread message

ruben safir

unread,
Aug 15, 2017, 1:18:52 AM8/15/17
to

Alf P. Steinbach

unread,
Aug 15, 2017, 1:58:29 AM8/15/17
to
On 8/15/2017 7:18 AM, ruben safir wrote:
> https://t.co/GOHa5sM6Cg
>

It's still amazing, every time, to observe how allegedly intelligent
mathematicians fail to come up with readable or self-describing names,
but instead choose hopeless single symbols from various alphabets.

One would think they were retarded, if it were not for the strong
association between mathematics and intelligence.

Still, I think they're generally retarded communications-wise, and that
this contributes much to the inaccessibility of Wikipedia pages about
math. Even the pages about basic stuff are pretty much impenetrable.
Apparently they simply don't grok how to communicate, or, more
basically, how knowledge and understanding evolves in the reader's mind.


Cheers!,

- Alf

David Brown

unread,
Aug 15, 2017, 3:40:44 AM8/15/17
to
That seems extremely harsh criticism. The paper is clearly not written
for /you/, or anyone else who is not already familiar with
graduate-level mathematics in the field of complexity theory. For
papers at this level, you might expect perhaps a dozen people in the
world will be able to read it reasonably fluently and understand it as
they do so - most experts in the same field will take days or weeks to
study through it to see how it works. It will be months, perhaps years,
before there is a consensus in the mathematical community about its
correctness and the almost inevitable small errors or missing
justifications. Proving P ≠ NP is a big deal - it is so important, and
so hard, that there is a million dollar prize resting on it.

Mathematicians have their own way of writing and their own symbolic
languages - just because /you/ don't understand them, does not make them
"hopeless" or "retarded". There is nothing in that article that is
remotely complex in the symbols. Beyond the first couple of pages, the
paper is way out of my league - but the use of symbols seems entirely
reasonable.

If I had one complaint, it would be that the text is too compact. The
paper would benefit from a good deal more white space and perhaps some
examples of the terms and definitions (mathematicians are rightly wary
of examples - it is too easy to assume generalisations from them).

This paper - if it is shown to be valid - is a milestone in the
computing world. If it is contains flaws, it will join the growing list
of failed proofs for P ≠ NP, but perhaps help someone else move forward.





Rick C. Hodgin

unread,
Aug 15, 2017, 6:08:57 AM8/15/17
to
On Tuesday, August 15, 2017 at 1:18:52 AM UTC-4, ruben safir wrote:
> https://t.co/GOHa5sM6Cg

It will be of great interest to see if his paper holds up to scrutiny.

If it does hold up, in my lifetime, Fermat's Last Theorem will have
been proven, the Poincare Conjecture, and now potentially P vs NP,
among others. I do wonder if the Riemann Hypothesis will be solved
in my lifetime.

Thank you,
Rick C. Hodgin

Paavo Helde

unread,
Aug 15, 2017, 8:25:27 AM8/15/17
to
Mathematicians have searched for best ways for representing their work
and communication for centuries. If the result seems incomprehensible to
you then it might be because you are not a mathematician or not doing
active research in mathematics.

It appears to me that you are confusing the mathematical language with a
programming language. Yes, in programming languages one needs to
maintain old code for many years, often without thorough understanding
how exactly it works. Using self-explanatory names helps with this task
(to some extent).

In maths, there is no such "maintenance" needed. The closest to
"maintenance" would be developing the theory further and to write a new
article based on the old one. But this is not possible without thorough
understanding of the topic. Once you have got the thorough understanding
then you already know the difference between Gothic D and Latin D, or
whatever other symbols, and using some long names instead of them would
just slow down both the author and the knowledgeable readers.

This does not mean mathematical markup cannot be enhanced, there are
many examples of this happening (Leibniz vs Newton, Einstein's summation
convention, Feynman diagrams, etc). However, replacing established
mathematical symbols with long descriptive names would not be an
enhancement, at least not for mathematicians themselves.

Cheers
Paavo



Rick C. Hodgin

unread,
Aug 15, 2017, 9:37:23 AM8/15/17
to
On Tuesday, August 15, 2017 at 8:25:27 AM UTC-4, Paavo Helde wrote:
> This does not mean mathematical markup cannot be enhanced, there are
> many examples of this happening (Leibniz vs Newton, Einstein's summation
> convention, Feynman diagrams, etc). However, replacing established
> mathematical symbols with long descriptive names would not be an
> enhancement, at least not for mathematicians themselves.

The Julia programming language allows for unicode characters to be
used for variable names and in all text. You can create real var
names like the pi symbol, or delta, epsilon, etc.

I've actually thought that would be a neat feature in general.

David Brown

unread,
Aug 15, 2017, 10:44:01 AM8/15/17
to
There are three major problems with unicode characters for identifier names.

One is that it is very difficult and inconvenient to type many of them,
especially for Windows users who have fewer symbols by default, usually
no dead keys or compose key, and no convenient way to add new symbols to
key combinations. You have to add additional keyboard layouts and
switch to Greek layouts (or Hebrew, or whatever has the symbols you
want). Or you have a character applet, or need an IDE with toolbars or
other support.

Second is that many fonts don't have many additional symbols, and many
editors can't handle font substitutions well.

And third, there are many unicode characters that look identical or very
similar. Should these be matched to the same identifier, or different
identifiers? The rules here would be a serious pain - should you map
"Greek capital letter alpha" Α to the same identifier as "Latin capital
letter A" A ?


It seems not unreasonable to allow unicode identifiers so that people
can write their code in their own language, but it is not without its
challenges.



0 new messages