Latex3: تعريف \ tl_if_ صحيح: 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 Ok للاسم ولكن الوظيفة مفيدة ، وتطابق العلامة القديمة في كتاب tex للتحقق مما إذا كان الرقم. أوافق على أنه يمكن تنفيذ عدد صحيح باستخدام regex ولكنه سيكون بطيئًا

تحسين مع تعليقاتك:

\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 يعني أنه + - + - + - + - + - + - + - + - + - + - + - + - + 0000000000000000000000000000000000000000000000000000000 يمكن كسر \ romannumeral ...

إذن ما هو الحد الأقصى لحجم السلسلة؟

@ bastien-roucaries \romannumeral ينقسم فقط مع "الرقم كبير جدًا" لرقم غير صفري. يمكن أن تأخذ TeX سلسلة طويلة عشوائية من الأصفار طالما أن العدد الصحيح الناتج يقع ضمن نطاق [−2³¹ − 1، 2³¹ − 1].

@ bastien- roucariesblefloch لن أنسى الأعداد الصحيحة في شكل سداسي عشري أو ثماني. و

-`a

هو عدد صحيح أيضا.

يوجد اختبار داخلي للأرقام في l3bitset \__bitset_test_digits:nTF . لا يتعامل مع الإشارات لأن هذا لم يكن ضروريًا ولكن يجب أن يتعامل مع التعبيرات الصحيحة.

كما ألمحت @ eg9 للتو ، ما هي حالة الاستخدام الفعلية هنا؟ هل هو فحص مستند على مستوى المستخدم لسلسلة من الأرقام ، أو التحقق من أن السلسلة هي إدخال صالح لوظيفة عدد صحيح expl3. يبدو الأخير أكثر فائدة في سياق expl3 ، ويعني بشكل أساسي أنه لم يتبق شيء بعد \numexpr#1 لذلك لن تكون هناك حاجة للتحقق البطيء من السلاسل الحرفية للأرقام.

davidcarlisle هذا الخطأ يتعلق بالحالة الأولى ، لكني أرغب في الاستخدام الثاني

لا أعتقد أنني أؤيد تمديد طبقة البرمجة L3 بامتدادات عشوائية تكون (ربما) مفيدة في مواقف خاصة ولكن ليس لديها حالات استخدام واضحة مطلوبة بانتظام. بالنسبة لي هذا هو أحد الأمثلة. إذا بدأنا بذلك ، فأين ننتهي؟ كم عدد "هل هذا tl بعض X" خاص يجب أن ندعمه بعد ذلك؟ تصويتي على هذا لا. ليس للغة الأساسية.

FrankMittelbach معرفة أنه يمكننا إجراء بعض العمليات الحسابية أو عدم القيام بها على TL أمر مفيد. يمكن إجراء الآخر باستخدام regex ، ولكن مع وجود مشكلة في أنه لا يعمل في توسيع السياق (وأنا بحاجة إلى هذا الاختبار للعمل في توسيع السياق)

بدون شك. ولكن هل هو مفيد بما يكفي لضمان إدراجه في اللغة الأساسية (أو يتم توفيره فقط كجزء من بعض رموز الحزمة عند الحاجة فعليًا)؟ هذا هو السؤال المطروح بالنسبة لي هنا وحتى الآن لم أر حقًا الحجج التي تؤيد إدراجها.

يمكنك طرح نفس السؤال عن "هل هو بُعد" ، أو "هل هو مجرد تخطي" ، أو "هل هو مجرد أحرف" ، أو "هل يحتوي على أحرف غير ascii" ، أو "هل هو تنسيق تاريخ" ، و ، و ... الاحتمالات مفتوحة تمامًا ويمكنك بالنسبة لمعظمهم إنشاء حالة استخدام أو اثنتين. لكن 99٪ من الوقت سيجلسون هناك ويشغلون مساحة. وعلى الرغم من أن المساحة ليست علاوة كما كانت في الماضي ، إلا أنها لا تزال تزيد من تعقيد النظام الأساسي وإمكانية صيانته. إذن مرة أخرى ، هل هذه الوظيفة ذات استخدام واسع ومتكرر؟ إذا كانت الإجابة بنعم ، وأسمع حججًا مقنعة لذلك فيمكن اعتباره مرشحًا للإدراج. إذا لم يكن الأمر كذلك ، فيجب تنفيذه كجزء من الكود الذي يحتاجه.

FrankMittelbach المشكلة خاصة بـ biblatex هنا. نحتاج إلى اختبار ما إذا كان بعض الحقول عددًا صحيحًا (فكر في عدد الصفحات) وكذلك إجراء بعض العمليات الحسابية عليه ، في سياق قابل للتوسيع.
حسنًا ، ti محدد ولكن الجزء الصعب هو العناصر القابلة للتوسيع.
قد يكون هذا النوع من الاختبار يجب فقط توثيقه. قراءة المستند لا أعرف كيفية القيام به ، وعلاوة على ذلك ، يعتقد جوهر biblatex أنه من غير الممكن اختبار (توسيع comptabible) إذا كان رمزًا مميزًا إذا كان عددًا صحيحًا.

قد يكون الحل هو جعل regex قابل للتوسيع (أعتقد أنه سيكون رائعًا)

لا تفهموني بشكل خاطئ ، أنا لست ضد ذلك على الإطلاق لأننا نساعدك على جانب biblatex لإنجاح هذا العمل ، وقد يكون من الجوهري أننا نفتقد بعض الوظائف التي يجب أن تكون جوهرية لدعم ذلك. نقطتي هي أن النواة يجب أن تقتصر على الاحتياجات "العامة" وأن توفر الأساس العام الأساسي لكتابة رمز خاص ، ولكن لا تقدم كل أنواع الامتدادات التي نادرًا ما تستخدم على الإطلاق (على سبيل المثال في هذه الحالة عندما يكون biblatex هو ليس مستخدما). وإلا فسوف ينتهي بنا الأمر بمجموعة كبيرة من الأوامر المتضخمة في النهاية.

عادةً ما يأتي جعل الأشياء تعمل بشكل قابل للتوسيع مصحوبًا بعلامة أسعار باهظة ، إما في وظائف محدودة أو فقدان السرعة أو كليهما. لذلك أشك في أنها فكرة جيدة أن تحاول جعل regex قابلًا للتوسيع ، لكنني تركت blefloch يعلق على ذلك.

ولكن دون معرفة حالة الاستخدام الخاصة بك بمزيد من التفصيل: في مكان ما يتم إعداد الحقول الخاصة بك ولا يتم ذلك بشكل موسع لأنه سيتطلب تعيينات ، لذلك في هذه المرحلة يمكنك تحديد ما إذا كان لديك عدد صحيح أو أي شيء آخر وتسجيل هذه الحقيقة التي يمكن ثم يتم استخدامها على نطاق واسع (لست متأكدًا من أن ذلك يساعد أو أنه ممكن ، ولكنه سيتجنب اختبار الحقل مرارًا وتكرارًا).