Latex3: \tl_if_integer:n 정의

더 나은 여기:

\prg_new_conditional:Npnn \tl_if_integer:n #1 { p, T, F, TF }
{
  \tl_if_blank:nTF{#1}
    {
      \prg_return_false:
    }
    {
      \tl_if_blank:oTF { \__int_to_roman:w -0#1 }
      {
        \prg_return_true:
      }
      {
        \prg_return_false:
      }
    }
}

이름이 이상해 보입니다. 실제로 정수를 확인하지 않습니다(예: -5 는 정수이지만 false를 반환하고 +7 도 false를 반환함). 숫자만 있으면 테스트처럼 보입니다.

@zauguin 이름은 괜찮지만 기능은 유용하고 tex book의 이전 눈금과 일치하여 숫자인지 확인합니다. 정수를 정규식을 사용하여 구현할 수 있다는 데 동의하지만 속도가 느릴 것입니다.

귀하의 의견으로 개선:

\prg_new_conditional:Npnn \tl_if_digit:n #1 { p, T, F, TF }
{
  \tl_if_blank:nTF{#1}
    {
      \prg_return_false:
    }
    {
      \tl_if_blank:oTF { \__int_to_roman:w -0#1 }
      {
        \prg_return_true:
      }
      {
        \prg_return_false:
      }
    }
  }
\prg_generate_conditional_variant:Nnn \tl_if_digit:n { o } { p, T, F, TF }
\prg_new_conditional:Npnn \__tl_if_integer:n #1 { p, T, F, TF }
{
    \exp_args:No\str_if_eq:onTF{\tl_head:n{#1}}{+}
    {
      \exp_args:No\tl_if_digit:oTF{\tl_tail:n{#1}}
      {
        \prg_return_true:
      }
      {
        \prg_return_false:
      }
    }
    {
      \exp_args:No\str_if_eq:onTF{\tl_head:n{#1}}{-}
      {
        \exp_args:No\tl_if_digit:oTF{\tl_tail:n{#1}}
        {
          \prg_return_true:
        }
        {
          \prg_return_false:
        }
      }
      {
        \prg_return_false:
      }
    }
}
\prg_new_conditional:Npnn \tl_if_integer:n #1 { p, T, F, TF }
{
  % fast path
  \tl_if_digit:nTF{#1}
  {
    \prg_return_true:
  }
  {
    % slow path
    \__tl_if_integer:nTF{#1}
    {
      \prg_return_true:
    }
    {
      \prg_return_false:
    }
  }
}

@bastien-roucaries TeX는 숫자 앞에 여러 기호를 허용하므로 일반적으로 테스트로 충분하지만 항상 그런 것은 아닙니다. 이것이 구현되면 다음과 같은 여러 기호를 허용할 수 있습니다.

\ExplSyntaxOn
\prg_new_conditional:Npnn \str_if_integer:n #1 { p, T, F, TF }
  { \exp_after:wN \__str_if_integer_sign:N \tl_to_str:n {#1} \scan_stop: }
\cs_new:Npn \__str_if_integer_sign:N #1
  {
    \if:w $
        \if_meaning:w - #1 F \fi:
        \if_meaning:w + #1 F \fi: $
      \exp_after:wN \__str_if_integer_digits:w \exp_after:wN #1
    \else:
      \exp_after:wN \__str_if_integer_sign:N
    \fi:
  }
\cs_new:Npn \__str_if_integer_digits:w #1 \scan_stop:
  {
    \tl_if_blank:nTF {#1}
      { \prg_return_false: }
      {
        \tl_if_blank:oTF { \__int_to_roman:w -0#1 }
          { \prg_return_true: }
          { \prg_return_false: }
      }
  }

\cs_new:Npn \test #1
  { \typeout { #1: \str_if_integer:nTF {#1} { INT } { NOT } } }

\test {   }
\test { ~ }
\test { 1 }
\test { - }
\test { -1 }
\test { +1 }
\test { +-+-+-1 }

\stop

테스트는 인수에서 토큰 확장을 방지하기 위한 str 입니다. 광산과 귀하의 구현 모두 기호를 확장하지 않지만 \romannumeral 를 사용하여 숫자를 확장합니다. tl 버전은 아마도 필요에 따라 모든 것을 확장해야 할 것입니다.

\str_if_integer:nTF 를 제공하는 것이 합리적이라는 데 동의하지만 허용되는 정수가 무엇인지는 아직 명확하지 않습니다. 아마도 기호 사이에 공백이 허용되어야 하지만 TeX가 허용하지 않기 때문에 정수 내에서는 허용되지 않습니까?

\romannumeral 기반 코드는 "숫자가 너무 큼" 오류와 함께 긴 숫자 문자열에 대해 중단됩니다. 아마도 우리는 한 번에 몇 자릿수만 잡는 더 느린 프로세스가 필요하지만, 자릿수 사이의 공백을 감지하는 것은 성가신 일입니다.

대안/추가는 \str_to_integer:nF 로 문자열이 정수처럼 "충분히" 보인다면(다소 느슨하다고 결정할 수 있음(그러나 잘 문서화되어 있음)) 두 번째 인수를 입력 스트림에 남겨둡니다.

@blefloch \romannumeral의 문서화된 제한은 무엇입니까?

@bastien-roucaries TeX가 처리할 수 있는 가장 큰 정수: 2³¹−1 = 2147483647.

@PhelypeOleinik @blefloch 는 +-+-+-+-+-+-+-+-+-+-+-+-+00000000000000000000000000000000000000000000000000000000000000000

그래서 최대 문자열 크기는 무엇입니까?

@bastien-roucaries \romannumeral 는 0이 아닌 숫자에 대해 "숫자가 너무 큼"으로만 중단됩니다. TeX는 결과 정수가 [−2³¹−1, 2³¹−1] 범위 내에 있는 한 임의로 긴 0 문자열을 사용할 수 있습니다.

@bastien-roucaries @blefloch 16진수 또는 8진수 형식의 정수를 잊지 않겠습니다. 그리고

-`a

도 정수입니다.

l3bitset \__bitset_test_digits:nTF 의 숫자에 대한 내부 테스트가 있습니다. 이것은 필요하지 않았기 때문에 기호를 처리하지 않지만 정수 표현식을 처리해야 합니다.

@eg9 가 방금 암시했듯이 실제 사용 사례는 무엇입니까? 숫자 문자열에 대한 사용자 수준 문서 검사입니까, 아니면 문자열이 expl3 정수 함수에 대한 유효한 입력인지 확인하십시오. 후자는 expl3 컨텍스트에서 더 유용해 보이며 기본적으로 \numexpr#1 뒤에 아무것도 남지 않으므로 문자 그대로 숫자 문자열에 대한 느린 검사가 필요하지 않습니다.

@davidcarlisle 이 버그는 첫 번째 경우에 관한 것이지만 두 번째로 사용하고 싶습니다.

나는 특별한 상황에서 (아마도) 유용하지만 정기적으로 필요한 사용 사례가 명확하지 않은 임의의 확장으로 L3 프로그래밍 계층을 확장하는 것에 찬성한다고 생각하지 않습니다. 나에게 이것은 하나의 그러한 예입니다. 그걸로 시작하면 끝은 어디일까요? 그렇다면 우리는 얼마나 많은 특별한 "이것은 X입니다"를 지원해야 합니까? 이에 대한 나의 투표는 아니오입니다. 핵심 언어가 아닙니다.

@FrankMittelbach TL에서 일부 계산을 수행할 수 있는지 여부를 아는 것이 유용합니다. 다른 하나는 정규식을 사용하여 수행할 수 있지만 확장 컨텍스트에서 작동하지 않는다는 함정이 있습니다(확장 컨텍스트에서 작동하려면 이 테스트가 필요합니다)

의심의 여지가 없습니다. 그러나 핵심 언어에 포함되는 것을 보증할 만큼 유용합니까(또는 실제로 필요할 때 일부 패키지 코드의 일부로 제공되는 경우에만)? 그것은 여기에서 저에게 질문이며 지금까지 포함을 찬성하는 주장을 실제로 보지 못했습니다.

"차원입니까?", "건너뛰기입니까?", " 그냥 글자입니까?", "비 ASCII 문자가 포함되어 있습니까?", "날짜 형식입니까?" 및, 그리고, 그리고 ... 가능성은 매우 개방적이며 대부분의 경우 한두 가지 사용 사례를 구성할 수 있습니다. 그러나 99%의 시간은 그냥 거기에 앉아서 공간을 차지할 것입니다. 그리고 공간은 과거와 같이 프리미엄이 아니지만 여전히 핵심 시스템의 복잡성과 유지 관리 가능성을 추가합니다. 다시 말하지만 이 기능이 광범위하고 반복적으로 사용됩니까? 그렇다면 포함 후보로 간주될 수 있다는 설득력 있는 주장을 듣습니다. 그렇지 않은 경우 이를 필요로 하는 코드의 일부로 구현해야 합니다.

@FrankMittelbach 문제는 biblatex에만 해당됩니다. 일부 필드가 정수인지(페이지 번호에 대해 생각) 테스트해야 하므로 확장 가능한 컨텍스트에서 이에 대해 약간의 연산을 수행해야 합니다.
Ok ti는 구체적이지만 까다로운 부분은 확장 가능한 것입니다.
이러한 종류의 테스트는 문서화되어야만 할 수 있습니다. 문서를 읽는 방법을 모르겠습니다. 게다가 biblatex 코어는 토큰이 정수인 경우 테스트(확장 가능)가 불가능하다고 생각합니다.

해결책은 정규식을 확장 가능하게 렌더링하는 것입니다(좋을 것이라고 생각합니다)

오해하지 마세요. 저는 우리가 biblatex 측에서 이 작업을 수행하는 데 도움을 준다는 것에 전혀 반대하지 않습니다. 핵심에서 이를 지원하기 위해 핵심이 되어야 하는 일부 기능이 누락되었을 수 있습니다. 내 요점은 핵심이 "일반적인" 요구 사항으로 제한되어야 하고 특수 코드를 작성하기 위한 기본적인 일반 토대를 제공해야 하지만 거의 사용되지 않는 모든 종류의 확장을 제공해서는 안 된다는 것입니다(예: biblatex가 사용되지 않음). 그렇지 않으면 결국 매우 부풀려진 명령 세트로 끝날 것입니다.

작업을 확장 가능하게 만드는 것은 일반적으로 제한된 기능이나 속도 저하 또는 둘 모두에서 막대한 가격표를 수반합니다. 그래서 정규식을 확장 가능하게 만드는 것이 좋은 생각인지 의심스럽긴 하지만 @blefloch 가 이에 대해 언급하도록 했습니다.

그러나 사용 사례를 더 자세히 알지 못하는 경우: 어딘가에 필드가 설정되고 할당이 필요하므로 확장 가능하게 수행되지 않으므로 해당 단계에서 정수 또는 다른 것이 있는지 확인하고 다음을 수행할 수 있는 사실을 기록할 수 있습니다. 그런 다음 확장 가능하게 사용하십시오(도움이 되거나 실현 가능한지 확실하지 않지만 필드를 반복해서 테스트하는 것은 피할 수 있습니다).