Re: [Metamath] Question abouot indistopon

2024-05-02 Thread Mario Carneiro
It's not my invention, although I'm not sure it's been used in this exact
situation before. Negative and positive position is a notion in proof
theory relating to whether a certain construct is covariant or
contravariant with respect to increasing in the ordering of propositions
(i.e. "more true"). So for example in the expression "P -> Q", P is in
negative position and Q is in positive position, because implication is
covariant on the right, i.e. if Q -> Q' then (P -> Q) -> (P -> Q'), but
contravariant on the left, because if P -> P' then (P' -> Q) -> (P -> Q).
In general the polarity flips every time you nest in another "negative
position", so in (P -> Q) -> R, P and R are in positive position and Q is
in negative position.

On Thu, May 2, 2024 at 2:04 AM 'B. Wilson' via Metamath <
metamath@googlegroups.com> wrote:

> Thank you for the pointer, Mario. Is this negative vs. positive position
> terminology something you neologized on the fly? Or does it have
> precedent? If
> I'm grokking you correctly, the positive positions plug into the negative
> positions, which jibes with your explanation and the Is-a-set convention
> you
> reference.
>
> Thanks for the clarity.
>
>
> Mario Carneiro  wrote:
> > There is a convention, which is to use "( A e. V -> ..." in antecedents
> to
> > theorems and deduction-form statements and |- A e. _V in inference-form
> > theorems. In "positive position", you often need to use A e. _V, i.e. in
> > fvex there is no other reasonable option for what set to say that
> function
> > value is a member of without any assumptions. In "negative position",
> it's
> > a question of whether to spend one extra elex step in some cases (e.g. 2
> e.
> > RR therefore 2 e. _V therefore I can apply this lemma about sets to 2),
> or
> > one extra syntax step to instantiate the V argument (which also takes
> some
> > space in proofs). I believe the above convention is derived from some
> > analysis along these lines, but it's also somewhat historical (it's more
> > important to have a consistent convention). See the "Is-a-set." section
> of
> > https://us.metamath.org/mpeuni/conventions.html for more information.
> >
> > On Wed, Apr 24, 2024 at 3:52 AM heiphohmia via Metamath <
> > metamath@googlegroups.com> wrote:
> >
> > > > It functions much like A e. _V would. A proof using this theorem can
> > > always
> > > > plug in _V for V but it also could plug in On, RR, or whatever is
> > > convenient.
> > > > Perhaps looking at <https://us.metamath.org/mpeuni/elex.html> makes
> it
> > > clear.
> > >
> > > Okay, elements of ZF classes are always sets, so A e. V restricts A
> from
> > > being
> > > proper classes. That begs the question why one would ever use A e. _V
> > > though.
> > > Is this just a case where there's no particular convention?
> > >
> > > --
> > > You received this message because you are subscribed to the Google
> Groups
> > > "Metamath" group.
> > > To unsubscribe from this group and stop receiving emails from it, send
> an
> > > email to metamath+unsubscr...@googlegroups.com.
> > > To view this discussion on the web visit
> > >
> https://groups.google.com/d/msgid/metamath/272R9VKF3UZLE.34NMDVUCB3A1P%40wilsonb.com
> > > .
> > >
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/2VC9HKX4Q39T0.1ZIJO4RNZ5BIT%40wilsonb.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJStzbKu4QCWU984ynXRBOQdNVRmRCQd7Udp6CM3cZAJ02g%40mail.gmail.com.


Re: [Metamath] Mnemonic of Fr

2024-05-01 Thread Mario Carneiro
My understanding is that it stands for "founded relation", as in
well-founded but without the "well", I think because it doesn't have any
other ordering properties like being a partial order attached to it.

On Wed, May 1, 2024 at 5:21 AM 'B. Wilson' via Metamath <
metamath@googlegroups.com> wrote:

> This has been bugging me midly for a while, but I couldn't figure out what
> the
> Fr symbol in df-fr stood for:
>
> 19201 df-fr $a |- ( R Fr A <-> A. x ( ( x C_ A /\ x =/= (/) ) -> E. y
> e. x A. z e. x -. z R y ) ) $.
>
> I finally bothered to look up the Takeuti and Zaring reference, which also
> uses
> "Fr" and calls R a "foundational relation". It's not super important, but
> would
> it be worth mentioning this in df-fr's comment?
>
> Cheers,
> B. Wilson
>
> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/2F5KIFFJJY2KH.28Z6N87TP90O2%40wilsonb.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSsXfJqj3nGxjuDEFGCMAw8Zvq6AFF0wZ53qib3d8u%3DD3A%40mail.gmail.com.


Re: [Metamath] Question abouot indistopon

2024-04-24 Thread Mario Carneiro
There is a convention, which is to use "( A e. V -> ..." in antecedents to
theorems and deduction-form statements and |- A e. _V in inference-form
theorems. In "positive position", you often need to use A e. _V, i.e. in
fvex there is no other reasonable option for what set to say that function
value is a member of without any assumptions. In "negative position", it's
a question of whether to spend one extra elex step in some cases (e.g. 2 e.
RR therefore 2 e. _V therefore I can apply this lemma about sets to 2), or
one extra syntax step to instantiate the V argument (which also takes some
space in proofs). I believe the above convention is derived from some
analysis along these lines, but it's also somewhat historical (it's more
important to have a consistent convention). See the "Is-a-set." section of
https://us.metamath.org/mpeuni/conventions.html for more information.

On Wed, Apr 24, 2024 at 3:52 AM heiphohmia via Metamath <
metamath@googlegroups.com> wrote:

> > It functions much like A e. _V would. A proof using this theorem can
> always
> > plug in _V for V but it also could plug in On, RR, or whatever is
> convenient.
> > Perhaps looking at  makes it
> clear.
>
> Okay, elements of ZF classes are always sets, so A e. V restricts A from
> being
> proper classes. That begs the question why one would ever use A e. _V
> though.
> Is this just a case where there's no particular convention?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/272R9VKF3UZLE.34NMDVUCB3A1P%40wilsonb.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSsZM-syOfP_R0EaEZrghkTYH1Ci349FFdvUzauXoE7iPg%40mail.gmail.com.


Re: [Metamath] Trying to understand 2p2e4

2024-04-02 Thread Mario Carneiro
uot; original numbers, you
>> should replace "ax-mulcom $a ... $." with ax-mulcom $p ... $= > axmulcom> $. and similarly for all the other axioms in the same section.
>> This will allow metamath-exe to see that uses of these axioms actually
>> depend on a big stack of other lemmas when calculating statistics like max
>> depth and full-expansion theorem counts.
>>
>> > 2. If I run show trace_back 2p2e4 /count_steps, it is stated that " a
>> total of 619 different subtheorems are used.  The statement and subtheorems
>> have a total of 12178 actual steps (...) The proof would have 5887862241803
>> =~ 5.9 x 10^12 steps if fully expanded back to axiom references.". What is
>> the difference between the 12178 steps, and the 5.9 x 10^12 steps? I guess
>> that 12178 steps refers to the case in which we take the axioms of the
>> complex numbers as "axioms", and 5.9 x 10^12 when we also prove the axioms
>> of the complex numbers, starting from ZFC. But I am not 100% sure, and I
>> would like to have confirmation of that.
>>
>> No, this is not about that. Metamath theorems are able to refer to
>> previous theorems multiple times, in multiple concrete instantiations. That
>> is, a theorem is really a "theorem schema" over the assignments to the wff
>> and class variables. If you wanted to perform the same proof in pure first
>> order logic, you would have to redo the proof for every choice of those wff
>> variables. So the statistic here (also calculated by metamath-exe) is
>> working out an approximation to the (exponential) speedup this
>> accomplishes, by seeing how many steps would have been taken if you had to
>> replay each use of each theorem. Effectively, you can think of this as
>> treating every metamath theorem as a macro which expands to a proof
>> containing more macro references, and if we macro-expand everything all
>> that remains are direct references to the axioms. It's easy to get
>> exponential growth in this process, since theorem 2 can use theorem 1
>> twice, theorem 3 uses theorem 2 twice and so on. Of course the metamath
>> library is not quite so pathological as that, but the nature of the process
>> is still exponential, where the base is related to the density of
>> converging paths in the DAG of theorem references.
>>
>> > 3. Is there some way to print/export to file the 12178 steps, and even
>> the 5.9 x 10^12 steps, all at once? I ask this since running  show
>> trace_back 2p2e4 /tree gives me a tree, but with only the name of the
>> subtheorems, not the steps themselves. And I have been unable to find a
>> command that gives the full number of steps, all at the same time.
>>
>> As far as I know, no. Both of these numbers are calculated by the
>> metamath-exe tool, using the command "SHOW TRACE_BACK 2p2e4 /COUNT_STEPS".
>> Internally, it only creates and manipulates the numbers, it doesn't
>> actually perform the expansion (which would take exponentially long just to
>> output). For the former number (12178 steps), an approximation to this is
>> to just "show proof *" which will print all proofs, or look at the entire
>> metamath web site on disk, which contains every step of every theorem. The
>> 12178 steps are a subset of those, and you can get metamath-exe to print
>> out all of the relevant theorems using "show trace_back 2p2e4" alone.
>>
>> That said, it is certainly possible to calculate the actual 5.9 x 10^12
>> steps if you are interested in such a programming project. But be aware
>> that the steps can also get pretty large in the process (I think also
>> exponential in general). Although I'm sure your terabyte drive has better
>> things to do...
>>
>> Mario Carneiro
>>
>> On Mon, Apr 1, 2024 at 9:44 AM Anarcocap-socdem 
>> wrote:
>>
>>> Hello, I am trying to understand 2p2e4, as an excuse to understand
>>> metamath better.
>>>
>>> I have a few questions:
>>>
>>> 1. In https://us.metamath.org/mpeuni/mmset.html#trivia, it is stated
>>> that "A longest path back to an axiom from 2 + 2 = 4 is *184 layers*
>>>  deep". However, if I run show trace_back 2p2e4 /count_steps, it is
>>> stated that "The maximum path length is 84". Is there a typo somewhere? (84
>>> != 184).
>>> 2. If I run show trace_back 2p2e4 /count_steps, it is stated that " a
>>> total of 619 different subtheorems are used.  The statement and subtheorems
>>> have a total of 12178 actual steps (...) The proof would have 5887862241803
>&g

Re: [Metamath] Trying to understand 2p2e4

2024-04-01 Thread Mario Carneiro
> 1. In https://us.metamath.org/mpeuni/mmset.html#trivia, it is stated that
"A longest path back to an axiom from 2 + 2 = 4 is *184 layers* deep".
However, if I run show trace_back 2p2e4 /count_steps, it is stated that
"The maximum path length is 84". Is there a typo somewhere? (84 != 184).

Note that that statistic is one of those that will go out of date quickly
due to changes in the library structure. So you should not expect it to be
exact, unless we have an automated mechanism for keeping it up to date, and
we don't currently. However, there is one major change between when that
text was written and now which significantly decreased most of the numbers
quoted, which is the isolation of the real numbers from their construction.
2+2 = 4 is a theorem very close to the axioms of real numbers, so it was
reduced from something depending on the entire stack of set theory and the
construction, down to just a few direct axiom applications (plus still a
bunch of set theory because of the use of df-ov "operation value" for
expressing the + function, defined in the set theory section).

In order to get something closer to the "true" original numbers, you should
replace "ax-mulcom $a ... $." with ax-mulcom $p ... $=  $.
and similarly for all the other axioms in the same section. This will allow
metamath-exe to see that uses of these axioms actually depend on a big
stack of other lemmas when calculating statistics like max depth and
full-expansion theorem counts.

> 2. If I run show trace_back 2p2e4 /count_steps, it is stated that " a
total of 619 different subtheorems are used.  The statement and subtheorems
have a total of 12178 actual steps (...) The proof would have 5887862241803
=~ 5.9 x 10^12 steps if fully expanded back to axiom references.". What is
the difference between the 12178 steps, and the 5.9 x 10^12 steps? I guess
that 12178 steps refers to the case in which we take the axioms of the
complex numbers as "axioms", and 5.9 x 10^12 when we also prove the axioms
of the complex numbers, starting from ZFC. But I am not 100% sure, and I
would like to have confirmation of that.

No, this is not about that. Metamath theorems are able to refer to previous
theorems multiple times, in multiple concrete instantiations. That is, a
theorem is really a "theorem schema" over the assignments to the wff and
class variables. If you wanted to perform the same proof in pure first
order logic, you would have to redo the proof for every choice of those wff
variables. So the statistic here (also calculated by metamath-exe) is
working out an approximation to the (exponential) speedup this
accomplishes, by seeing how many steps would have been taken if you had to
replay each use of each theorem. Effectively, you can think of this as
treating every metamath theorem as a macro which expands to a proof
containing more macro references, and if we macro-expand everything all
that remains are direct references to the axioms. It's easy to get
exponential growth in this process, since theorem 2 can use theorem 1
twice, theorem 3 uses theorem 2 twice and so on. Of course the metamath
library is not quite so pathological as that, but the nature of the process
is still exponential, where the base is related to the density of
converging paths in the DAG of theorem references.

> 3. Is there some way to print/export to file the 12178 steps, and even
the 5.9 x 10^12 steps, all at once? I ask this since running  show
trace_back 2p2e4 /tree gives me a tree, but with only the name of the
subtheorems, not the steps themselves. And I have been unable to find a
command that gives the full number of steps, all at the same time.

As far as I know, no. Both of these numbers are calculated by the
metamath-exe tool, using the command "SHOW TRACE_BACK 2p2e4 /COUNT_STEPS".
Internally, it only creates and manipulates the numbers, it doesn't
actually perform the expansion (which would take exponentially long just to
output). For the former number (12178 steps), an approximation to this is
to just "show proof *" which will print all proofs, or look at the entire
metamath web site on disk, which contains every step of every theorem. The
12178 steps are a subset of those, and you can get metamath-exe to print
out all of the relevant theorems using "show trace_back 2p2e4" alone.

That said, it is certainly possible to calculate the actual 5.9 x 10^12
steps if you are interested in such a programming project. But be aware
that the steps can also get pretty large in the process (I think also
exponential in general). Although I'm sure your terabyte drive has better
things to do...

Mario Carneiro

On Mon, Apr 1, 2024 at 9:44 AM Anarcocap-socdem <
jordi.molins.coron...@gmail.com> wrote:

> Hello, I am trying to understand 2p2e4, as an excuse to understand
> metamath better.
>
> I have a few questions:
>
> 1. In https:/

Re: [Metamath] Re: Meaning of "JFM"

2024-03-30 Thread Mario Carneiro
Yes, these are references to the Mizar Mathematical Library, as published
in the Journal of Formalized Mathematics.

On Sat, Mar 30, 2024 at 4:58 PM Glauco  wrote:

> Using Gemini and some luck, could it be Journal Of Formalized Mathematics
> ?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/72adc053-0dee-4621-b669-72b5bc0536dbn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSs5GR6bLH-Y3jmaFaHNvhDvQKbcrSXutukPDRE8QUrypw%40mail.gmail.com.


Re: [Metamath] Help building hmm (Haskell Metamath verifier)

2024-03-18 Thread Mario Carneiro
Regarding the Haskell errors, do you have warnings-as-errors on? It seems
like all of the errors are actually just promoted warnings, so possibly you
can just disable those warnings.

On Mon, Mar 18, 2024 at 4:59 PM Antony Bartlett  wrote:

> I've been trying to add hmm to metamath-docker, because it's one of the
> verifiers that metamath-test is set up to run against.
>
> The more I think about it, the more any attempt to maintain metamath-test
> without containerization seems insane.  You need to have C, C++, Rust,
> Java, Python, and Haskell installed, then use them to build metamath.exe,
> checkmm, metamath-knife, mmj2, mmverifypy, and hmm respectively in order to
> be able to run ./run-testsuite-all-drivers
>
> Respect to David Wheeler for getting it all running in the first place!
>
> The README (http://home.solcon.nl/mklooster/repos/hmm/README) says hmm
> was developed with GHC 6.4, and this is almost certainly the problem
> because neither the apt or apk package manager repositories seem to go back
> any further than the current major version of Haskell, GHC 9.x
>
> Any suggestions?  I'm afraid it's not my programming language, so I'm not
> going to be able to upgrade it myself.
>
> For the sake of completeness my attempted changes look like this
> https://github.com/Antony74/metamath-docker/compare/main...add-haskell-verifier
>
> # hmm: dependencies for building Haskell programs
> RUN apk add --no-cache ghc
> # hmm: get and build
> WORKDIR /build
> RUN curl https://us.metamath.org/downloads/hmm.zip -o hmm.zip
> RUN unzip hmm.zip -d .
> WORKDIR /build/hmm
> # RUN make
> And the errors I get when I run make:
>
> /build/hmm # make
> ghc -Wall -Werror -O -o hmmTest --make HmmTest
> [1 of 3] Compiling HmmImpl  ( HmmImpl.hs, HmmImpl.o )
>
> HmmImpl.hs:37:1: error: [-Wtabs, -Werror=tabs]
> Tab character found here, and in 756 further locations.
> Suggested fix: Please use spaces instead.
>|
> 37 | deriving (Eq, Show)
>| 
>
> HmmImpl.hs:94:40: error: [-Wincomplete-uni-patterns,
> -Werror=incomplete-uni-patterns]
> Pattern match(es) are non-exhaustive
> In a pattern binding:
> Patterns of type ‘Expression’ not matched:
> []
> ((Var _):_)
> [(Con _)]
> ((Con _):(Con _):_)
> ...
>|
> 94 | DollarF -> let [Con _c, Var v] = syms in
>|^^
>
> HmmImpl.hs:219:17: error: [-Wunused-do-bind, -Werror=unused-do-bind]
> A do-notation statement discarded a result of type ‘[()]’
> Suggested fix:
>   Suppress this warning by saying
> ‘_ <- many1 ((space >> return ()) <|> mmpComment)’
> |
> 219 | many1 ((space >> return ()) <|> mmpComment)
> | ^^^
>
> HmmImpl.hs:224:17: error: [-Wunused-do-bind, -Werror=unused-do-bind]
> A do-notation statement discarded a result of type ‘String’
> Suggested fix:
>   Suppress this warning by saying ‘_ <- try (string "$(")’
> |
> 224 | try (string "$(")
> | ^
>
> HmmImpl.hs:225:17: error: [-Wunused-do-bind, -Werror=unused-do-bind]
> A do-notation statement discarded a result of type ‘[Char]’
> Suggested fix:
>   Suppress this warning by saying
> ‘_ <- manyTill anyChar (try (space >> string "$)"))’
> |
> 225 | manyTill anyChar (try (space >> string "$)"))
> | ^
>
> HmmImpl.hs:279:17: error: [-Wunused-do-bind, -Werror=unused-do-bind]
> A do-notation statement discarded a result of type ‘String’
> Suggested fix: Suppress this warning by saying ‘_ <- string "$."’
> |
> 279 | string "$."
> | ^^^
>
> HmmImpl.hs:319:17: error: [-Wunused-do-bind, -Werror=unused-do-bind]
> A do-notation statement discarded a result of type ‘String’
> Suggested fix: Suppress this warning by saying ‘_ <- string "("’
> |
> 319 | string "("
> | ^^
>
> HmmImpl.hs:344:33: error: [-Wincomplete-uni-patterns,
> -Werror=incomplete-uni-patterns]
> Pattern match(es) are non-exhaustive
> In a pattern binding: Patterns of type ‘[Proof]’ not matched: []
> |
> 344 | newSubproofStack@(newSubproof:_) =
> (meaning !! n) subproofStack
> |
> ^^^
>
> HmmImpl.hs:400:17: error: [-Wunused-do-bind, -Werror=unused-do-bind]
> A do-notation statement discarded a result of type ‘String’
> Suggested fix: Suppress this warning by saying ‘_ <- string "$}"’
> |
> 400 | string "$}"
> | ^^^
>
> HmmImpl.hs:410:33: error: [-Wunused-do-bind, -Werror=unused-do-bind]
> A do-notation statement discarded a result 

Re: [Metamath] Help building hmm (Haskell Metamath verifier)

2024-03-18 Thread Mario Carneiro
On Mon, Mar 18, 2024 at 4:59 PM Antony Bartlett  wrote:

> The more I think about it, the more any attempt to maintain metamath-test
> without containerization seems insane.  You need to have C, C++, Rust,
> Java, Python, and Haskell installed, then use them to build metamath.exe,
> checkmm, metamath-knife, mmj2, mmverifypy, and hmm respectively in order to
> be able to run ./run-testsuite-all-drivers
>

As a docker noob, could you explain to me how containerization helps with
this in any way? You still have to have all those things, plus docker, if
you are doing it with containers.

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSs%3Dv94Fermc-B7ASstgK5j6%2B%2B0%3D5EZcJminVQmr4OXGDA%40mail.gmail.com.


Re: [Metamath] metamath-test added to metamath-cmds docker image

2024-03-17 Thread Mario Carneiro
 16.410 s10 runs
>
> /set.mm # hyperfine -w 2 -- 'checkmmc set.mm'
> Benchmark 1: checkmmc set.mm
>   Time (mean ± σ): 34.860 s ±  0.949 s[User: 30.446 s, System:
> 4.412 s]
>   Range (min … max):   34.097 s … 37.491 s10 runs
>
>   Warning: Statistical outliers were detected. Consider re-running this
> benchmark on a quiet system without any interferences from other programs.
> It might help to use the '--warmup' or '--prepare' options.
>
> /set.mm # hyperfine -w 2 -- 'python3 mmverify.py set.mm'
> Benchmark 1: python3 mmverify.py set.mm
>   Time (mean ± σ): 52.228 s ±  0.240 s[User: 51.274 s, System:
> 0.953 s]
>   Range (min … max):   51.939 s … 52.631 s10 runs
>
> On Sun, Mar 17, 2024 at 4:00 AM Mario Carneiro  wrote:
>
>> As far as I know and last I checked, metamath-knife can check set.mm in
>> sub-one-second with verification enabled, and about half a second with
>> verification disabled. It's possible that things have changed due to the
>> growth of set.mm?
>>
>> Just checked again:
>>
>> $ cargo build --release
>> $ hyperfine -w 2 -- "target/release/metamath-knife -v set.mm"
>> Benchmark 1: target/release/metamath-knife -v set.mm
>>   Time (mean ± σ):  1.367 s ±  0.052 s[User: 1.280 s, System:
>> 0.085 s]
>>   Range (min … max):1.307 s …  1.464 s10 runs
>> $ hyperfine -w 2 -- "target/release/metamath-knife set.mm"
>> Benchmark 1: target/release/metamath-knife set.mm
>>   Time (mean ± σ): 199.7 ms ±  13.7 ms[User: 151.8 ms, System:
>> 47.4 ms]
>>   Range (min … max):   185.6 ms … 236.6 ms15 runs
>>
>> so a bit more than a second now, and without verification it's even less
>> than I remember, probably because the default profile has more things
>> disabled than there used to be.
>>
>> On Sat, Mar 16, 2024 at 5:59 PM Antony Bartlett  wrote:
>>
>>> metamath-cmds is a docker image where I've collected a number of
>>> metamath command line tools together for convenience (metamath.exe,
>>> metamath-knife, mmj2, checkmm, checkmm-ts, mmverify.py).
>>>
>>> Today I have updated this image, so if you run
>>>
>>> docker run -it akb74/metamath-cmds
>>>
>>> you will be in a command line which has all the latest versions of these
>>> tools and the latest set.mm.  However, the last time I did this was two
>>> years ago, so most of the time you'd be better off following the
>>> instructions in the github repository
>>>
>>> https://github.com/Antony74/metamath-docker
>>>
>>> Today I have also added metamath-test (
>>> https://github.com/david-a-wheeler/metamath-test) to the commands
>>> available.  This is a useful collection of good .mm files which a verifier
>>> is expected to pass, and bad .mm files which a verifier is expected to
>>> fail.  I had to patch my copy of the test harness considerably to get it to
>>> run in the metamath-cmds container, some of which is due to the
>>> environment, but additionally I think the suite itself may be a little out
>>> of date?
>>>
>>> Finally, I have a question about metamath-knife.  In order for the test
>>> suite to pass, you have to set the --verify parameter.  However, if you do
>>> that, it seems metamath-knife loses much of its fabled speed.  So I'm
>>> wondering in what sense metamath-knife can be considered a sub-one-second
>>> verifier if it doesn't pass the test suite in this mode?  Sorry if that
>>> sounds impertinent, I'd just like to understand the distinction, I'm sure
>>> it's doing the most important checks really fast.
>>>
>>> Thanks,
>>>
>>> Best regards,
>>>
>>> Antony
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Metamath" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to metamath+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/metamath/CAJ48g%2BASabinmU590eC41US0So42YSeuMdbR0GUwenj0P1Fd%2Bw%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/metamath/CAJ48g%2BASabinmU590eC41US0So42YSeuMdbR0GUwenj0P1Fd%2Bw%40mail.gmail.com?utm_medium=email_source=footer>
>>> .
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Metamath" group.
>> To unsubscribe from this group and stop receiving e

Re: [Metamath] metamath-test added to metamath-cmds docker image

2024-03-16 Thread Mario Carneiro
As far as I know and last I checked, metamath-knife can check set.mm in
sub-one-second with verification enabled, and about half a second with
verification disabled. It's possible that things have changed due to the
growth of set.mm?

Just checked again:

$ cargo build --release
$ hyperfine -w 2 -- "target/release/metamath-knife -v set.mm"
Benchmark 1: target/release/metamath-knife -v set.mm
  Time (mean ± σ):  1.367 s ±  0.052 s[User: 1.280 s, System: 0.085
s]
  Range (min … max):1.307 s …  1.464 s10 runs
$ hyperfine -w 2 -- "target/release/metamath-knife set.mm"
Benchmark 1: target/release/metamath-knife set.mm
  Time (mean ± σ): 199.7 ms ±  13.7 ms[User: 151.8 ms, System: 47.4
ms]
  Range (min … max):   185.6 ms … 236.6 ms15 runs

so a bit more than a second now, and without verification it's even less
than I remember, probably because the default profile has more things
disabled than there used to be.

On Sat, Mar 16, 2024 at 5:59 PM Antony Bartlett  wrote:

> metamath-cmds is a docker image where I've collected a number of metamath
> command line tools together for convenience (metamath.exe, metamath-knife,
> mmj2, checkmm, checkmm-ts, mmverify.py).
>
> Today I have updated this image, so if you run
>
> docker run -it akb74/metamath-cmds
>
> you will be in a command line which has all the latest versions of these
> tools and the latest set.mm.  However, the last time I did this was two
> years ago, so most of the time you'd be better off following the
> instructions in the github repository
>
> https://github.com/Antony74/metamath-docker
>
> Today I have also added metamath-test (
> https://github.com/david-a-wheeler/metamath-test) to the commands
> available.  This is a useful collection of good .mm files which a verifier
> is expected to pass, and bad .mm files which a verifier is expected to
> fail.  I had to patch my copy of the test harness considerably to get it to
> run in the metamath-cmds container, some of which is due to the
> environment, but additionally I think the suite itself may be a little out
> of date?
>
> Finally, I have a question about metamath-knife.  In order for the test
> suite to pass, you have to set the --verify parameter.  However, if you do
> that, it seems metamath-knife loses much of its fabled speed.  So I'm
> wondering in what sense metamath-knife can be considered a sub-one-second
> verifier if it doesn't pass the test suite in this mode?  Sorry if that
> sounds impertinent, I'd just like to understand the distinction, I'm sure
> it's doing the most important checks really fast.
>
> Thanks,
>
> Best regards,
>
> Antony
>
> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/CAJ48g%2BASabinmU590eC41US0So42YSeuMdbR0GUwenj0P1Fd%2Bw%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJStBxNPJ04LwojKHnof-PZRnCBNTebgO9fd1U%2BpM%3DecujQ%40mail.gmail.com.


Re: [Metamath] Results about ax-13 usage

2024-03-12 Thread Mario Carneiro
On Mon, Mar 11, 2024 at 11:36 AM Jim Kingdon  wrote:

> If this is just a hypothetical question I guess we don't really need to
> come up with a definitive answer, but I will say that if we want to keep
> some of our other values (like preferring short proofs), we'd end up
> with a lot of ALT theorems or other ways in which there is a classical
> proof, there is an intuitionistic proof, and the intuitionistic proof is
> much longer.


We already have a caveat in the proof shortening rules for this. We want
shorter proofs but *only* assuming it doesn't take the theorem out of a
"subsystem of interest". For the most part that means that proof searches
using MINIMIZE will add /NO_NEW_AXIOMS to ensure that intuitionistic proofs
stay intuitionistic. So in the variation you are talking about I would
expect there to only be an intuitionistic proof, and the classical proof
(if the statement is different) would be the shorter of "do the proof
directly" and "apply the intuitionistic version and remove the unnecessary
assumptions", which probably would end up with the latter most of the time.


> Proof length aside, I guess I'm just not sure that set.mm would read
> very nicely if it needed to concern itself with decidability, apartness,
> additional conditions on things like supremums and convergence, etc. Not
> to mention topology which beyond a certain point falls apart unless you
> switch from point-set topology to locales (or so I read, iset.mm hasn't
> really gotten that far yet).
>

This is a fair criticism. For those areas like topology where it's still
unclear how to intuitionize it, the whole thing would simply be classical.
But I would expect a cover-to-cover reader of set.mm to already know that
it is trying to simultaneously cover intuitionistic and classical logic,
and the abstractions that work in intuitionistic logic are also interesting
in their own way. I know I had to search far and wide for proofs about
measure theory in the absence of the axiom of choice (thanks Fremlin!) so
it wouldn't be the first time for proofs that go out of their way to avoid
some axiom.


> I'll also say that I do agree about the observations about how iset.mm
> and set.mm are similar enough that it is also awkward, in different
> ways, to keep them separate. There are a lot of theorems which can
> simply be copy-pasted in one direction or the other.
>

And of course these copy-pasted theorems are a future maintenance issue,
since people will have to remember to change them in tandem (or not! if the
change needs classical logic) and this is hard to deal with without a
global view of all the databases.

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSt9UHdv%2BPAN0wYH-E%2BsN5XxQpmPTmS6DUUS9a5G%3DW7dew%40mail.gmail.com.


Re: [Metamath] Results about ax-13 usage

2024-03-11 Thread Mario Carneiro
Well it's redoing a lot of the work that exists in set.mm, and you can't
really share results across them. For most logical subsystems, we address
it directly in set.mm by using more itemized axioms and leveraging the
"this theorem was proved from axioms:" list for tracking so that all the
subsystems can transparently coexist. When the axiomatic system is
significantly different and/or inconsistent with set.mm, it has to be
developed in a separate database (like hol.mm or nf.mm), but iset.mm does
not look like that to me, it uses variables and binding and all of the
other structural things in exactly the same way, it just omits some logical
axiom and replaces it with weaker things. Given a free choice I think that
developing in the same database is better since then intuitionistic proofs
can be used in classical theorems (and vice versa, when the classical
theorem was not actually using classical logic on accident or because of a
refactor).

On Sun, Mar 10, 2024 at 9:16 AM Gino Giotto 
wrote:

> > And of course the largest such refactor in this vein is iset.mm,
> although this one was considered sufficiently different as to be moved to a
> separate database (which I think is slightly unfortunate).
>
> Why is it slightly unfortunate? (just curious, I don't know much about
> iset.mm).
>
> Il giorno mercoledì 10 gennaio 2024 alle 09:16:41 UTC+1 kin...@panix.com
> ha scritto:
>
>> In a sense iset.mm is that sort of thing, although to state what is
>> probably obvious but maybe needs to be said anyway, iset.mm does not
>> only remove axioms relative to set.mm, it also adds axioms and modifies
>> axioms.
>> On 1/9/24 19:19, Mario Carneiro wrote:
>>
>> And of course the largest such refactor in this vein is iset.mm,
>> although this one was considered sufficiently different as to be moved to a
>> separate database (which I think is slightly unfortunate).
>>
>> On Tue, Jan 9, 2024 at 10:17 PM Mario Carneiro  wrote:
>>
>>> IMO this is definitely worthwhile, especially since it moves an axiom
>>> from used almost everywhere to used almost nowhere. We have previously done
>>> refactors of that kind for ax-groth, ax-ac2, ax-reg, ax-rep and I think we
>>> have a better understanding of the true dependencies of many theorems as a
>>> result.
>>>
>>> On Tue, Jan 9, 2024 at 9:30 PM Gino Giotto 
>>> wrote:
>>>
>>>> I believe the question now is whether there is a general consensus for
>>>> eventually bringing set.mm towards this direction. Is low usage of
>>>> ax-13 at the cost of more than 100 additional lemmas what we wish for? Or
>>>> maybe you would like to follow different paths and pursue different
>>>> achievements? Looking forward to hear your thoughts.
>>>>
>>>> Il giorno mercoledì 3 gennaio 2024 alle 02:02:21 UTC+1 Benoit ha
>>>> scritto:
>>>>
>>>>> Thanks Gino, I'm going to have a look.  In addition to my post on the
>>>>> discussion group that you mention, I also began to do in my mathbox what
>>>>> you described, i.e., adding enough DV conditions to the technical lemmas 
>>>>> so
>>>>> as to later remove some ax-13 usages, but less systematically.  Some
>>>>> theorems made it to the main sections, but most remain in my mathbox, in
>>>>> the section "20.15.4.12  Removing dependencies on ax-13 (and ax-11)", 
>>>>> which
>>>>> also has a section head comment to explain the principles. The plan was to
>>>>> move to Main only the ones that had the greatest benefits, but since there
>>>>> was no clear criterion, this kind of stalled.
>>>>>
>>>>> Benoît
>>>>>
>>>>> On Tuesday, January 2, 2024 at 12:52:10 AM UTC+1 di@gmail.com
>>>>> wrote:
>>>>>
>>>>>> On Mon, Jan 1, 2024 at 6:43 PM Jim Kingdon  wrote:
>>>>>>
>>>>>>> One (historical?) note: some of what we have now is the result of
>>>>>>> experimentation in the opposite direction - trying to figure out 
>>>>>>> whether a
>>>>>>> logical system can be built without distinct variable constraints at 
>>>>>>> all (I
>>>>>>> think there is some reference to this in some comments or web pages). I
>>>>>>> think the verdict was that it was possible but so cumbersome as to be
>>>>>>> impractical (because all the distinctor antecedents need to be carried
>>>>>>> along until the point where 

Re: [Metamath] Re: Proof generation

2024-02-12 Thread Mario Carneiro
I think mmj2 only ever uses wceq, because it "parses" formulas and using
weq introduces an ambiguity into the resulting grammar. However
metamath-exe's MINIMIZE will find shorter proofs using lemmas, and it
treats syntax lemmas just like real lemmas, so it will "optimize" the proof
to use weq. I think you shouldn't worry much about whether you produce one
vs another, IMO having syntax lemmas was a mistake.

On Mon, Feb 12, 2024 at 7:14 PM jagra  wrote:

> Thanks both for the explanations.
>
> I had it working, but since the generated proofs were in some cases so
> different from those in set.mm, I was trying to understand why.
>
> One of the things I noticed, and caused the differences I had, was
> avoiding the use of $p statements in parsing rules. For instance, weq and
> wceq seem to be similar, but weq is a $p while wceq is a $a, but they seem
> to be basically equivalent when used in generated proof.
>
> Including weq creates in some cases, several distinct correct parsing
> alternatives for the same statement, while using just $a rules (wceq
> instead of weq) does not. Tested (only) with ax8, replacing the original
> proof with one that contained a proof generated just from $a rules (from
> base ax8 proof statements), and set.mm was verified without errors.
>
> The proof is bigger and I understand that's a concern always present, but,
> other than that, do you see any problems with it?
>
> Best regards,
> Jorge Agra
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/980d8c60-d073-4784-81c8-11a698612730n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSvO1BXFcYRxVv96%2ByANDj8r_v7dZDhefRZ0auDmPA7xQQ%40mail.gmail.com.


Re: [Metamath] Re: Proof generation

2024-02-12 Thread Mario Carneiro
On Mon, Feb 12, 2024 at 8:40 AM Glauco  wrote:

> The proofs produced by mmj2 are not exactly the same, because (in my
> opinion) mmj2 has a small bug in the knapsack algorithm
>


> IMHO, metamath.exe and mmj2 don't produce the same compressed proofs (I've
> shown several examples, in the past)
>

I would be interested to hear specifics about these claims, because they
are supposed to be the same and I haven't heard any bug reports to the
contrary. I also don't understand what knapsack bug you are describing or
why it is a matter of opinion whether it is a bug.


>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/f687d4b6-412f-4be0-92b8-4d92dd893277n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSuKbEWmMbEsfd_A%2BcCXxCVRVExdKxv8hwVgTnBhRQBhow%40mail.gmail.com.


Re: [Metamath] Proof generation

2024-02-11 Thread Mario Carneiro
The specification for metamath checking in general is given in the Metamath
Book: https://us.metamath.org/downloads/metamath.pdf

The proof blocks are written in "compressed proof format", which is
specified in Appendix B of the metamath book. (Although, metamath-exe, mmj2
and metamath-knife generate proofs which are byte identical because they
also implement a specific sorting / packing strategy taking advantage of
some flexibility in the specification to produce more compact proofs. If
you want to implement this you will have to read the code of one of these
systems.)

On Sun, Feb 11, 2024 at 9:42 PM Jorge Agra  wrote:

> Greetings,
>
> tried to find a definition for proof generation from a list of
> statements/expressions+justifications+dependencies.
>
> mmj2, metamath.exe, yamma, metamath-lamp, all generate valid proof
> statements, but could not find a spec on the requirements that they
> implement.
>
> Is a spec available, even if informally?
>
> Best regards.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/e3b5b65e-1c4c-4f88-9ae1-a69e74b0ca0cn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSsGJbyDc208%2B4OgCf8Eci0DrqJMbD0aMWsa%3D%2B3WOHWyOw%40mail.gmail.com.


[Metamath] Re: mm-web-rs server support

2024-02-07 Thread Mario Carneiro
It requires some changes to the mmrecent.html CSS, so for now a copy is
hosted at https://github.com/digama0/mm-web-rs/blob/master/mmrecent.raw.html
. The pages generated by mm-web-rs are significantly different under the
hood, making use of modern HTML5, although it's still dressed up in the web
1.0 clothing of the original website. Once we've confirmed that the site
isn't missing anything critical, I want to update the site design a bit
(and possibly finally ditch the GIF pages!). I'm working on this in my
spare time between my other projects though, so progress will probably be
slow. Feel free to run https://github.com/digama0/mm-web-rs locally before
the beta version goes live.

On Thu, Feb 8, 2024 at 1:59 AM Mario Carneiro  wrote:

> mm-web-rs now supports generation of the auxiliary pages:
> mmtheorems.html, mmrecent.html, mmtheoremsall.html, mmdefinitions.html, and
> mmascii.html, which was the last remaining piece to completely replace
> metamath-exe web site generation functionality. The next step is to add it
> to the website build (under an experimental subfolder) so that regular
> users can play with it and find differences with the original.
>
> On Sun, Jan 30, 2022 at 2:43 AM Mario Carneiro  wrote:
>
>> Hi All,
>>
>> I just wanted to share some metamath-knife progress: The
>> https://github.com/digama0/mm-web-rs experimental metamath web site
>> clone is now able to draw complete theorem pages, including the step list,
>> forward references and axioms used, comment markup, dummy variable and
>> allowed substitution hints, basically everything visible on the page, all
>> powered by the metamath-knife API. Furthermore, as a result of the switch
>> to a rust backend it is now quite simple to add a web server, so now you
>> can run "mm-web-rs server" and it will serve pages like
>> http://localhost:8080/mpeuni/pnt.html as you would expect from a static
>> server.
>>
>> Mario
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJStBNgO5u1Bx%2BFP%3DWX9Hms9kJ8CyKCy7NWjHcXvXSEeLpw%40mail.gmail.com.


[Metamath] Re: mm-web-rs server support

2024-02-07 Thread Mario Carneiro
mm-web-rs now supports generation of the auxiliary pages:
mmtheorems.html, mmrecent.html, mmtheoremsall.html, mmdefinitions.html, and
mmascii.html, which was the last remaining piece to completely replace
metamath-exe web site generation functionality. The next step is to add it
to the website build (under an experimental subfolder) so that regular
users can play with it and find differences with the original.

On Sun, Jan 30, 2022 at 2:43 AM Mario Carneiro  wrote:

> Hi All,
>
> I just wanted to share some metamath-knife progress: The
> https://github.com/digama0/mm-web-rs experimental metamath web site clone
> is now able to draw complete theorem pages, including the step list,
> forward references and axioms used, comment markup, dummy variable and
> allowed substitution hints, basically everything visible on the page, all
> powered by the metamath-knife API. Furthermore, as a result of the switch
> to a rust backend it is now quite simple to add a web server, so now you
> can run "mm-web-rs server" and it will serve pages like
> http://localhost:8080/mpeuni/pnt.html as you would expect from a static
> server.
>
> Mario
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSv6cu8L3b3ggy2DzpPAokhDrC5c9WtMVnZQL_e3V%2Bhm6A%40mail.gmail.com.


Re: [Metamath] Constant symbols are not allowed in a "$d" statement.

2024-02-03 Thread Mario Carneiro
You can't use $d to ensure that constants don't appear in a formula. I
don't have all the context needed to understand why you need to do this,
but one way to express it would be to have a predicate "|- ^.-free A" and
have rules like "|- ( ^.-free A -> ( ^.-free B -> ^.-free ( A /\ B ) ) )"
for all formula constructors except for ^. . But this wouldn't really be
suitable for set.mm, it would have to be its own database because it would
require new axioms. (It's not that unusual to have alternative databases
for different logics, we already have about 10 such databases. set.mm is
just the biggest one since it represents "conventional" logic in some
sense.)

More likely, what you actually need here is some kind of modality like "A
always holds" or "A holds N steps in the future", and it commutes with most
operators but has special behavior around ^. .

On Sat, Feb 3, 2024 at 7:28 AM Brian Larson 
wrote:

> In the process of cleaning-up my theorems for possible addition to set.mm
> I found a fundamental inconsistency in the definition of my discrete time
> operator ^. which is defined in terms of my continuous time operator @.
>
> p@t says evaluate p at time t which is restricted to time the machine
> starts operation, t=0, to the present instant, t=now, when the software
> controlling the machine must decide what to do:
>
> $( Define domain of time ` TIME ` from ` t = 0 ` to ` now ` $)
> df-bl.time $a |- TIME = { x | ( x e. RR /\ 0 <_ x /\ x <_ now ) }  $.
>
> @ is used to declaratively specify machine timing behavior such as:
>
> invariant
>   << LRL: : --Lower Rate Limit
> exists t~time  --there was a moment
>   in (now-lrl)..now   --within the previous LRL interval
>   that (n@t or p@t) >>  --with a pace or non-refractory sense
>
> which defines the fundamental effectiveness property of pacemakers
> treating bradycardia.   If the physician decides that the Lower Rate Limit
> should be 60 beats per minute, the LRL interval (lrl) will be 1 s.  Then
> LRL asserts that forever the pacemaker is operating, a heart beat will have
> occurred, either intrinsically, n@t or paced p@t.
>
> Naturally, ( p@t_1 ) @ t_2 <-> p@t_1.
>
> Works great for threads with sporadic dispatch protocols.  For periodic
> threads, a discrete temporal operator shifts time of evaluation by an
> integer number of thread periods.
>
> p^-3 means the value of p, three periods before now.  The discrete time
> operator is defined in terms of the continuous time operator for which $d A
> ^. $. caused the error.
>
>   ${
>   $d A ^. $.
> $( Time Shift Value (for ` ^. ` not in ` A ` )  $)
> df-bl.tsc $a |- ( ( A e. RR /\ B e. ZZ /\ D e. RR /\ ( now + ( D x. B ) )
> e. TIME ) ->
> ( A ^. B ) = ( A @ ( now + ( D x. B ) ) ) ) $.
>   $}
>
> This is to be applied only when no ^. are used to express A because
> composition of ^. add the time shift values:
>
> $( Distribute ` ^. ` over values $)
> df-bl.tsdisc $a |- ( ( A e. RR /\ B e. ZZ /\ C e. ZZ ) ->
>   ( ( A ^. B ) ^. C ) = ( A ^. ( B + C ) ) ) $.
>
> If I am the only person using df-bl.tsc (or its wff equivalent df-bl.ts) I
> can be sure to use them atomically . . . except all of the proofs of
> distribution have the same problem.
>
> The rigor of Metamath exposed a fundamental flaw in BLESS logic.
>
> I'm considering removing ^. from the language entirely and try to prove
> the periodic threads using only the continuous time operator.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/cf3b8654-0c1b-4b89-8f5e-63cfaa54a3f3n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSuAbKsVNPX9kpES0fGMC_FciBEwEpTkC7nxu29nYPpGdQ%40mail.gmail.com.


Re: [Metamath] mmj2: Unification failure in derivation proof step

2024-02-02 Thread Mario Carneiro
The issue is that the '. syntax is ambiguous, A = B '. can be interpreted
as either "A = (B '.)" or "(A = B) '." . Syntax ambiguity in set.mm (and
most metamath databases) is a big no-no, you can generally prove a
contradiction from them, but because mmj2 parses formulas into trees
ambiguous parses instead manifest as unification failures. My guess is that
the expression you wrote as |- ( A = B '. <-> ( A = B ^. 1 ) ) is parsed
using the A = (B '.) interpretation, but the instantiation of df-bl.tick
would produce the (A = B) '. interpretation.

The short version of the ambiguity restriction as it applies to set.mm is
that you are not allowed to have pure postfix operators without
parentheses, which means both wtick and ctick are illegal, but wts and clts
are fine.

On Fri, Feb 2, 2024 at 8:33 AM Brian Larson 
wrote:

> Thank you for the quick, and disappointing (as expected) answers.
>
> The problematic definition:
> $( Define Tick, Predicate ` ph '. <-> ( ph ^. 1 ) ` $)
> df-bl.tick $a |- ( ph '. <-> ( ph ^. 1 ) ) $.
>
> Because tick is used as syntactic sugar,  I can do without it.
> Unfortunately, I have other theorems whose proofs mmj2 won't unify, so
> were also proved using MM-PA.
>
> I forked the set.mm GitHub repo (brlarson) in preparation for
> contributing my small bit to the community.
>
> On Friday, February 2, 2024 at 5:49:07 AM UTC-6 di@gmail.com wrote:
>
>> That error message means that the theorem df-bl.tick has a statement that
>> does not match the expression  |- ( A = B '. <-> ( A = B ^. 1 ) ) that you
>> have provided. It's difficult to say more without seeing the rest of the
>> code (and in particular, the definition of `df-bl.tick`).
>>
>> Q1: No, this is a fatal error, the proof is not correct as written. One
>> way you can try to clear things up is to delete the statement (just the |-
>> ( A = B '. <-> ( A = B ^. 1 ) ) part) and let mmj2 fill it in for you. The
>> only steps you can't delete are the hypotheses IIRC.
>> Q2: I think there isn't any centralized listing other than the source
>> code:
>> https://github.com/digama0/mmj2/blob/1cd95c1fe4435899c8575644fccb412dd77d79e4/src/main/java/mmj/pa/PaConstants.java#L2790-L2794
>> . In general you can search the repo for uses of the constant which might
>> have some additional clues about it, but most of them carry a decent amount
>> of explanation text which will be more helpful than looking at the code.
>> Q3: Yes, because set.mm only accepts completed proofs, and mmj2 will not
>> produce a completed proof (a block starting with $= at the bottom of the
>> file) until all unification errors are fixed and missing steps are filled
>> in.
>>
>>
>> On Thu, Feb 1, 2024 at 10:59 AM Brian Larson 
>> wrote:
>>
>>> I much enjoy using mmj2, and am often amazed at how its unification
>>> deduces a theorem to solve qed when I think I've got a couple more steps to
>>> go.  However, sometimes I get failure in its final unification check.
>>>
>>> The error message:
>>> E-PA-0410 Theorem bl.tkeq: Step 100: Unification failure in derivation
>>> proof step df-bl.tick. The step's formula and/or its hypotheses could not
>>> be reconciled with the referenced Assertion. Try the Unify/Step Selector
>>> Search to find unifiable assertions for the step.
>>>  -
>>>
>>> The culprit:
>>> 100::df-bl.tick |- ( A = B '. <-> ( A = B ^. 1 ) )
>>>
>>> '. and ^. are modal logic operators which determine in which "world"
>>> variables and predicates made with them should be evaluated:  A must equal
>>> B one thread period hence.
>>>
>>> Both operators can be applied to wffs or classes:
>>> $( Define ` ( ph ^. A ) ` as a wff $)
>>> wts $a wff ( ph ^. A ) $.
>>>
>>> $( Define ` ( A ^. B ) ` as a class $)
>>> clts $a class ( A ^. B ) $.
>>>
>>> $( Define ` ph '. ` as a wff $)
>>> wtick $a wff ph '. $.
>>>
>>> $( Define ` A '. ` as a class $)
>>> ctick $a class A '. $.
>>>
>>> For other theorems which encountered this problem, I used MM-PA, and
>>> then included such theorems in the ProofAsstUnifySearchExclude list.
>>>
>>> Q1)  Is there some clever RunParamFile setting which will avoid the
>>> error?
>>> Q2)  Where can the list of error codes like E-PA-0410 be found?
>>> Q3)  Will the mmj2 check preclude such theorems from acceptance into
>>> set.mm?
>>>
>>>
>>> --Brian
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Metamath" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to metamath+u...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/metamath/e6bd6e24-9110-49cc-ac8b-08128a7828abn%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To 

Re: [Metamath] mmj2: Unification failure in derivation proof step

2024-02-02 Thread Mario Carneiro
That error message means that the theorem df-bl.tick has a statement that
does not match the expression  |- ( A = B '. <-> ( A = B ^. 1 ) ) that you
have provided. It's difficult to say more without seeing the rest of the
code (and in particular, the definition of `df-bl.tick`).

Q1: No, this is a fatal error, the proof is not correct as written. One way
you can try to clear things up is to delete the statement (just the |- ( A
= B '. <-> ( A = B ^. 1 ) ) part) and let mmj2 fill it in for you. The only
steps you can't delete are the hypotheses IIRC.
Q2: I think there isn't any centralized listing other than the source code:
https://github.com/digama0/mmj2/blob/1cd95c1fe4435899c8575644fccb412dd77d79e4/src/main/java/mmj/pa/PaConstants.java#L2790-L2794
. In general you can search the repo for uses of the constant which might
have some additional clues about it, but most of them carry a decent amount
of explanation text which will be more helpful than looking at the code.
Q3: Yes, because set.mm only accepts completed proofs, and mmj2 will not
produce a completed proof (a block starting with $= at the bottom of the
file) until all unification errors are fixed and missing steps are filled
in.


On Thu, Feb 1, 2024 at 10:59 AM Brian Larson 
wrote:

> I much enjoy using mmj2, and am often amazed at how its unification
> deduces a theorem to solve qed when I think I've got a couple more steps to
> go.  However, sometimes I get failure in its final unification check.
>
> The error message:
> E-PA-0410 Theorem bl.tkeq: Step 100: Unification failure in derivation
> proof step df-bl.tick. The step's formula and/or its hypotheses could not
> be reconciled with the referenced Assertion. Try the Unify/Step Selector
> Search to find unifiable assertions for the step.
>  -
>
> The culprit:
> 100::df-bl.tick |- ( A = B '. <-> ( A = B ^. 1 ) )
>
> '. and ^. are modal logic operators which determine in which "world"
> variables and predicates made with them should be evaluated:  A must equal
> B one thread period hence.
>
> Both operators can be applied to wffs or classes:
> $( Define ` ( ph ^. A ) ` as a wff $)
> wts $a wff ( ph ^. A ) $.
>
> $( Define ` ( A ^. B ) ` as a class $)
> clts $a class ( A ^. B ) $.
>
> $( Define ` ph '. ` as a wff $)
> wtick $a wff ph '. $.
>
> $( Define ` A '. ` as a class $)
> ctick $a class A '. $.
>
> For other theorems which encountered this problem, I used MM-PA, and then
> included such theorems in the ProofAsstUnifySearchExclude list.
>
> Q1)  Is there some clever RunParamFile setting which will avoid the error?
> Q2)  Where can the list of error codes like E-PA-0410 be found?
> Q3)  Will the mmj2 check preclude such theorems from acceptance into
> set.mm?
>
>
> --Brian
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/e6bd6e24-9110-49cc-ac8b-08128a7828abn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSuBCQpLVCxm-PEhvBuNNti_soxCjEML5d%3Ds-5-kYXbsew%40mail.gmail.com.


Re: [Metamath] Prime Number Theorem

2024-01-31 Thread Mario Carneiro
In the most technical sense, I wouldn't really call it "following in my
footsteps", because the approach planned is not at all similar to the
Erdos-Selberg method, and this is a good thing, I think mathlib has no need
for the Erdos-Selberg proof (although I did port it to lean
<https://leanprover.zulipchat.com/#narrow/stream/113488-general/topic/Prime.20number.20theorem.20in.20lean/near/168109101>
almost 5 years ago...). The complex analysis proof is much more productive
in terms of its related results, and will be more useful for future
projects like Fermat's Last Theorem (which has almost all areas of
mathematics in its dependency tree). That's what the "and more" part of the
project is about - PNT has been done before multiple times, it's old news,
but *this way* of doing it will lead to other theorems that have not been
formalized before. And the fact that big shot mathematicians are leading
the charge makes me even more hopeful that (1) it will get done quickly and
(2) it will actually prove theorems which are relevant and interesting to
mathematicians.

On Wed, Jan 31, 2024 at 3:55 AM 'Thierry Arnoux' via Metamath <
metamath@googlegroups.com> wrote:

> That's nice!
>
> Lean really has a lot of traction, especially with such names as Terrence
> Tao, and with people like Andrej Bauer making publicity around it.
>
> What I really like about it is that collaboration is fostered through
> tools such as the blue print and the dependency graph:
>
>
> https://alexkontorovich.github.io/PrimeNumberTheoremAnd/web/dep_graph_document.html
>
> This gives a good overview of the steps to reach the goal, and everyone
> can grab a piece (there is a Zulip Chat channel to synchronize about who
> does what).
>
> And more importantly, this is a nice bridge between people who know the
> math but don't do formalization, and people who like to do formalization
> but are maybe not so sure about the advanced math involved.
>
> I think it would be beneficial for the Metamath community to have such a
> tool, too. I've been thinking about it for a while.
>
> BR,
> _
> Thierry
>
>
> On 31/01/2024 07:04, Jim Kingdon wrote:
>
> Looks like Terrence Tao is planning [1] to follow in the footsteps of
> Mario Carneiro [2] and formalize the Prime Number Theorem.
>
> More seriously, it is really nice to see people getting excited about
> formalization. I figure this can only be a good thing.
>
> [1] https://mathstodon.xyz/@tao/111847680248482955
>
> [2] https://us.metamath.org/mpeuni/pnt.html
> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/8102B940-2AD8-4D32-9C26-42FD3ECDB73E%40panix.com
> <https://groups.google.com/d/msgid/metamath/8102B940-2AD8-4D32-9C26-42FD3ECDB73E%40panix.com?utm_medium=email_source=footer>
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/f5b7a37f-ea21-48d5-8d0b-cd90e2f18c0f%40gmx.net
> <https://groups.google.com/d/msgid/metamath/f5b7a37f-ea21-48d5-8d0b-cd90e2f18c0f%40gmx.net?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSvCCOJqDv5aCXetO36cqjAhc%2Be6UTDfMzWDJN23HkBnHA%40mail.gmail.com.


Re: [Metamath] Results about ax-13 usage

2024-01-09 Thread Mario Carneiro
And of course the largest such refactor in this vein is iset.mm, although
this one was considered sufficiently different as to be moved to a separate
database (which I think is slightly unfortunate).

On Tue, Jan 9, 2024 at 10:17 PM Mario Carneiro  wrote:

> IMO this is definitely worthwhile, especially since it moves an axiom from
> used almost everywhere to used almost nowhere. We have previously done
> refactors of that kind for ax-groth, ax-ac2, ax-reg, ax-rep and I think we
> have a better understanding of the true dependencies of many theorems as a
> result.
>
> On Tue, Jan 9, 2024 at 9:30 PM Gino Giotto 
> wrote:
>
>> I believe the question now is whether there is a general consensus for
>> eventually bringing set.mm towards this direction. Is low usage of ax-13
>> at the cost of more than 100 additional lemmas what we wish for? Or maybe
>> you would like to follow different paths and pursue different achievements?
>> Looking forward to hear your thoughts.
>>
>> Il giorno mercoledì 3 gennaio 2024 alle 02:02:21 UTC+1 Benoit ha scritto:
>>
>>> Thanks Gino, I'm going to have a look.  In addition to my post on the
>>> discussion group that you mention, I also began to do in my mathbox what
>>> you described, i.e., adding enough DV conditions to the technical lemmas so
>>> as to later remove some ax-13 usages, but less systematically.  Some
>>> theorems made it to the main sections, but most remain in my mathbox, in
>>> the section "20.15.4.12  Removing dependencies on ax-13 (and ax-11)", which
>>> also has a section head comment to explain the principles. The plan was to
>>> move to Main only the ones that had the greatest benefits, but since there
>>> was no clear criterion, this kind of stalled.
>>>
>>> Benoît
>>>
>>> On Tuesday, January 2, 2024 at 12:52:10 AM UTC+1 di@gmail.com wrote:
>>>
>>>> On Mon, Jan 1, 2024 at 6:43 PM Jim Kingdon  wrote:
>>>>
>>>>> One (historical?) note: some of what we have now is the result of
>>>>> experimentation in the opposite direction - trying to figure out whether a
>>>>> logical system can be built without distinct variable constraints at all 
>>>>> (I
>>>>> think there is some reference to this in some comments or web pages). I
>>>>> think the verdict was that it was possible but so cumbersome as to be
>>>>> impractical (because all the distinctor antecedents need to be carried
>>>>> along until the point where that variable is no longer in use, I think).
>>>>> But perhaps I'm not summarizing that quite right - like I say this isn't a
>>>>> topic I've been hugely engaged with.
>>>>>
>>>>
>>>> No it's worse than that: even after the variable is done being used you
>>>> still can't discharge the distinctor, it permanently sticks around.
>>>> Effectively all proofs end up saying "provided there are at least N
>>>> variables in the metalogic, the following theorem holds" because you
>>>> actually can't prove anything about whether variables exist in this
>>>> setting. This admits models where e.g. the object logic only has three
>>>> variables v0 v1 v2 and so you can't write any expression containing four or
>>>> more forall or exists quantifiers without being degenerate in some way, so
>>>> the undischargeable assumptions that pile up are saying that the object
>>>> logic is at least nondegenerate enough to perform the proof in question.
>>>>
>>>>
>>>>> On 1/1/24 13:38, Gino Giotto wrote:
>>>>>
>>>>> In the last few days, I've been working on reducing the usage of
>>>>> ax-13, aiming at getting the highest result with the minimum amount of
>>>>> changes. The results of my findings are committed in my repository branch
>>>>> https://github.com/GinoGiotto/set.mm/tree/ax-13-complete, which is
>>>>> based on a version of set.mm dating back to December 13, 2023.
>>>>>
>>>>> This research was primarily motivated by curiosity. I read this email
>>>>> from Benoit
>>>>> https://groups.google.com/g/metamath/c/1wi1s6qBYqY/m/FPkPsd5oAwAJ. He
>>>>> described how most theorems use technical lemmas with dummy variables and 
>>>>> I
>>>>> became interested in checking the real extent of this. The good news is
>>>>> that ax-13 can be erased almost everywhere. The bad news is that I needed
>>&

Re: [Metamath] Results about ax-13 usage

2024-01-09 Thread Mario Carneiro
IMO this is definitely worthwhile, especially since it moves an axiom from
used almost everywhere to used almost nowhere. We have previously done
refactors of that kind for ax-groth, ax-ac2, ax-reg, ax-rep and I think we
have a better understanding of the true dependencies of many theorems as a
result.

On Tue, Jan 9, 2024 at 9:30 PM Gino Giotto 
wrote:

> I believe the question now is whether there is a general consensus for
> eventually bringing set.mm towards this direction. Is low usage of ax-13
> at the cost of more than 100 additional lemmas what we wish for? Or maybe
> you would like to follow different paths and pursue different achievements?
> Looking forward to hear your thoughts.
>
> Il giorno mercoledì 3 gennaio 2024 alle 02:02:21 UTC+1 Benoit ha scritto:
>
>> Thanks Gino, I'm going to have a look.  In addition to my post on the
>> discussion group that you mention, I also began to do in my mathbox what
>> you described, i.e., adding enough DV conditions to the technical lemmas so
>> as to later remove some ax-13 usages, but less systematically.  Some
>> theorems made it to the main sections, but most remain in my mathbox, in
>> the section "20.15.4.12  Removing dependencies on ax-13 (and ax-11)", which
>> also has a section head comment to explain the principles. The plan was to
>> move to Main only the ones that had the greatest benefits, but since there
>> was no clear criterion, this kind of stalled.
>>
>> Benoît
>>
>> On Tuesday, January 2, 2024 at 12:52:10 AM UTC+1 di@gmail.com wrote:
>>
>>> On Mon, Jan 1, 2024 at 6:43 PM Jim Kingdon  wrote:
>>>
 One (historical?) note: some of what we have now is the result of
 experimentation in the opposite direction - trying to figure out whether a
 logical system can be built without distinct variable constraints at all (I
 think there is some reference to this in some comments or web pages). I
 think the verdict was that it was possible but so cumbersome as to be
 impractical (because all the distinctor antecedents need to be carried
 along until the point where that variable is no longer in use, I think).
 But perhaps I'm not summarizing that quite right - like I say this isn't a
 topic I've been hugely engaged with.

>>>
>>> No it's worse than that: even after the variable is done being used you
>>> still can't discharge the distinctor, it permanently sticks around.
>>> Effectively all proofs end up saying "provided there are at least N
>>> variables in the metalogic, the following theorem holds" because you
>>> actually can't prove anything about whether variables exist in this
>>> setting. This admits models where e.g. the object logic only has three
>>> variables v0 v1 v2 and so you can't write any expression containing four or
>>> more forall or exists quantifiers without being degenerate in some way, so
>>> the undischargeable assumptions that pile up are saying that the object
>>> logic is at least nondegenerate enough to perform the proof in question.
>>>
>>>
 On 1/1/24 13:38, Gino Giotto wrote:

 In the last few days, I've been working on reducing the usage of ax-13,
 aiming at getting the highest result with the minimum amount of changes.
 The results of my findings are committed in my repository branch
 https://github.com/GinoGiotto/set.mm/tree/ax-13-complete, which is
 based on a version of set.mm dating back to December 13, 2023.

 This research was primarily motivated by curiosity. I read this email
 from Benoit
 https://groups.google.com/g/metamath/c/1wi1s6qBYqY/m/FPkPsd5oAwAJ. He
 described how most theorems use technical lemmas with dummy variables and I
 became interested in checking the real extent of this. The good news is
 that ax-13 can be erased almost everywhere. The bad news is that I needed
 129 lemmas to accomplish this task, which is higher than the final
 estimates provided in that conversation (100 seemed to be the upper bound).

 The approach I pursued goes as follows: Starting from
 https://us.metamath.org/mpeuni/ax13w.html, I proved all theorems in
 the ax-13 section by adding the necessary dv conditions. Then I continued
 to the "Uniqueness and unique existence" section and the first few set
 theory sections until usage of proofs with dummy variables became
 prevalent. Distinguishing between the theorems that require additional dv
 conditions from those that don't isn't straightforward, so at first I
 simply proved them all and later I pruned away those that didn't
 necessitate additional dv conditions.

 This process resulted in more than 300 additional lemmas, which I later
 pruned again by eliminating unused and already existing ones. This job
 ultimately reduced the number to 129 additional lemmas, which I believe
 cannot be lowered further unless proof lenghtenings are introduced.

 In the meantime, I conducted multiple minimization 

Re: [Metamath] Results about ax-13 usage

2024-01-01 Thread Mario Carneiro
On Mon, Jan 1, 2024 at 6:43 PM Jim Kingdon  wrote:

> One (historical?) note: some of what we have now is the result of
> experimentation in the opposite direction - trying to figure out whether a
> logical system can be built without distinct variable constraints at all (I
> think there is some reference to this in some comments or web pages). I
> think the verdict was that it was possible but so cumbersome as to be
> impractical (because all the distinctor antecedents need to be carried
> along until the point where that variable is no longer in use, I think).
> But perhaps I'm not summarizing that quite right - like I say this isn't a
> topic I've been hugely engaged with.
>

No it's worse than that: even after the variable is done being used you
still can't discharge the distinctor, it permanently sticks around.
Effectively all proofs end up saying "provided there are at least N
variables in the metalogic, the following theorem holds" because you
actually can't prove anything about whether variables exist in this
setting. This admits models where e.g. the object logic only has three
variables v0 v1 v2 and so you can't write any expression containing four or
more forall or exists quantifiers without being degenerate in some way, so
the undischargeable assumptions that pile up are saying that the object
logic is at least nondegenerate enough to perform the proof in question.


> On 1/1/24 13:38, Gino Giotto wrote:
>
> In the last few days, I've been working on reducing the usage of ax-13,
> aiming at getting the highest result with the minimum amount of changes.
> The results of my findings are committed in my repository branch
> https://github.com/GinoGiotto/set.mm/tree/ax-13-complete, which is based
> on a version of set.mm dating back to December 13, 2023.
>
> This research was primarily motivated by curiosity. I read this email from
> Benoit  https://groups.google.com/g/metamath/c/1wi1s6qBYqY/m/FPkPsd5oAwAJ.
> He described how most theorems use technical lemmas with dummy variables
> and I became interested in checking the real extent of this. The good news
> is that ax-13 can be erased almost everywhere. The bad news is that I
> needed 129 lemmas to accomplish this task, which is higher than the final
> estimates provided in that conversation (100 seemed to be the upper bound).
>
> The approach I pursued goes as follows: Starting from
> https://us.metamath.org/mpeuni/ax13w.html, I proved all theorems in the
> ax-13 section by adding the necessary dv conditions. Then I continued to
> the "Uniqueness and unique existence" section and the first few set theory
> sections until usage of proofs with dummy variables became prevalent.
> Distinguishing between the theorems that require additional dv conditions
> from those that don't isn't straightforward, so at first I simply proved
> them all and later I pruned away those that didn't necessitate additional
> dv conditions.
>
> This process resulted in more than 300 additional lemmas, which I later
> pruned again by eliminating unused and already existing ones. This job
> ultimately reduced the number to 129 additional lemmas, which I believe
> cannot be lowered further unless proof lenghtenings are introduced.
>
> In the meantime, I conducted multiple minimization sessions with the new
> lemmas using the /MAY_GROW option. This option allows to replace steps even
> when the proof length increases. In most of my minimizations, the overall
> proof shape and length remained unchanged as I replaced theorems with
> identical versions with more dv conditions.
>
> All and only my 129 additional lemmas have a *(Contributed by Gino
> Giotto, 30-Dec-2023.) *tag, so this information can be used to
> distinguish them from the other theorems in the database.
>
> I adopted the naming convention of adding a *w suffix to the original
> theorem names. The reason I did not use a *v suffix is because it would
> have resulted in 17 naming collisions. Since all the pre-exisiting versions
> have more dv conditions than mine, they would have to be renamed with *vv,
> which would have increased the amount of changes in the commit. Also I
> believe it makes sense to name them as *w since they all originated from
> ax13w (even tho after shortening their proofs they don't use ax13w
> anymore). So in the end, by using a *w suffix, no naming collision was
> generated.
>
> But enough rambling, let's get to the numbers:
> As of commit
> https://github.com/metamath/set.mm/tree/5228c50ed1c4f3e7c41dd0d5fe49c91f5c7725c8
>  dating
> back to December 13, 2023, ax-13 was used by 32,347 out of 41,652 theorems,
> covering 77.66% of the entire database. As of January 1, 2024, this
> percentage is at 77.64%, so it hasn't changed much since then.
>
> In my branch  https://github.com/GinoGiotto/set.mm/tree/ax-13-complete,
> thanks to the lemmas I added and the minimizations I performed, ax-13 is
> used by only 819 theorems out of 41,781, which is just 1.96% of the entire
> database. If we exclude 

Re: [Metamath] German translation of the Metamath book

2023-12-03 Thread Mario Carneiro
Sounds good to me. You should send a PR to
https://github.com/metamath/metamath-website-seed, which contains the
source for index.html. What are you planning to do with the translated
sources? Are they in a separate repo? The site build does run latex for
some things although I don't think it compiles the metamath pdf right now.

On Sun, Dec 3, 2023 at 3:29 AM 'Alexander van der Vekens' via Metamath <
metamath@googlegroups.com> wrote:

> I want to announce that I created a German translation of the Metamath
> book, based on the Latex files of the original book (see GitHub
> https://github.com/metamath/metamath-book). I plan to provide it for the
> Metamath community, and all interested, German speaking people. The easiest
> way to do it, in my opinion, is to add the PDF-version to the Metamath
> hompage, section "Metamath book" (
> https://us.metamath.org/index.html#book).Would this be acceptable, or are
> there other proposals?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/d418a77d-3c31-4368-a435-7f2574a767f5n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSvh7TKgjkG2VE%2Brnz1%2B_pESvUoLyYbZS8cD8RgSqfRqsw%40mail.gmail.com.


Re: [Metamath] mm0 semantic equivalence

2023-11-28 Thread Mario Carneiro
MM0 does not itself do any normalization of expressions. Instead, it acts
as a verification tool for already completed proofs, although it has some
facilities for constructing proofs and it is extensible enough to let you
add more automation to it, which you could use to automate normalization
tasks. But most likely for some really advanced proof work you would want
to use a custom front end language or user interface, and MM0 would come
out the back as a way to generate portable and cross-checkable proofs. The
facilities of MM0 are mostly designed for ensuring that large and complex
systems produce trustworthy results, but it is far outshined by other tools
when it comes to aspects of human-computer interaction.

As far as your example is concerned, I think that is a reasonable way to
pose a "prove or disprove" question to a high automation system or AI,
because the only way to construct a proof of isExample is by proving or
disproving the claim.

On Tue, Nov 28, 2023 at 7:40 PM Olof  wrote:

> Hello! if I sound pretentious, it's because I let chat gpt rewrite my
> question in better English :). Anyways:
>
> Hello! I've recently stumbled upon formal mathematics due to its potential
> application in interactive education. Despite delving into the source code
> of mm0 and scanning through available documentation, I find it challenging
> to fully grasp certain concepts.
>
> I'm curious about how mm0 handles the normalization/canonicalization of
> expressions, if it addresses this at all. My interest stems from its
> potential use beyond proof generation, particularly in interactive
> scenarios where users may answer questions. Instead of requiring users to
> generate entire proofs to demonstrate their abilities, the idea is to allow
> users to generate expressions appearing in the proof. The backend then
> determines whether that is sufficient to conclude that the user has proven
> the provable, thereby eliminating the need to learn the advanced syntax of
> proof generation software. The concept involves representing questions as
> provable theorems within mm0 using eroteric logic.
>
> For example, a simple "or" question could be answered by "proving"
> (providing selected expressions to) a theorem:
> -- Or Inquiry
> provable sort ef; -- question
> term askOr: wff > wff > ef;
> axiom inferOrAnswer1 (a b: wff): $ a $ > $ askOr a b $;
> axiom inferOrAnswer2 (a b: wff): $ a $ > $ askOr b a $;
> theorem isExample (h: $ a -> b -> c $): $ askOr (~((a -> b) -> (a -> c)))
> ((a -> b) -> (a -> c)) $ = '(inferOrAnswer2 (a2i h));
> Some questions only require providing an expression to conclude that the
> end user has likely proven a provable, such as questions about solutions to
> equations. Tackling this is obviously challenging. How would one approach
> it, and does mm0/metamath already implement tools that could be useful to
> compare input expressions for "semantic equivalence"?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/8fdc51fa-a68b-44af-9c6c-6a7aa68cada5n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSsRfv2GZo_rQuruj8kVfW_71D-%3DhbaESEDHO8DvfeDHoA%40mail.gmail.com.


Re: [Metamath] Website is down

2023-11-12 Thread Mario Carneiro
Fixed in https://github.com/metamath/metamath-website-seed/pull/20.

On Sun, Nov 12, 2023 at 4:18 AM Mario Carneiro  wrote:

> Looks like this is because the source was line-broken there, it says
>
> 
>
> in the source and this is enough to fool the simple image usage heuristic
> here:
>
>
> https://github.com/metamath/metamath-website-scripts/blob/8d81a0c1ab3e433b335b4e6a3bdc364d277b4946/build-website.sh#L133
>
> I'm not sure what the best alternative is. Perhaps the easiest thing would
> be to just make those non-breaking points and make sure that there are no
> such breaks in any of the other files...
>
> On Sat, Nov 11, 2023 at 9:48 AM Gino Giotto 
> wrote:
>
>> On the https://us.metamath.org/mmsolitaire/mms.html webpage, when it
>> says  " [image: <->] (double arrow): logically equivalent to" there
>> seems to be a missing picture.
>>
>> Il giorno domenica 29 ottobre 2023 alle 03:46:02 UTC+1 di@gmail.com
>> ha scritto:
>>
>>> On Wed, Oct 25, 2023 at 3:46 PM Gino Giotto 
>>> wrote:
>>>
>>>> From https://us.metamath.org/copyright.html#pd the GNU General Public
>>>> License <https://us.metamath.org/LICENSE.TXT> link gives a 404.
>>>
>>>
>>> The top level LICENSE.TXT has been removed, as the web site is PD not
>>> GPLv2 (except for some enumerated exceptions) and this positioning of the
>>> license was misleading. The script used to copy this LICENSE.TXT into
>>> mmsolitaire/ and metamath/, but metamath/ is now being handled separately
>>> (the metamath-exe repo) and mmsolitaire already has this file, so the
>>> copies are no longer necessary. I think it would make the most sense to
>>> just point to
>>> https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html#SEC1 in that
>>> link rather than use a local copy.
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Metamath" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to metamath+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/metamath/ee5cb20c-ab52-4d2b-9b4b-ab67bf0c27fdn%40googlegroups.com
>> <https://groups.google.com/d/msgid/metamath/ee5cb20c-ab52-4d2b-9b4b-ab67bf0c27fdn%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJStY0XcawRZ3RBkuvmyaRbPMZSPnfkzwD5L56E5BPoR%3DEA%40mail.gmail.com.


Re: [Metamath] Website is down

2023-11-12 Thread Mario Carneiro
Looks like this is because the source was line-broken there, it says



in the source and this is enough to fool the simple image usage heuristic
here:

https://github.com/metamath/metamath-website-scripts/blob/8d81a0c1ab3e433b335b4e6a3bdc364d277b4946/build-website.sh#L133

I'm not sure what the best alternative is. Perhaps the easiest thing would
be to just make those non-breaking points and make sure that there are no
such breaks in any of the other files...

On Sat, Nov 11, 2023 at 9:48 AM Gino Giotto 
wrote:

> On the https://us.metamath.org/mmsolitaire/mms.html webpage, when it
> says  " [image: <->] (double arrow): logically equivalent to" there seems
> to be a missing picture.
>
> Il giorno domenica 29 ottobre 2023 alle 03:46:02 UTC+1 di@gmail.com
> ha scritto:
>
>> On Wed, Oct 25, 2023 at 3:46 PM Gino Giotto 
>> wrote:
>>
>>> From https://us.metamath.org/copyright.html#pd the GNU General Public
>>> License  link gives a 404.
>>
>>
>> The top level LICENSE.TXT has been removed, as the web site is PD not
>> GPLv2 (except for some enumerated exceptions) and this positioning of the
>> license was misleading. The script used to copy this LICENSE.TXT into
>> mmsolitaire/ and metamath/, but metamath/ is now being handled separately
>> (the metamath-exe repo) and mmsolitaire already has this file, so the
>> copies are no longer necessary. I think it would make the most sense to
>> just point to
>> https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html#SEC1 in that
>> link rather than use a local copy.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/ee5cb20c-ab52-4d2b-9b4b-ab67bf0c27fdn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSsFQmmHOEwXFGa8LsbFUNgQue0ot8Vb8DmunDHODtSAfg%40mail.gmail.com.


Re: [Metamath] Update: website generation rewrite

2023-11-10 Thread Mario Carneiro
Another update: mm-web-rs now supports mmtheoremN.html generation. This was
not really a bottleneck but it is the next largest cost, taking around 10
seconds in metamath-exe, which is a small fraction of the overall build
cost but is still much slower than mm-web-rs can do. It takes about 600ms
now.

Besides speed improvements, the main other thing I am focusing on in this
rewrite is updating the HTML to use modern standards and pass the
validators (for some reason we have a link to the validator in the footer
of every theorem page but it hasn't passed in years). So far I'm just using
inline and  CSS but once metamath-exe is off the critical path for
the website generation it will be easier to move more of the CSS into a
separate file (which will result in big space savings since it won't have
to be duplicated 4 times).

Both kinds of autogenerated file are also supported in mm-web-rs's server
mode, so you can also have a live version of the website without filling
your disk. It supports multiple databases now with the same URL layout as
us.metamath.org, although it doesn't know how to serve static files yet, so
this could in principle be called by the metamath.org web server for files
that are not precompiled.

On Mon, Oct 2, 2023 at 7:42 PM Benoit  wrote:

> On Saturday, September 30, 2023 at 11:12:48 PM UTC+2 di@gmail.com
> wrote:
>
> the other thing is that dealing with files hosted on set.mm repo is a bit
> of a mess because it is so jumbled and flat. We have to cherry pick which
> files go in mpegif, which are for ilegif and which are for nfegif. Putting
> things in folders will make the script a lot simpler, and would make me
> more supportive of just moving all the database-specific files into set.mm
> repo if that's what we want to do.
>
>
> I lean toward a rule like:
> * files associated with a given database go the metamath/set.mm
> repository (which could be renamed metamath/databases -- github manages
> repository aliases);
> * files which are more general and "website-wide" go to the
> metamath/website repository (which is the merging of the
> metamath/metamath-website-seed and metamath/metamath-website-scripts
> repositories).
>
> As for organizing the metamath/databases repository, I'm of course all for
> it, having opened https://github.com/metamath/set.mm/issues/1887 and
> https://github.com/metamath/set.mm/pull/3515.
>
> Benoît
>
>
>
> On Sat, Sep 30, 2023 at 5:08 PM Mario Carneiro  wrote:
>
> There is very little code involved in keeping a file somewhere else, there
> is just one cp line in the script. So I'm fine if we want to make an
> exception for certain files. But currently it's not clear that this is what
> is happening, and yet there is a lot of inconsistency, for example
> mmbiblio.raw.html is hosted on set.mm repo but IL's mmbiblio.raw.html is
> in the seed repo. Some kind of general rule for where to look for files
> would be appreciated, the simpler the better.
>
> On Sat, Sep 30, 2023 at 1:04 PM Jim Kingdon  wrote:
>
> On 9/30/23 04:27, Mario Carneiro wrote:
>
> Moreover, I am of the opinion that we should also move all the .html and
> .raw.html files from set.mm repo to the website repo, even though those
> files are more heavily trafficked than most other pages. When you want to
> add a new page, you need to modify the website repo anyway because
> otherwise it won't get copied correctly, and if it's living next to the
> scripts then it will be easy to maintain .raw.html and the necessary
> processing along with it. By comparison, there is very little "tandem
> update" work involved in an .html file versus the .mm file - they can
> generally be updated in any order, with the main issue being possible
> broken links if the mm file links to the html file or vice versa before the
> other has landed.
>
> I see the big issue as being the links from the html files to specific
> theorem names or math syntax. If the web pages now in the set.mm repo are
> moved, there would appear to be some kind of catch-22 in terms of which
> repository would have to be updated first and how we could build automated
> checks that the websites refer to valid syntax/theorems.
>
> In particular, mmil.raw.html changes very frequently and it is very much
> tied to updates to iset.mm and set.mm.
>
> Adding a new page is rarer, so I'm not sure that's a huge consideration
> (especially if we make the scripts better organized so we better understand
> where we need to add it).
>
> I'm not saying I'm implacably opposed to any change but I'd tread
> cautiously. On the whole I think the current organization has served us
> well (I mean, in terms of which web pages are maintained where, not all the
> details of how the scripts are written which hopefully we are alread

Re: [Metamath] Website is down

2023-10-28 Thread Mario Carneiro
On Wed, Oct 25, 2023 at 3:46 PM Gino Giotto 
wrote:

> From https://us.metamath.org/copyright.html#pd the GNU General Public
> License  link gives a 404.


The top level LICENSE.TXT has been removed, as the web site is PD not GPLv2
(except for some enumerated exceptions) and this positioning of the license
was misleading. The script used to copy this LICENSE.TXT into mmsolitaire/
and metamath/, but metamath/ is now being handled separately (the
metamath-exe repo) and mmsolitaire already has this file, so the copies are
no longer necessary. I think it would make the most sense to just point to
https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html#SEC1 in that link
rather than use a local copy.

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSu%3D0kFt2nqMu%2BG2b2OS9t9eT-tguurgr6dbc9rEH0e28w%40mail.gmail.com.


Re: [Metamath] Website is down

2023-10-28 Thread Mario Carneiro
On Wed, Oct 25, 2023 at 3:46 PM Gino Giotto 
wrote:

> From https://us.metamath.org/ the mmsolitaire.tar.gz
>  , mpeuni.tar.gz
>  , qleuni.tar.gz
>  and symbols.tar.gz
>  links give a 404.


These links have been discontinued for space concerns:
https://github.com/metamath/metamath-website-scripts/blob/8d81a0c1ab3e433b335b4e6a3bdc364d277b4946/old/install.sh#L1580-L1581
although the new code
https://github.com/metamath/metamath-website-scripts/blob/8d81a0c1ab3e433b335b4e6a3bdc364d277b4946/build-website.sh#L188-L189
extends this to all subfolders rather than just mpeuni for consistency.

A PR to remove / comment out the links from the website are welcome.

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSt0AMr4FVfMrCRN6J9Fd1rhbHB_7fw673aZJYWdfRVRqg%40mail.gmail.com.


Re: [Metamath] Website is down

2023-10-25 Thread Mario Carneiro
We have one more test to go, tonight I will let it run on its own.
Hopefully all the hotfixes for issues reported here will also be reflected
in the updated script.

There is also a bit of remaining cleanup to do re: images in set.mm repo.
All the _frege_*.svg files are duplicated in seed/mpegif/, and I think
something similar is true for the other images as well. I want to move most
of these files (including mmfrege.html, mmcomplex.html, mmzfcnd.html) to
the seed repo because they are just static files.

On Wed, Oct 25, 2023 at 2:07 PM Gino Giotto 
wrote:

> From my perspective Tirix website feels a bit "hidden" and "hard to
> reach", which I think it's a bit of a shame since how much potential it
> has. I would be happy to see it advertised more around.
>
> Il giorno mercoledì 25 ottobre 2023 alle 19:33:01 UTC+2 Metamath ha
> scritto:
>
>> I'm afraid tirix will have to fix that himself, I don't know where the
>> source or hosting for that site is. (Although, I think it would be quite
>> possible to integrate those pages into the main site now.)
>>
>> On Wed, Oct 25, 2023 at 1:30 PM Gino Giotto 
>> wrote:
>>
>>> From https://us.metamath.org/mpeuni/bezout.html
>>> I click  Structured version  on
>>> the top right.
>>> That brings me to Tirix website.
>>> But from Tirix website clicking Unicode version
>>>  or Nearby theorems
>>>  gives a "Not
>>> Found" page.
>>>
>>> (Btw Tirix website is actually very pretty, I like it a lot)
>>>
>>> Il giorno mercoledì 25 ottobre 2023 alle 19:18:04 UTC+2 Metamath ha
>>> scritto:
>>>
 On Wed, Oct 25, 2023 at 1:14 PM Gino Giotto 
 wrote:

> Also, I don't know if it's just me, but if I click Recent proofs
>  which is in the
> first box titled
> *Metamath Proof Explorer* 
> from https://us.metamath.org/ then it says:
>
> This site can’t be reached
>
> *us2.metamath.org *
> took too long to respond.
>

 That one was fixed by @tirix in
 https://github.com/metamath/metamath-website-seed/pull/19 , it will
 show up tomorrow.

 The floating head of wisdom just happens to be symbol-sized and styled
 so I missed it in the other commit.

>>> --
>>>
>> You received this message because you are subscribed to the Google Groups
>>> "Metamath" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to metamath+u...@googlegroups.com.
>>>
>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/metamath/0899e5e9-5535-458f-b84e-afbb9824a860n%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/8c574141-5856-475c-baf9-ceaded20bb72n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSsLwSchvfdDv2MP%2BLULq4HpxpUyoWLF5ePj%2BLrHEXAE7Q%40mail.gmail.com.


Re: [Metamath] Website is down

2023-10-25 Thread Mario Carneiro
I'm afraid tirix will have to fix that himself, I don't know where the
source or hosting for that site is. (Although, I think it would be quite
possible to integrate those pages into the main site now.)

On Wed, Oct 25, 2023 at 1:30 PM Gino Giotto 
wrote:

> From https://us.metamath.org/mpeuni/bezout.html
> I click  Structured version  on
> the top right.
> That brings me to Tirix website.
> But from Tirix website clicking Unicode version
>  or Nearby theorems
>  gives a "Not Found"
> page.
>
> (Btw Tirix website is actually very pretty, I like it a lot)
>
> Il giorno mercoledì 25 ottobre 2023 alle 19:18:04 UTC+2 Metamath ha
> scritto:
>
>> On Wed, Oct 25, 2023 at 1:14 PM Gino Giotto 
>> wrote:
>>
>>> Also, I don't know if it's just me, but if I click Recent proofs
>>>  which is in the first
>>> box titled
>>> *Metamath Proof Explorer* 
>>> from https://us.metamath.org/ then it says:
>>>
>>> This site can’t be reached
>>>
>>> *us2.metamath.org *
>>> took too long to respond.
>>>
>>
>> That one was fixed by @tirix in
>> https://github.com/metamath/metamath-website-seed/pull/19 , it will show
>> up tomorrow.
>>
>> The floating head of wisdom just happens to be symbol-sized and styled so
>> I missed it in the other commit.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/0899e5e9-5535-458f-b84e-afbb9824a860n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSvGHZmUD2esvuz9xaVuSOFjMn280B7kkxS65dBV1oSDFQ%40mail.gmail.com.


Re: [Metamath] Website is down

2023-10-25 Thread Mario Carneiro
On Wed, Oct 25, 2023 at 1:14 PM Gino Giotto 
wrote:

> Also, I don't know if it's just me, but if I click Recent proofs
>  which is in the first
> box titled
> *Metamath Proof Explorer* 
> from https://us.metamath.org/ then it says:
>
> This site can’t be reached
>
> *us2.metamath.org *
> took too long to respond.
>

That one was fixed by @tirix in
https://github.com/metamath/metamath-website-seed/pull/19 , it will show up
tomorrow.

The floating head of wisdom just happens to be symbol-sized and styled so I
missed it in the other commit.

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSsapQm0SMRaMCk7s0Go%2B3XcCNZNHKfaRyMaQdta3R0F7Q%40mail.gmail.com.


Re: [Metamath] Website is down

2023-10-25 Thread Mario Carneiro
The images have been restored on the live site, and the corresponding
changes to the repos are metamath-website-seed@39991733 and
symbols@85edf428.

On Wed, Oct 25, 2023 at 12:03 PM Discher, Samiro <
samiro.disc...@rwth-aachen.de> wrote:

> I also do not see the breakdown image. Maybe you didn't clear browser
> cache?
> --
> *Von:* metamath@googlegroups.com  im Auftrag
> von BTernary Tau 
> *Gesendet:* Mittwoch, 25. Oktober 2023 17:58:02
> *An:* Metamath
> *Betreff:* Re: [Metamath] Website is down
>
> I am able to see the breakdown of a proof step image, as well as the
> circled orange number icons.
>
> On Wednesday, October 25, 2023 at 11:35:23 AM UTC-4 Metamath wrote:
>
>> It seems there are problems with pictures. For example in
>> https://us.metamath.org/mpeuni/mmset.html scrolling down a little there
>> is the "Breakdown of a proof step. Credit: N. Megill 2003. Public Domain."
>> that doesn't show.
>>
>> Il giorno mercoledì 25 ottobre 2023 alle 16:52:47 UTC+2 Metamath ha
>> scritto:
>>
>>> Clicking around now..
>>>
>>> * https://us.metamath.org/ileuni/mmil.html is up to date (missing
>>> theorems list goes to dvcn) for the first time in over a year.
>>> https://us.metamath.org/ilegif/mmil.html too.
>>>
>>> * https://us.metamath.org/mpeuni/mmset.html and
>>> https://us.metamath.org/mpegif/mmset.html include the [Bauer] reference
>>> (another litmus test for up to dateness).
>>>
>>> * https://us.metamath.org/ileuni/mmrecent.html is up to date (shows a
>>> revision from 22-Oct-2023)
>>>
>>> So looks good!
>>>
>>> Thanks for all the hard work on this.
>>> On 10/25/23 00:33, Mario Carneiro wrote:
>>>
>>> Sorry about that, I chose the wrong time to test the new website build
>>> process and the cron job started running in the middle of it, and
>>> unfortunately killing the cron job just made it copy an empty website to
>>> the live site. Things should be back up now.
>>>
>>> On that note, what is now up is the new website build, so everyone
>>> please try clicking around and make sure everything seems to be working
>>> (not just theorem pages but also links to the downloads and other stuff on
>>> the homepage, the GIF and UNI directories for all five supported databases,
>>> and the symbols and mmsolitaire pages).
>>>
>>> On Wed, Oct 25, 2023 at 3:28 AM Rohan Ridenour 
>>> wrote:
>>>
>>>> https://us.metamath.org/ 403s, other pages 404.
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Metamath" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to metamath+u...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/metamath/bddc8891-7fae-467b-b794-ca84f2681fc8n%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/metamath/bddc8891-7fae-467b-b794-ca84f2681fc8n%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Metamath" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to metamath+u...@googlegroups.com.
>>>
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/metamath/CAFXXJSvt7E89qnTKXTppUv1Awsy5SCB-YiBbDBHYfn-hGr%2B7HQ%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/metamath/CAFXXJSvt7E89qnTKXTppUv1Awsy5SCB-YiBbDBHYfn-hGr%2B7HQ%40mail.gmail.com?utm_medium=email_source=footer>
>>> .
>>>
>>> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/7eaff53f-cf22-4a6e-bdac-e98b9390b27cn%40googlegroups.com
> <https://groups.google.com/d/msgid/metamath/7eaff53f-cf22-4a6e-bdac-e98b9390b27cn%40googlegroups.com?utm_medium=email_source=footer>
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/48d84c2f3b32419ab514a92cf22bdb07%40rwth-aachen.de
> <https://groups.google.com/d/msgid/metamath/48d84c2f3b32419ab514a92cf22bdb07%40rwth-aachen.de?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSsdCrDCShVG5knyqGwoQrT5t%2Bj4fCQJnf7Y_sda-5uCBQ%40mail.gmail.com.


Re: [Metamath] Website is down

2023-10-25 Thread Mario Carneiro
The proof step picture is indeed misplaced (@BTernaryTau try clearing your
cache), it seems it was placed in the symbols repo by mistake (
https://github.com/metamath/symbols/blob/main/symbols/_proofstep.gif). Same
for _orange1circ.gif and _orange2circ.gif . These will probably have to be
fixed individually so if you spot any others mention them here.

On Wed, Oct 25, 2023 at 11:58 AM BTernary Tau  wrote:

> I am able to see the breakdown of a proof step image, as well as the
> circled orange number icons.
>
> On Wednesday, October 25, 2023 at 11:35:23 AM UTC-4 Metamath wrote:
>
>> It seems there are problems with pictures. For example in
>> https://us.metamath.org/mpeuni/mmset.html scrolling down a little there
>> is the "Breakdown of a proof step. Credit: N. Megill 2003. Public Domain."
>> that doesn't show.
>>
>> Il giorno mercoledì 25 ottobre 2023 alle 16:52:47 UTC+2 Metamath ha
>> scritto:
>>
>>> Clicking around now..
>>>
>>> * https://us.metamath.org/ileuni/mmil.html is up to date (missing
>>> theorems list goes to dvcn) for the first time in over a year.
>>> https://us.metamath.org/ilegif/mmil.html too.
>>>
>>> * https://us.metamath.org/mpeuni/mmset.html and
>>> https://us.metamath.org/mpegif/mmset.html include the [Bauer] reference
>>> (another litmus test for up to dateness).
>>>
>>> * https://us.metamath.org/ileuni/mmrecent.html is up to date (shows a
>>> revision from 22-Oct-2023)
>>>
>>> So looks good!
>>>
>>> Thanks for all the hard work on this.
>>> On 10/25/23 00:33, Mario Carneiro wrote:
>>>
>>> Sorry about that, I chose the wrong time to test the new website build
>>> process and the cron job started running in the middle of it, and
>>> unfortunately killing the cron job just made it copy an empty website to
>>> the live site. Things should be back up now.
>>>
>>> On that note, what is now up is the new website build, so everyone
>>> please try clicking around and make sure everything seems to be working
>>> (not just theorem pages but also links to the downloads and other stuff on
>>> the homepage, the GIF and UNI directories for all five supported databases,
>>> and the symbols and mmsolitaire pages).
>>>
>>> On Wed, Oct 25, 2023 at 3:28 AM Rohan Ridenour 
>>> wrote:
>>>
>>>> https://us.metamath.org/ 403s, other pages 404.
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Metamath" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to metamath+u...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/metamath/bddc8891-7fae-467b-b794-ca84f2681fc8n%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/metamath/bddc8891-7fae-467b-b794-ca84f2681fc8n%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Metamath" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to metamath+u...@googlegroups.com.
>>>
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/metamath/CAFXXJSvt7E89qnTKXTppUv1Awsy5SCB-YiBbDBHYfn-hGr%2B7HQ%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/metamath/CAFXXJSvt7E89qnTKXTppUv1Awsy5SCB-YiBbDBHYfn-hGr%2B7HQ%40mail.gmail.com?utm_medium=email_source=footer>
>>> .
>>>
>>> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/7eaff53f-cf22-4a6e-bdac-e98b9390b27cn%40googlegroups.com
> <https://groups.google.com/d/msgid/metamath/7eaff53f-cf22-4a6e-bdac-e98b9390b27cn%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSvBUgs_DR7JnkWs%3D5Mi1dZqYzQZK2Kph5gD-6vxNMucXw%40mail.gmail.com.


Re: [Metamath] Website is down

2023-10-25 Thread Mario Carneiro
Crap, I deleted the site again. Sorry folks, it will be back in 3 hours.

On Wed, Oct 25, 2023 at 4:54 AM Mario Carneiro  wrote:

> Oh, this is probably because the site build was done using the set.mm
> branch from https://github.com/metamath/set.mm/pull/3524. I'll have to
> rerun the whole thing to update the website with the latest stuff from the
> develop branch, which is probably a good test just to make sure that the
> last minute issues are fixed this time now that all the branches have
> landed, but it apparently takes about 3 hours to run. (I can't wait for the
> 400x speedup from https://groups.google.com/g/metamath/c/eqsqv7WjQPs...)
>
> On Wed, Oct 25, 2023 at 4:45 AM Thierry Arnoux 
> wrote:
>
>> Thanks! That page now loads Ok, even though "most recent" shows theorems
>> from 24-Sep-2023.
>>
>> The link on the home page https://us.metamath.org/ still points to
>> http://us2.metamath.org:88/mpeuni/mmrecent.html but that's a different
>> issue.
>>
>>
>> On 25/10/2023 10:10, Mario Carneiro wrote:
>>
>> should be fixed now
>>
>> On Wed, Oct 25, 2023 at 3:39 AM Thierry Arnoux 
>> wrote:
>>
>>> https://us.metamath.org/mpeuni/mmrecent.html
>>>
>>> Still throws a 404.
>>> On 25/10/2023 09:33, Mario Carneiro wrote:
>>>
>>> Sorry about that, I chose the wrong time to test the new website build
>>> process and the cron job started running in the middle of it, and
>>> unfortunately killing the cron job just made it copy an empty website to
>>> the live site. Things should be back up now.
>>>
>>> On that note, what is now up is the new website build, so everyone
>>> please try clicking around and make sure everything seems to be working
>>> (not just theorem pages but also links to the downloads and other stuff on
>>> the homepage, the GIF and UNI directories for all five supported databases,
>>> and the symbols and mmsolitaire pages).
>>>
>>> On Wed, Oct 25, 2023 at 3:28 AM Rohan Ridenour 
>>> wrote:
>>>
>>>> https://us.metamath.org/ 403s, other pages 404.
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Metamath" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to metamath+unsubscr...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/metamath/bddc8891-7fae-467b-b794-ca84f2681fc8n%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/metamath/bddc8891-7fae-467b-b794-ca84f2681fc8n%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Metamath" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to metamath+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/metamath/CAFXXJSvt7E89qnTKXTppUv1Awsy5SCB-YiBbDBHYfn-hGr%2B7HQ%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/metamath/CAFXXJSvt7E89qnTKXTppUv1Awsy5SCB-YiBbDBHYfn-hGr%2B7HQ%40mail.gmail.com?utm_medium=email_source=footer>
>>> .
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSue9mHO465zGwgJnGBn8cCb8CLaxk8HMGvwYK4-b7iVag%40mail.gmail.com.


Re: [Metamath] Website is down

2023-10-25 Thread Mario Carneiro
Oh, this is probably because the site build was done using the set.mm
branch from https://github.com/metamath/set.mm/pull/3524. I'll have to
rerun the whole thing to update the website with the latest stuff from the
develop branch, which is probably a good test just to make sure that the
last minute issues are fixed this time now that all the branches have
landed, but it apparently takes about 3 hours to run. (I can't wait for the
400x speedup from https://groups.google.com/g/metamath/c/eqsqv7WjQPs...)

On Wed, Oct 25, 2023 at 4:45 AM Thierry Arnoux 
wrote:

> Thanks! That page now loads Ok, even though "most recent" shows theorems
> from 24-Sep-2023.
>
> The link on the home page https://us.metamath.org/ still points to
> http://us2.metamath.org:88/mpeuni/mmrecent.html but that's a different
> issue.
>
>
> On 25/10/2023 10:10, Mario Carneiro wrote:
>
> should be fixed now
>
> On Wed, Oct 25, 2023 at 3:39 AM Thierry Arnoux 
> wrote:
>
>> https://us.metamath.org/mpeuni/mmrecent.html
>>
>> Still throws a 404.
>> On 25/10/2023 09:33, Mario Carneiro wrote:
>>
>> Sorry about that, I chose the wrong time to test the new website build
>> process and the cron job started running in the middle of it, and
>> unfortunately killing the cron job just made it copy an empty website to
>> the live site. Things should be back up now.
>>
>> On that note, what is now up is the new website build, so everyone please
>> try clicking around and make sure everything seems to be working (not just
>> theorem pages but also links to the downloads and other stuff on the
>> homepage, the GIF and UNI directories for all five supported databases, and
>> the symbols and mmsolitaire pages).
>>
>> On Wed, Oct 25, 2023 at 3:28 AM Rohan Ridenour 
>> wrote:
>>
>>> https://us.metamath.org/ 403s, other pages 404.
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Metamath" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to metamath+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/metamath/bddc8891-7fae-467b-b794-ca84f2681fc8n%40googlegroups.com
>>> <https://groups.google.com/d/msgid/metamath/bddc8891-7fae-467b-b794-ca84f2681fc8n%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Metamath" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to metamath+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/metamath/CAFXXJSvt7E89qnTKXTppUv1Awsy5SCB-YiBbDBHYfn-hGr%2B7HQ%40mail.gmail.com
>> <https://groups.google.com/d/msgid/metamath/CAFXXJSvt7E89qnTKXTppUv1Awsy5SCB-YiBbDBHYfn-hGr%2B7HQ%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSs7SydGVz-zVowS0P0o4Pea_fk1jxxzuYHhz5fGFpGAKQ%40mail.gmail.com.


Re: [Metamath] Website is down

2023-10-25 Thread Mario Carneiro
should be fixed now

On Wed, Oct 25, 2023 at 3:39 AM Thierry Arnoux 
wrote:

> https://us.metamath.org/mpeuni/mmrecent.html
>
> Still throws a 404.
> On 25/10/2023 09:33, Mario Carneiro wrote:
>
> Sorry about that, I chose the wrong time to test the new website build
> process and the cron job started running in the middle of it, and
> unfortunately killing the cron job just made it copy an empty website to
> the live site. Things should be back up now.
>
> On that note, what is now up is the new website build, so everyone please
> try clicking around and make sure everything seems to be working (not just
> theorem pages but also links to the downloads and other stuff on the
> homepage, the GIF and UNI directories for all five supported databases, and
> the symbols and mmsolitaire pages).
>
> On Wed, Oct 25, 2023 at 3:28 AM Rohan Ridenour 
> wrote:
>
>> https://us.metamath.org/ 403s, other pages 404.
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Metamath" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to metamath+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/metamath/bddc8891-7fae-467b-b794-ca84f2681fc8n%40googlegroups.com
>> <https://groups.google.com/d/msgid/metamath/bddc8891-7fae-467b-b794-ca84f2681fc8n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/CAFXXJSvt7E89qnTKXTppUv1Awsy5SCB-YiBbDBHYfn-hGr%2B7HQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/metamath/CAFXXJSvt7E89qnTKXTppUv1Awsy5SCB-YiBbDBHYfn-hGr%2B7HQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSvHgc6Um4VXSNSQtn8ZUt1XMG2UZ1cHS9fN5BGwkOxboA%40mail.gmail.com.


Re: [Metamath] Website is down

2023-10-25 Thread Mario Carneiro
Sorry about that, I chose the wrong time to test the new website build
process and the cron job started running in the middle of it, and
unfortunately killing the cron job just made it copy an empty website to
the live site. Things should be back up now.

On that note, what is now up is the new website build, so everyone please
try clicking around and make sure everything seems to be working (not just
theorem pages but also links to the downloads and other stuff on the
homepage, the GIF and UNI directories for all five supported databases, and
the symbols and mmsolitaire pages).

On Wed, Oct 25, 2023 at 3:28 AM Rohan Ridenour 
wrote:

> https://us.metamath.org/ 403s, other pages 404.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/bddc8891-7fae-467b-b794-ca84f2681fc8n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSvt7E89qnTKXTppUv1Awsy5SCB-YiBbDBHYfn-hGr%2B7HQ%40mail.gmail.com.


Re: [Metamath] Order of variables in DV statements

2023-10-18 Thread Mario Carneiro
IMO class/wff variables should come at the beginning, with the list of
setvars being read as a (non)dependency specification for the class/wff
variable. I most recently visited this question for mm-web-rs, which does
not put the class/wff variables first - it just sorts all the variables,
meaning classes come first but "ph" comes between "p" and "q" - because you
need to be set.mm specific to treat class/wff variables differently from
other variables. This is likely to be a problem for other metamath
processors which try not to be set.mm specific, unless we introduce a new
$j command or interpret an existing one as a way to say that setvars come
after other things.

But also, this is not a thing that users should ever have to think about.
It should be implemented in the set.mm formatter so that even if an
authoring tool comes up with a weird order it is automatically normalized.
(But tools should also strive to honor the default convention because it's
best if the formatter doesn't need to do anything.)

On Wed, Oct 18, 2023 at 2:09 AM 'Alexander van der Vekens' via Metamath <
metamath@googlegroups.com> wrote:

> $d statements (disjoint variable restrictions) can contain two or more
> variables (wff, setvar and class variables). The order of them is
> arbitrary, but it could be helpful to have conventions how they should be
> ordered. These conventions should be also implemented in the tools which
> create $d-statements.
>
> Until now, it seems that there are the (unwritten) conventions that class
> variables and wff variables should be at the beginning or the end, and that
> setvar variables are alphabetically ordered.
>
> * In the Metamath book and
> https://us.metamath.org/mpeuni/mmset.html#distinct, class variables and
> wwf variables are always at the end.
> * mmj2 creates d$ statements with class variables and wwf variables at the
> beginning.
> * the html pages for the theorems display class variables and wwf
> variables at the beginning.
>
> mm-lamp, however, seems to create $d statements in arbitrary order (at
> least it puts class variables in the middle, see ~ cplgredgex, and does not
> always order the setvar variables alphabetically).
>
> In my opinion, we should fix the conventions (in section "Conventions" in
> set.mm) that:
> * each $d statement should contain at most one class or wff variable
> * the class variable and the wff variable should be at the beginning or
> the end
> * that setvar variables should be alphabetically ordered
>
> The tools should respect these conventions.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/a976c123-c431-4ec8-a3a2-f14c5ff88527n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSurugVtKxU6C%2B2SEi_kNr%2BPWdwUjB5_uXqAjiJpq1jeuQ%40mail.gmail.com.


Re: [Metamath] Question on definition of magma

2023-10-11 Thread Mario Carneiro
On Thu, Oct 12, 2023 at 1:46 AM bil...@gmail.com  wrote:

> I am at a more basic level than what you are trying to address. My goal is
> to learn how to prove theorems in metamath.
>
> My current task is to do the follow: given B = { x | ph }, how would I
> prove that A e. B. This is beginning level stuff.
>
> I see that there is  theorem elab2g that would be useful: I just need to
> show the following: x = A -> ( ph <-> ps )
>

Yes that's the right theorem to apply when this is your goal. Normally you
would take ps to be ph with all occurrences of x replaced by A, and use
equality theorems to prove it.


> For substitution: df-sb: [t/x] phi  <->  Ay ( y = t -> Ax ( x = y -> phi ))
> I find this more intuitive: sb5 |- ( [. y / x ]. ph <-> E. x (  x = y /\
> ph )
>

Generally you should not need to deal with the definitions of basic
functions like this (in fact, even in advanced definitions you almost never
use the definition directly, you prove an extraction lemma and use the
lemma instead of the definition). It is defined in a slightly weird way to
deal with some edge cases involving when t is x or an expression containing
x, but generally you can just choose it to not overlap and then the
definition simplifies. The usual way to unpack a substitution is using sbie
or one of its many variants (such as sbcied2 which shows up in the ismgm
theorem you referenced).

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSsrWRicern6Da0%2BXCKM8EpeTbGqL5GNJxe83kNQVqxOrQ%40mail.gmail.com.


Re: [Metamath] Question on definition of magma

2023-10-11 Thread Mario Carneiro
Usually we prioritize minimizing the length of the definition (number of
symbols) over the length of the extraction theorem, because the former is
an axiom and the latter is not.

On Thu, Oct 12, 2023 at 12:46 AM bil...@gmail.com  wrote:

> You say that the definitions are the same, but to me "substitution" needs
> to be proved in a roundabout way: that is, it is not just substituting "(
> Base ` g )" for "b".
>
> The theorem ismgm that immediately follows the definition for Mgm requires
> 19 steps, whereas only 8 steps are needed for the revised definition.
>
> I guess you answered my question that the revised definition is valid.
>
>
>
> On Wednesday, October 11, 2023 at 11:11:22 PM UTC-5 di@gmail.com
> wrote:
>
>> Those two definitions are the same except you have removed the
>> substitutions b := ( Base ` g ) and o := ( +g ` g ) . The substitutions are
>> there to make the definition more readable (and usually shorter, although
>> it might be a wash in a short definition like this one). For a more
>> elaborate example check out https://us.metamath.org/mpeuni/df-lmod.html .
>>
>> On Wed, Oct 11, 2023 at 11:38 PM bil...@gmail.com 
>> wrote:
>>
>>> The given definition of magma is:
>>>
>>> df-mgm |- Mgm = { g | [. ( Base ` g ) / b ]. [. ( +g ` g ) / o ]. A. x
>>> e. b A. y e. b ( x o y ) e. b }
>>>
>>>
>>> Would it be ok to define magma as follows:
>>>
>>> df-mgm  |-  Mgm = { g | A. x e. ( Base ` g ) A. y e. ( Base ` g ) ( x (
>>> +g ` g ) y ) e. ( Base ` g ) }
>>>
>>> If so, what problems would result ?
>>>
>>> In other words, why was the given definition chosen over the more
>>> explicit definition ?
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Metamath" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to metamath+u...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/metamath/3e26ed0a-5b15-4c29-adf5-434fb591eb96n%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/726a9570-1c6f-47ea-86af-ba553f89690fn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSukO3AKf_%3DqDnyQCQCoVqo5k4gGkcAPqXTTjq7%2BJc4mZw%40mail.gmail.com.


Re: [Metamath] Question on definition of magma

2023-10-11 Thread Mario Carneiro
Those two definitions are the same except you have removed the
substitutions b := ( Base ` g ) and o := ( +g ` g ) . The substitutions are
there to make the definition more readable (and usually shorter, although
it might be a wash in a short definition like this one). For a more
elaborate example check out https://us.metamath.org/mpeuni/df-lmod.html .

On Wed, Oct 11, 2023 at 11:38 PM bil...@gmail.com  wrote:

> The given definition of magma is:
>
> df-mgm |- Mgm = { g | [. ( Base ` g ) / b ]. [. ( +g ` g ) / o ]. A. x e.
> b A. y e. b ( x o y ) e. b }
>
>
> Would it be ok to define magma as follows:
>
> df-mgm  |-  Mgm = { g | A. x e. ( Base ` g ) A. y e. ( Base ` g ) ( x ( +g
> ` g ) y ) e. ( Base ` g ) }
>
> If so, what problems would result ?
>
> In other words, why was the given definition chosen over the more explicit
> definition ?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/3e26ed0a-5b15-4c29-adf5-434fb591eb96n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJStM7MyX9avDaeVfwnMBGHg9vvakUcy2bg5XFepS-0GHyQ%40mail.gmail.com.


Re: [Metamath] Update: website generation rewrite

2023-09-30 Thread Mario Carneiro
the other thing is that dealing with files hosted on set.mm repo is a bit
of a mess because it is so jumbled and flat. We have to cherry pick which
files go in mpegif, which are for ilegif and which are for nfegif. Putting
things in folders will make the script a lot simpler, and would make me
more supportive of just moving all the database-specific files into set.mm
repo if that's what we want to do.

On Sat, Sep 30, 2023 at 5:08 PM Mario Carneiro  wrote:

> There is very little code involved in keeping a file somewhere else, there
> is just one cp line in the script. So I'm fine if we want to make an
> exception for certain files. But currently it's not clear that this is what
> is happening, and yet there is a lot of inconsistency, for example
> mmbiblio.raw.html is hosted on set.mm repo but IL's mmbiblio.raw.html is
> in the seed repo. Some kind of general rule for where to look for files
> would be appreciated, the simpler the better.
>
> On Sat, Sep 30, 2023 at 1:04 PM Jim Kingdon  wrote:
>
>> On 9/30/23 04:27, Mario Carneiro wrote:
>>
>> Moreover, I am of the opinion that we should also move all the .html and
>> .raw.html files from set.mm repo to the website repo, even though those
>> files are more heavily trafficked than most other pages. When you want to
>> add a new page, you need to modify the website repo anyway because
>> otherwise it won't get copied correctly, and if it's living next to the
>> scripts then it will be easy to maintain .raw.html and the necessary
>> processing along with it. By comparison, there is very little "tandem
>> update" work involved in an .html file versus the .mm file - they can
>> generally be updated in any order, with the main issue being possible
>> broken links if the mm file links to the html file or vice versa before the
>> other has landed.
>>
>> I see the big issue as being the links from the html files to specific
>> theorem names or math syntax. If the web pages now in the set.mm repo
>> are moved, there would appear to be some kind of catch-22 in terms of which
>> repository would have to be updated first and how we could build automated
>> checks that the websites refer to valid syntax/theorems.
>>
>> In particular, mmil.raw.html changes very frequently and it is very much
>> tied to updates to iset.mm and set.mm.
>>
>> Adding a new page is rarer, so I'm not sure that's a huge consideration
>> (especially if we make the scripts better organized so we better understand
>> where we need to add it).
>>
>> I'm not saying I'm implacably opposed to any change but I'd tread
>> cautiously. On the whole I think the current organization has served us
>> well (I mean, in terms of which web pages are maintained where, not all the
>> details of how the scripts are written which hopefully we are already on
>> the path to improving quite aside from moving web page files around).
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Metamath" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to metamath+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/metamath/c2fd9098-cd27-4557-f5f3-a5a4041c2461%40panix.com
>> <https://groups.google.com/d/msgid/metamath/c2fd9098-cd27-4557-f5f3-a5a4041c2461%40panix.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSuQQ%3DStiqjAAGRuw0JFoSCP0tE75CBmkX56FYxcCt167A%40mail.gmail.com.


Re: [Metamath] Update: website generation rewrite

2023-09-30 Thread Mario Carneiro
There is very little code involved in keeping a file somewhere else, there
is just one cp line in the script. So I'm fine if we want to make an
exception for certain files. But currently it's not clear that this is what
is happening, and yet there is a lot of inconsistency, for example
mmbiblio.raw.html is hosted on set.mm repo but IL's mmbiblio.raw.html is in
the seed repo. Some kind of general rule for where to look for files would
be appreciated, the simpler the better.

On Sat, Sep 30, 2023 at 1:04 PM Jim Kingdon  wrote:

> On 9/30/23 04:27, Mario Carneiro wrote:
>
> Moreover, I am of the opinion that we should also move all the .html and
> .raw.html files from set.mm repo to the website repo, even though those
> files are more heavily trafficked than most other pages. When you want to
> add a new page, you need to modify the website repo anyway because
> otherwise it won't get copied correctly, and if it's living next to the
> scripts then it will be easy to maintain .raw.html and the necessary
> processing along with it. By comparison, there is very little "tandem
> update" work involved in an .html file versus the .mm file - they can
> generally be updated in any order, with the main issue being possible
> broken links if the mm file links to the html file or vice versa before the
> other has landed.
>
> I see the big issue as being the links from the html files to specific
> theorem names or math syntax. If the web pages now in the set.mm repo are
> moved, there would appear to be some kind of catch-22 in terms of which
> repository would have to be updated first and how we could build automated
> checks that the websites refer to valid syntax/theorems.
>
> In particular, mmil.raw.html changes very frequently and it is very much
> tied to updates to iset.mm and set.mm.
>
> Adding a new page is rarer, so I'm not sure that's a huge consideration
> (especially if we make the scripts better organized so we better understand
> where we need to add it).
>
> I'm not saying I'm implacably opposed to any change but I'd tread
> cautiously. On the whole I think the current organization has served us
> well (I mean, in terms of which web pages are maintained where, not all the
> details of how the scripts are written which hopefully we are already on
> the path to improving quite aside from moving web page files around).
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/c2fd9098-cd27-4557-f5f3-a5a4041c2461%40panix.com
> <https://groups.google.com/d/msgid/metamath/c2fd9098-cd27-4557-f5f3-a5a4041c2461%40panix.com?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSt-BLb6Q4jfs3KUGtGPav5bhXYzVx9Ersf6BP9vhU1Xew%40mail.gmail.com.


Re: [Metamath] Update: website generation rewrite

2023-09-30 Thread Mario Carneiro
I agree that the -scripts and -seed repos could be merged into one repo.
Moreover, I am of the opinion that we should also move all the .html and
.raw.html files from set.mm repo to the website repo, even though those
files are more heavily trafficked than most other pages. When you want to
add a new page, you need to modify the website repo anyway because
otherwise it won't get copied correctly, and if it's living next to the
scripts then it will be easy to maintain .raw.html and the necessary
processing along with it. By comparison, there is very little "tandem
update" work involved in an .html file versus the .mm file - they can
generally be updated in any order, with the main issue being possible
broken links if the mm file links to the html file or vice versa before the
other has landed.

On Sat, Sep 30, 2023 at 7:18 AM Mario Carneiro  wrote:

> I don't think we should delete the symbols repo. Those GIFs are the result
> of Norm's hard work, and they stand alone as a project. See
> https://us.metamath.org/symbols/symbols.html for more context.
>
> On Sat, Sep 30, 2023 at 7:12 AM Benoit  wrote:
>
>> Thanks for the website generation work, and the much needed
>> simplification. I think further simplification, on many levels, would be
>> achieved by dropping GIF support (as for the HTML generation, we could have
>> the default be the current HTML/unicode, and the backup being
>> HTML/plaintext, which simply displays the text in the source, with possibly
>> some coloring as in the unicode case).
>>
>> As for the repos, this would allow to delete
>> https://github.com/metamath/symbols. I also think that the two repos
>> metamath-website-script and metamath-website-seed be a single repo
>> "website" (which I already proposed when I was informed of their creation).
>> I don't see the need for this extra complexity. (Also, why prepend
>> repositories in the project "metamath" with the prefix "metamath-" ?)
>>
>> Benoît
>>
>>
>> On Saturday, September 30, 2023 at 11:02:40 AM UTC+2 di@gmail.com
>> wrote:
>>
>>> Note that mm-web-rs also supports a "server" mode, where you can give it
>>> a file and it will serve a live site without much precomputation. All it
>>> needs is a live reload feature (i.e. it detects when you save the .mm file
>>> and reloads) and you will get instant feedback (loading individual pages
>>> takes milliseconds). I've also been contemplating just running this on the
>>> server directly, so that we don't need to spend gigabytes of space on all
>>> the precomputed HTML files if it is comparably fast to just compute them on
>>> the spot.
>>>
>>> On Sat, Sep 30, 2023 at 3:04 AM Jim Kingdon  wrote:
>>>
>>>> On 9/29/23 21:52, Mario Carneiro wrote:
>>>>
>>>> > in my test these are 4893.94 s and 5020.87 s respectively (that is,
>>>> > 2h45m total). I just got the new version working, and it takes 10.8 s
>>>> > and 11.1 s respectively
>>>>
>>>> Exciting stuff!
>>>>
>>>> This has me pondering various possibilities, such as generating the
>>>> whole site on my machine (because I'm often proving where I don't have
>>>> good internet) rather than just one page at a time as I have been doing.
>>>>
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Metamath" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to metamath+u...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/metamath/a1613087-36e4-a936-0641-e935315cedda%40panix.com
>>>> .
>>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "Metamath" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to metamath+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/metamath/81baa742-493d-457a-9f5b-bb4d26498153n%40googlegroups.com
>> <https://groups.google.com/d/msgid/metamath/81baa742-493d-457a-9f5b-bb4d26498153n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSsn1P-uZLnYhCzE%3DkGQErhcYvcAV%2BoAscSSiaq-%3D3u_sQ%40mail.gmail.com.


Re: [Metamath] Update: website generation rewrite

2023-09-30 Thread Mario Carneiro
I don't think we should delete the symbols repo. Those GIFs are the result
of Norm's hard work, and they stand alone as a project. See
https://us.metamath.org/symbols/symbols.html for more context.

On Sat, Sep 30, 2023 at 7:12 AM Benoit  wrote:

> Thanks for the website generation work, and the much needed
> simplification. I think further simplification, on many levels, would be
> achieved by dropping GIF support (as for the HTML generation, we could have
> the default be the current HTML/unicode, and the backup being
> HTML/plaintext, which simply displays the text in the source, with possibly
> some coloring as in the unicode case).
>
> As for the repos, this would allow to delete
> https://github.com/metamath/symbols. I also think that the two repos
> metamath-website-script and metamath-website-seed be a single repo
> "website" (which I already proposed when I was informed of their creation).
> I don't see the need for this extra complexity. (Also, why prepend
> repositories in the project "metamath" with the prefix "metamath-" ?)
>
> Benoît
>
>
> On Saturday, September 30, 2023 at 11:02:40 AM UTC+2 di@gmail.com
> wrote:
>
>> Note that mm-web-rs also supports a "server" mode, where you can give it
>> a file and it will serve a live site without much precomputation. All it
>> needs is a live reload feature (i.e. it detects when you save the .mm file
>> and reloads) and you will get instant feedback (loading individual pages
>> takes milliseconds). I've also been contemplating just running this on the
>> server directly, so that we don't need to spend gigabytes of space on all
>> the precomputed HTML files if it is comparably fast to just compute them on
>> the spot.
>>
>> On Sat, Sep 30, 2023 at 3:04 AM Jim Kingdon  wrote:
>>
>>> On 9/29/23 21:52, Mario Carneiro wrote:
>>>
>>> > in my test these are 4893.94 s and 5020.87 s respectively (that is,
>>> > 2h45m total). I just got the new version working, and it takes 10.8 s
>>> > and 11.1 s respectively
>>>
>>> Exciting stuff!
>>>
>>> This has me pondering various possibilities, such as generating the
>>> whole site on my machine (because I'm often proving where I don't have
>>> good internet) rather than just one page at a time as I have been doing.
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Metamath" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to metamath+u...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/metamath/a1613087-36e4-a936-0641-e935315cedda%40panix.com
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/81baa742-493d-457a-9f5b-bb4d26498153n%40googlegroups.com
> <https://groups.google.com/d/msgid/metamath/81baa742-493d-457a-9f5b-bb4d26498153n%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSvRkBqNtVJf8y%3DjjNZ6bkZ44YKk7pC7TTbfCNqfS6FRGQ%40mail.gmail.com.


Re: [Metamath] Update: website generation rewrite

2023-09-30 Thread Mario Carneiro
Note that mm-web-rs also supports a "server" mode, where you can give it a
file and it will serve a live site without much precomputation. All it
needs is a live reload feature (i.e. it detects when you save the .mm file
and reloads) and you will get instant feedback (loading individual pages
takes milliseconds). I've also been contemplating just running this on the
server directly, so that we don't need to spend gigabytes of space on all
the precomputed HTML files if it is comparably fast to just compute them on
the spot.

On Sat, Sep 30, 2023 at 3:04 AM Jim Kingdon  wrote:

> On 9/29/23 21:52, Mario Carneiro wrote:
>
> > in my test these are 4893.94 s and 5020.87 s respectively (that is,
> > 2h45m total). I just got the new version working, and it takes 10.8 s
> > and 11.1 s respectively
>
> Exciting stuff!
>
> This has me pondering various possibilities, such as generating the
> whole site on my machine (because I'm often proving where I don't have
> good internet) rather than just one page at a time as I have been doing.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/a1613087-36e4-a936-0641-e935315cedda%40panix.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSvnK5Z81TQGOgSJNz0GZzvr40LSp95woN_51JZwVeU5tw%40mail.gmail.com.


[Metamath] Update: website generation rewrite

2023-09-29 Thread Mario Carneiro
For those who aren't aware, I've been working on a rewrite of the website
generation code. The main PR is
https://github.com/metamath/metamath-website-scripts/pull/16 , with links
to other parts of the process. I wanted to share another milestone: I'm
also writing https://github.com/digama0/mm-web-rs/ as a rewrite-it-in-rust
alternative to the metamath.exe theorem generation code. The most expensive
part of the website generation is the theorem files (GIF and unicode) for
set.mm, in my test these are 4893.94 s and 5020.87 s respectively (that is,
2h45m total). I just got the new version working, and it takes 10.8 s and
11.1 s respectively, a phenomenal 452x improvement over the original. This
is multithreaded, but it is still only 18s + 17.3s single-threaded, so this
still makes a huge difference even if the machine is single-threaded (I
think it is).

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSveh%3DEeqHKFBa6tFexeB-quA%3D3AaDo-DP1xxbBiripu_g%40mail.gmail.com.


Re: [Metamath] Question on Theorem pm2.61ne

2023-09-29 Thread Mario Carneiro
No, set.mm is working in ZFC, or rather a conservative extension thereof.
Classes are ZFC classes, they cannot be quantified but they represent
maybe-proper classes in the usual way. They are not "in the universe" in
the sense that "A. x ph" ranges over all sets, and proper classes are not
considered, but they are expressible in the language, essentially as
syntactic sugar for predicates with one designated free variable.

On Fri, Sep 29, 2023 at 11:59 PM bil...@gmail.com  wrote:

> So we can say that metamath is working in "new foundations" rather than
> "zfc"? In particular, this would explain why "classes" are being used.
>
> On Friday, September 29, 2023 at 10:51:44 PM UTC-5 di@gmail.com wrote:
>
>> (copying my answer, something odd seems to have happened to the first
>> post)
>>
>> The first assumption ( A = B -> ( ps <-> ch ) ) is the idiomatic way to
>> say that ch is the result of substituting A for B in ps, and there are many
>> theorems that produce results of this form. The theorem is still true when
>> you only have a one-directional implication (in fact the first step of the
>> proof is to weaken it to one), but users of the theorem will normally have
>> the biconditional on hand so it is more convenient to write it that way to
>> make the theorems more interoperable.
>>
>> This theorem is true in any classical logic, so it holds in both NF and
>> ZFC. (It does not hold in iset.mm, which uses intuitionistic logic,
>> because there is a case distinction on A = B in this theorem.) New
>> Foundations is an axiomatic system with a lot in common with ZFC, and basic
>> theorems like this will be true in both.
>>
>> On Fri, Sep 29, 2023 at 11:46 PM bil...@gmail.com 
>> wrote:
>>
>>> Theorem pm2.61ne is the following:
>>>
>>> Hypotheses:
>>> pm2.61ne.1 |- ( A = B -> ( ps <-> ch ) )
>>> pm2.61ne.2 |- ( ( ph and A =/= B ) -> ps )
>>> pm2.61ne/3 |- ( ph -> ch )
>>>
>>> Assertion:
>>> pm2.61ne |- ( ph -> ps )
>>>
>>> Question 1. Why isn't the first hypothesis given in the weaker condition:
>>>
>>> pm2.61ne.1weaker |- ( A = B -> (  ch -> ps ) )
>>>
>>> Question 2. How does this "new foundations" fit in with metamath? It
>>> seems like "new foundations" is being mixed together with "zfc foundation".
>>> For example, Theorem msqge0 that asserts A in R -> 0 <= A * A uses pm2.61ne
>>> in its proof.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Metamath" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to metamath+u...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/metamath/4765307e-2a18-40aa-a754-7591522e4305n%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/dcbccba7-8a0d-40ad-86cf-829ce4c7a333n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSs%3Dxr2jc9kbHq_TAcrbNncTNKiWH2p80hyaYRMyA%2BfD9w%40mail.gmail.com.


Re: [Metamath] Question on Theorem pm2.61ne

2023-09-29 Thread Mario Carneiro
(copying my answer, something odd seems to have happened to the first post)

The first assumption ( A = B -> ( ps <-> ch ) ) is the idiomatic way to say
that ch is the result of substituting A for B in ps, and there are many
theorems that produce results of this form. The theorem is still true when
you only have a one-directional implication (in fact the first step of the
proof is to weaken it to one), but users of the theorem will normally have
the biconditional on hand so it is more convenient to write it that way to
make the theorems more interoperable.

This theorem is true in any classical logic, so it holds in both NF and
ZFC. (It does not hold in iset.mm, which uses intuitionistic logic, because
there is a case distinction on A = B in this theorem.) New Foundations is
an axiomatic system with a lot in common with ZFC, and basic theorems like
this will be true in both.

On Fri, Sep 29, 2023 at 11:46 PM bil...@gmail.com  wrote:

> Theorem pm2.61ne is the following:
>
> Hypotheses:
> pm2.61ne.1 |- ( A = B -> ( ps <-> ch ) )
> pm2.61ne.2 |- ( ( ph and A =/= B ) -> ps )
> pm2.61ne/3 |- ( ph -> ch )
>
> Assertion:
> pm2.61ne |- ( ph -> ps )
>
> Question 1. Why isn't the first hypothesis given in the weaker condition:
>
> pm2.61ne.1weaker |- ( A = B -> (  ch -> ps ) )
>
> Question 2. How does this "new foundations" fit in with metamath? It seems
> like "new foundations" is being mixed together with "zfc foundation". For
> example, Theorem msqge0 that asserts A in R -> 0 <= A * A uses pm2.61ne in
> its proof.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/4765307e-2a18-40aa-a754-7591522e4305n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSs%3Dz1XsXK2AZs%3DD%3Dj-eg%2Bewt%3DyB%2B0pqDakKURFwrfHCrA%40mail.gmail.com.


Re: [Metamath] Question on Theorem pm2.61ne

2023-09-29 Thread Mario Carneiro
The first assumption ( A = B -> ( ps <-> ch ) ) is the idiomatic way to say
that ch is the result of substituting A for B in ps, and there are many
theorems that produce results of this form. The theorem is still true when
you only have a one-directional implication (in fact the first step of the
proof is to weaken it to one), but users of the theorem will normally have
the biconditional on hand so it is more convenient to write it that way to
make the theorems more interoperable.

This theorem is true in any classical logic, so it holds in both NF and
ZFC. (It does not hold in iset.mm, which uses intuitionistic logic, because
there is a case distinction on A = B in this theorem.)

On Fri, Sep 29, 2023 at 11:31 PM bil...@gmail.com  wrote:

> Theorem pm2.61ne is:
>
> ● pm2.61ne.1
> |- ( A = B -> ( ps <-> ch ) )
>
> ● pm2.61ne.2
> |- ( ( ph /\ A =/= B ) -> ps )
>
> ● pm2.61ne.3
> |- ( ph -> ch )
>
> pm2.61ne
> |- ( ph -> ps )
>
> Question 1. Why isn't the first premise weakened to: ( A = B -> ( ch ->
> ps ) )
>
> Question 2. Is this is a "new foundation" theorem rather than a "zfc
> theorem"? Why is is being used in the proof of Theorem msqge0 which asserts
> ( A in R -> 0 <= ( A * A )) ?
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/8119ecde-1c93-4caf-92fc-f2efe2c0772cn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSu9Jgic7mxOviLAO%2BGxN1HtjBk%3D1YZU-6BTW4a%2BmKz4hA%40mail.gmail.com.


Re: [Metamath] ?Statement "a3" cannot be unified with step 25.

2023-08-13 Thread Mario Carneiro
axiom a3 is missing parentheses around it

On Sun, Aug 13, 2023 at 5:30 PM Jeroen van Rensen 
wrote:

> Hello everyone,
>
> I am trying to prove the following statement:
>
> ! ! p |- p
>
> The formal proof is as follows (the axioms are the same as in set.mm):
>
> 1. ! ! p (Premiss)
> 2. ! ! p -> (! ! ! ! p -> ! ! p) (Axiom 1)
> 3. ! ! ! ! p -> ! ! p (MP 1, 2)
> 4. (! ! ! ! p -> ! ! p) -> (! p -> ! ! ! p) (Axiom 3)
> 5. ! p -> ! ! ! p (MP 3, 4)
> 6. (! p -> ! ! ! p) -> (! ! p -> p) (Axiom 3)
> 7. ! ! p -> p (MP 5, 6)
> 8. p (MP 1, 7)
>
> This is my entire database (irrelevant parts are removed):
>
> ```
> $c -> ! ( ) wff |- $.
> $v p q r $.
>
> wp $f wff p $.
> wq $f wff q $.
> wr $f wff r $.
>
> wim $a wff ( p -> q ) $.
> wn $a wff ! p $.
>
> a1 $a |- ( p -> ( q -> p ) ) $.
> a2 $a |- ( ( p -> ( q -> r ) ) -> ( ( p -> q ) -> ( p -> r ) ) ) $.
> a3 $a |- ( ! p -> ! q ) -> ( q -> p ) $.
>
> ${
> min $e |- p $.
> maj $e |- ( p -> q ) $.
> mp $a |- q $.
> $}
>
> ${
> dne.1 $e |- ! ! p $.
> dne $p |- p $.
> $}
> ```
>
> The current proof in the metamath CLI is as follows:
>
> ```
>  5   min=dne.1 $e |- ! ! p
> 18 min=dne.1 $e |- ! ! p
> 23 maj=a1$a |- ( ! ! p -> ( $10 -> ! ! p ) )
> 24   min=mp$a |- ( $10 -> ! ! p )
> 25   maj=? $? |- ( ( $10 -> ! ! p ) -> $5 )
> 26 min=mp$a |- $5
> 27 maj=? $? |- ( $5 -> ( ! ! p -> p ) )
> 28   maj=mp$a |- ( ! ! p -> p )
> 29 dne=mp$a |- p
> ```
>
> I need to assign axiom 3 to line 25 and 27, but when I type `assign 25 a3`
> I get the following error: ?Statement "a3" cannot be unified with step 25.
>
> I think the problem is that $10 in line 23 has not yet been resolved.
>
> I hope someone can help me. Thank you!
>
> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/8b8e924f-796a-4e5d-bdf7-36fc7fd08cd4n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSsen3M%2Bwd_zxOeHK5AC5NoTHH09mMxc19E0iq_mqkYzLA%40mail.gmail.com.


Re: [Metamath] Substitute wff for a variable

2023-08-11 Thread Mario Carneiro
Actually you have the same syntax error in a1 and a2, the outermost
implication should be surrounded in parentheses. Since you declared the
implication symbol with parentheses around it they are required for any
implication and cannot be omitted.

On Fri, Aug 11, 2023 at 11:47 AM Mario Carneiro  wrote:

> you have a syntax error in `maj` , it should read |- ( p -> q ) instead of
> |- p -> q. With the incorrect statement it won't be able to unify when you
> try to apply it.
>
> On Fri, Aug 11, 2023 at 11:45 AM Jeroen van Rensen <
> jeroenvanren...@gmail.com> wrote:
>
>> Hello everyone,
>>
>> I'm new to Metamath and it looks really cool!
>>
>> I'm trying to prove the following statement (in order to prove p -> p):
>>
>> |- ( ( p -> ( p -> p ) ) -> ( p -> p ) )
>>
>> And this is my entire database:
>>
>> ```
>> $c -> ! ( ) wff |- $.
>> $v p q r $.
>>
>> wp $f wff p $.
>> wq $f wff q $.
>> wr $f wff r $.
>>
>> wim $a wff ( p -> q ) $.
>> wn $a wff ! p $.
>>
>> a1 $a |- p -> ( q -> p ) $.
>> a2 $a |- ( p -> ( q -> r ) ) -> ( ( p -> q ) -> ( p -> r ) ) $.
>>
>> ${
>> min $e |- p $.
>> maj $e |- p -> q $.
>> mp $a |- q $.
>> $}
>>
>> lem1 $p |- ( ( p -> ( p -> p ) ) -> ( p -> p ) ) $.
>> ```
>>
>> For the proof I use a modus ponens, where the minor part is: p -> ((p ->
>> p) -> p), from axiom a1.
>>
>> The major part I can't get to work. The idea is to use axiom a2,
>> substituting p = p, q = p -> p and r = p.
>>
>> When I try to assign a2 to the right step, I get this message that I
>> don't understand:
>>
>> ```
>> MM-PA> assign 6 a2
>> ?Statement "a2" cannot be unified with step 6.
>> ```
>>
>> What should I do? How can I substitute a wff (p -> p) for a variable (q)?
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Metamath" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to metamath+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/metamath/23a2913d-c5a1-4c42-a809-5f6dba8aab77n%40googlegroups.com
>> <https://groups.google.com/d/msgid/metamath/23a2913d-c5a1-4c42-a809-5f6dba8aab77n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSupJF%2BGspxMtEJwTakCCAAEx%2BPumccTASmmi681k8hmXA%40mail.gmail.com.


Re: [Metamath] Substitute wff for a variable

2023-08-11 Thread Mario Carneiro
you have a syntax error in `maj` , it should read |- ( p -> q ) instead of
|- p -> q. With the incorrect statement it won't be able to unify when you
try to apply it.

On Fri, Aug 11, 2023 at 11:45 AM Jeroen van Rensen <
jeroenvanren...@gmail.com> wrote:

> Hello everyone,
>
> I'm new to Metamath and it looks really cool!
>
> I'm trying to prove the following statement (in order to prove p -> p):
>
> |- ( ( p -> ( p -> p ) ) -> ( p -> p ) )
>
> And this is my entire database:
>
> ```
> $c -> ! ( ) wff |- $.
> $v p q r $.
>
> wp $f wff p $.
> wq $f wff q $.
> wr $f wff r $.
>
> wim $a wff ( p -> q ) $.
> wn $a wff ! p $.
>
> a1 $a |- p -> ( q -> p ) $.
> a2 $a |- ( p -> ( q -> r ) ) -> ( ( p -> q ) -> ( p -> r ) ) $.
>
> ${
> min $e |- p $.
> maj $e |- p -> q $.
> mp $a |- q $.
> $}
>
> lem1 $p |- ( ( p -> ( p -> p ) ) -> ( p -> p ) ) $.
> ```
>
> For the proof I use a modus ponens, where the minor part is: p -> ((p ->
> p) -> p), from axiom a1.
>
> The major part I can't get to work. The idea is to use axiom a2,
> substituting p = p, q = p -> p and r = p.
>
> When I try to assign a2 to the right step, I get this message that I don't
> understand:
>
> ```
> MM-PA> assign 6 a2
> ?Statement "a2" cannot be unified with step 6.
> ```
>
> What should I do? How can I substitute a wff (p -> p) for a variable (q)?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/23a2913d-c5a1-4c42-a809-5f6dba8aab77n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSsNn_9-h19%2BjWpc6fQ7L4ebf5F-TR%2Bi%2BMwGoRCH95%2BF4g%40mail.gmail.com.


Re: [Metamath] Uncomfortable with definitions as axioms ... help?

2023-07-12 Thread Mario Carneiro
The justification of definitions requires imposing additional structure on
metamath databases in the form of being able to unambiguously parse
statements into trees. Without it, you can't use the definition checker at
all, and the rules do not make sense / could be circumvented without more
rules.

On Wed, Jul 12, 2023 at 8:53 AM Marshall Stoner 
wrote:

> I wasn't talking about set.mm or mmj2.  I was talking in metamath in
> general, which doesn't seem to enforce non-ambiguity since it only reads
> strings of tokens with no other underlying structure.  I was in learning
> the definition checker rules in terms of learning in detail how definitions
> are theoretically justified.   I didn't know there was a parsing step in
> mmj2 separate from metamath itself, so I assumed it was part of the
> definition checker (since theorem grammar is taken care of by 'w' axioms
> during proof verification).
>
>
>
> On Wednesday, July 12, 2023 at 12:02:45 AM UTC-4 di@gmail.com wrote:
>
>> On Wed, Jul 12, 2023 at 4:35 AM Marshall Stoner 
>> wrote:
>>
>>> I trust that intuitively that these definitions are valid.  The problem
>>> is an alias rule can still fail if the syntax of the definition doesn't
>>> meet certain criteria.  If the parenthesis surrounding ↔ were missing in
>>> the definition of the biconditional, for instance.  If I could understand
>>> how the definition checker for the set.mm database works I would have a
>>> better understanding.  I have my own hypothesis, but I'm not sure if it's
>>> fully sufficient.
>>
>>
>> That example fails for a very simple reason: it wouldn't parse. Step 0 of
>> the definition checker is to parse the definition as a wff, and if you omit
>> the parentheses then the parser would fail on this axiom. This would
>> actually cause mmj2 to fail if you wrote a non-parsing statement anywhere,
>> not just in a definition but in any $e, $a, or $p statement.
>>
>> If you changed the definition of the syntax "ph ↔ ps" itself to not have
>> parentheses, and removed it from the definition as well, then it would
>> parse, but mmj2 would still fail for a different parsing reason: the
>> resulting grammar is ambiguous and the parser constructs some tables that
>> witness unambiguity of the grammar, meaning that this parser construction
>> will fail if the grammar is ambiguous.
>>
>> In both cases it isn't really the definition checker catching the error.
>> The definition checker presupposes that the database has an unambiguous
>> grammar and all statements parse by that grammar.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/1c92e482-fcee-4659-a858-076edb89d6e5n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSsEfcGJDJGf-mBByE%3DcND5mwd%3Dq8R%3DHygaf9S6g%2BwT9iw%40mail.gmail.com.


Re: [Metamath] Uncomfortable with definitions as axioms ... help?

2023-07-11 Thread Mario Carneiro
On Wed, Jul 12, 2023 at 4:35 AM Marshall Stoner 
wrote:

> I trust that intuitively that these definitions are valid.  The problem is
> an alias rule can still fail if the syntax of the definition doesn't meet
> certain criteria.  If the parenthesis surrounding ↔ were missing in the
> definition of the biconditional, for instance.  If I could understand how
> the definition checker for the set.mm database works I would have a
> better understanding.  I have my own hypothesis, but I'm not sure if it's
> fully sufficient.


That example fails for a very simple reason: it wouldn't parse. Step 0 of
the definition checker is to parse the definition as a wff, and if you omit
the parentheses then the parser would fail on this axiom. This would
actually cause mmj2 to fail if you wrote a non-parsing statement anywhere,
not just in a definition but in any $e, $a, or $p statement.

If you changed the definition of the syntax "ph ↔ ps" itself to not have
parentheses, and removed it from the definition as well, then it would
parse, but mmj2 would still fail for a different parsing reason: the
resulting grammar is ambiguous and the parser constructs some tables that
witness unambiguity of the grammar, meaning that this parser construction
will fail if the grammar is ambiguous.

In both cases it isn't really the definition checker catching the error.
The definition checker presupposes that the database has an unambiguous
grammar and all statements parse by that grammar.

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSskrbo9yw0hEy2ALCMCoTeX1uv4uCtYetkkOpG9K0VXYA%40mail.gmail.com.


Re: [Metamath] Writing a pdf that organizes the introductory logic portion of set.mm.

2023-07-04 Thread Mario Carneiro
> I will try to hack away more at the proper substitution section.  I'm
mainly interested covering as many theorems as needed to show that the
definition is equivalent to a recursively defined definition with literal
substitution.  That is where I'm stuck.  I believe I have enough to do this
for the "effectively not free" definition, as the necessary theorems that
could be strung together into an equivalent recursively definition
obvious.  I'm having trouble finding the equivalent theorems in the proper
substitution case.  Hopefully this clears things up.  I don't need answers
right away.  I'm just exploring at this point.

Okay, this helps somewhat with understanding the motivation. If you want to
prove that substitution is equivalent to the recursive definition, you will
need cases for every formula constructor. There are a few alternative
methods to do that, metatheorems phrased in slightly different ways all of
which are equivalent. In order of how well supported they are:

1. Implicit substitution. These are theorems that say `( ph -> F(x1, ...,
xn) = F(y1, ..., yn) )` given `( ph -> x1 = y1 )`, ..., `( ph -> xn = yn )`.
2. Not free: These are theorems that say `F/ z F(x1, ..., xn)` given `F/ z
x1`, ..., `F/ z xn`.
3. Explicit substitution: These are theorems that say [ a / b ] F(x1, ...,
xn) = F([ a / b ] x1, ..., [ a / b ] xn).

These are to be interpreted with `=` being used to mean either `<->` or `=`
as appropriate. The statements for binders are also somewhat different;
this is the prototypical form for regular class or wff operators.

Your theorem is most similar to (3), but it is also the least well
supported in terms of theorems for every constructor. (That is, you aren't
going to find a theorem saying that a random non-foundational definition
like df-lly commutes with explicit substitution.) However, (1) has
essentially full support in the library - there is a theorem of the
described form for basically every definition, so if you can rewrite the
goal such that it is in terms of implicit substitution, then you can apply
that metatheorem and it all works.

In this case, you want to say that `[ y / x ] P(x)` is equivalent to
`P(y)`, where `P(x)` represents any propositional formula containing free
occurrences of `x`. To do this, we would apply theorem
https://us.metamath.org/mpeuni/sbie.html , which reduces the goal to a case
of (1) and a case of (2). (It is possible to avoid a dependence on
metatheorem (2) as well, by alpha renaming all bound occurrences of x in
P(y) to something else, so that P(y) syntactically contains no occurrences
of x and theorem ~nfv applies. Proving that such an alpha rename is legal
is a recursive application of (1).)

The metatheorem (1) is worked out for all the primitive constructors in the
section https://us.metamath.org/mpeuni/mmtheorems36.html#mm3566s ; using
those theorems you can prove that the implicit substitution metatheorem
holds for any formula built up from those primitives, and then it is a
short hop using theorems like ~sbie to get other forms of it involving
explicit substitution, not free, alpha renaming, or other things.

On Tue, Jul 4, 2023 at 2:10 AM Mario Carneiro  wrote:

> (This group is manually moderated, so posts may not appear immediately.)
>
> On Tue, Jul 4, 2023 at 2:04 AM Marshall Stoner 
> wrote:
>
>> I wanted to share the pdf I've written so far but it didn't send and I
>> lost what I wrote.  I guess attachments aren't allowed.  I'll post a link
>> instead.
>>
>> pdf file <https://1drv.ms/b/s!AuvNPSOQfN3xjKxgB2QVuLZMOT_W5Q?e=FCRy2b>
>> On Monday, July 3, 2023 at 11:31:45 PM UTC-4 kin...@panix.com wrote:
>>
>>> On 7/3/23 15:56, Marshall Stoner wrote:
>>>
>>> > have written up everything I considered prior to the definition of the
>>> > biconditional and conjugation.
>>> > . . . will attach and share what I have written so far as soon as I
>>> > know that I am approved for the mailing list. . . .
>>>
>>> I'll be curious to see what you came up with and how you organize it. We
>>> have some ways of organizing material on the website, for example "How
>>> to intuitionize classical proofs" at
>>> https://us.metamath.org/ileuni/mmil.html#intuitionize , "Real and
>>> Complex Numbers" at https://us.metamath.org/mpeuni/mmcomplex.html , or
>>> "Algebraic and Topological Structures" at
>>> https://us.metamath.org/mpeuni/mmtopstr.html . All of these link to
>>> relevant theorems but add explanations or give some structure in terms
>>> of how one statement relates to another.
>>>
>>> Making pull requests to the web site should now be possible but feel
>>> free to ask if it isn't clear where files go, whether website scripts
>>> need to be

Re: [Metamath] Writing a pdf that organizes the introductory logic portion of set.mm.

2023-07-04 Thread Mario Carneiro
(This group is manually moderated, so posts may not appear immediately.)

On Tue, Jul 4, 2023 at 2:04 AM Marshall Stoner  wrote:

> I wanted to share the pdf I've written so far but it didn't send and I
> lost what I wrote.  I guess attachments aren't allowed.  I'll post a link
> instead.
>
> pdf file 
> On Monday, July 3, 2023 at 11:31:45 PM UTC-4 kin...@panix.com wrote:
>
>> On 7/3/23 15:56, Marshall Stoner wrote:
>>
>> > have written up everything I considered prior to the definition of the
>> > biconditional and conjugation.
>> > . . . will attach and share what I have written so far as soon as I
>> > know that I am approved for the mailing list. . . .
>>
>> I'll be curious to see what you came up with and how you organize it. We
>> have some ways of organizing material on the website, for example "How
>> to intuitionize classical proofs" at
>> https://us.metamath.org/ileuni/mmil.html#intuitionize , "Real and
>> Complex Numbers" at https://us.metamath.org/mpeuni/mmcomplex.html , or
>> "Algebraic and Topological Structures" at
>> https://us.metamath.org/mpeuni/mmtopstr.html . All of these link to
>> relevant theorems but add explanations or give some structure in terms
>> of how one statement relates to another.
>>
>> Making pull requests to the web site should now be possible but feel
>> free to ask if it isn't clear where files go, whether website scripts
>> need to be changed, etc.
>>
>> Semi-relatedly, someone recently asked on Mastodon what a good source
>> for the constructive ordinals is. There have been three suggestions so
>> far. One is a normal math book (the HoTT book). The other two are
>> collections of formalized proofs (iset.mm and TypeToplogy). And neither
>> of the latter two give you an especially good idea of where to find the
>> ordinal stuff and where to start. It got me thinking about how to make
>> the material we have easy to read especially in cases where noone has
>> written a textbook which lays everything out carefully with the purpose
>> of teaching. Anyway, the thread is
>> https://mathstodon.xyz/@boarders/110646213816213644 in case anyone is
>> interested.
>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/77ecbdd0-a0e5-4977-aa66-aa772768a651n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSs%2BMUj%2BoSEKMOcFA4CgsTYTqjkWaU9t%2B4zEX6m51901DA%40mail.gmail.com.


Re: [Metamath] Writing a pdf that organizes the introductory logic portion of set.mm.

2023-07-03 Thread Mario Carneiro
On Mon, Jul 3, 2023 at 7:31 PM Marshall Stoner  wrote:

> I'm going through the database trying to understand everything from very
> first principles.  One of my frustrations in trying to follow proofs on the
> site is the cryptic naming of theorems and lack of organization of theorems
> by usage or importance.  I have managed to get through the propositional
> logic section and have written up everything I considered prior to the
> definition of the biconditional and conjugation.


Regarding the naming convention, I do encourage reading
https://us.metamath.org/mpeuni/conventions-labels.html . It is certainly
not something we expect you to just know without learning it, but it is
effective once you know the basic patterns. (It is somewhat similar to vim
keybindings in this regard.)

As far as organization is concerned, it is primarily organized by topic,
with a concession for dependency order when it becomes an issue. Reading
set.mm "cover to cover" sounds like quite a daunting task and you can
probably start to skim a lot of sections once you get past the first couple
theorems that set up the new material to be covered in the section.
(Especially in propositional logic and predicate logic, this part is almost
entirely composed of utility theorems and once you've seen one you've seen
them all.) A better way to find theorems that interest you is to use
depth-first search on an interesting theorem, sometimes alternating between
following backreferences and using the "related theorems" link to look
around in the section. You can also use the "used by" links to travel
forward along those links. Basically, treat it as a web of related theorems
and definitions, not so much a linear arrangement of chapters.  You can
interpret it that way to some extent but the sections are probably much too
long for a real "book" like experience. But that's just my opinion,
everyone has different approaches to learning and YMMV.


> It is in the section with theorems regarding "proper substitution" where I
> am somewhat lost without additional resources at this point.  Substitution
> is utilized in order to define classes, which are used extensively later
> on, but the motivation behind the theorems and definitions regarding
> substitution is lost on me.  I cannot find which theorems are important to
> build the expected behavior starting with atomic wffs and working up
> through induction by adding theorems regarding quantifiers and logical
> connectives.  There is also nothing distinguishing which proofs are the
> most important, plus many theorems that really belong together conceptually
> are placed far away form each other on the site as set.mm places theorems
> that require fewer axioms much earlier.
>

The short answer for the motivation for substitution is that we want to
define a notion of "replace occurrences of x with y in ph" such that "[ y /
x ] ( ( x + 1 ) = 0 /\ A. x x = 5 )" is equivalent to (or "evaluates to" if
you prefer to think of it that way) "( ( y + 1 ) = 0 /\ A. x x = 5 )". In
other words, the proper substitution of free occurrences of the variable.
There is an additional complication for the case when x and y are not
disjoint, but ignoring that the key definitional lemma is
https://us.metamath.org/mpeuni/sb6.html . (This is covered to some extent
in the docstring on https://us.metamath.org/mpeuni/df-sb.html , with
specific links to what we consider to be the important theorems and the
intended interpretation of the notation. If you think this documentation
can be improved, we of course welcome any tweaks you would like to suggest.)

Mario Carneiro

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSsJE2fQALaz9Xj3tGfiFDUPt2Xk0pO4SFTspXkdg8h24g%40mail.gmail.com.


Re: [Metamath] Is set.mm available in a more "graph-parseable" format other than in html or .mm, and/or what is the easiest way to perform graph-related operations on the set.mm dataset?

2023-06-08 Thread Mario Carneiro
I was thinking of the latter: have two crates, one for the library and one
for the executable, and put assorted functionality in the command line tool
and keep the library focused to things that make it easy to write the CLI
and are metamath-related.

On Thu, Jun 8, 2023 at 7:24 PM Thierry Arnoux 
wrote:

> Yes this feature is quite far away from a core functionality.
>
> The `metamath-knife` crate is actually both the library and a command-line
> tool.
>
> What do you have in mind here?
>
> - still keeping both library and command-line together, but moving some
> functionality (like graph exports) to another command-line crate,
>
> - or splitting library and command-line tool, with the graph export
> functionality moving to the command-line tool part?
>
> _
> Thierry
>
>
> On 08/06/2023 19:40, Mario Carneiro wrote:
>
> I am actually a bit concerned at the growth in behaviors of what is
> ostensibly a library. We need better separation between the proof assistant
> and the library, possibly a second crate in the same repo.
>
> On Thu, Jun 8, 2023 at 9:48 AM David A. Wheeler 
> wrote:
>
>>
>>
>> > On Jun 5, 2023, at 8:48 AM, Thierry Arnoux 
>> wrote:
>> >
>> > Yes, the PR has not been merged in yet, so until then you will need
>> check my branch out.
>> >
>> > This feature required an "XML" library and I've kept it optional, so
>> you will only be able to access it if the program is compiled with the
>> "xml" feature, like so:
>> >
>> > cargo run --features xml -- ../set.mm/set.mm --time
>> --export-graphml-deps deps.graphml
>> >
>> > Or
>> >
>> > cargo build --features xml
>>
>> I appreciate making it optional.
>>
>> Can you make it so the *default* is to include it, and then optionally
>> exclude it?
>> That way, people can use options to build it for special purposes, but the
>> "out of the box" functionality has whatever people might like?
>>
>> --- David A. Wheeler
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Metamath" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to metamath+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/metamath/03E6D2BE-FC76-4663-A563-9BE08D9DF2A1%40dwheeler.com
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/CAFXXJSu4TttF50YBYg%3D1x5vwKde6vUcTm1BFLDb%3D_RUU0pxshA%40mail.gmail.com
> <https://groups.google.com/d/msgid/metamath/CAFXXJSu4TttF50YBYg%3D1x5vwKde6vUcTm1BFLDb%3D_RUU0pxshA%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSszF2krw69MRt4Fbg1FqngSGeOFGNpSR3%2BiC%2BJWJedkZA%40mail.gmail.com.


Re: [Metamath] Is set.mm available in a more "graph-parseable" format other than in html or .mm, and/or what is the easiest way to perform graph-related operations on the set.mm dataset?

2023-06-08 Thread Mario Carneiro
I am actually a bit concerned at the growth in behaviors of what is
ostensibly a library. We need better separation between the proof assistant
and the library, possibly a second crate in the same repo.

On Thu, Jun 8, 2023 at 9:48 AM David A. Wheeler 
wrote:

>
>
> > On Jun 5, 2023, at 8:48 AM, Thierry Arnoux 
> wrote:
> >
> > Yes, the PR has not been merged in yet, so until then you will need
> check my branch out.
> >
> > This feature required an "XML" library and I've kept it optional, so you
> will only be able to access it if the program is compiled with the "xml"
> feature, like so:
> >
> > cargo run --features xml -- ../set.mm/set.mm --time
> --export-graphml-deps deps.graphml
> >
> > Or
> >
> > cargo build --features xml
>
> I appreciate making it optional.
>
> Can you make it so the *default* is to include it, and then optionally
> exclude it?
> That way, people can use options to build it for special purposes, but the
> "out of the box" functionality has whatever people might like?
>
> --- David A. Wheeler
>
> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/03E6D2BE-FC76-4663-A563-9BE08D9DF2A1%40dwheeler.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSu4TttF50YBYg%3D1x5vwKde6vUcTm1BFLDb%3D_RUU0pxshA%40mail.gmail.com.


Re: [Metamath] How are typecodes used/enforced by the Metamath program?

2023-06-05 Thread Mario Carneiro
On Mon, Jun 5, 2023 at 1:43 AM Humanities Clinic 
wrote:

> Hihi, I have read most of Dr Megill/Wheeler's Metamath book, as well as
> most of the MPE pages, and I understand that typecodes are used to specify
> the type of a variable in $f statements.
>
> (1) How and when does Metamath ensure the types are "enforced"? When does
> it throw an error? (Oh, please do let me know which part of Dr
> Megill/Wheeler's book has the answer if I have missed it.)
>

Most theorem applications involve subproofs showing that the substitutions
are well typed. For example if you apply ax-mp, this has two main premises
|- ph and |- ( ph -> ps ), but also two syntax subproofs "wff ph" and "wff
ps". So you have to prove that your substitution is in fact a well formed
formula before you can apply it, and the $f hypotheses can be used as the
base case here - if your formula is a variable like "ch" then you can apply
wch $f wff ch $. to prove "wff ch".


> (2) Also, I know $e, $a, $p statements all have typecodes as well. Are
> their type codes enforced/used in the same way as $f statements?
>

Yes. Whenever you apply a hypothesis or theorem the typecode has to match
just like any other part of the statement.

(3) And, am I right to say that a type code can just be *any* constant? ie
> declared in $c statement?
>

Yes, there is no explicit declaration for typecodes, any constant symbol
can act like a typecode. (I regard this as somewhat unfortunate, and the
dialect of MM used by set.mm includes typecode declarations in the form of
"syntax" commands inside $j comments, like

syntax 'wff';
syntax '|-' for 'wff';

which say respectively that 'wff' is a syntax typecode and '|-' is a
logical typecode whose main argument is of type 'wff'. More information can
be found at https://github.com/metamath/set.mm/blob/develop/j-commands.html
.)

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSuXAiBQc6wvT7eR2Pmcfn-%2BkUY5gKbhFv1t56yG6xXaeg%40mail.gmail.com.


Re: [Metamath] How to Understand The "More Complicated" Expressions in Definitions

2023-05-31 Thread Mario Carneiro
The ∀푎 ∈ (Base‘푔) expression, or in ascii syntax "A. a e. (Base`g)" is
the beginning of the restricted forall quantifier "A. x e. A ph" where you
have highlighted just the "A. x e. A" part. It is read "for all x in A,
..." and denotes that some property "ph" holds for every x such that x e. A
holds. In this case, the property in question is the remainder of the
expression ∃푚 ∈ (Base‘푔)(푚(+g‘푔)푎) = (0g‘푔). In words, the expression
says this:

The class "Grp" is defined to be the set of all *g* in "Mnd" (i.e. *g*
being a monoid) such that for all *a* in the base set (carrier) of *g*,
there exists some *m* in the base set of *g* such that *m* + *a* = 0, where
+ and 0 are the monoid operations on *g*.

On Wed, May 31, 2023 at 7:46 PM Humanities Clinic <
humanitiescli...@gmail.com> wrote:

> Please pardon me for this rather basic question.
>
> I have read https://us.metamath.org/mpeuni/mmset.html, especially on the
> sections "The Axioms", "The Theory of Classes". I have basic knowledge on
> set theory and classical logic, so I understand all the black symbols in
> prepositional and predicate, but I still find it difficult to understand
> some expressions in definitions.
>
> For example, in https://us.metamath.org/mpeuni/df-grp.html:
>
> Grp = {푔 ∈ Mnd ∣ ∀푎 ∈ (Base‘푔)∃푚 ∈ (Base‘푔)(푚(+g‘푔)푎) = (0g‘푔)}
>
> I know that Mnd, Base, +g, 0g etc. are all classes. But I don't get what
> it means for ∀푎 ∈ (Base‘푔) to be next to  ∃푚 ∈ (Base‘푔)(푚(+g‘푔)푎)
> = (0g‘푔)
>
> What background knowledge am I still missing out which I should be
> reading, or did I miss out some material already on
> https://us.metamath.org/mpeuni/mmset.html? Please help me by pointing me
> to relevant reading material..
>
> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/ef11fbc4-7c45-42bd-a982-06b714fa9aecn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSsyni4-B%3DUjRE3V9sOoN9Xa6WWsRROaT3TC5ZZU4RzMZQ%40mail.gmail.com.


Re: [Metamath] Is set.mm available in a more "machine-readable" format other than in html?

2023-05-29 Thread Mario Carneiro
MM is already a "machine-readable" format, it is not much harder to parse
than JSON (depending on what kind of information you are interested in),
and you can even reasonably parse it with regexes, especially if you stick
to MM files with a standard layout like set.mm. Your query about graph file
formats suggest that you are interested in theorem references? If so, you
can get this information fairly easily from a regex, if you search for a
label followed by $p, some stuff, $=, and then a list of theorem references
inside parentheses.

On Mon, May 29, 2023 at 1:03 PM Humanities Clinic <
humanitiescli...@gmail.com> wrote:

> Is set.mm available in a more "machine-readable" format other than in
> html? For example, in json, or sql, or mayb in a graph database file like
> neo4j?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/9ef3a9e5-2510-4deb-9f17-6ab25ad533b5n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSvQt6D6xoufTE5%2BbvyKmfUVN0R0AZK0Ch_7qfLbR95Duw%40mail.gmail.com.


Re: [Metamath] metamath-lamp is impressive, check it out, and let's eventually modify the Metamath front page to mention it (at least)

2023-05-28 Thread Mario Carneiro
> Therefore there is a risk that official Metamath site suggests a tool
which performs not so good as it has to and nobody knows that.

I don't think this is a major concern, as long as we manage expectations on
the landing page. Metamath and all associated tools come with no warranty,
after all. I see no reason to wait for it to be perfect before making it
available for use, since anything is better than nothing and users can
always download another proof assistant if they decide the JS version isn't
great. (And BTW: this is the case almost every time I have seen a "we put
our theorem prover on the web" situation, the web prover is not actually
all that great and if you want to do "real work" you will eventually want
to download the tool and use it locally. But at that point the web version
has already satisfied its purpose as a gateway to heavier use. This is not
to say that you can't make the web prover as good or better than the
offline competitors, although even with a perfect implementation there are
some fundamental limitations regarding how files are read and written in a
web browser that make it not quite as good as native due to the sandboxing.)

On Sun, May 28, 2023 at 11:12 AM Igor Ieskov  wrote:

> I want to add few more things to consider before suggesting metamath-lamp
> as a proof assistant to start with in the first place. Not that I don't
> want a tool I am developing to be present on the front page of the official
> Metamath site :) But I think I have to mention what may be not so obvious
> from the technical point of view:
>
> This is a pretty new tool, I tested it on only simple proofs and use
> cases.  So far it worked well for me.   I do my best to cover complex
> functions with unit and integration tests. But without "testing in the
> field" I cannot assure that there are no bugs. And this is not a java
> application when if it works on developer's computer then most probably it
> will work on many other computers. It is JavaScript code running in a
> browser and risks of something may go wrong for other users is higher than
> in the case of a typical java application, for example.
>
> metamath-lamp runs completely in a browser so I will not know how often
> and how successfully it is used by others. Therefore there is a risk that
> official Metamath site suggests a tool which performs not so good as it has
> to and nobody knows that.
>
> -
> Igor
>
> On Sunday, May 28, 2023 at 11:19:01 AM UTC+2 Alexander van der Vekens
> wrote:
>
>> Hi Igor, hi David,
>> I think the current status of metamath-lamp is already very good, but not
>> good enough for a beginner. So there is room for some improvements
>> (especially regarding documentation, as indicated by David).
>> In any case, it is a good candidate to replace the Metamath Solitaire
>> Applet (does it actually work somewhere/somehow?) very soon. Maybe a
>> restriction of the scope (for beginners) could help: if only propositional
>> or predicate calculus (or ZF set theory) is used (this is a great
>> functionality of methamath-lamp to restrict the amount of set.mm to be
>> loaded and used. "Stop at exists2" would only load definitions and theorems
>> for propositional or predicate calculus, "Stop at hsmex3" for ZF set
>> theory), metamath-lamp may be fast and intuitive enough for a beginner.
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/8f557136-b1cc-4b7f-add7-1f0ed4275280n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJStVLrHNxZzVofHns5Tt7ymLX9LYmA%2BbgVKuSmBvJ_%3DWQw%40mail.gmail.com.


Re: [Metamath] eimm -i < test.mmp chokes on lines starting with * and !, also labels starting with d

2023-04-19 Thread Mario Carneiro
> I'm not sure how other people are using mmj2, and how they
export/import...

Ah, I just realized that you are talking about a subsystem of mmj2 which is
intended for export? If so it makes sense that it would be out of date,
because I am the mmj2 maintainer and I have never used or attempted to
figure out how to use that feature, so it has most likely bit-rot.

As for "how do people export/import from mmj2": for import, I make a stub
proof in set.mm including the full theorem statement, comments, etc, prove
it by ?, restart mmj2, and locate the theorem to work on it. For export,
when the proof is complete it prints a big block of text, and I copy that
block into the .mm file.

On Wed, Apr 19, 2023 at 11:51 AM Mario Carneiro  wrote:

> You can use the "Renumber" option in the menu of mmj2 to get rid of "d"
> and other alphabetic naming. The ! steps should also go away once you have
> proved the step, meaning that complete proofs will hopefully not have these
> things. * comments though are ubiquitous in mmj2 proof worksheets and I
> don't know any method other than manually removing them if they cause
> problems.
>
> But really, this all sounds like problems with eimm (which I don't know
> much about). Parsing the full syntax of mmj2-acceptable worksheets is a bit
> annoying because it is very forgiving of malformed steps, but I think it is
> reasonable to at least be able to support the kinds of worksheets that mmj2
> actually generates. I would assume that it is just an out of date parser,
> since mmj2 was not always capable of parsing alphabetic step names, and did
> not always put !, although it has put * as long as I can remember.
>
> Mario
>
> On Wed, Apr 19, 2023 at 8:49 AM LM  wrote:
>
>> I am probably doing something wrong, but when I try using eimm it doesn't
>> like the .mmp saved by mmj2.
>>
>> the labels are expected to be purely numeric, while the autogenerated
>> labels have a 'd' prefix.
>>
>> it also fails to ignore * comments
>>
>>
>> I'm not sure how other people are using mmj2, and how they
>> export/import...
>>
>> Greetings,
>> Ludwig
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Metamath" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to metamath+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/metamath/207d31b0-3426-4620-8d78-089967874e72n%40googlegroups.com
>> <https://groups.google.com/d/msgid/metamath/207d31b0-3426-4620-8d78-089967874e72n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSvBfmWzTz%3DHb0vdvARo2Rc1mAgdviQkSOFV8cZp0m3PUg%40mail.gmail.com.


Re: [Metamath] eimm -i < test.mmp chokes on lines starting with * and !, also labels starting with d

2023-04-19 Thread Mario Carneiro
You can use the "Renumber" option in the menu of mmj2 to get rid of "d" and
other alphabetic naming. The ! steps should also go away once you have
proved the step, meaning that complete proofs will hopefully not have these
things. * comments though are ubiquitous in mmj2 proof worksheets and I
don't know any method other than manually removing them if they cause
problems.

But really, this all sounds like problems with eimm (which I don't know
much about). Parsing the full syntax of mmj2-acceptable worksheets is a bit
annoying because it is very forgiving of malformed steps, but I think it is
reasonable to at least be able to support the kinds of worksheets that mmj2
actually generates. I would assume that it is just an out of date parser,
since mmj2 was not always capable of parsing alphabetic step names, and did
not always put !, although it has put * as long as I can remember.

Mario

On Wed, Apr 19, 2023 at 8:49 AM LM  wrote:

> I am probably doing something wrong, but when I try using eimm it doesn't
> like the .mmp saved by mmj2.
>
> the labels are expected to be purely numeric, while the autogenerated
> labels have a 'd' prefix.
>
> it also fails to ignore * comments
>
>
> I'm not sure how other people are using mmj2, and how they export/import...
>
> Greetings,
> Ludwig
>
> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/207d31b0-3426-4620-8d78-089967874e72n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSvOzrp7J4-mD1esEE-%2BVvQEyHfRr3k6PaO9V7MdcvtumQ%40mail.gmail.com.


Re: [Metamath] how to deduce a positive integer is a natural number? (slowly getting familiar with set.mm style)

2023-04-18 Thread Mario Carneiro
The most relevant theorem appears to be
https://us.metamath.org/mpeuni/elnnz1.html . In general, you should try to
look for biconditional statements as well, because we try to prove
biconditionals when possible, and instead rely on versions of modus ponens
that build in some kind of biconditional elimination to make them easy to
use. You would apply it using something like
https://us.metamath.org/mpeuni/sylibr.html or
https://us.metamath.org/mpeuni/sylanbrc.html .

On Tue, Apr 18, 2023 at 11:11 PM LM  wrote:

> what is most set.mm-fitting way to prove:
>
> ( ( A e. ZZ /\ 1 <_ A ) -> A e. NN )
>
> ?
>
> Grepping through set.mm I only find " e. NN " on antecedent side, never
> on consequent side.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/7a3251c5-87bd-4d95-9db0-6198cad47f43n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSsFZqgNo26-h_Qayc28SBj_7zSohkt%3DQ1maKupE6hT4dw%40mail.gmail.com.


Re: [Metamath] Reverse polish notation proofs from first principles exclusively

2023-04-05 Thread Mario Carneiro
IIRC metamath.exe has a mechanism to show the length of such a proof, but
not to calculate the proof itself. Note that these proofs get really
ridiculously long (I think you need bignum arithmetic just to determine how
many lines of proof there would be), so it's not practical outside toy
problems.

On Wed, Apr 5, 2023 at 8:29 PM Guram Mikaberidze <
guram.mikaberi...@gmail.com> wrote:

> I am wondering if there is a way to display full RPN proof of an assertion
> in set.mm without relying on any previously proved theorems. I would like
> instead to include the proofs of the used theorems in the final RPN, which
> would only reference the axioms.
>
> --Guga
>
> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/701e744f-a297-4ce4-94b5-66bf24b4991an%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSvXTAriwhD0Otmr-ewngctpna8b60LnaRQgjAuG_DcHaA%40mail.gmail.com.


Re: [Metamath] Re: mmj2 compact representation for $d statements

2023-04-02 Thread Mario Carneiro
The implementation in mmj2 is here:
https://github.com/digama0/mmj2/blob/master/src/mmj/lang/ScopeFrame.java#L154-L294

It does not use the same algorithm as mm-web-rs. I don't have any
particular insights regarding the theoretical properties of the mmj2
algorithm.

On Sun, Apr 2, 2023 at 9:59 PM Mario Carneiro  wrote:

> I recently implemented a variation on this algorithm for mm-web-rs:
> https://github.com/digama0/mm-web-rs/blob/master/src/render.rs#L1026-L1077
>
> As the function name suggests, the thing to google is "clique cover". It
> is an NP hard problem, but there are some okay approximations.
>
> On Sun, Apr 2, 2023 at 1:39 PM Benoit  wrote:
>
>> Did you try searching things like "search complete subgraphs" ?
>>
>> Benoît
>>
>> On Sunday, April 2, 2023 at 1:44:45 PM UTC+2 Glauco wrote:
>>
>>> What's the algorithm used by mmj2 to represent $d pairs as $d sets ?
>>>
>>> For instance, for a given theorem, with yamma I'm producing
>>>
>>> $d ph x $. $d k x $. $d k ph $. $d j x $. $d j k $.
>>> $d F x $. $d F k $. $d A x $. $d A k $. $d A j $.
>>>
>>> whereas mmj2 produces
>>>
>>> $d A j k x $. $d F k x $. $d k ph x $.
>>>
>>> (from 'visual' inspection, they actually represent the same relation)
>>>
>>> I've googled for 'compact representation of symmetric relations' and
>>> stuff like that, but no luck, so far.
>>>
>>> Can anybody point me in the right direction.
>>>
>>> Thanks in advance
>>> Glauco
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Metamath" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to metamath+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/metamath/3692a051-5119-481c-b21a-250c13f99a3dn%40googlegroups.com
>> <https://groups.google.com/d/msgid/metamath/3692a051-5119-481c-b21a-250c13f99a3dn%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSsUqHxiC6FXLGhRW1CLGCmta7zXdaFnD_PAFXJH98_Ghg%40mail.gmail.com.


Re: [Metamath] Re: mmj2 compact representation for $d statements

2023-04-02 Thread Mario Carneiro
I recently implemented a variation on this algorithm for mm-web-rs:
https://github.com/digama0/mm-web-rs/blob/master/src/render.rs#L1026-L1077

As the function name suggests, the thing to google is "clique cover". It is
an NP hard problem, but there are some okay approximations.

On Sun, Apr 2, 2023 at 1:39 PM Benoit  wrote:

> Did you try searching things like "search complete subgraphs" ?
>
> Benoît
>
> On Sunday, April 2, 2023 at 1:44:45 PM UTC+2 Glauco wrote:
>
>> What's the algorithm used by mmj2 to represent $d pairs as $d sets ?
>>
>> For instance, for a given theorem, with yamma I'm producing
>>
>> $d ph x $. $d k x $. $d k ph $. $d j x $. $d j k $.
>> $d F x $. $d F k $. $d A x $. $d A k $. $d A j $.
>>
>> whereas mmj2 produces
>>
>> $d A j k x $. $d F k x $. $d k ph x $.
>>
>> (from 'visual' inspection, they actually represent the same relation)
>>
>> I've googled for 'compact representation of symmetric relations' and
>> stuff like that, but no luck, so far.
>>
>> Can anybody point me in the right direction.
>>
>> Thanks in advance
>> Glauco
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/3692a051-5119-481c-b21a-250c13f99a3dn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSuiKrRYgMkExdnEtr1rawTxukfzZ-v%2BKoXfZYj3%2B%3DyUAA%40mail.gmail.com.


Re: [Metamath] Negative use cases database?

2023-03-10 Thread Mario Carneiro
The only source I am aware of is
https://github.com/david-a-wheeler/metamath-test and the metamath-exe test
suite (https://github.com/metamath/metamath-exe/tree/master/tests).
Collecting failing tests and serving as a unit test for new verifiers is
part of the stated purpose of the former repository, so perhaps that
answers your question.

On Fri, Mar 10, 2023 at 5:00 PM Samuel Goto  wrote:

> Hey all,
>
> I'm wondering: is there any chance anyone has built a list of proofs
> that are expected to fail to check verifiers?
>
> Context: as I'm trying to verify some of the disjoint variable
> restrictions, I'm finding that I'm missing a lot of corner cases I missed
> from the book/specification, and when I do, verifications succeeds rather
> than fails, and I have to manually catch those bugs. So, if I'm thinking
> that if had a list of proofs that have known bugs (for the $d statement
> specifically, but more generally too) that a valid verifier would
> successfully catch, I'd feel more comfortable knowing that I've captured
> known ways a proof is invalid.
>
> Anyone?
>
> Sam
>
> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/63400cee-5e0e-4b16-9c80-fc4ed8b430ddn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSvY-oggjiATKMa5Co7OukNb5nQSS3PUKp1wqytxFeLBsw%40mail.gmail.com.


Re: [Metamath] Metamatix

2023-03-10 Thread Mario Carneiro
The paper "models for metamath" (https://arxiv.org/abs/1601.07699) works
out the requirements for models of metamath databases. They tend to be
rather abstract as metamath is fairly logic-agnostic; you can get more
useful models if you add some axioms to make it more like FOL specifically.
If you are looking for just the formal definition of metamath provability,
the canonical reference is Appendix C of the metamath book (on which that
paper builds).

On Fri, Mar 10, 2023 at 4:59 PM Denis Carnier 
wrote:

> Hi all,
>
> How delightful to see our tiny project find its way onto your mailing
> list! I am one of the developers for Metamathix (Arthur Correnson <
> arthur.corren...@cispa.de> being the other). The project is at its
> infancy, but we already have a minimal implementation of a proof checker
> (without parsing/output) that we hope to prove correct with respect to a
> declarative specification or formal semantics for Metamath's underlying
> logic. To this end, if there already exists a reasonable model for Metamath
> then we'd love to hear about it. At present, we have proposed a reference
> logic and semantics, but we are rather unsure if they make sense.
>
> Looking forward to hearing your thoughts,
> Denis
> On Monday, February 27, 2023 at 10:58:04 AM UTC+1 Thierry Arnoux wrote:
>
>> Hi David,
>>
>> Feel free to add it!
>>
>>
>> On 26/02/2023 16:20, David A. Wheeler wrote:
>>
>> We have a list of Metamath tools on the website pages. Will you add it?
>> If not, let me know and I will add it, I just don't want to duplicate
>> effort.
>>
>> On February 25, 2023 3:26:02 PM EST, Thierry Arnoux 
>> wrote:
>>>
>>> Hi all,
>>>
>>> FYI, I recently found out about Metamatix
>>> , a verified implementation of
>>> a metamath proof checker, written in Coq.
>>>
>>> I'm not sure how far the project goes, but it's probably of interest for
>>> people in this group.
>>>
>>> BR,
>>> _
>>> Thierry
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Metamath" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to metamath+u...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/metamath/5DBFBC50-D236-4A71-9F55-82392C457A1A%40dwheeler.com
>> 
>> .
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/eaea1b13-6b52-4a1f-87a1-1f2d007d08dfn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSt8L-Mw__wLTedsrTEcBMAjebG1qZZHxC5fhcbfx36Dmw%40mail.gmail.com.


Re: [Metamath] mmj2 error js does not exist

2023-03-04 Thread Mario Carneiro
Oops, you already sent the result. This is the nashorn error, same as for
JDK 18+.

On Sat, Mar 4, 2023 at 3:18 AM Mario Carneiro  wrote:

> That's the expected error when you run mmj2.jar without any arguments. Try
> running the bash script now.
>
> On Sat, Mar 4, 2023 at 2:03 AM William Mitchell Jr 
> wrote:
>
>> after apt install openjdk-17-jre,
>>
>> java --version:
>> openjdk 17.0.6 2023-01-17
>> OpenJDK Runtime Environment (build 17.0.6+10-Debian-1)
>> OpenJDK 64-Bit Server VM (build 17.0.6+10-Debian-1, mixed mode, sharing)
>>
>> jar --version:
>> jar 21-ea
>>
>> output of mmj2/mmj2jar/mmj2:
>> https://pastebin.com/5Xgy1e0u
>>
>> output of java -jar mmj2/mmj2jar/mmj2.jar compiled and run with JDK 17:
>> CommandLineArguments.displayArgumentOptionReport():
>>
>> Hi! I am mmj2 v2.5.3 as of 23-Sep-2019.
>> Visit https://github.com/digama0/mmj2/ or
>> http://code.google.com/p/metamath-mmj2/
>> for support or bug reports.
>>
>>   Command Line Arguments:
>>
>>   [3] mmj2Path = null (e.g. /home/wdmjun/YourFile.xyz)
>>   [4] metamathPath = null (e.g. /home/wdmjun/YourFile.xyz)
>>   [5] svcPath  = null (e.g. /home/wdmjun/YourFile.xyz)
>>   [1] runParmFile  = null
>>   [2] displayMMJ2FailPopupWindow
>>= true
>>
>> ***END CommandLineArguments.displayArgumentOptionReport()***
>>
>> mmj.pa.ErrorCode@5ef04b5A-UT-0007 RunParmFile not found or
>> SecurityException. Input file name = null System message follows: null
>>
>> William
>> On Saturday, March 4, 2023 at 12:30:22 AM UTC-5 di@gmail.com wrote:
>>
>>> (FYI you have to pass arguments to the jar file if you don't want it to
>>> immediately quit with an error message, this is why the bash wrapper
>>> exists. But the missing .so error seems to happen first.) Googling this
>>> seems to suggest that your JDK 17 installation is broken, try reinstalling
>>> it. Does the indicated file
>>> "/usr/lib/jvm/java-17-openjdk-arm64/lib/libawt_xawt.so" exist?
>>>
>>> On Sat, Mar 4, 2023 at 12:26 AM William Mitchell Jr 
>>> wrote:
>>>
>>>> Oops.
>>>> Output of java -jar mmj2/mmj2jar/mmj2.jar compiled and run with JDK 17:
>>>>
>>>> CommandLineArguments.displayArgumentOptionReport():
>>>>
>>>> Hi! I am mmj2 v2.5.3 as of 23-Sep-2019.
>>>> Visit https://github.com/digama0/mmj2/ or
>>>> http://code.google.com/p/metamath-mmj2/
>>>> for support or bug reports.
>>>>
>>>>   Command Line Arguments:
>>>>
>>>>   [3] mmj2Path = null (e.g. /home/wdmjun/YourFile.xyz)
>>>>   [4] metamathPath = null (e.g. /home/wdmjun/YourFile.xyz)
>>>>   [5] svcPath  = null (e.g. /home/wdmjun/YourFile.xyz)
>>>>   [1] runParmFile  = null
>>>>   [2] displayMMJ2FailPopupWindow
>>>>= true
>>>>
>>>> ***END CommandLineArguments.displayArgumentOptionReport()***
>>>>
>>>> mmj.pa.ErrorCode@5ef04b5A-UT-0007 RunParmFile not found or
>>>> SecurityException. Input file name = null System message follows: null
>>>> Exception in thread "main" java.lang.UnsatisfiedLinkError: Can't load
>>>> library: /usr/lib/jvm/java-17-openjdk-arm64/lib/libawt_xawt.so
>>>> at
>>>> java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2393)
>>>> at java.base/java.lang.Runtime.load0(Runtime.java:755)
>>>> at java.base/java.lang.System.load(System.java:1953)
>>>> at java.base/jdk.internal.loader.NativeLibraries.load(Native
>>>> Method)
>>>> at
>>>> java.base/jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(NativeLibraries.java:388)
>>>> at
>>>> java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:232)
>>>> at
>>>> java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:174)
>>>> at
>>>> java.base/jdk.internal.loader.NativeLibraries.findFromPaths(NativeLibraries.java:315)
>>>> at
>>>> java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:285)
>>>> at
>>>> java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2398)
>>>> at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:

Re: [Metamath] mmj2 error js does not exist

2023-03-04 Thread Mario Carneiro
That's the expected error when you run mmj2.jar without any arguments. Try
running the bash script now.

On Sat, Mar 4, 2023 at 2:03 AM William Mitchell Jr  wrote:

> after apt install openjdk-17-jre,
>
> java --version:
> openjdk 17.0.6 2023-01-17
> OpenJDK Runtime Environment (build 17.0.6+10-Debian-1)
> OpenJDK 64-Bit Server VM (build 17.0.6+10-Debian-1, mixed mode, sharing)
>
> jar --version:
> jar 21-ea
>
> output of mmj2/mmj2jar/mmj2:
> https://pastebin.com/5Xgy1e0u
>
> output of java -jar mmj2/mmj2jar/mmj2.jar compiled and run with JDK 17:
> CommandLineArguments.displayArgumentOptionReport():
>
> Hi! I am mmj2 v2.5.3 as of 23-Sep-2019.
> Visit https://github.com/digama0/mmj2/ or
> http://code.google.com/p/metamath-mmj2/
> for support or bug reports.
>
>   Command Line Arguments:
>
>   [3] mmj2Path = null (e.g. /home/wdmjun/YourFile.xyz)
>   [4] metamathPath = null (e.g. /home/wdmjun/YourFile.xyz)
>   [5] svcPath  = null (e.g. /home/wdmjun/YourFile.xyz)
>   [1] runParmFile  = null
>   [2] displayMMJ2FailPopupWindow
>= true
>
> ***END CommandLineArguments.displayArgumentOptionReport()***
>
> mmj.pa.ErrorCode@5ef04b5A-UT-0007 RunParmFile not found or
> SecurityException. Input file name = null System message follows: null
>
> William
> On Saturday, March 4, 2023 at 12:30:22 AM UTC-5 di@gmail.com wrote:
>
>> (FYI you have to pass arguments to the jar file if you don't want it to
>> immediately quit with an error message, this is why the bash wrapper
>> exists. But the missing .so error seems to happen first.) Googling this
>> seems to suggest that your JDK 17 installation is broken, try reinstalling
>> it. Does the indicated file
>> "/usr/lib/jvm/java-17-openjdk-arm64/lib/libawt_xawt.so" exist?
>>
>> On Sat, Mar 4, 2023 at 12:26 AM William Mitchell Jr 
>> wrote:
>>
>>> Oops.
>>> Output of java -jar mmj2/mmj2jar/mmj2.jar compiled and run with JDK 17:
>>>
>>> CommandLineArguments.displayArgumentOptionReport():
>>>
>>> Hi! I am mmj2 v2.5.3 as of 23-Sep-2019.
>>> Visit https://github.com/digama0/mmj2/ or
>>> http://code.google.com/p/metamath-mmj2/
>>> for support or bug reports.
>>>
>>>   Command Line Arguments:
>>>
>>>   [3] mmj2Path = null (e.g. /home/wdmjun/YourFile.xyz)
>>>   [4] metamathPath = null (e.g. /home/wdmjun/YourFile.xyz)
>>>   [5] svcPath  = null (e.g. /home/wdmjun/YourFile.xyz)
>>>   [1] runParmFile  = null
>>>   [2] displayMMJ2FailPopupWindow
>>>= true
>>>
>>> ***END CommandLineArguments.displayArgumentOptionReport()***
>>>
>>> mmj.pa.ErrorCode@5ef04b5A-UT-0007 RunParmFile not found or
>>> SecurityException. Input file name = null System message follows: null
>>> Exception in thread "main" java.lang.UnsatisfiedLinkError: Can't load
>>> library: /usr/lib/jvm/java-17-openjdk-arm64/lib/libawt_xawt.so
>>> at
>>> java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2393)
>>> at java.base/java.lang.Runtime.load0(Runtime.java:755)
>>> at java.base/java.lang.System.load(System.java:1953)
>>> at java.base/jdk.internal.loader.NativeLibraries.load(Native
>>> Method)
>>> at
>>> java.base/jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(NativeLibraries.java:388)
>>> at
>>> java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:232)
>>> at
>>> java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:174)
>>> at
>>> java.base/jdk.internal.loader.NativeLibraries.findFromPaths(NativeLibraries.java:315)
>>> at
>>> java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:285)
>>> at
>>> java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2398)
>>> at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:818)
>>> at java.base/java.lang.System.loadLibrary(System.java:1989)
>>> at java.desktop/java.awt.Toolkit$2.run(Toolkit.java:1392)
>>> at java.desktop/java.awt.Toolkit$2.run(Toolkit.java:1390)
>>> at
>>> java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
>>> at java.desktop/java.awt.Toolkit.loadLibraries(Toolkit.java:1389)
>>> at java.desktop/java.awt.Toolkit.initStatic(Toolkit.java:1427)
>>> at java.desktop/java.awt.Toolkit.(Toolkit.java:1401)
>>> at java.desktop/java.awt.Color.(Color.java:277)
>>> at mmj.pa.PaConstants.(PaConstants.java:863)
>>> at
>>> mmj.pa.ProofAsstPreferences.(ProofAsstPreferences.java:339)
>>> at
>>> mmj.pa.ProofAsstPreferences.(ProofAsstPreferences.java:266)
>>> at mmj.pa.AuxFrameGUI.(AuxFrameGUI.java:61)
>>> at
>>> mmj.util.MMJ2FailPopupWindow.showAuxFrameGUI(MMJ2FailPopupWindow.java:229)
>>> at
>>> mmj.util.MMJ2FailPopupWindow.displayFailMessage(MMJ2FailPopupWindow.java:119)
>>> at mmj.util.BatchFramework.runIt(BatchFramework.java:243)
>>> at mmj.util.BatchMMJ2.main(BatchMMJ2.java:53)
>>>

Re: [Metamath] mmj2 error js does not exist

2023-03-03 Thread Mario Carneiro
(FYI you have to pass arguments to the jar file if you don't want it to
immediately quit with an error message, this is why the bash wrapper
exists. But the missing .so error seems to happen first.) Googling this
seems to suggest that your JDK 17 installation is broken, try reinstalling
it. Does the indicated file
"/usr/lib/jvm/java-17-openjdk-arm64/lib/libawt_xawt.so" exist?

On Sat, Mar 4, 2023 at 12:26 AM William Mitchell Jr 
wrote:

> Oops.
> Output of java -jar mmj2/mmj2jar/mmj2.jar compiled and run with JDK 17:
>
> CommandLineArguments.displayArgumentOptionReport():
>
> Hi! I am mmj2 v2.5.3 as of 23-Sep-2019.
> Visit https://github.com/digama0/mmj2/ or
> http://code.google.com/p/metamath-mmj2/
> for support or bug reports.
>
>   Command Line Arguments:
>
>   [3] mmj2Path = null (e.g. /home/wdmjun/YourFile.xyz)
>   [4] metamathPath = null (e.g. /home/wdmjun/YourFile.xyz)
>   [5] svcPath  = null (e.g. /home/wdmjun/YourFile.xyz)
>   [1] runParmFile  = null
>   [2] displayMMJ2FailPopupWindow
>= true
>
> ***END CommandLineArguments.displayArgumentOptionReport()***
>
> mmj.pa.ErrorCode@5ef04b5A-UT-0007 RunParmFile not found or
> SecurityException. Input file name = null System message follows: null
> Exception in thread "main" java.lang.UnsatisfiedLinkError: Can't load
> library: /usr/lib/jvm/java-17-openjdk-arm64/lib/libawt_xawt.so
> at
> java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2393)
> at java.base/java.lang.Runtime.load0(Runtime.java:755)
> at java.base/java.lang.System.load(System.java:1953)
> at java.base/jdk.internal.loader.NativeLibraries.load(Native
> Method)
> at
> java.base/jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(NativeLibraries.java:388)
> at
> java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:232)
> at
> java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:174)
> at
> java.base/jdk.internal.loader.NativeLibraries.findFromPaths(NativeLibraries.java:315)
> at
> java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:285)
> at
> java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2398)
> at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:818)
> at java.base/java.lang.System.loadLibrary(System.java:1989)
> at java.desktop/java.awt.Toolkit$2.run(Toolkit.java:1392)
> at java.desktop/java.awt.Toolkit$2.run(Toolkit.java:1390)
> at
> java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
> at java.desktop/java.awt.Toolkit.loadLibraries(Toolkit.java:1389)
> at java.desktop/java.awt.Toolkit.initStatic(Toolkit.java:1427)
> at java.desktop/java.awt.Toolkit.(Toolkit.java:1401)
> at java.desktop/java.awt.Color.(Color.java:277)
> at mmj.pa.PaConstants.(PaConstants.java:863)
> at
> mmj.pa.ProofAsstPreferences.(ProofAsstPreferences.java:339)
> at
> mmj.pa.ProofAsstPreferences.(ProofAsstPreferences.java:266)
> at mmj.pa.AuxFrameGUI.(AuxFrameGUI.java:61)
> at
> mmj.util.MMJ2FailPopupWindow.showAuxFrameGUI(MMJ2FailPopupWindow.java:229)
> at
> mmj.util.MMJ2FailPopupWindow.displayFailMessage(MMJ2FailPopupWindow.java:119)
> at mmj.util.BatchFramework.runIt(BatchFramework.java:243)
> at mmj.util.BatchMMJ2.main(BatchMMJ2.java:53)
>
> William
>
> On Friday, March 3, 2023 at 11:55:29 PM UTC-5 di@gmail.com wrote:
>
>> This is the same error as before, you need to compile the java files
>> using the same version as the one you use to run the jar file (in this case
>> JDK 17). Since you are switching between versions it is likely you forgot
>> to recompile and are using a class file from JDK 18+, as the error message
>> says.
>>
>> On Fri, Mar 3, 2023 at 11:46 PM William Mitchell Jr 
>> wrote:
>>
>>> java -jar mmj2/mmj2jar/mmj2.jar:
>>>
>>> Error: LinkageError occurred while loading main class mmj.util.BatchMMJ2
>>> java.lang.UnsupportedClassVersionError: mmj/util/BatchMMJ2 has
>>> been compiled by a more recent version of the Java Runtime (class file
>>> version 65.0), this version of the Java Runtime only recognizes class file
>>> versions up to 61.0
>>>
>>> William
>>> On Friday, March 3, 2023 at 11:25:01 PM UTC-5 di@gmail.com wrote:
>>>
 what is the regular output?

 On Fri, Mar 3, 2023 at 11:21 PM William Mitchell Jr 
 wrote:

> Here is the output of strace java -jar mmj2/mmj2jar/mmj2.jar:
>
> https://pastebin.com/eMMHSGLs
>
> William
> On Friday, March 3, 2023 at 10:26:40 PM UTC-5 di@gmail.com wrote:
>
>> The strace output is not very informative because mmj2/mmj2jar/mmj2
>> is actually a shell script which calls java. Most of what you can see is
>> just bash reading the script. You can call java directly if you want a 
>> more
>> useful 

Re: [Metamath] mmj2 error js does not exist

2023-03-03 Thread Mario Carneiro
This is the same error as before, you need to compile the java files using
the same version as the one you use to run the jar file (in this case JDK
17). Since you are switching between versions it is likely you forgot to
recompile and are using a class file from JDK 18+, as the error message
says.

On Fri, Mar 3, 2023 at 11:46 PM William Mitchell Jr 
wrote:

> java -jar mmj2/mmj2jar/mmj2.jar:
>
> Error: LinkageError occurred while loading main class mmj.util.BatchMMJ2
> java.lang.UnsupportedClassVersionError: mmj/util/BatchMMJ2 has
> been compiled by a more recent version of the Java Runtime (class file
> version 65.0), this version of the Java Runtime only recognizes class file
> versions up to 61.0
>
> William
> On Friday, March 3, 2023 at 11:25:01 PM UTC-5 di@gmail.com wrote:
>
>> what is the regular output?
>>
>> On Fri, Mar 3, 2023 at 11:21 PM William Mitchell Jr 
>> wrote:
>>
>>> Here is the output of strace java -jar mmj2/mmj2jar/mmj2.jar:
>>>
>>> https://pastebin.com/eMMHSGLs
>>>
>>> William
>>> On Friday, March 3, 2023 at 10:26:40 PM UTC-5 di@gmail.com wrote:
>>>
 The strace output is not very informative because mmj2/mmj2jar/mmj2 is
 actually a shell script which calls java. Most of what you can see is just
 bash reading the script. You can call java directly if you want a more
 useful trace.

 On Fri, Mar 3, 2023 at 9:40 PM William Mitchell Jr 
 wrote:

> Here is the output of strace mmj2/mmj2jar/mmj2 compiled and run under
> openjdk-17-jdk, Debian Sid, arm64, x11:
>
> https://pastebin.com/zcwgs2pc
>
> William
> On Friday, March 3, 2023 at 7:31:18 PM UTC-5 William Mitchell Jr wrote:
>
>> After git clone https://github.com/digama0/mmj2,
>>
>> Success: compile with openjdk-11-jdk and runtime openjdk-11-jdk.
>> Every other combination of compiling/runtime I have available fails.
>>
>> Here is the error message from compiling and running under
>> openjdk-17-jdk:
>>
>> Error: LinkageError occurred while loading main class
>> mmj.util.BatchMMJ2
>> java.lang.UnsupportedClassVersionError: mmj/util/BatchMMJ2
>> has been compiled by a more recent version of the Java Runtime (class 
>> file
>> version 65.0), this version of the Java Runtime only recognizes class 
>> file
>> versions up to 61.0
>>
>> William
>> On Friday, March 3, 2023 at 6:33:32 PM UTC-5 di@gmail.com wrote:
>>
>>> By the way, if you are thinking about modernizing mmj2 there are two
>>> known issues with newer versions of the JDK. One is the missing nashorn
>>> support as already mentioned, and the other is an issue in the undo 
>>> system
>>> which causes ComposedEdits to not work correctly (the required class
>>> doesn't exist on JDK 10+). It is being version-checked now so you 
>>> shouldn't
>>> get any build failures, but the user experience is that undo goes one
>>> character at a time which is pretty miserable. Maybe there is something 
>>> in
>>> newer versions of the JDK for this but I couldn't find anything useful 
>>> in
>>> JDK 10. That's why I recommend JDK 9 for most mmj2 users.
>>>
>>> On Fri, Mar 3, 2023 at 6:26 PM David Crisp 
>>> wrote:
>>>

 On Friday, 3 March 2023 at 22:41:54 UTC wdm...@gmail.com wrote:

 openjdk-11-jdk works on my system.

 Debian Sid
 arm64
 Java versions available to me: openjdk-8-jdk, openjdk-11-jdk,
 openjdk-17-jdk, openjdk-18-jdk, openjdk-19-jdk, openjdk-20-jdk,
 openjdk-21-jdk.

 openjdk-8-jdk: fails (error message posted below)
 openjdk-11-jdk: success
 openjdk-17-jdk: fails (error message posted below)
 openjdk-18-jdk through openjdk-21-jdk: fails (all with the same
 error message posted below)


  The issue with JDK8 is what Mario suggests, and the issues with
 JDK18+ are what I'd expect from missing Nashorn support, but 17 is a 
 weird
 one. I'd expect it to fail for the same reason as 18 (Nashorn was 
 removed
 in 14) but it looks like it's not even getting that far and is instead
 having trouble with loading the GUI libraries (libawt_xawt.so is the
 library that implements Java's low-level windowing functionality on 
 top of
 X11).

 I suspect this is an issue with your install of 17, but I don't
 currently have an ARM system available to me so I can't test it myself 
 with
 your exact setup - would you mind please trying to uninstall and 
 reinstall
 17 for me and seeing if you get the same stacktrace? If you do I'll 
 add it
 to my list of things to investigate once I start diving into the code 
 - 17
 is the most recent LTS version, so it's one 

Re: [Metamath] mmj2 error js does not exist

2023-03-03 Thread Mario Carneiro
what is the regular output?

On Fri, Mar 3, 2023 at 11:21 PM William Mitchell Jr 
wrote:

> Here is the output of strace java -jar mmj2/mmj2jar/mmj2.jar:
>
> https://pastebin.com/eMMHSGLs
>
> William
> On Friday, March 3, 2023 at 10:26:40 PM UTC-5 di@gmail.com wrote:
>
>> The strace output is not very informative because mmj2/mmj2jar/mmj2 is
>> actually a shell script which calls java. Most of what you can see is just
>> bash reading the script. You can call java directly if you want a more
>> useful trace.
>>
>> On Fri, Mar 3, 2023 at 9:40 PM William Mitchell Jr 
>> wrote:
>>
>>> Here is the output of strace mmj2/mmj2jar/mmj2 compiled and run under
>>> openjdk-17-jdk, Debian Sid, arm64, x11:
>>>
>>> https://pastebin.com/zcwgs2pc
>>>
>>> William
>>> On Friday, March 3, 2023 at 7:31:18 PM UTC-5 William Mitchell Jr wrote:
>>>
 After git clone https://github.com/digama0/mmj2,

 Success: compile with openjdk-11-jdk and runtime openjdk-11-jdk.
 Every other combination of compiling/runtime I have available fails.

 Here is the error message from compiling and running under
 openjdk-17-jdk:

 Error: LinkageError occurred while loading main class mmj.util.BatchMMJ2
 java.lang.UnsupportedClassVersionError: mmj/util/BatchMMJ2 has
 been compiled by a more recent version of the Java Runtime (class file
 version 65.0), this version of the Java Runtime only recognizes class file
 versions up to 61.0

 William
 On Friday, March 3, 2023 at 6:33:32 PM UTC-5 di@gmail.com wrote:

> By the way, if you are thinking about modernizing mmj2 there are two
> known issues with newer versions of the JDK. One is the missing nashorn
> support as already mentioned, and the other is an issue in the undo system
> which causes ComposedEdits to not work correctly (the required class
> doesn't exist on JDK 10+). It is being version-checked now so you 
> shouldn't
> get any build failures, but the user experience is that undo goes one
> character at a time which is pretty miserable. Maybe there is something in
> newer versions of the JDK for this but I couldn't find anything useful in
> JDK 10. That's why I recommend JDK 9 for most mmj2 users.
>
> On Fri, Mar 3, 2023 at 6:26 PM David Crisp 
> wrote:
>
>>
>> On Friday, 3 March 2023 at 22:41:54 UTC wdm...@gmail.com wrote:
>>
>> openjdk-11-jdk works on my system.
>>
>> Debian Sid
>> arm64
>> Java versions available to me: openjdk-8-jdk, openjdk-11-jdk,
>> openjdk-17-jdk, openjdk-18-jdk, openjdk-19-jdk, openjdk-20-jdk,
>> openjdk-21-jdk.
>>
>> openjdk-8-jdk: fails (error message posted below)
>> openjdk-11-jdk: success
>> openjdk-17-jdk: fails (error message posted below)
>> openjdk-18-jdk through openjdk-21-jdk: fails (all with the same error
>> message posted below)
>>
>>
>>  The issue with JDK8 is what Mario suggests, and the issues with
>> JDK18+ are what I'd expect from missing Nashorn support, but 17 is a 
>> weird
>> one. I'd expect it to fail for the same reason as 18 (Nashorn was removed
>> in 14) but it looks like it's not even getting that far and is instead
>> having trouble with loading the GUI libraries (libawt_xawt.so is the
>> library that implements Java's low-level windowing functionality on top 
>> of
>> X11).
>>
>> I suspect this is an issue with your install of 17, but I don't
>> currently have an ARM system available to me so I can't test it myself 
>> with
>> your exact setup - would you mind please trying to uninstall and 
>> reinstall
>> 17 for me and seeing if you get the same stacktrace? If you do I'll add 
>> it
>> to my list of things to investigate once I start diving into the code - 
>> 17
>> is the most recent LTS version, so it's one that we really want mmj2 to
>> work with if at all possible.
>>
>> Thanks
>>
>> Dave
>>
>> --
>>
> You received this message because you are subscribed to the Google
>> Groups "Metamath" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to metamath+u...@googlegroups.com.
>>
> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/metamath/ba2288fa-9f13-4d50-8334-cc6fc361e117n%40googlegroups.com
>> 
>> .
>>
> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Metamath" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to metamath+u...@googlegroups.com.
>>>
>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/metamath/eefc22b1-5a98-4509-8bd9-bba24f410af2n%40googlegroups.com

Re: [Metamath] mmj2 error js does not exist

2023-03-03 Thread Mario Carneiro
The strace output is not very informative because mmj2/mmj2jar/mmj2 is
actually a shell script which calls java. Most of what you can see is just
bash reading the script. You can call java directly if you want a more
useful trace.

On Fri, Mar 3, 2023 at 9:40 PM William Mitchell Jr  wrote:

> Here is the output of strace mmj2/mmj2jar/mmj2 compiled and run under
> openjdk-17-jdk, Debian Sid, arm64, x11:
>
> https://pastebin.com/zcwgs2pc
>
> William
> On Friday, March 3, 2023 at 7:31:18 PM UTC-5 William Mitchell Jr wrote:
>
>> After git clone https://github.com/digama0/mmj2,
>>
>> Success: compile with openjdk-11-jdk and runtime openjdk-11-jdk.
>> Every other combination of compiling/runtime I have available fails.
>>
>> Here is the error message from compiling and running under openjdk-17-jdk:
>>
>> Error: LinkageError occurred while loading main class mmj.util.BatchMMJ2
>> java.lang.UnsupportedClassVersionError: mmj/util/BatchMMJ2 has
>> been compiled by a more recent version of the Java Runtime (class file
>> version 65.0), this version of the Java Runtime only recognizes class file
>> versions up to 61.0
>>
>> William
>> On Friday, March 3, 2023 at 6:33:32 PM UTC-5 di@gmail.com wrote:
>>
>>> By the way, if you are thinking about modernizing mmj2 there are two
>>> known issues with newer versions of the JDK. One is the missing nashorn
>>> support as already mentioned, and the other is an issue in the undo system
>>> which causes ComposedEdits to not work correctly (the required class
>>> doesn't exist on JDK 10+). It is being version-checked now so you shouldn't
>>> get any build failures, but the user experience is that undo goes one
>>> character at a time which is pretty miserable. Maybe there is something in
>>> newer versions of the JDK for this but I couldn't find anything useful in
>>> JDK 10. That's why I recommend JDK 9 for most mmj2 users.
>>>
>>> On Fri, Mar 3, 2023 at 6:26 PM David Crisp  wrote:
>>>

 On Friday, 3 March 2023 at 22:41:54 UTC wdm...@gmail.com wrote:

 openjdk-11-jdk works on my system.

 Debian Sid
 arm64
 Java versions available to me: openjdk-8-jdk, openjdk-11-jdk,
 openjdk-17-jdk, openjdk-18-jdk, openjdk-19-jdk, openjdk-20-jdk,
 openjdk-21-jdk.

 openjdk-8-jdk: fails (error message posted below)
 openjdk-11-jdk: success
 openjdk-17-jdk: fails (error message posted below)
 openjdk-18-jdk through openjdk-21-jdk: fails (all with the same error
 message posted below)


  The issue with JDK8 is what Mario suggests, and the issues with JDK18+
 are what I'd expect from missing Nashorn support, but 17 is a weird one.
 I'd expect it to fail for the same reason as 18 (Nashorn was removed in 14)
 but it looks like it's not even getting that far and is instead having
 trouble with loading the GUI libraries (libawt_xawt.so is the library that
 implements Java's low-level windowing functionality on top of X11).

 I suspect this is an issue with your install of 17, but I don't
 currently have an ARM system available to me so I can't test it myself with
 your exact setup - would you mind please trying to uninstall and reinstall
 17 for me and seeing if you get the same stacktrace? If you do I'll add it
 to my list of things to investigate once I start diving into the code - 17
 is the most recent LTS version, so it's one that we really want mmj2 to
 work with if at all possible.

 Thanks

 Dave

 --

>>> You received this message because you are subscribed to the Google
 Groups "Metamath" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to metamath+u...@googlegroups.com.

>>> To view this discussion on the web visit
 https://groups.google.com/d/msgid/metamath/ba2288fa-9f13-4d50-8334-cc6fc361e117n%40googlegroups.com
 
 .

>>> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/eefc22b1-5a98-4509-8bd9-bba24f410af2n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSv4yXbkbhZKbyr8W2RYF1CD2kCa4-1DfdpHafBGRE%3D5kg%40mail.gmail.com.


Re: [Metamath] mmj2 error js does not exist

2023-03-03 Thread Mario Carneiro
By the way, if you are thinking about modernizing mmj2 there are two known
issues with newer versions of the JDK. One is the missing nashorn support
as already mentioned, and the other is an issue in the undo system which
causes ComposedEdits to not work correctly (the required class doesn't
exist on JDK 10+). It is being version-checked now so you shouldn't get any
build failures, but the user experience is that undo goes one character at
a time which is pretty miserable. Maybe there is something in newer
versions of the JDK for this but I couldn't find anything useful in JDK 10.
That's why I recommend JDK 9 for most mmj2 users.

On Fri, Mar 3, 2023 at 6:26 PM David Crisp  wrote:

>
> On Friday, 3 March 2023 at 22:41:54 UTC wdm...@gmail.com wrote:
>
> openjdk-11-jdk works on my system.
>
> Debian Sid
> arm64
> Java versions available to me: openjdk-8-jdk, openjdk-11-jdk,
> openjdk-17-jdk, openjdk-18-jdk, openjdk-19-jdk, openjdk-20-jdk,
> openjdk-21-jdk.
>
> openjdk-8-jdk: fails (error message posted below)
> openjdk-11-jdk: success
> openjdk-17-jdk: fails (error message posted below)
> openjdk-18-jdk through openjdk-21-jdk: fails (all with the same error
> message posted below)
>
>
>  The issue with JDK8 is what Mario suggests, and the issues with JDK18+
> are what I'd expect from missing Nashorn support, but 17 is a weird one.
> I'd expect it to fail for the same reason as 18 (Nashorn was removed in 14)
> but it looks like it's not even getting that far and is instead having
> trouble with loading the GUI libraries (libawt_xawt.so is the library that
> implements Java's low-level windowing functionality on top of X11).
>
> I suspect this is an issue with your install of 17, but I don't currently
> have an ARM system available to me so I can't test it myself with your
> exact setup - would you mind please trying to uninstall and reinstall 17
> for me and seeing if you get the same stacktrace? If you do I'll add it to
> my list of things to investigate once I start diving into the code - 17 is
> the most recent LTS version, so it's one that we really want mmj2 to work
> with if at all possible.
>
> Thanks
>
> Dave
>
> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/ba2288fa-9f13-4d50-8334-cc6fc361e117n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSvWNeBtAda3knUeKKxJwMBz11MbyPj2vUOYyCBx%2BW1%2Bng%40mail.gmail.com.


Re: [Metamath] mmj2 error js does not exist

2023-03-03 Thread Mario Carneiro
On Fri, Mar 3, 2023 at 5:41 PM William Mitchell Jr  wrote:

> openjdk-8-jdk:
> Error: A JNI error has occurred, please check your installation and try
> again
> Exception in thread "main" java.lang.UnsupportedClassVersionError:
> mmj/util/BatchFramework has been compiled by a more recent version of the
> Java Runtime (class file version 55.0), this version of the Java Runtime
> only recognizes class file versions up to 52.0
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:756)
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:473)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:756)
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:473)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
> at
> sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:601)
>

This seems like a strange error, it sounds like you attempted to use a jar
compiled by a newer version of the JDK. If you switch to an older version
than the one used by the pre-built .jar file, you will need to recompile
the .jar file from the sources. (You might still have trouble, but I think
JDK 8 should work. An expected error for using a too-old version would be
something like not recognizing lambda functions or a class from the
standard library.)

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSvb3Vrt-kid_jx6N7kvXm9zuSMkzT9vO5C5UAPgZzCE-g%40mail.gmail.com.


Re: [Metamath] mmj2 error js does not exist

2023-03-03 Thread Mario Carneiro
I'm fine with this (and Mel is no longer active). I haven't done any Java
work for the past 5 years or so beyond basic maintenance, so if you have a
better idea of how to make stuff run on the new hotness then be my guest.

On Fri, Mar 3, 2023 at 2:24 PM David Crisp  wrote:

>
> If this is likely to be an issue going forward would it be a good idea to
> mavenize/gradleize the mmj2 build process so that the standalone version of
> nashorn-core (
> https://mvnrepository.com/artifact/org.openjdk.nashorn/nashorn-core) gets
> auto-downloaded and incorporated into the Jar file? It would increase the
> size of the jar somewhat but would at least ensure that the program isn't
> dependent on an antique version of Java? Although jdk8 is still technically
> under LTS it's no longer recommended for production use and anything modern
> should really be targeting jdk11+, if not jdk17.
>
> I'm a Java guy and have some time off work coming up later this month, if
> Mel and Mario are okay with it I'd at least be willing to spend a day
> looking at the repo to see how much work it would be likely to be.
>
> DC
> On Thursday, 2 March 2023 at 22:38:49 UTC David A. Wheeler wrote:
>
>>
>>
>> > On Mar 2, 2023, at 4:36 PM, Mario Carneiro  wrote:
>> >
>> > It sounds like the nashorn JS engine was removed from a later version
>> of JDK, and the empty list following the prompt suggests there is no
>> replacement. Without it you won't be able to run any macros, although you
>> might be able to install it manually? The easiest thing to do is probably
>> just to downgrade to JDK 9.
>>
>> Ah, of course! I should have noticed the openjdk version more carefully.
>>
>> Oracle has long warned that they'd stop supporting JavaScript from Java
>> using the Nashorn JS engine, but mmj2 depends on it.
>>
>> --- David A. Wheeler
>>
>>
>> >
>> > On Thu, Mar 2, 2023 at 3:53 PM David A. Wheeler 
>> wrote:
>> >
>> >
>> > > On Mar 2, 2023, at 3:23 AM, William Mitchell Jr 
>> wrote:
>> > >
>> > > running mmj2 in the mmj2jar directory produced this error:
>> > >
>> > > mmj.pa.MMJException: E-UT-1502 You attempted to use a macro, but the
>> default Macro language 'js' does not exist. Use 'MacroLanguage,xxx' with
>> one of the following installed languages:
>> > >
>> > > This is the git version (uncompiled) running on
>> > > arm64
>> > > Debian Linux
>> > > openjdk-18
>> >
>> > Weird. I have no idea what's going on. Anyone else?
>> >
>> > --- David A. Wheeler
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups "Metamath" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an email to metamath+u...@googlegroups.com.
>> > To view this discussion on the web visit
>> https://groups.google.com/d/msgid/metamath/CCC54F28-92E6-4C7D-B8EF-1A993DB50449%40dwheeler.com.
>>
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups "Metamath" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an email to metamath+u...@googlegroups.com.
>> > To view this discussion on the web visit
>> https://groups.google.com/d/msgid/metamath/CAFXXJSsoTbBby4QCy6zh-JEF%2B3qM80bSASPLJ4zk9RkA4%2B1C%2Bw%40mail.gmail.com.
>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/4d1ba8e0-5a86-416f-b554-6fb16484c17cn%40googlegroups.com
> <https://groups.google.com/d/msgid/metamath/4d1ba8e0-5a86-416f-b554-6fb16484c17cn%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSs3ONJ8Lwje80JU2sywFnacrqMkZwME7wMTmOj1qzMavg%40mail.gmail.com.


Re: [Metamath] Future website directions

2023-03-02 Thread Mario Carneiro
On Thu, Mar 2, 2023 at 5:37 PM David A. Wheeler 
wrote:

>
>
> > On Thu, Mar 2, 2023 at 12:53 PM David A. Wheeler 
> wrote:
> > 2. The text just runs off to the right, instead of going over multiple
> lines, making long ones unreadable. That's important but easy for the
> non-MathML case (just a little CSS), though I don't know how hard that is
> for MathML/MathJax.
> >
> > On Mar 2, 2023, at 4:33 PM, Mario Carneiro  wrote:
> > This is a pretty fundamental problem with MathJax style displays, and I
> don't have a good solution. LaTeX generally isn't great about automatic
> line breaking inside mathematics, but metamath routinely involves very
> large formulas, so although this looks good for the mid-sized examples the
> large ones really suffer. A related issue is that mathjax isn't really able
> to cope with having thousands of large and complex formulas on a page and
> the CPU time / draw time really spikes on some of the examples. For MM0 I'm
> planning to mostly just sidestep this issue by using ASCII-first displays,
> perhaps using unicode or programming fonts with ligatures but not much
> more. That way line breaking is limited to just pretty printing which can
> feasibly be written with a handcrafted JS library.
>
> That makes sense. I don't *object* to beautiful presentations, but if
> that's unsolved, we could generally prefer pointing to the Unicode versions
> (where long formulas are easily handled).
>
> MathJax is well aware of the need for automatic line breaking. They hope
> to have s version 3 that resolves it:
> https://docs.mathjax.org/en/latest/output/linebreaks.html
>
> https://stackoverflow.com/questions/40628064/mathjax-automatic-line-breaking-when-resizing
> ... I'm fine with letting them solve the problem & we use their solution.
> I don't know when they'll actually do that (if ever).
>
> >
> > 3. I think it's important we support existing URLs. That's easy with
> pregeneration, just rename to taste. If this is dynamically generated, that
> would require some changes to support the .html endings *and* support
> returning static pages.
> >
> > I don't think this will be difficult no matter what we do, since we can
> set up all the necessary routing in nginx.
>
> Not *difficult*, but some are harder than others if we *dynamically*
> generate.
> In nginx you would typically specify a location pattern as a parameter,
> and if it matches,
> call a program (e.g., using fastcgi). Here's an example:
> https://www.nginx.com/resources/wiki/start/topics/examples/fastcgiexample/
>
> You'd *like* to have the web server directly serve static files (they're
> good at that!),
> but currently directories like "mpeuni" have a lot of files, some of which
> might be dynamically generated
> while others are probably statically generated. Typical websites put them
> in separate directories,
> to make it easy to tell them apart.
>

I'm fairly sure there is a way to set up an nginx config to do essentially
the following:

* On a request to /mpeuni/X.html:
  * If /var/www/mpeuni/X.html exists, serve that
  * Otherwise, call 'web-page-generator /mpeuni/X.html', save the result as
/var/www/mpeuni/X.html (assuming it is not a 404) and serve it

If they're all dynamically generated via the same program, or all
> statically generated, then that's moot.
>

In this case 'web-page-generator' doesn't exactly have to be a single
program, it can be a shell script or shim which calls out to multiple
actual tools. It's basically another server behind the server, with nginx
acting as a cache for it. It could handle a fairly wide range of different
endpoints, including a mix of static and dynamic stuff. (Probably nginx can
handle the static stuff though, assuming the relevant URLs can be easily
described with globs.)


> > I think the variable coloring heuristic uses some hard-coded typecode
> names so it is not suitable for general databases; there are actually quite
> a few aspects of the web site generator that are tailored for set.mm
> which should probably use $t commands instead.
>
> We could start with hard-coding, then move towards supporting a general
> form.
> I agree that in the long term we want to be general.
>
> I suspect type code coloring primarily useful to new users... but since we
> *do* want to new users/readers, that's still relevant. We could even add it
> later, but it also doesn't seem *that* hard to implement (at least
> hard-coded).
>

Random coloring is another option to get an ok overall look (where the seed
is something tied to the database itself or the typecode names so that it
is stable enough for people to be able to use it as a consistent visual),
or something based on the same rainbow spectrum used for the label numbers.

Re: [Metamath] mmj2 error js does not exist

2023-03-02 Thread Mario Carneiro
It sounds like the nashorn JS engine was removed from a later version of
JDK, and the empty list following the prompt suggests there is no
replacement. Without it you won't be able to run any macros, although you
might be able to install it manually? The easiest thing to do is probably
just to downgrade to JDK 9.

On Thu, Mar 2, 2023 at 3:53 PM David A. Wheeler 
wrote:

>
>
> > On Mar 2, 2023, at 3:23 AM, William Mitchell Jr 
> wrote:
> >
> > running mmj2 in the mmj2jar directory produced this error:
> >
> > mmj.pa.MMJException: E-UT-1502 You attempted to use a macro, but the
> default Macro language 'js' does not exist. Use 'MacroLanguage,xxx' with
> one of the following installed languages:
> >
> > This is the git version (uncompiled) running on
> > arm64
> > Debian Linux
> > openjdk-18
>
> Weird. I have no idea what's going on. Anyone else?
>
> --- David A. Wheeler
>
> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/CCC54F28-92E6-4C7D-B8EF-1A993DB50449%40dwheeler.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSsoTbBby4QCy6zh-JEF%2B3qM80bSASPLJ4zk9RkA4%2B1C%2Bw%40mail.gmail.com.


Re: [Metamath] Future website directions

2023-03-02 Thread Mario Carneiro
On Thu, Mar 2, 2023 at 12:53 PM David A. Wheeler 
wrote:

> 2. The text just runs off to the right, instead of going over multiple
> lines, making long ones unreadable. That's important but easy for the
> non-MathML case (just a little CSS), though I don't know how hard that is
> for MathML/MathJax.
>

This is a pretty fundamental problem with MathJax style displays, and I
don't have a good solution. LaTeX generally isn't great about automatic
line breaking inside mathematics, but metamath routinely involves very
large formulas, so although this looks good for the mid-sized examples the
large ones really suffer. A related issue is that mathjax isn't really able
to cope with having thousands of large and complex formulas on a page and
the CPU time / draw time really spikes on some of the examples. For MM0 I'm
planning to mostly just sidestep this issue by using ASCII-first displays,
perhaps using unicode or programming fonts with ligatures but not much
more. That way line breaking is limited to just pretty printing which can
feasibly be written with a handcrafted JS library.


> 3. I think it's important we support existing URLs. That's easy with
> pregeneration, just rename to taste. If this is dynamically generated, that
> would require some changes to support the .html endings *and* support
> returning static pages.
>

I don't think this will be difficult no matter what we do, since we can set
up all the necessary routing in nginx. I am not above potentially making
mpegif redirect to mpeuni though (or a future URL scheme), or serving only
dynamic pages for deprecated formats. I think we should try to make
https://us.metamath.org/mpeuni/areacirc.html link to a theorem about the
area of a circle in perpetuity but not necessarily serving exactly the same
HTML as it does today.


> 4. This one omits many of the capabilities of the metamath-exe generator,
> e.g., compare with . That
> includes:
>   Distinct variable group:   푥,푦,푅
>   Allowed substitution hints:   푆(푥,푦)
>   Colors of variables (off, setvar, class) ... this one isn't as important
> to me & would be a lot of work, so I'm not fussy there.
>   Syntax hints (with links to them)
>   List of axioms used (with links)
>   List of definitions used (with links)
>   List of theorems that reference it (with links)
>

By the way (and I realize this wasn't directed at both tools), mm-web-rs
was designed explicitly as a carbon copy replacement for metamath-exe
generation, and supports all of these things. (Thierry's generator as I
understand it is more of an exploration of what we could have if we break
with the traditional format.) IIRC if you open them in a browser side by
side the result is identical except for distinct variable groups, which use
a different (arguably better) heuristic for collecting $d pairs into
cliques. (Exact clique cover is an NP hard problem, though, so some amount
of approximation is required.) I think the variable coloring heuristic uses
some hard-coded typecode names so it is not suitable for general databases;
there are actually quite a few aspects of the web site generator that are
tailored for set.mm which should probably use $t commands instead.

I would link an example here, but I'm not sure where to host it. On that
note, we might consider a place on the main website for experimental stuff
now that us2 is down. Do you know if there is a spot which already works
for this? I'm thinking of some place where it is safe to just drop files
and have them persisted across website builds, with a URL that implies that
they may go offline at any time.

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSuQVq2bW3G8uqoAXcpZhE8_jrdGi0meL_zgPKsH%3DCUcKw%40mail.gmail.com.


Re: [Metamath] Future website directions

2023-02-26 Thread Mario Carneiro
FYI I did a fairly comprehensive HTML modernization in mm-web-rs [
https://github.com/digama0/mm-web-rs/blob/master/src/render.rs] (which is
basically a clone of the metamath-exe theorem page generator), which among
other things lowercased all the tags and made it pass the w3c validator
again (there is a link at the bottom of most pages but they don't pass more
modern HTML standards and still use things like ).

On Sun, Feb 26, 2023 at 11:52 AM David A. Wheeler 
wrote:

> I completely agree, a page on AI/ML would be great. The pages could do
> with a refresh anyway, many places suggest contacting Norm.
>
> Norm used an HTML 1.0 convention of using uppercase tags. I suggest that
> new text use lowercase tags as a style choice
> It doesn't matter technically, but it is the current convention, and it
> would make it easier to see which parts are unchanged.
>
> On February 25, 2023 5:33:02 PM EST, Mario Carneiro 
> wrote:
>>
>> A page with short descriptions of papers and projects using Metamath for
>> AI would be great to put on the website. I think it would be good publicity
>> for both metamath and the AI systems, and maybe we can solicit the paper
>> authors to write the descriptions and provide related links as well.
>>
>> On Sat, Feb 25, 2023 at 5:27 PM Jon P  wrote:
>>
>>> Re the subject of LLMs being trained on metamath this new model called
>>> LLama from facebook is interesting. It seems to be smaller than other
>>> systems and it looks like they're already training on metamath.
>>>
>>> https://ai.facebook.com/blog/large-language-model-llama-meta-ai/
>>>
>>> It links to this page and this paper which talk about the matheamtical
>>> aspects
>>>
>>> https://ai.facebook.com/blog/ai-math-theorem-proving/
>>>
>>> https://arxiv.org/abs/2205.11491
>>>
>>> It's interesting they talk about the "metamath benchmark". Maybe one
>>> approach is to take that and have a page which presents the metamath
>>> database for training (kind of like the .txt files or json or whatever is
>>> preferred) and then has some notes about the papers that have already been
>>> published about it (gpt-f, LLama) and their results. Might be interesting.
>>>
>>> On Sunday, February 19, 2023 at 10:39:55 PM UTC David A. Wheeler wrote:
>>>
>>>>
>>>> > On Sun, Feb 19, 2023 at 2:19 PM David A. Wheeler <
>>>> dwhe...@dwheeler.com> wrote:
>>>> > My first choice when building a website, where it's easily achieved,
>>>> is static rendering (statically-generated pages) where the most important
>>>> data is visible without client-side JavaScript. Those are easily
>>>> understood, incredibly hard to attack, trivial to configure, trivial to
>>>> mirror, support security/privacy-conscious users, etc. Some sites *cannot*
>>>> be developed this way, of course!! But using that as the "starting point"
>>>> helps clarify "what else do you need?" - that is, it forces a discussion of
>>>> "what are the unspoken requirements?". It's also where we are in the
>>>> metamath site.
>>>> >
>>>> > With pre-rendering as a replacement for dynamic server side stuff, we
>>>> can still do most of the things. For example we could prerender all the
>>>> json queries and use client side JS to request them when doing cross
>>>> linking stuff. This is only made difficult if the set of all queries is
>>>> infinite, for example if we can do a search query.
>>>>
>>>>
>>>> > On Feb 19, 2023, at 3:13 PM, Mario Carneiro 
>>>> wrote:
>>>> > The main advantages of dynamic rendering are:
>>>> > (1) quicker turnaround time, e.g. if we want to hastily put up a
>>>> mm100 theorem on the website;
>>>> > (2) faster iteration - it is possible to make changes to the server
>>>> and see the results ~immediately;
>>>> > (3) lower storage cost, since we won't have to generate all the HTML
>>>> for the web site in advance and just cache important stuff (I assume that
>>>> most of the work going into the website build is wasted, since no one looks
>>>> at that page before it is next regenerated);
>>>> > (4) the ability to have many more rendering styles (unicode, gif,
>>>> text, latex, mathml, json have all been considered and more are possible)
>>>> and more databases, which is a combinatorial problem for the website build
>>>> lim

Re: [Metamath] Future website directions

2023-02-25 Thread Mario Carneiro
A page with short descriptions of papers and projects using Metamath for AI
would be great to put on the website. I think it would be good publicity
for both metamath and the AI systems, and maybe we can solicit the paper
authors to write the descriptions and provide related links as well.

On Sat, Feb 25, 2023 at 5:27 PM Jon P  wrote:

> Re the subject of LLMs being trained on metamath this new model called
> LLama from facebook is interesting. It seems to be smaller than other
> systems and it looks like they're already training on metamath.
>
> https://ai.facebook.com/blog/large-language-model-llama-meta-ai/
>
> It links to this page and this paper which talk about the matheamtical
> aspects
>
> https://ai.facebook.com/blog/ai-math-theorem-proving/
>
> https://arxiv.org/abs/2205.11491
>
> It's interesting they talk about the "metamath benchmark". Maybe one
> approach is to take that and have a page which presents the metamath
> database for training (kind of like the .txt files or json or whatever is
> preferred) and then has some notes about the papers that have already been
> published about it (gpt-f, LLama) and their results. Might be interesting.
>
> On Sunday, February 19, 2023 at 10:39:55 PM UTC David A. Wheeler wrote:
>
>>
>> > On Sun, Feb 19, 2023 at 2:19 PM David A. Wheeler 
>> wrote:
>> > My first choice when building a website, where it's easily achieved, is
>> static rendering (statically-generated pages) where the most important data
>> is visible without client-side JavaScript. Those are easily understood,
>> incredibly hard to attack, trivial to configure, trivial to mirror, support
>> security/privacy-conscious users, etc. Some sites *cannot* be developed
>> this way, of course!! But using that as the "starting point" helps clarify
>> "what else do you need?" - that is, it forces a discussion of "what are the
>> unspoken requirements?". It's also where we are in the metamath site.
>> >
>> > With pre-rendering as a replacement for dynamic server side stuff, we
>> can still do most of the things. For example we could prerender all the
>> json queries and use client side JS to request them when doing cross
>> linking stuff. This is only made difficult if the set of all queries is
>> infinite, for example if we can do a search query.
>>
>>
>> > On Feb 19, 2023, at 3:13 PM, Mario Carneiro  wrote:
>> > The main advantages of dynamic rendering are:
>> > (1) quicker turnaround time, e.g. if we want to hastily put up a mm100
>> theorem on the website;
>> > (2) faster iteration - it is possible to make changes to the server and
>> see the results ~immediately;
>> > (3) lower storage cost, since we won't have to generate all the HTML
>> for the web site in advance and just cache important stuff (I assume that
>> most of the work going into the website build is wasted, since no one looks
>> at that page before it is next regenerated);
>> > (4) the ability to have many more rendering styles (unicode, gif, text,
>> latex, mathml, json have all been considered and more are possible) and
>> more databases, which is a combinatorial problem for the website build
>> limited by storage space and generation time.
>>
>> Sure. As always, it's all about trade-offs :-).
>>
>> I don't know if quicker turnaround time & such is all that important.
>> A "local" server run (by, say, a tool that called metamath-knife) would
>> have the same
>> tooling problems: You'd need to set up additional tools to run the tool
>> locally.
>>
>> Of that list, the ability to have more rendering styles is possibly the
>> most compelling of that list.
>> But exactly what rendering styles?
>>
>>
>> > > We can obviously use a program to dynamically generate many of the
>> pages instead, but what would it need to do?
>> >
>> > For the first version, I would aim simply to replicate the behavior /
>> look and feel of the current metamath web pages. That's what I implemented
>> in https://github.com/digama0/mm-web-rs . Once we have something that
>> can potentially replace the functionality of metamath-exe it will be easier
>> to consider incremental improvements, in an architecture where we can do
>> fancy things if we want.
>>
>> Okay, but what is desirable that is *different* long term? I think there
>> are plausible good answers,
>> but it'd be good to have some idea about them.
>>
>> > One technique that I use in the MM0 web pages is to use the HTML as the
>> data source: put all the proofs in a ta

Re: [Metamath] Re: Formalizing Fermat's Last Theorem

2023-02-20 Thread Mario Carneiro
I'm pretty sure the people who can edit wiki articles is the same as the
set of people with write access to the set.mm repo.

On Tue, Feb 21, 2023 at 12:02 AM Jim Kingdon  wrote:

> Oooh, thanks. I've been thinking a bit about formalizing n=3 or n=4 in
> metamath (or perhaps more likely, encouraging others to do so) but I was
> just thinking in terms of something we could accomplish soon, I didn't
> realize that the proof via the Modularity Theorem also needed those cases
> to be proved separately.
>
> I've taken the liberty of writing up what has been posted in this thread
> so far at https://github.com/metamath/set.mm/wiki/Fermat's-Last-Theorem
> which is part of the metamath wiki - I did so with the intention that other
> people could edit as we learn new things (I'm not sure I know the github
> permission system to know who already has an "edit" button but if anyone
> doesn't, just post proposed changes here or to a github issue or whatever).
> On 2/20/23 04:42, David Crisp wrote:
>
>
> (Breaking my years-long lurking habit to post this :))
>
> One thing that's often left out in discussions of how to formalize FLT is
> that even if the entire Frey - Serre - Ribet - Wiles sequence is included,
> the cases n=3 and n=4 will still need to be added as separate proofs. It's
> not obvious from a 'casual' read of Wiles' paper, but the level-lowering
> procedure used by Serre and Ribet to establish the non-modularity of the
> Frey curve is only guaranteed to work if the exponent in the Fermat
> equation is an odd prime != 3. Induction over the multiplicative structure
> of N then establishes the theorem for all n except those whose only prime
> factors are 2 and 3, but the n=3 and n=4 cases would still need to be
> proved separately to complete the proof.
>
> Luckily these two cases are fairly elementary to prove individually
> (especially compared to the monumental task of formalizing the entire
> modularity theorem) and so are often handwaved away in informal
> discussions, but a formal system like Metamath obviously can't do that.
>
> Dave
> On Sunday, 19 February 2023 at 04:05:37 UTC kin...@panix.com wrote:
>
>> Looks like http://www.ipam.ucla.edu/abstract/?tid=19347=MAP2023 has
>> both an abstract (which goes into more detail about what the talk is about)
>> and a video of the talk.
>>
>> Maybe you'd be able to figure out where this fits into your outline; I'm
>> afraid I'm even less far up the learning curve than you.
>>
>>
>> On February 18, 2023 7:58:11 PM MST, Steven Nguyen 
>> wrote:
>>>
>>> I've actually taken some notes over Fermat's Last Theorem:
>>> https://docs.google.com/document/d/19dXkojJJt6gq9rYLo6zbz7HpHpD9iMJJkY0LEpGqPs0/edit?usp=sharing
>>> Although so far, all that has come out of it are some useful resources,
>>> definitions, and the overall structure of Fermat's Last Theorem, which I
>>> summarize here:
>>>
>>>1.
>>>
>>>Modularity Theorem (previously the Taniyama-Shigura(-Weil)
>>>conjecture): every rational elliptic curve is modular
>>>2.
>>>
>>>Yves Hellegouarch came up with the idea of associating hypothetical
>>>solutions (a, b, c) with elliptic curves of the form y^2 = x(x −
>>>a^n)(x + b^n).
>>>1.
>>>
>>>   Such curves are called Frey curves or Frey-Hellegouarch curves.
>>>   3.
>>>
>>>Ribet’s Theorem (previously called the epsilon or ε-conjecture): All
>>>Frey curves are not modular
>>>
>>> Note that the final paper by Wiles proved a special case of the
>>> modularity theorem for semistable curves over ℚ. In this case, "Frey curves
>>> are semistable" would have to be proved as well.
>>>
>>> This is enough to prove FLT. If there were any solutions, then there
>>> would be a corresponding Frey curve. By Ribet’s Theorem, the curve would
>>> not be modular, but that contradicts the Modularity Theorem. Therefore
>>> there are no fermat triples, FLT is proved. ∎
>>>
>>>
>>> However, I admit I don't understand almost all of the theory behind
>>> FLT... I've never heard of local field class theory. So that's quite an
>>> interesting link.
>>> On Thursday, February 16, 2023 at 8:36:10 PM UTC-6 kin...@panix.com
>>> wrote:
>>>
 I know this is a bit of a white whale and there is a lot of mathematics
 to formalize before this is even in reach. But when the formal math
 community (taken as a whole) is at 99 out of 100 of the Top 100 list, of
 course it is easy to focus on the one.

 Anyway the news is that there was a recent talk on formalizing local
 field class theory which apparently is one of the things that will be
 needed. https://mathstodon.xyz/@tao/109877480759530521

>>> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> 

Re: [Metamath] Future website directions

2023-02-19 Thread Mario Carneiro
On Sun, Feb 19, 2023 at 2:19 PM David A. Wheeler 
wrote:

> > While yes I agree that this would be much better done with
> metamath-knife than metamath-exe, I don't think there is a major concern
> here, or at least we can mostly mitigate the issues since this flow is
> extremely light on input from the attacker. Basically the only thing you
> can specify is the theorem you want to see. But for sure I'm not interested
> in doing this by building on metamath-exe, there are some great frameworks
> for writing these kind of servers in rust that should already handle most
> of the issues. The main thing to be concerned about is DOS attacks, and
> having a 'real' server like nginx in front helps with that.
> >
> > But our threat model is pretty much nonexistent to begin with; almost
> all the server data and code is public domain in the first place and even
> if the server is taken down it's not a critical service. I think a much
> more critical problem for the project is giving a perception of being an
> old unfriendly software used by few.
>
> It's not a *critical* service absolutely, but there are a lot of attackers
> who just attack everything using a variety of tools, then see what they can
> get out of it. So I'd rather make it hard to successfully attack the site.
> I agree that strong filtering would eliminate many problems.
>

Obviously that wasn't to downplay the necessity for not putting buggy
servers on the internet. We should certainly take all reasonable
precautions. But it is important to keep in mind what the threat model is
when talking about security concerns, and ours is about as low as one can
be for something that is on the internet.


> My first choice when building a website, where it's easily achieved, is
> static rendering (statically-generated pages) where the most important data
> is visible without client-side JavaScript. Those are easily understood,
> incredibly hard to attack, trivial to configure, trivial to mirror, support
> security/privacy-conscious users, etc. Some sites *cannot* be developed
> this way, of course!! But using that as the "starting point" helps clarify
> "what else do you need?" - that is, it forces a discussion of "what are the
> unspoken requirements?". It's also where we are in the metamath site.
>

With pre-rendering as a replacement for dynamic server side stuff, we can
still do most of the things. For example we could prerender all the json
queries and use client side JS to request them when doing cross linking
stuff. This is only made difficult if the set of all queries is infinite,
for example if we can do a search query.

The main advantages of dynamic rendering are:
(1) quicker turnaround time, e.g. if we want to hastily put up a mm100
theorem on the website;
(2) faster iteration - it is possible to make changes to the server and see
the results ~immediately;
(3) lower storage cost, since we won't have to generate all the HTML for
the web site in advance and just cache important stuff (I assume that most
of the work going into the website build is wasted, since no one looks at
that page before it is next regenerated);
(4) the ability to have many more rendering styles (unicode, gif, text,
latex, mathml, json have all been considered and more are possible) and
more databases, which is a combinatorial problem for the website build
limited by storage space and generation time.


> A disadvantage fo static rendering is that you have to prerender all
> pages, which takes time. I see that as a non-problem for our case; if
> someone can't wait a few hours, they can use tools to locally generate the
> page themselves.
>

For most web site readers, there is a HUGE gap between the effort required
to click on a link and the effort required to download the tool, figure out
how to make it work, and generate the page they want. I have a working
setup and even I would not bother to go to the trouble in most cases. (Even
when I do, the results often have broken links or missing GIF symbols
because I didn't do the full build or don't have the rest of the web site
directory hierarchy set up.)

A tool which can act as a *local* server would be a measurable improvement
over piecemeal HTML generation, since you can give the impression of a
fully built website without having to wait two hours first.


> We can obviously use a program to dynamically generate many of the pages
> instead, but what would it need to do?
>

For the first version, I would aim simply to replicate the behavior / look
and feel of the current metamath web pages. That's what I implemented in
https://github.com/digama0/mm-web-rs . Once we have something that can
potentially replace the functionality of metamath-exe it will be easier to
consider incremental improvements, in an architecture where we can do fancy
things if we want.


> > I expect to have a proposal for a JSON format - just a parse tree of a
> .mm file, really - early next month if not sooner.
>
> I think the more interesting case is a 

Re: [Metamath] Idea: Release ".txt" proofs for set.mm databases ("mpetxt") for AI/ML tools, esp Generative Pre-trained Transformers (GPTs)

2023-02-19 Thread Mario Carneiro
Oops, that was the wrong link, I meant to point to
https://www.mediawiki.org/wiki/Page_Previews . (I investigated how this
feature is implemented a while ago, with an eye for doing something similar
for theorem references.)

On Sun, Feb 19, 2023 at 1:05 PM Mario Carneiro  wrote:

> I don't see those as competing goals at all. They play different roles:
> for browsing you would ideally have some server supplying only the required
> information to render a specific proof, and for a proof assistant (and to
> some extent a search tool as well) you want to have the whole database
> available, or at least all the signatures of all the theorems and the body
> for the current theorem. Especially when you consider how these things
> scale asymptotically, it is clear that the dependencies for one proof will
> be a lot less than the entirety of the file, and a streaming parser can
> only save you a factor of 2 if we assume that theorems of interest are
> sampled uniformly. For example I don't think wikipedia is sending a
> compressed archive of the whole project on every page load - it only sends
> the data for the current article, as well as server-side json blurbs for
> link hovers (
> https://en.wikipedia.org/wiki/Wikipedia:Tools/Navigation_popups). But
> when someone clicks the "start proof mode" button they will have an
> expectation that there will be a startup cost, so it is easy to justify
> loading set.mm and a streaming parser still helps for making that
> experience better.
>
> On Sun, Feb 19, 2023 at 5:43 AM Antony Bartlett  wrote:
>
>> On Sat, Feb 18, 2023 at 11:04 PM Mario Carneiro 
>> wrote:
>>
>>> Even if you have a highly optimized mm verifier, you can't get around
>>> the fact that you need to send some 30 MB over the wire before you can do
>>> anything.
>>>
>>
>> Just to recap a few things from other threads, back in November, Samuel
>> Goto demonstrated a dynamic (client-side) proof explorer here
>>
>> https://code.sgo.to/2022/11/26/2p2e4.html
>>
>> It does indeed take some time to load while a set.mm is sent over the
>> wire.  Hence the subsequent discussion of "streaming parsers", which would
>> allow for the page to render as soon as the bit of set.mm that we're
>> interested in has loaded rather than waiting for the whole thing.  (or a
>> verifier could be running on whatever part of the file is available,
>> successively as it's chunks download)
>>
>> (Igor Ieskov's web-based proof assistant loads locally saved files, so
>> doesn't have the same load time problem).
>>
>> I expect to have a proposal for a JSON format - just a parse tree of a
>> .mm file, really - early next month if not sooner.
>>
>> demo0.mm currently looks like this as JSON:
>> https://github.com/Antony74/mmparsers/blob/main/examples/demo0.mm.json
>> and the TypeScript types look like this:
>> https://github.com/Antony74/mmparsers/blob/main/src/mmParser/mmParseTree.ts
>> and I plan on writing a JSON schema too, but haven't started on that yet.
>>
>> And I'm not proposing anything until I have a working parser! - after
>> which getting the streaming working may take a little longer.
>>
>> Whether this proves popular, or whether I turn out to be its only
>> adoptee, it's impossible to say, but I wouldn't be at all sorry to see the
>> streaming parser superseded by some sort of server side JSON if that's what
>> you're mulling over.
>>
>> Best regards,
>>
>> Antony
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Metamath" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to metamath+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/metamath/CAJ48g%2BBXDYisz8C%3DvWkOLEUj7V%2BoeCwONqL0m4bDdKZ%2B3EvaEg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/metamath/CAJ48g%2BBXDYisz8C%3DvWkOLEUj7V%2BoeCwONqL0m4bDdKZ%2B3EvaEg%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSvRCXqXa5X%2B7%2B3SSEZ5A63P%2BeJLhmRcwuP_x8QE6EwdcQ%40mail.gmail.com.


Re: [Metamath] Idea: Release ".txt" proofs for set.mm databases ("mpetxt") for AI/ML tools, esp Generative Pre-trained Transformers (GPTs)

2023-02-19 Thread Mario Carneiro
I don't see those as competing goals at all. They play different roles: for
browsing you would ideally have some server supplying only the required
information to render a specific proof, and for a proof assistant (and to
some extent a search tool as well) you want to have the whole database
available, or at least all the signatures of all the theorems and the body
for the current theorem. Especially when you consider how these things
scale asymptotically, it is clear that the dependencies for one proof will
be a lot less than the entirety of the file, and a streaming parser can
only save you a factor of 2 if we assume that theorems of interest are
sampled uniformly. For example I don't think wikipedia is sending a
compressed archive of the whole project on every page load - it only sends
the data for the current article, as well as server-side json blurbs for
link hovers (https://en.wikipedia.org/wiki/Wikipedia:Tools/Navigation_popups).
But when someone clicks the "start proof mode" button they will have an
expectation that there will be a startup cost, so it is easy to justify
loading set.mm and a streaming parser still helps for making that
experience better.

On Sun, Feb 19, 2023 at 5:43 AM Antony Bartlett  wrote:

> On Sat, Feb 18, 2023 at 11:04 PM Mario Carneiro  wrote:
>
>> Even if you have a highly optimized mm verifier, you can't get around the
>> fact that you need to send some 30 MB over the wire before you can do
>> anything.
>>
>
> Just to recap a few things from other threads, back in November, Samuel
> Goto demonstrated a dynamic (client-side) proof explorer here
>
> https://code.sgo.to/2022/11/26/2p2e4.html
>
> It does indeed take some time to load while a set.mm is sent over the
> wire.  Hence the subsequent discussion of "streaming parsers", which would
> allow for the page to render as soon as the bit of set.mm that we're
> interested in has loaded rather than waiting for the whole thing.  (or a
> verifier could be running on whatever part of the file is available,
> successively as it's chunks download)
>
> (Igor Ieskov's web-based proof assistant loads locally saved files, so
> doesn't have the same load time problem).
>
> I expect to have a proposal for a JSON format - just a parse tree of a .mm
> file, really - early next month if not sooner.
>
> demo0.mm currently looks like this as JSON:
> https://github.com/Antony74/mmparsers/blob/main/examples/demo0.mm.json
> and the TypeScript types look like this:
> https://github.com/Antony74/mmparsers/blob/main/src/mmParser/mmParseTree.ts
> and I plan on writing a JSON schema too, but haven't started on that yet.
>
> And I'm not proposing anything until I have a working parser! - after
> which getting the streaming working may take a little longer.
>
> Whether this proves popular, or whether I turn out to be its only adoptee,
> it's impossible to say, but I wouldn't be at all sorry to see the streaming
> parser superseded by some sort of server side JSON if that's what you're
> mulling over.
>
> Best regards,
>
> Antony
>
> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/CAJ48g%2BBXDYisz8C%3DvWkOLEUj7V%2BoeCwONqL0m4bDdKZ%2B3EvaEg%40mail.gmail.com
> <https://groups.google.com/d/msgid/metamath/CAJ48g%2BBXDYisz8C%3DvWkOLEUj7V%2BoeCwONqL0m4bDdKZ%2B3EvaEg%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSuT8-PEGsQFeQav5kB0hJrtR5YXHB5qRmpGwd55KWyDVQ%40mail.gmail.com.


Re: [Metamath] Idea: Release ".txt" proofs for set.mm databases ("mpetxt") for AI/ML tools, esp Generative Pre-trained Transformers (GPTs)

2023-02-18 Thread Mario Carneiro
On Sat, Feb 18, 2023 at 5:16 PM David A. Wheeler 
wrote:

>
>
> > On Feb 18, 2023, at 4:08 PM, Mario Carneiro  wrote:
> > In case it wasn't clear (and it probably wasn't), in a future world in
> which the default mechanism is some super fancy client side renderer it is
> still possible to offer a fallback "static site" of HTML pages which is
> nevertheless not generated in advance and is being served dynamically
> server-side. This has a relatively small generation cost even if we don't
> stick a CDN in front of it, but if we do then I think that's a viable
> approach to having all the HTML pages with basically zero preprocessing,
> just a smarter server. I would really love it if the only thing the site
> build needs to do is download and load the latest set.mm .
>
> I understand, that's just a typical dynamically-generated data file and/or
> HTML with possibly front-end JavaScript. Bog standard stuff. Of course,
> there are pluses & minuses with that approach. In the 2010s almost everyone
> switched to that model, today there's a big press back to
> statically-regenerated sites where practical (with Jekyll, etc.) because
> attackers routinely pop systems that do dynamic response.
>
> There are big concerns if you hook up a program written in C to input sent
> by an attacker. Rigorous input filtering would definitely help, but using
> something like metamath-knife as a basis instead of metamath-exe might be
> better. So doing this would involve a nontrivial amount of software,
> *along* with analysis to ensure that it was unlikely to lead to a
> vulnerability. Statically generating files is a much simpler path from
> where we are. That's not to say we must go that way, but it'd take more
> effort to do full dynamic generation *with* confidence in its security.
>

While yes I agree that this would be much better done with metamath-knife
than metamath-exe, I don't think there is a major concern here, or at least
we can mostly mitigate the issues since this flow is extremely light on
input from the attacker. Basically the only thing you can specify is the
theorem you want to see. But for sure I'm not interested in doing this by
building on metamath-exe, there are some great frameworks for writing these
kind of servers in rust that should already handle most of the issues. The
main thing to be concerned about is DOS attacks, and having a 'real' server
like nginx in front helps with that.

But our threat model is pretty much nonexistent to begin with; almost all
the server data and code is public domain in the first place and even if
the server is taken down it's not a critical service. I think a much more
critical problem for the project is giving a perception of being an old
unfriendly software used by few.

> I don't think this is a very competitive option though, since you would
> have to load all of set.mm.
>
> It's more competitive than you might think. Igor's prover loads the whole
> database in a few seconds.


I was talking about the data cost. Even if you have a highly optimized mm
verifier, you can't get around the fact that you need to send some 30 MB
over the wire before you can do anything. That's big even by modern bloated
web page standards. If the user doesn't have a great connection then that
might dwarf the cost of processing.

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSvKVCOmYtuGjvK8WRA8nO5GxGbc1R-QNfAedYmsUzU2Qg%40mail.gmail.com.


Re: [Metamath] Idea: Release ".txt" proofs for set.mm databases ("mpetxt") for AI/ML tools, esp Generative Pre-trained Transformers (GPTs)

2023-02-18 Thread Mario Carneiro
> > While I have some sympathy for this argument, I also think it is holding
> us back a lot. Catering to the least common denominator of no-JS means that
> our web pages are stuck permanently in web 1.0, with no search
> functionality, intra-page links, subproof expansion, mathml rendering,
> go-to-definition for symbols, or a laundry list of other features.
> Furthermore, doing the rendering client-side means that the cost of
> transmission is lower which means shorter load times and no need for a
> two-hour processing phase.
>
> What I want is for *a* way for people to access the basic information
> without *requiring* client-side JavaScript. I see no reason that it be the
> *only* way we provide the information, we already provide it in multiple
> forms. I just want to retain that capability. So you don't need to feel
> held back :-).
>

In case it wasn't clear (and it probably wasn't), in a future world in
which the default mechanism is some super fancy client side renderer it is
still possible to offer a fallback "static site" of HTML pages which is
nevertheless not generated in advance and is being served dynamically
server-side. This has a relatively small generation cost even if we don't
stick a CDN in front of it, but if we do then I think that's a viable
approach to having all the HTML pages with basically zero preprocessing,
just a smarter server. I would really love it if the only thing the site
build needs to do is download and load the latest set.mm .


> Indeed, you can implement rendering with client-side JavaScript today,
> just download the .mm files.
>

I don't think this is a very competitive option though, since you would
have to load all of set.mm. The advantage of pre-processed json files is
that when you have a single theorem you want to look at you don't need to
request everything and start up a whole client-side MM verifier first.

The current CORS setting means that any client-side JavaScript program can
> do that, it doesn't even need to be hosted on us.metamath.org. So
> technically people today can view the generated HTML on the website, *or*
> use any client-side JavaScript/WebAssembly. We "just" need someone to write
> the client-side renderer.


An in-browser .mm browser and proof assistant is a very cool project, but
somewhat distinct from what I'm talking about, which is a replacement for
the existing proof docs. That's not to say that we shouldn't have such a
thing available as well on metamath.org as a kind of "try it online" mode.
But the heavy startup cost will definitely make it feel like a different
experience.


> Also, almost everything you listed doesn't require client-side JavaScript.
> Intra-page links work (they're just hyperlinks), subproof expansion works
> (use HTML ), MathML ships in Chromium & Chrome & Firefox
> (Firefox's support is only partial but it's probably more than enough for
> us) per ,
> go-to-definition is just another hyperlink, and so on.
>

While it is true that you can do almost all of that with static HTML, it
would make the pages far heavier than they currently are. Load times for
large proof pages are already pretty bad and this would make it a lot
worse. Not to mention that more text means more pre-processing time during
site build.

Basic searches can be supported via a form that queries a search engine
> (e.g., Google).
>

Oof. I'm sure you know that this is not a very good option for a host of
reasons. It's basically equivalent to not having a search mechanism at all,
since google already indexes the site.


> As far as speed goes, JavaScript is often slower than HTML where both can
> be used. In practice JavaScript files are often quite large, and JavaScript
> has to be parsed, examined, executed, and then its execution must cause
> document tree changes which finally get rendered. Web browsers are *really*
> good at rapidly & progressively rendering HTML. On systems I've worked
> with, HTML (even with server roundtrips) is often *MUCH* faster when
> measuring paint-to-screen times. JavaScript *has* gotten faster over the
> years, thankfully, but the gap is still large. Of course, when you need
> functionalities only provided by JavaScript then you need it. Like all
> technologies there are tradeoffs.
>

I am imagining the main purpose of the JS here is to pump up a basic
version of the page into the fully interactive / hyperlinked version of the
page, without having to put loads of redundant text in all the tags. There
is no need for a heavy JS library here; I did essentially this for the MM0
docs (https://digama0.github.io/mm0/peano/thms/expr.html) and the JS
support library for it (https://digama0.github.io/mm0/peano/proof.js) is
very light and does not need to come with every page. (There is still more
that can be done to make the MM0 docs more interactive but it helps a lot
if there is an actual server on the other end rather than just a static
site.)


> > Is there much 

Re: [Metamath] Idea: Release ".txt" proofs for set.mm databases ("mpetxt") for AI/ML tools, esp Generative Pre-trained Transformers (GPTs)

2023-02-17 Thread Mario Carneiro
>
> I do see big downsides for the use cases listed here though:
> 1. For training a GPT, I fear that the system would focus on "it's a JSON
> file!"
> and any tool-specific training would be swamped by thinking it's the same
> as other JSON files.
> I think a GPT system that trains on the "Internet as a whole" is more
> likely to
> generate some useful information if we minimize distractors.
> In short, make it REALLY OBVIOUS that this text is regular in some way, yet
> clearly different from anything else, and expose structure where we
> reasonably can.


I think this is looking at it the wrong way. Stuff trained on the entire
internet is going to have a clear upper bound on the precision of the
answers it can give. I'm not really interested in supplying a poor quality
data source just for the purpose of a speculative application like this.
For projects that are actually interested in doing ML specifically on
metamath, it is very normal to have some data wrangling by the researchers
beforehand to prepare things for the model. This kind of glue code is
usually some ad-hoc python script so it helps if we are providing a data
source that is easily manipulable. (I'm working on a paper with Josef Urban
regarding ATP for metamath and it benefits significantly from
metamath-knife as a way of getting information from mm files, but it's not
always possible to use mm-knife and if we are going for something more
easily digestible from many languages without a dedicated library JSON is a
strong choice.)

2. For rendering on the client side, there are big advantages to showing
> static data
> as straight HTML. For one, people who disable JavaScript can still see it
> fine.
> Sure, sometimes it's useful to run arbitrary code sent by strangers, but
> there are good
> reasons to minimize that as a requirement :-). It also means that search
> engines see
> "what we actually have".


While I have some sympathy for this argument, I also think it is holding us
back a lot. Catering to the least common denominator of no-JS means that
our web pages are stuck permanently in web 1.0, with no search
functionality, intra-page links, subproof expansion, mathml rendering,
go-to-definition for symbols, or a laundry list of other features.
Furthermore, doing the rendering client-side means that the cost of
transmission is lower which means shorter load times and no need for a
two-hour processing phase. (Even without making the web pages dynamic I've
been considering generating the web pages on-demand and using nginx only as
a cache. I already have a prototype that can serve HTML directly from the
.mm file, no preprocessing necessary, and that means we don't have to worry
about slow updates and stuff going down due to issues that occurred during
the massive install script.)


On Fri, Feb 17, 2023 at 4:27 AM Auguste Poiroux 
wrote:

> Hi everyone!
>
> I am very interested in this discussion topic too. There is an
> organization that is currently working on something highly related to this
> topic and is starting to release open-source datasets/models on
> HuggingFace: https://huggingface.co/hoskinson-center. They provide a math
> dataset and a first model of 6.7B parameters trained on it. In their math
> dataset, they put several proof databases from different formal systems,
> including Metamath. They used this code: 
> https://github.com/zhangir-azerbayev/mm-extract
> to extract a "human readable" form of the proofs. This seems to be close
> to the format you propose David.
> I think the model they provide can be used to make proof suggestions. I
> don't know what this is worth though, I just stumbled across it. It may not
> be the best, but I think it can be a really good start.
> The work looks very recent, maybe they will publish some evaluation
> results of their model soon.
>
> Auguste
>
> Le jeudi 16 février 2023 à 16:05:01 UTC+1, David A. Wheeler a écrit :
>
>>
>> > On Feb 14, 2023, at 1:46 PM, Jon P  wrote:
>> >
>> > I think that's a great idea David! Seems like very low downside and it
>> would be interesting to see if language models could train on the datasets.
>> >
>> > There's already an option to Customise GPT3 with additional datasets so
>> once this is ready it could be an interesting experiment to try.
>> >
>> > https://openai.com/blog/customized-gpt-3/
>>
>> Thanks so much for that link. So I looked into creating a
>> specially-trained model
>> to create metamath proofs. that page points to this pricing model for
>> GPT-3:
>> https://openai.com/api/pricing/#faq-token
>>
>> I did a quick estimate of training costs for the top GPT-3 model on
>> all of set.mm. It comes out to about $2600.
>> That's less than I expected, and that's easily affordable in a grant (you
>> could train multiple times),
>> but it's not an amount I have pocket change for :-(.
>> Inference isn't expensive; trying to generate axtgcgrrflx is $0.15 (15
>> cents).
>> See below for how I created the quick estimate.
>> We could do a subset of set.mm 

Re: [Metamath] Idea: Release ".txt" proofs for set.mm databases ("mpetxt") for AI/ML tools, esp Generative Pre-trained Transformers (GPTs)

2023-02-14 Thread Mario Carneiro
I think a json version of the web pages would make a lot more sense than a
plain text version, if the intent is to support machine consumption by
tools that can't parse metamath already. There are even uses for that in
the web pages themselves, since an interactive version of the web pages
would like to have the underlying data in a more easily processed form so
that it can do things with it. In fact, we could even eliminate the
mpeuni/mpegif pages entirely and replace them with a on-the-spot client
side renderer which uses the json file as input along with some global
formatting data (i.e. a json version of the $t comment), which would
significantly decrease the space cost of the web site without changing the
user experience at all.

On Tue, Feb 14, 2023 at 9:32 PM Cris Perdue  wrote:

> David,
>
> I take this idea as an approach to making metamath proofs more digestible
> by machines, and I love it for that.
>
> It might be worth mentioning that it is easier than it might appear to
> extract the text from a web page as in the Metamath site. In fact a tiny
> experiment on my part came out nicer than I hoped.  Opening up the Chrome
> debugging console on the page for pm5.74, I did:
>
> > console.log(document.body)
>
> and got:
>
> Metamath Proof Explorer < Previous   Next >
> Nearby theorems
> Mirrors  >  Home  >  MPE Home  >  Th. List  >  pm5.74 Structured version
> Visualization version   GIF version
> Theorem pm5.74 262
> Description: Distribution of implication over biconditional. Theorem *5.74
> of [WhiteheadRussell] p. 126. (Contributed by NM, 1-Aug-1994.) (Proof
> shortened by Wolf Lammen, 11-Apr-2013.)
> Assertion
> Ref Expression
> pm5.74 ⊢ ((휑 → (휓 ↔ 휒)) ↔ ((휑 → 휓) ↔ (휑 → 휒)))
> Proof of Theorem pm5.74
> Step Hyp Ref Expression
> 1   biimp 207 . . . 4 ⊢ ((휓 ↔ 휒) → (휓 → 휒))
> 2 1 imim3i 64 . . 3 ⊢ ((휑 → (휓 ↔ 휒)) → ((휑 → 휓) → (휑 → 휒)))
> 3   biimpr 212 . . . 4 ⊢ ((휓 ↔ 휒) → (휒 → 휓))
> 4 3 imim3i 64 . . 3 ⊢ ((휑 → (휓 ↔ 휒)) → ((휑 → 휒) → (휑 → 휓)))
> 5 2, 4 impbid 204 . 2 ⊢ ((휑 → (휓 ↔ 휒)) → ((휑 → 휓) ↔ (휑 → 휒)))
> 6   biimp 207 . . . 4 ⊢ (((휑 → 휓) ↔ (휑 → 휒)) → ((휑 → 휓) → (휑 → 휒)))
> 7 6 pm2.86d 108 . . 3 ⊢ (((휑 → 휓) ↔ (휑 → 휒)) → (휑 → (휓 → 휒)))
> 8   biimpr 212 . . . 4 ⊢ (((휑 → 휓) ↔ (휑 → 휒)) → ((휑 → 휒) → (휑 →
> 휓)))
> 9 8 pm2.86d 108 . . 3 ⊢ (((휑 → 휓) ↔ (휑 → 휒)) → (휑 → (휒 → 휓)))
> 10 7, 9 impbidd 202 . 2 ⊢ (((휑 → 휓) ↔ (휑 → 휒)) → (휑 → (휓 ↔ 휒)))
> 11 5, 10 impbii 201 1 ⊢ ((휑 → (휓 ↔ 휒)) ↔ ((휑 → 휓) ↔ (휑 → 휒)))
> Colors of variables: wff setvar class
> Syntax hints:   → wi 4   ↔ wb 198
> This theorem was proved from axioms:  ax-mp 5  ax-1 6  ax-2 7  ax-3 8
> This theorem depends on definitions:  df-bi 199
> This theorem is referenced by:  pm5.74i  263  pm5.74ri  264  pm5.74d  265
>  pm5.74rd  266  bibi2d  334  pm5.32  570  orbidi  976
>   Copyright terms: Public domain W3C validator
>
>
> So perhaps the "plain text" may be accessible enough to systems with
> well-developed HTML and DOM processing. Arguably it might be more desirable
> to have the ASCII text rather than Unicode in the formulas, as parsing of
> the ASCII text is presumably more well-defined.
>
> There is something quite similar that I think would be even cooler:
> JSON-format versions of theorem pages. JSON is a well-defined textual
> format, extremely popular and widespread in use on the Web and elsewhere.
> I'm thinking of a JSON-based format something like:
>
> {"theorem": "m5.74",
>  "hyps": [],
>  "wff": "( ( ph -> ( ps <-> ch ) ) <-> ( ( ph -> ps ) <-> ( ph -> ch ) )
> )",
>  "proof": [
>  {"i": 1, "ref": "biimp" "f": "( ( ps <-> ch ) -> ( ps -> ch ) )"},
>  {"i": 2, "deps": [1], "ref": "imim3i", "f":( ( ph -> ( ps <-> ch ) ) -> (
> ( ph -> ps ) -> ( ph -> ch ) ) )"},
>  {"i": 3 "ref": "biimpr", "f": "( ( ps <-> ch ) -> ( ch -> ps ) )"},
>  {"i": 4 "deps": [3], "ref": "imim3i", "f": "( ( ph -> ( ps <-> ch ) ) ->
> ( ( ph -> ch ) -> ( ph -> ps ) ) )"},
>  {"i": 5, "deps": [2,4], "ref": "impbid", "f":  "( ( ph -> ( ps <-> ch ) )
> -> ( ( ph -> ps ) <-> ( ph -> ch ) ) )"},
>  (and so on)
>  ]
> }
>
> (The details of course could vary, while still making use of the JSON
> format.)
>
> Presumably pages in such a format would include enough information such as
> distinct variable groups,
> to enable reproducing actual proofs. It could be used as data for
> experimental proof displayers. It would also
> be very straightforward to build web apps that present proofs in custom
> formats within web browsers, as
> browsers support JSON format very well.
>
> I see no reason this kind of format would should not be at least as
> accessible to AI as plain text.
>
> -Cris
>
>
> On Mon, Feb 13, 2023 at 10:20 AM David A. Wheeler 
> wrote:
>
>> All: I'm thinking it might be a good idea to create a new "database area",
>> "mpetxt" (to match "mpeuni"/"mpegif"), with many simple text files - 1
>> per proof.
>> The goal would be to make it easier for AI/ML tools to learn from them
>> so they perhaps could generate potential proofs.
>>
>> Current AI (specifically 

Re: [Metamath] status of nnne0ALT

2023-02-01 Thread Mario Carneiro
It sounds like we were unable to prevent a proof modification in this case.
We'll have to go back through the history to find out what the original
proof was and how it degenerated.

On Wed, Feb 1, 2023 at 12:54 PM Zheng Fan  wrote:

> The proof of nnne0ALT is a thin wrapper of 0nnn, which is in turn a thin
> wrapper of nnne0, which makes me think why this alternative proof is kept.
> The caption says that it is supposed to be a shorter proof using more
> axioms, but it seems not the case, at least for the current version of
> set.mm.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/65b3f52c-17c8-42c5-8349-582f2ff86bd8n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSu_SWsfjpFEhshPaNYC4LahujxLBP-%3DU%3Du5PMwCxjdzSg%40mail.gmail.com.


Re: [Metamath] Re: Should eliminate the GIF directories & just use Unicode?

2023-01-02 Thread Mario Carneiro
I don't think the redirect would be that difficult, it is a one time apache
configuration thing, possibly plus updates to the mirrors.

On Mon, Jan 2, 2023 at 11:25 PM Jim Kingdon  wrote:

> There are a lot of ideas on this thread which might be worth doing, but
> the redirect from mpegif to mpeuni is the only which is in my mind a
> (likely) prerequisite for retiring mpegif. Most of the others we could do
> later if we find we wish we had them.
> On 1/2/23 07:49, Samiro Discher wrote:
>
> Another issue that immediately comes to my mind is that in such case one
> shouldn't invalidate old hyperlinks,
> e.g. https://us.metamath.org/mpegif/id.html should be redirected to
> https://us.metamath.org/mpeuni/id.html
> in case the mpegif pages are removed.
>
> David A. Wheeler schrieb am Montag, 2. Januar 2023 um 16:42:35 UTC+1:
>
>> Should eliminate the GIF directories & just use Unicode? That is, for
>> example,
>> redirect all uses of  to
>>  ?
>>
>> I welcome comments/thoughts. A few notes are below.
>>
>> --- David A. Wheeler
>>
>> ===
>>
>> The Metamath project has, for many years, generated HTML pages with
>> embedded GIF images.
>> For a very long time this was the only practical way for most people to
>> read the results.
>> However, today practically all web browsing systems support Unicode.
>> We switched to Unicode as the default years ago. Many
>> people's fonts didn't cover math symbols, but when we posted web fonts
>> (my fault :-) )
>> that problem was basically solved.
>>
>> At this point I think the primary reason to keep GIF directories is to
>> make copying text easier:
>> https://us.metamath.org/mpeuni/mmset.html#textonly
>> That's a perfectly valid use case, as long as people are actually doing
>> it.
>> I don't know how many people find that useful.
>>
>> Generating everything twice takes time, but that's not a big deal.
>> It does create more opportunities for error & complicates our scripts.
>> The big advantage of eliminating the GIF generation would be to save disk
>> space.
>> Because we generate everything twice, we use about double the disk space.
>> Anyone can see our current disk space status by viewing this page:
>> https://us.metamath.org/status.txt
>> The main drive /dev/sda has 26G, with 1.3G available (95% used).
>> We can pay for more space, but there's a jump in price.
>> We should be fine for a long time as long as we keep log files limited in
>> size,
>> but any error in its configuration can cause problems (as illustrated
>> recently).
>>
>> There may be other issues I'm not aware of.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/4d0b2379-fff3-4712-b43f-2a1ba194c13en%40googlegroups.com
> 
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/f420e0ce-f888-e26a-c8fc-32ed56a3c78d%40panix.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSs_tOkYp2zevO3xD0TfuYF_scOXkwG%3D9UPE5p3SUM1izQ%40mail.gmail.com.


Re: [Metamath] Should eliminate the GIF directories & just use Unicode?

2023-01-02 Thread Mario Carneiro
I think it's not worth it to have ascii symbols in title attributes on
every character. This will unnecessarily blow up the page size quite
considerably. I think Benoit's suggestion of an all-ascii version of the
pages is better - I think this is already implemented in one of the
alternate verifiers, and it seems like a better overall approach if the
purpose is to get expressions which can be copy-pasted into e.g. an mmj2
worksheet or an .mm file compared to a bunch of tiny tooltips.

On Mon, Jan 2, 2023 at 4:53 PM David A. Wheeler 
wrote:

>
>
> > On Jan 2, 2023, at 2:47 PM, Glauco  wrote:
> >
> > The gif version has a useful feature: when you hover on a symbol, the
> ascii string for the symbol is shown.
> >
> > Would it be possible to have the same behavior in the Unicode version?
>
> Yes. Any HTML element can have a "global attribute", and one of them is
> "title":
> https://www.w3.org/TR/2016/REC-html51-20161101/dom.html#the-title-attribute
>
> If we create a span and use a "title" element we could do the same thing.
>
> I tried out both Firefox and Chrome (on MacOS) and after having for just a
> moment I saw the tooltip.
> My demo HTML is below, in case anyone else wants to try the experiment.
>
> --- David A. Wheeler
>
> ===
>
> 
> 
>
> 
> This is a tooltip demo for althtmldef "->" as "  ";
>
>
> 
> A  B.
>
> 
> 
>
> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/FF0A4BFB-8BAC-4482-83ED-E409B453552F%40dwheeler.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSu9J-DBCJW8rwjTXvTsRVhem5G2JTVUJ3OZAEr3naKteg%40mail.gmail.com.


  1   2   3   4   5   >