Infinity

[dbauer-ets]

There are many problems in physics where it is convenient to use the constant INF, for example with logical tests such as if ($x === INF) or with the function is_finite($x).

Checking for infinite values directly in the Global variables field, as is currently done, may be helpful for beginner users, but it is a significant and unjustified obstacle in advanced calculations.

In my opinion, simply notifying the user that some values or expressions are infinite would be sufficient — blocking the calculation is a poor design choice.

Here are two examples of calculations that should be possible in the Formulas question:

if ($x > 1e12) { 
    $x = INF; // Treat as infinite
}

if ($x === INF) { 
    // Handle infinite case
} else {
    // Handle finite case 
}

if (!is_finite($x)) {
    // Handle infinite case
}

The Formulas question must be usable for solving advanced scientific problems. Consequently, the handling of infinity should be completely reconsidered. Unfortunately, it has regressed compared to the earlier versions and should instead be improved, for example by taking inspiration from how PHP handles it.

:-)

[PhilippImhof]

There are many problems in physics where it is convenient to use the constant INF, for example with logical tests such as if ($x === INF) or with the function is_finite($x).

Checking for infinite values directly in the Global variables field, as is currently done, may be helpful for beginner users, but it is a significant and unjustified obstacle in advanced calculations.

It is not unjustified. Prior to PHP 8.0 (note that we still support Moodle 4.1 which may run with PHP 7.4!), division by zero only issued a warning, but yielded INF or -INF. So the reliable way to catch bad expressions was to test not only for NAN, but also for INF. Starting with PHP 8.0, division by zero always throws a fatal error, so there is room to change that check in the future and maybe only throw an error when a function or operation returns NAN.

In my opinion, simply notifying the user that some values or expressions are infinite would be sufficient — blocking the calculation is a poor design choice.

Older versions of the Formulas question had absolutely no idea what the user was calculating. They just piped it over to PHP and took what ever came back. That's why error reporting used to be so bad. As a consequence, results could change between various instances if they did not use the same (major) PHP version. And I remember that people actually had issues with such changes.

The plugin is supposed to always keep the database in a consistent state, so the validation must make sure that the question, as it is entered, will not cause problems downstream. A bad question can lead to problems during automatic grading which can invalidate an entire attempt. Teachers without admin access might not be able to access a quiz or a student's quiz attempt due to such errors. That too has happened in the past.

Therefore, I think it is an acceptable tradeoff to throw an error for calculations that are likely wrong and give the teacher to correct their input. Even if that is an obstacle for other people that might have constructed a case where using INF did actually make sense. I am convinced that most appearances of INF are not intentional, but rather due to errors.

Here are two examples of calculations that should be possible in the Formulas question:

if ($x > 1e12) { 
    $x = INF; // Treat as infinite
}

if ($x === INF) { 
    // Handle infinite case
} else {
    // Handle finite case 
}

if (!is_finite($x)) {
    // Handle infinite case
}

Note that we do not have the if-else construct in Formulas. That being said, I do not see any added value in the use of the constant INF in the code above. Why not simply write it like this:

if ($x > 1e12) {
   // Handle infinite case
} else {
  // Handle finite case
}

The Formulas question must be usable for solving advanced scientific problems. Consequently, the handling of infinity should be completely reconsidered.

That probably depends on what one sees as an advanced scientific problems. Every tool comes with some limitations. Formulas cannot rely on a computing engine like Wolfram Alpha. If things become too advanced, users should probably use STACK rather than Formulas, because STACK relies on Maxima, a full-fledged computer algebra system.

Unfortunately, it has regressed compared to the earlier versions and should instead be improved, for example by taking inspiration from how PHP handles it.

In my opinion, Formulas has made huge steps forward in the last two years, but thanks for the feedback anyway.

You are making it look as if anything had been lost. That is not the case. Earlier versions of the plugin simply said something like: "15: Some expressions cannot be evaluated numerically." A meaningless error message with the number 15 referring to the statement number, so one had to search for the offending statement first.

But I am happy to have a look at this once we drop support for PHP 7.4, which will be in December 2025, when security support for Moodle 4.1 LTS ends.

[PhilippImhof]

If we do no longer consider INF and -INF as problematic return values, then what you described here will not work anymore:

In previous versions of the Formulas question type, log10(0) was not flagged as being undefined, so I hadn’t noticed my programming error, which, although harmless in my question, was still a mistake.

The new versions of the Formulas question type now correctly indicate that log10(0) is undefined. This is excellent and once again demonstrates the high quality of your work.

log(0) and log10(0) will then return -INF and Formulas will not flag it as an error. As you said earlier, it might be desirable to have INF and -INF in calculations. But it comes with a price. What do you suggest?