Numbers formatted with sigfig() will not use scientific notation

[Uriel-Cerem-Devlion]

In the past (until plugin version 5.3.6) we were able to see big number that we used for the scintific totation XeY, where X is a base, e stand for the power of 10, and Y is the power value.

Until we upgraded the plugin version (due to upgrading moodle to 4.5), we've been able to see the generated number via variables, and also student answer, in this notation.

It might be ralted to this opened issue - #243

How to restore?

1. install on moodle 4.4 qtype_formula version 5.3.6, and on moodle 4.5 the plugin version 6.2.2
2. create a quiz with formula question, use 2 variable - one holds a number with the notation (something like 5.21e12) and another variable that calls the first one using it for calculation.
3. add an expected answer, also in the notation.
4. use preview to see the qestion - you will see difference. also, if you try to save a student submission with the same notation, the teacher view will not see the notation in the student's answer.

[PhilippImhof]

Hello @Uriel-Cerem-Devlion and thanks for reporting this.

For me, numbers are output in scientific notation as soon as their absolute value is above (or equal to) 1e14 or below 0.0001:

These are the following variables:

a=fact(19);
n = 15.2 * 5.511838962e23;
m = 1.5e100;
q = 0.0000005;

That behaviour only changes if I use sigfig, because sigfig uses PHP's built-in number_format which will never return a number in scientific notation, and it used to do so already in legacy versions, as you can see in the following code snipped from 5.3.x:

moodle-qtype_formulas/variables.php

Lines 304 to 315 in 77b2664

	function sigfig($number, $precision) {
	if ($number == 0) {
	$decimalplaces = $precision - 1;
	} else if ($number < 0) {
	$decimalplaces = $precision - floor(log10($number * -1)) - 1;
	} else {
	$decimalplaces = $precision - floor(log10($number)) - 1;
	}
	$answer = ($decimalplaces > 0) ?
	number_format($number, $decimalplaces, '.', '') : number_format(round($number, $decimalplaces), 0, '.', '');
	return $answer;
	}

Compare to the following PHP snippet:

$n = 0.000001;
    
var_dump($n);  // -> float(1.0E-6)
var_dump(number_format($n, 8, ".", "")); // string(10) "0.00000100"

That leaves the question why you did not see this behaviour in earlier versions. My suspicion is that in earlier versions the output from sigfig (a string) was, in certain situations, converted back to a number. Once it is a number again, it will be output according to the normal PHP rules, as stated above. The following little test shows that this guess is plausible:

$n = 0.000001;
    
var_dump(number_format($n, 8, ".", "")); // string(10) "0.00000100"
var_dump(number_format($n, 8, ".", "") * 1.0); // float(1.0E-6)

I will try to provide a fix. Although this might seem easy at first, it is not, because that re-conversion from string to number can have negative side-effects. Also note that this conversion was not intentional in legacy versions. Rather it "just happened", because the old code used to call eval() and simply piped its stuff to the PHP interpreter. The interpreter will read the 0.000001 and interpret it as a number.

[PhilippImhof]

Just to give a quick example of why things are complicated.

Take the following variable definitions:

a=0.3;
b=sigfig(a, 2);

And the following question text:

{a}
{b}

On the left, we have the current version. The right version uses the legacy version 5.3.x. Due to the re-conversion of the sigfig output to a number, the trailing zeroes are lost in legacy code. I consider this as a bug in the sense that 0.3 and 0.30 do not convey the same meaning.

[Uriel-Cerem-Devlion]

Hi @PhilippImhof ,

Thank you for your quick reply!
As you said, if the value is explicit enough and not going through some other function or complex logic, it is presented correctly.

Yes, I understand the difiiculties as a devloper my self. This bug was reported to us from a client that experienced it, and we right away understood the complexity about it and about the .

I actually briefly tried myself to find a case or logic that will help reduce the bug into it, but I encounter a lot of places in code and type conflict that may cause that.

If I could help. could you direct me to what part of the code may be relevant? I've tried by intuition to look into variables.php and renderer.php but it was too shallow digging.

Thanks in advance!

[PhilippImhof]

@Uriel-Cerem-Devlion You might want to have a look at #301 and give it a try. It makes sure that string-typed numbers (as the ones coming from sigfig()) are converted back to numbers before they are rendered by the browser.

This brings back the legacy behaviour (that I consider as wrong) where sigfig(3.5, 3) will be displayed as 3.5. That is unfortunate, but it did not seem to bother the users too much.

[shenkarcollage]

Hello , I'm the client who work with Uriel :) . I'll try to explain myself a bit better:
in Moodle 4.5 I have these settings in our specific Formulas Question Type problem:
Random variables :
a={15.2:48.6:2.3};
c={3.51e24:9.89e24:0.5e24};

Global variables:
n=a5.511838962e23;
b=sigfig(c,3);
m=(b30.974)/(1000*6.022e23);

question text:
How Many P atoms in {a}  OZ?

Part 1
1
....
Answer Type: Number
Answer: sigfig(n,3)

Part 2
1
How Many kg  in {b}  Atoms of P?
.....
Answer Type: Number
Answer : sigfig(m,3)

as you see in the Preview of the question in Moodle it looks like this were the text in the question (green square in the image) is not priview as it should be. and the answer after clicking "fill in current responses" is also not as it should be (red square in the image)

[PhilippImhof]

Thanks @shenkarcollage

I have well understood what @Uriel-Cerem-Devlion explained. And I have suggested a fix in #301, waiting for feedback.

[shenkarcollage]

I wasn't sure, sorry, that's why I gave the certain example just incase.
I appreciate your help very much/ Thanks a lot

[PhilippImhof]

@shenkarcollage No worries at all, I appreciate you chiming in. It is always good to have direct feedback from the people who actually encounter a certain problem.

Note that the fix I have suggested will not change the behaviour when clicking "Fill in correct responses", it only affects the display of numbers in the question text and the feedback (including "the correct answer is…").

Fixing it for the "Fill in correct response" would need a separate approach and does not seem so important to me, because (i) the number given is a valid input for a correct answer and (ii) that functionality is never shown to students. It is only available to teachers when they are testing their own questions and want to check their grading and/or feedback.

[shenkarcollage]

This could be great and good enough :"Note that the fix I have suggested will not change the behaviour when clicking "Fill in correct responses", it only affects the display of numbers in the question text and the feedback (including "the correct answer is…")."

Thank you