Fwd: From pretext-support dynamic fill-in exercise allowed operations

[Charilaos Skiadas]

(Redirecting to -dev)

As long as we are dreaming, here's what I would probably like to see. I hope I'm not stepping on too many toes. And there’s probably a ton of things I’m missing.

I think the bottom line is I like Rob’s suggestion for using some existing computation engine and would like to see the idea hashed out more. Though I would rather not limit the computation engine/language.

1. First a suggestion for a #context block that can go almost anywhere and is used to define a dictionary-map of name-value pairs, with values randomly generated or specific. It has an associated label used to reference it from elsewhere. Then #var entries can be used to get its values. An alternative to this would be a "setup" block to be delegated to the API described below, but to be ran on problem generation (i.e. when user views page, not when answering). I think this can have usefulness aside from this particular use-case.

2. The #evaluation tag gets a @language attribute and an @api attribute. Language can be anything and is simply passed to the API (with one exception below). The API is either a direct https link or a name for a link defined in the configs. A @context may also be specified.

3. PreTeXt does not specify or provide any APIs, but perhaps provides an in-browser javascript (possibly also python?) implementation. I.e. if language is js and no api is provided, we handle it in-browser.

4. An optional <code> block inside evaluation, for code to be run on user submission. 

5. Each #evaluate -> #test can contain #apiobj whose body (or @value) is a boolean-evaluating expression in the language.

6. The API is given a json document containing the language, the context, the code block, and an array of the #apiobj test expressions. It is expected to "evaluate the code block and each test expression in the provided context and return the results of the test expressions".

7. I think that the PreTeXt team should be minimal in just specifying the form of the API request/response format, and not try to actually implement any APIs, beyond any in-browser things.

Here's the overall format I am envisioning:

<exercise>

    <context label="..." seed="..">   

        <!-- Optional new thing, based on RNG work? Allows the creation of a context of RNG- or specific values --!>

        <!-- To be accessed using <var ...> elsewhere --!>

        <!-- Seed provided for static version or generated. --!>

        <rng name="b" />      b set to random in [0,1]  (type="double" implicit)

        <rng name="c" type="integer" min=0 max=5 /> 

        <rng name="d" type="double" min=3 max=4 />

        <const name="foo" type="string" value="A fixed name here" />

    </context>

    <statement>

     ... use <fillin name="a" />  <-- entry by user, always named

     ... use <var context="..." name="b" />   <-- dynamically generated value provided by "context" above. Maybe use new <value> tag instead?

     </statement>

     <evaluation language="js" api="..." context="...">

        <code>

        ... Code ran by the API on user submission.

        ... Receives as "local variables" the vars from context.

        </code>

        <evaluate>

            <test>

                <apicmp> ... expression in the language ... </apicmp>

            </test>

            <test> ... </test>

        </evaluate>

     </evaluation>

</exercise>

API request: 

{

    language: ...,

    context: { seed: ..., b: ..., c: ... },

    code: "...from <code> block...",

    tests: ["testcode1", "testcode2", ...]

}

The API is responsible for placing the context appropriately in the code so they are local variables, and to add the testcode blocks and store their results.

API response:

{

    success: true/false,  // True if all tests passed

    tests: [ true, false, false, ...]  // Answer for each test.

}

Example (with context):

<exercise>

    <context label="modulo">

        <rng name="a" type="integer" min="12" max="20" />

        <rng name="b" type="integer" min="4" max="8" />

    </context>

    <statement>

        Compute the modulo: <var context="modulo" name="a" />  modulo <var context="modulo" name="a" /> equals <fillin name="c" />.

    </statement>

    <evaluation language="js" context="modulo">

        <!-- No code needed--!>

        <evaluate><test><apicmp> c == a % b </apicmp></test></evaluate>

    </evaluation>

</exercise>

Charilaos Skiadas
Department of Mathematics
Hanover College

Begin forwarded message:

From: "'Rob Beezer' via PreTeXt support" <pretext...@googlegroups.com>

Subject: Re: [pretext-support] dynamic fill-in exercise allowed operations

Date: January 22, 2026 at 12:08:31 AM EST

To: pretext...@googlegroups.com

Reply-To: pretext...@googlegroups.com

Nothing here should be construed as minimizing Hunter's  request.

The possible requests for supported operators is vast.  How about polynomial multiplication with coefficients over a finite field?  ;-)  Yes, I know, out of scope right now.

Years ago, the WeBWorK folks added for me a function to pass computations to Sage and get back the results.  It was a bit cumbersome to use (nobody's fault).  Suppose there was a dedicated Sage Cell server that FITB problems could utilize?  Imagine randomized questions about non-commutative rings for an abstract algebra course.

Not sure what markup, or much else, would look like.  Just dreamin'.

Rob

On January 21, 2026 4:06:41 PM HST, "D. Brian Walton" <dbrian...@gmail.com> wrote:

Hunter,

The mod operator has not been implemented. It could be possible but would
require a dependent package is updated and could take some time. Note that
the library was designed for floating point arithmetic, and I haven't
thought about what happens with the modulus. Also, there is no integer
division implemented.

I do need to get back to that and will see about implementing that operator.

Brian

On Wed, Jan 21, 2026 at 3:38 PM Hunter Lehmann <hlehm...@gmail.com>
wrote:

Hi,

I am trying to create a dynamic exercise to compute the Hamming weight of
a random vector in F_p^n, say with entries x_1,...,x_6 in {0,1,..p-1}.  Is
it possible to use a mod operator somehow in the computation of dynamic
values in PreTeXT?

The computation I would like to do is (x_1^4+x_2^4+...+x_6^4) mod 5.  I
tried using % to invoke the mod operator but that just breaks the code.

Current exercise code below also.

Best,
Hunter

<exercise xml:id="daily-prep-fp-hamming-weight">
     <setup seed="123456">
       <de-object name="x1" context="number">
         <de-random distribution="discrete" min="0" max="4" by="1" />
       </de-object>
       <de-object name="x2" context="number">
         <de-random distribution="discrete" min="0" max="4" by="1" />
       </de-object>
       <de-object name="x3" context="number">
         <de-random distribution="discrete" min="0" max="4" by="1" />
       </de-object>
       <de-object name="x4" context="number">
         <de-random distribution="discrete" min="0" max="4" by="1" />
       </de-object>
       <de-object name="x5" context="number">
         <de-random distribution="discrete" min="0" max="4" by="1" />
       </de-object>
       <de-object name="x6" context="number">
         <de-random distribution="discrete" min="0" max="4" by="1" />
       </de-object>
       <de-object name="wt" context="number">
         <de-number>(x1^4+x2^4+x3^4+x4^4+x5^4+x6^4)%5</de-number>
       </de-object>
     </setup>
     <statement>
       <p>
         Compute the Hamming weight of <m>(<eval obj="x1"/>,<eval
obj="x2"/>,<eval obj="x3"/>,<eval obj="x4"/>,<eval obj="x5"/>,<eval
obj="x6"/>)</m>.
       </p>
       <p>
         <fillin mode="math" name="hamming_wt" ansobj="wt"
width="4"></fillin>
       </p>
     </statement>
     <evaluation>
       <evaluate name="hamming_wt">
         <test correct="yes">
         <mathcmp obj="wt" />
         </test>
       </evaluate>
     </evaluation>
   </exercise>

--
You received this message because you are subscribed to the Google Groups
"PreTeXt support" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to pretext-suppo...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/pretext-support/a06d053c-6eca-43e9-9aa9-abc0456b254cn%40googlegroups.com
<https://groups.google.com/d/msgid/pretext-support/a06d053c-6eca-43e9-9aa9-abc0456b254cn%40googlegroups.com?utm_medium=email&utm_source=footer>
.

--
You received this message because you are subscribed to the Google Groups "PreTeXt support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pretext-suppo...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pretext-support/MTAwMDAyOC5iZWV6ZXI.1769058521%40pnsh.

[dbrian...@gmail.com]

Charilaos,

I missed this thread earlier this year. Much of what you were asking for is actually present, as long as there is a javascript bridge possible. I would be interested to know how the existing structure that I describe below matches what you are asking for in terms of an API.

What you call the #context block is defined as the #setup block. The biggest mismatch between your request and what is presently available is that the #setup is specific to a single exercise-like element. (I would like to see a database-centric approach to this so that multiple exercise-like elements could share the same setup and thus have common randomized values — this is greatly complicated by the possibility of rerendering a problem with a new instance of the randomization.)

Inside of #setup, it is possible to define your own javascript code that does reasonably arbitrary setup. See this Paragraph of the guide.
That paragraph also references a vague idea of "types", which are really parser functions that can be called to parse the text in an arbitrary way to generate whatever structure you wish to use when actually evaluating the response. This has not been explored to my knowledge, but would be the analogue of what you call the #code inside of evaluation.

The <jscmp> test that is available within the #evaluation block could then do arbitrary javascript testing of the objects were generated by those parsers. The answer object of the currently being tested blank is available in the variable "ans", while any of the other submitted answer objects are in an array "ans_array". This is discussed in this Paragraph of the Guide.

One thing that would be needed to expand is for the loading of external javascript libraries. I know the Runestone Component implementation expects an array in a field named `dyn_imports` that is going to load libraries at the time the variable context is created and that will then be available also during evaluation. There is a comment in the PreTeXt code where this would be updated. But I have never experimented with that to see whether I could provide arbitrary javascript libraries (they do need to be dynamically loaded) to work with this.

I haven't had a good personal reason to invent a scenario to test out all of these hooks. However, the "API" component could be to construct the random values and then in javascript create an internal JSON of the "v" javascript object to define the "context". That other API could then be responsible to pass back a new JSON of an augmented "v" object that will contain any necessary *javascript* objects that can be used at the later steps. The jscmp calls could then send those objects back to whatever library that works with the objects to determine validity.

I will think about how to author a demonstration of several of these ideas.

Brian