Pythagoras number

In mathematics, the Pythagoras number or reduced height of a field describes the structure of the set of squares in the field. The Pythagoras number p(K) of a field K is the smallest positive integer p such that every sum of squares in K is a sum of p squares.

A Pythagorean field is a field with Pythagoras number 1: that is, every sum of squares is already a square.

Examples
  • Every positive real is a square, so p(R) = 1.
  • For a finite field of odd characteristic, not every element is a square, but all are the sum of two squares,[1] so p = 2.
  • By Lagrange's four-square theorem, every positive rational number is a sum of four squares, and not all are sums of three squares, so p(Q) = 4.

Properties
  • Every positive integer occurs as the Pythagoras number of some formally real field.[2]
  • The Pythagoras number is related to the Stufe by p(F) ≤ s(F) + 1.[3] If F is not formally real then s(F) ≤ p(F) ≤ s(F) + 1,[4] and both cases are possible: for F = C we have s = p = 1, whereas for F = F5 we have s = 1, p = 2.[5]
  • The Pythagoras number is related to the height of a field F: if F is formally real then h(F) is the smallest power of 2 which is not less than p(F); if F is not formally real then h(F) = 2s(F).[6] As a consequence, the Pythagoras number of a non formally real field, if finite, is either a power of 2 or 1 less than a power of 2, and all cases occur.[7]

Notes
  1. Lam (2005) p. 36
  2. Lam (2005) p. 398
  3. Rajwade (1993) p. 44
  4. Rajwade (1993) p. 228
  5. Rajwade (1993) p. 261
  6. Lam (2005) p. 395
  7. Lam (2005) p. 396
gollark: My "fix" is this:```lua--[["Fix" for bug PS#E9DCC81BSummary: `pcall(getfenv, -1)` seemingly returned the environment outside the sandbox.Based on some testing, this seems like some bizarre optimization-type feature gone wrong.It seems that something is simplifying `pcall(getfenv)` to just directly calling `getfenv` and ignoring the environment... as well as, *somehow*, `function() return getfenv() end` and such.The initial attempt at making this work did `return (fn(...))` instead of `return fn(...)` in an attempt to make it not do this, but of course that somehow broke horribly. I don't know what's going on at this point.This is probably a bit of a performance hit, and more problematically liable to go away if this is actually some bizarre interpreter feature and the fix gets optimized away.Unfortunately I don't have any better ideas. Also, I haven't tried this with xpcall, but it's probably possible, so I'm attempting to fix that too.]]local real_pcall = pcallfunction _G.pcall(fn, ...) return real_pcall(function(...) local ret = {fn(...)} return unpack(ret) end, ...)end local real_xpcall = xpcallfunction _G.xpcall(fn, handler) return real_xpcall(function() local ret = {fn()} return unpack(ret) end, handler)end```which appears to work at least?
gollark: Fixed, but I don't really know how or why.
gollark: ... should I create a bug report?
gollark: It returns two, actually. The second one. I don't know *what* the first one is doing.
gollark: Is this some weird implementation thing or is Lua actually defined/specified to work like this?!

References
  • Lam, Tsit-Yuen (2005). Introduction to Quadratic Forms over Fields. Graduate Studies in Mathematics. 67. American Mathematical Society. ISBN 0-8218-1095-2. MR 2104929. Zbl 1068.11023.
  • Rajwade, A. R. (1993). Squares. London Mathematical Society Lecture Note Series. 171. Cambridge University Press. ISBN 0-521-42668-5. Zbl 0785.11022.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.