Skip to content

Convert Euclidean n-spaces to 0-based indices #5416

Open

Description

@tirix

When first introducing definitions for Euclidean n-spaces, I raised the question about whether 1-based indices or 0-based indices would be a better choice.

My original choice was to used 1-based indices because @sctfn's df-ee was already using 1-based indices, and I wanted to later reference it.

The one advantage I thought about for 0-based indices was the direct sum:

For proving RR^m ⊕ RR^n = RR^(m+n), it might be interesting to use the Word concept, which has indices starting at zero ( 0 ..^ n ), but I still don't believe it a reason enough to choose this convention.

Later, @avekens built upon this definition and added theorems about circles and circle-line intersections, using 1-based indices.

Recently, @littledumb proposed a definition of cross-product which also uses 1-based indices, referring to ~ rrxval and ~ ehlval.
@ProgramCrafter accurately pointed out that using 0-based indices would allow to use Word, and the word constructor <" X Y Z "> would make things much easier. This would be another advantage of 0-based indices.

It would be really nice if the definition of the cross product could be both practical (using the word constructor <" X Y Z ">), and could fit in the more general definition of Euclidean space of dimension n.

Note that the chapter header for matrices mentions 1-based indices, but actually, very few theorems about matrices require 1-based indices. Instead, most theorems are proved about a generic finite set of indices.

What is the community's opinion?

Activity

  1. ProgramCrafter commented on Jul 29, 2026

    @ProgramCrafter
    Contributor

    My background is programming so I'm for 0-based.
    Remember that there is the zero-dimensional space, for which ( 0 ..^ 0 ) looks much better than ( 1 ... 0 ).

    I wouldn't care too much if coordinates were named, either, as the extensible structures do; but it hardly works for higher dimensions.

  2. benjub commented on Jul 29, 2026

    @benjub
    Contributor

    What is the community's opinion?

    As for me:

    • Most importantly, the current definition https://us.metamath.org/mpeuni/df-ee.html excludes the zero-dimensional space, which seems rather arbitrary (recall that we also use the nonstandard notation $\mathbb{N}$ for the nonzero natural numbers). I think a definition of Euclidean spaces should not exclude it.
    • I would also prefer zero-based, and would write it as (0..^n), which indeed looks more natural.
    • I have not looked at the sections precisely, but do we really need both https://us.metamath.org/mpeuni/df-ee.html and https://us.metamath.org/mpeuni/df-ehl.html ? I would be happy with only the latter (well, its 0-based version).
  3. ProgramCrafter commented on Jul 29, 2026

    @ProgramCrafter
    Contributor

    (recall that we also use the nonstandard notation N for the nonzero natural numbers)

    If only the same symbol for natural numbers u. { 0 } was any more standard.
    Fortunately here is the realm of definition-based maths, and any other inconvenience could be avoided by rendering NN as $\mathbb{N}^+$ and NN0 as $\mathbb{N}_0$. On opt-in basis, to be clear.

  4. tirix commented on Jul 30, 2026

    @tirix
    ContributorAuthor

    Copying here @david-a-wheeler's comment in #5411 :

    We try to follow general conventions. Unfortunately, both conventions are in use, so that isn't helpful here. There are good arguments for starting at 0 and for starting at 1. Edsger Dijkstra argued for starting at 0. I personally have a small preference for starting at 0, but as I said, 1 has good arguments too. This discussion might be better done within the general metamath mailing list because it's so cross-cutting. Here are two ideas:

    1. What interactions would be simpler if we did it some way? I suspect being consistently 0-based is easier to do and would eliminate some conversions.
    2. Where possible, can we hide it? E.g., "loop through all of them" as much as we can, so it doesn't matter so much?
  5. jkingdon commented on Aug 3, 2026

    @jkingdon
    Contributor

    Being able to use Word seems like maybe a convincing reason for 0-based but I haven't done enough with the theorems being discussed here to have an especially well informed opinion.

  6. sctfn commented on Aug 3, 2026

    @sctfn
    Contributor

    FWIW df-ee predates words in set.mm. If I was redoing it today I'd use words and 0-indices.

  7. tirix commented on Oct 2, 2026

    @tirix
    ContributorAuthor

    I see a consensus is building around 0-based indices - thanks all for your feedback!

    I've started checking what the impacts would be.
    Many impacted theorems are in @avekens's mathbox (Real euclidean space of dimension 2, Spheres and lines in real Euclidean spaces) @avekens, what would be your position about this issue in general? If we were to do the change, would you agree that I change the related theorems in your mathbox?

    Same question to @arpie-steele, for your section on Simplicial Sets.

  8. avekens commented on Oct 3, 2026

    @avekens
    Contributor

    I did not join the discussion yet, but I also would prefer 0-based indices in general, and especially for df-ee and df-ehl (if these can be unified, as proposed by @benjub , this would be fine). I think the theorems in my mathbox are based on df-ehl and not on df-ee (but I am not sure anymore). In either case, I agree that the theorems in my mathbox are adapted to the new definition(s).

  9. changed the title [-]0-based or 1-based indices for Euclidean n-spaces[/-] [+]Convert Euclidean n-spaces to 0-based indices[/+] on Oct 3, 2026
  10. tirix commented on Oct 11, 2026

    @tirix
    ContributorAuthor

    @benjub writes:

    I have not looked at the sections precisely, but do we really need both https://us.metamath.org/mpeuni/df-ee.html and https://us.metamath.org/mpeuni/df-ehl.html ? I would be happy with only the latter (well, its 0-based version).

    A difference between EE and EEHil is that the former is a set of points, while the latter is a structure (as a Hilbert space with addition, inner product, etc.).

    We have ( Base ` ( EEHil ` N ) ) = ( EE ` N ), therefore I could replace ( EE ` N ) with ( Base ` ( EEHil ` N ) ) wherever it is used.

    The alternative would be to use the more basic ( RR ^m ( 0 ..^ N ) ) instead of ( EE ` N ).

    In either case I would probably add hypotheses giving an alias, as in:

    elee.e $e |- P = ( RR ^m ( 0 ..^ N ) ) $.
    

    (choosing P for the set of points, which does not seem to have too many collisions)

    I think I would prefer ( RR ^m ( 0 ..^ N ) ). The reason is that we have two separated constructions of the Euclidean spaces:

    • one which is purely algebraic, starting with the free module over the real numbers, and building a Hilbert space,
    • one which is purely geometric, starting with words of real numbers and building betweenness/colinearity relations

    @avekens has built a bridge between the two by defining a nothing of line in an algebraic way, and proving that it matches the "geometric" definition of the line. This is the theorem eenglngeehlnm which I could not immediately convert in #5531, but this is currently the only link.

    By using ( Base ` ( EEHil ` N ) ), we would use the algebraic concept to define the geometric notion : I my view, this would break that independance. I would prefer the link to be made as late as possible.

    I would be nice to hear the opinion of others about eliminating the definition EE, and if they agree, which replacement they would prefer.

    @sctfn, this second part will massively impact your mathbox. In your comments you already suggested he would agree with the change of base, what about the removal of the EE definition?

  11. avekens commented on Oct 11, 2026

    @avekens
    Contributor

    I agree with replacing ( EE ` N ) by ( RR ^m ( 0 ..^ N ) ), and I would disagree with a replacement by ( Base ` ( EEHil ` N ) ), having the same concerns as @tirix .

    I searched for EE in set.mm, and found 984 occurences, but "only" 273 not in @sctfn `s mathbox. So all these must be replaced, preferably by an alias P = ( RR ^m ( 0 ..^ N ) ) as suggested by @tirix .

    I wonder if certain "closure" therorems may cause problems (see ~ eedimeq], whereas others become trivial (see ~ eleei) and may be removed entirely.

    The replacement of ( EE ` N ) in the definition of EEG should not cause any problems, and this is the only change which would have an impact on theorem ~eenglngeehlnm in my mathbox.

  12. benjub commented on Oct 11, 2026

    @benjub
    Contributor

    14. I agree with replacing ( EE ` N ) by ( RR ^m ( 0 ..^ N ) ), and I would disagree with a replacement by ( Base ` ( EEHil ` N ) ), having the same concerns as @tirix .

    Yes, that sounds more practical and "economical" (except maybe in a few statements that already use EEHil at other places).

  13. tirix commented on Oct 11, 2026

    @tirix
    ContributorAuthor

    I searched for EE in set.mm, and found 984 occurences, but "only" 273 not in @sctfn's mathbox.

    Ok, this sounds daunting!

    Maybe I would first do the change in Jiamin Zhao's mathbox. @littledumb would you agree?

  14. littledumb commented on Oct 11, 2026

    @littledumb
    Contributor
     Maybe I would first do the change in Jiamin Zhao's mathbox.
    

    Thanks for the ping @tirix . I agree that starting with my mathbox makes sense.

    I’ve just submitted the Pascal PR, so I’d prefer to keep that PR focused and do the EE → RR ^m ( 0 ...^ N ) migration separately right after it. I’m happy to take this on and report back if I run into any closure-theorem issues.

  15. sctfn commented on Oct 12, 2026

    @sctfn
    Contributor
  16. sctfn commented on Oct 12, 2026

    @sctfn
    Contributor
  17. tirix commented on Oct 12, 2026

    @tirix
    ContributorAuthor

    Honestly, what I would rather see happen is the addition of an extensible structure for N-dimensional geometry and a proof that ( RR ^m ( 0 ..^ N ) ) models it. EE predates extensible structures and if I were doing it all again today I’d take that approach.

    I think it's very similar to what I did with df-eeg: It is an extensible structure with:

    • ( EE ` N ) = ( RR ^m ( 0 ..^ N ) ) as its base,
    • the notion of congruence (in the dist slot)
    • the notion of betweenness (in the Itv slot)

    The theorems eengtrkg and eengtrkge then proceed to show that this EEG structure fulfills all of Tarski's axioms. This means that all results derived from those axioms are valid in EEG.

    The other advantage of that approach is that non-Euclidean geometries are also covered.

  18. littledumb commented on Oct 16, 2026

    @littledumb
    Contributor

    Hi @tirix, I'd like to revisit the sequencing of the 0-based migration in my mathbox, particularly in relation to the pending Pascal PR (#5535).

    I've done some preliminary migration experiments. The 0-based cross and triple products are verified, including their equivalence to the existing 1-based versions. I've also verified a generalization of the 3×3 determinant theorems to arbitrary three-element index sets, which should make the matrix side of the migration more straightforward.

    There is still substantial coupling between the cross/triple-product definitions and the Pascal proof chain, but the migration looks manageable.

    I see two possible approaches:

    1. Merge Add Pascal bracket identity for six points on a real conic #5535 first, then migrate the mathbox to 0-based indices in a separate PR, as originally discussed.
    2. Close Add Pascal bracket identity for six points on a real conic #5535 for now, migrate the existing mathbox first, and then resubmit Pascal Phase II using the new indexing convention.

    I'm comfortable with either approach and happy to do the migration work myself. From the perspective of the broader community effort, which sequencing would you prefer?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions