PageRenderTime 51ms CodeModel.GetById 19ms RepoModel.GetById 1ms app.codeStats 0ms

/ComputerAlgebra/Algebra/Lisp/Groupoids/plans/BasicNotions.hpp

https://github.com/PJames/oklibrary
C++ Header | 129 lines | 0 code | 2 blank | 127 comment | 0 complexity | 8e873a25946328449a0da4b1b3aa9708 MD5 | raw file
  1. // Oliver Kullmann, 9.7.2008 (Swansea)
  2. /* Copyright 2008 Oliver Kullmann
  3. This file is part of the OKlibrary. OKlibrary is free software; you can redistribute
  4. it and/or modify it under the terms of the GNU General Public License as published by
  5. the Free Software Foundation and included in this library; either version 3 of the
  6. License, or any later version. */
  7. /*!
  8. \file ComputerAlgebra/Algebra/Lisp/Groupoids/plans/BasicNotions.hpp
  9. \brief Plans on groupoids regarding the most basic notions
  10. \todo Notions and notations
  11. <ul>
  12. <li> A "groupoid" ("grd") is a pair [V,f] such that V is a set and
  13. f: V^2 -> V; thus a groupoid is formally exactly a square combinatorial
  14. matrix over V with index set V. </li>
  15. <li> A "semigroup" ("sgr") is a groupoid with associative f. </li>
  16. <li> A "unital groupoid" ("ugrd") is a triple [V,f,e] such that [V,f]
  17. is a groupoid and e is the identity element. </li>
  18. <li> A "monoid" ("mon") is a unital groupoid [V,f,e] such that [V,f] is
  19. a semigroup. </li>
  20. <li> For groups we provide four different signatures:
  21. <ul>
  22. <li> A "group" ("grp") is a semigroup [V,f] such that there exists an
  23. identity element and every element has an inverse. </li>
  24. <li> A "group with identity" ("grp0") is a monoid [V,f,e] such that
  25. every element has an inverse. </li>
  26. <li> A "group with inverse" ("grp1") is a triple [V,f,i] such that [V,f]
  27. is a semigroup which has an identity element, and where i: V -> V provides
  28. for every element an inverse. </li>
  29. <li> A "group with identity and inverse" ("grp01") is a quadruple [V,f,e,i]
  30. such that [V,f,e] is a group with identity and [V,f,i] is a group with
  31. inverse. </li>
  32. </ul>
  33. </li>
  34. <li> Quasigroups:
  35. <ul>
  36. <li> A "quasigroup" ("qgrp") is a groupoid [V,f] such that every linear
  37. equation a*x = b has a unique solution x. </li>
  38. <li> A "quasigroup with solution" ("qgrp2") is a triple [V,f,s] such that
  39. [V,f] is a quasigroup and s: V^2 -> V provides the solution, i.e., for all
  40. a,b in V we have a*s(a,b) = b. </li>
  41. <li> There is the issue of a*x=b and x*a=b ? </li>
  42. </ul>
  43. </li>
  44. <li> Promotions are grp2grp0, grp2grp1, grp2grp01, and then we have the
  45. down-casts ugrd2grd, grp02grp, grp12grp, etc..
  46. <ol>
  47. <li> Two consecutive digits don't look good?
  48. <ol>
  49. <li> We could speak of "grpn" (group with neutral element) and
  50. "grpi" (group with inverse), and "grpni". </li>
  51. <li> Then we should also use "qgrps". </li>
  52. </ol>
  53. </li>
  54. <li> It seems that for example mon2sem is not needed since we have
  55. ugrd2grd, and there are no types attached to the objects. </li>
  56. </ol>
  57. </li>
  58. <li> All the above likely should also exist in ordered versions, with
  59. prefix "o".
  60. <ol>
  61. <li> However, an "ordered monoid" for example usually is a monoid
  62. with a partial order which is compatible with the composition?!? </li>
  63. <li> Perhaps here we should use something like "listified monoid" ? </li>
  64. </ol>
  65. </li>
  66. <li> A fundamental problem is that for example lambda-expressions cannot
  67. be put (reliably) into a set (equality would be decided here w.r.t.
  68. identicallity of terms):
  69. <ol>
  70. <li> So besides "set-groupoids" we need other forms of groupoids. </li>
  71. <li> The base-set could be specified by a pair [n,l], where n is a
  72. natural number from 0 to inf, specifying the size of the initial segment
  73. of NN to be considered, while l is a labelling functions, which assigns
  74. a label to each now standardised element. </li>
  75. <li> In this way also certain infinite groups could be handled; but the
  76. rational numbers for example only clumsily. </li>
  77. <li> On the other hand we could use "implicit" representations by pairs
  78. [p,l], where p is some predicate (the inverse image of true specifies the
  79. set), while l is a labelling function defined on the elements of the
  80. set). </li>
  81. <li> Perhaps we introduce a module "Sets" in
  82. ComputerAlgebra/DataStructures for handling all these different set
  83. representations. </li>
  84. <li> On the other hand, the labelling function can be used with arbitrary
  85. sets, and this seems preferable. </li>
  86. <li> And the labelling function can be hidden in the other functions
  87. which need them (the composition etc.), and perhaps this suffices, at
  88. least for the moment. </li>
  89. <li> So we just stick to the naive concepts? </li>
  90. <li> But a problem occurs with automorphism groups, since our morphisms
  91. are just maps?! </li>
  92. <li> One solution would be to make the group element then just the
  93. corresponding lists-as-permutations, or some other presentation
  94. (the index in some standard enumeration, a cycle presentation etc). </li>
  95. <li> The only point in attaching the labelling function to the group
  96. presentation would be that then we know how to find it; perhaps we have
  97. the convention, that labelling functions are collected into one list,
  98. which is attached as the last element of the groupoid-as-list etc. </li>
  99. </ol>
  100. </li>
  101. </ul>
  102. \todo Partial groupoids, and extensions
  103. <ul>
  104. <li> We need "partial groupoids" ("pargrd"). </li>
  105. <li> Regarding extensions, we might want to add for example a
  106. partial inversion, and a null element; then we have the problem
  107. of the ordering of these components? </li>
  108. <li> Perhaps such non-standard extensions are always added as a list,
  109. which is the final element of the list representing the structure. </li>
  110. </ul>
  111. \todo Different forms of tests
  112. <ul>
  113. <li> Especially for groups there are different forms of the tests for
  114. defining properties, which exploit that the basic "axioms" are not
  115. independent. </li>
  116. <li> We need to provide these different versions. </li>
  117. <li> How to name them? </li>
  118. <li> And which version shall be the default? </li>
  119. </ul>
  120. */