Moodle

Allow me to say that

The way i have written this bug, it's obvious that this is my first bug report. Therefore i dare say it doen't appear to be crystal clear to the reader. So I ruefully request you to please read the forum post that generated this bug. The link is in the first line of description itself. After that, you'd know the reference to the context and will comprehend the bug better.

Sorry for the hotch-potch.

This is not a real bug but a quite normal misunderstaning of the Tolerance parameter and the significant figures requirement.

The tolerance that you set to 0 is correctly interpreted.

The number of significant figures is also an evaluation criteria. It is significant in my teaching of analytical chemistry so the actual code is OK.

And the resulting criterias are correctly interpreted are shown when you created data items.Look at the minimum and maximum values on your screenshot #2.

Sorry I just report what I understand from the posting to the forum. I will test it and come back.

Ok I find the problem.
You set Tolerance 0 and set it relative so you ask 0% error on the result so you want the exact number. If you were dividing 1/3, the correct response will 0.333333333333333 up to the decimal precision of the php settings.
The code calculate the MIn and Max value and apply a corecting factor for the decimal precision say delta so the Min= Min-delta and Max is Max+ delta.
The significant figures are applied after this calculation and and there are the figures that are displayed when you ask to fill or to see the grade.
Having a 0 relative tolerance setting is not surely what you want and this is why there is a 0.01 nominal value suggested when you fill the form.
I think that this is more a feature of the actual code than a bug although ideally the code should correct ALL the user errors or misunderstandings.

We can live with this Pierre

But i guess it is important to have this point explicit in the help which pops up when you click the icon of tolerance or set decimal places so that a teacher knows what he/she is bargaining for.

see http://moodle.org/mod/forum/discuss.php?d=55849#254804 for a more complete explanation

see http://moodle.org/mod/forum/discuss.php?d=55849#254986 for a solution tested and the tests results

Pierre has done the requisite I Guess.
This can be closed now, I suppose.

This is not so simple because if the nb of significant figures is defined in calculated question, it is not defined in numerical question.
This has to be set before as a new element of the editing display of numerical question.

As a possible solution we can use the fact that when $answer is coming from calcualted question the $answer->correctanswerlength (i.e. number of decimals) is defined but not defined in numerical

if(isset(answer->correctanserlength && $answer->correctansewrlength >= 0) {
return (round($answer->min,$answer->correctanswerlength) <= $response && $response <= round($answer->max ,$answer->correctanswerlength));
}
else{
return ($answer->min <= $response && $response <= $answer->max );
}

This is more complex because correctanswerlength is not the right parameter.It has to go with correctanswerformat.
Perhaps the best way will be to create a get_tolerance_interval specific to calculated question

Frankly Pierre,
i am not really able to follow what you are telling coz of limited tech knowledge.
however if you have realized this is a proper bug, then please go ahead to involve other people too.
I can see that i am not being very helpful to you coz i can't follow much ;-(

My comments are mostly for Tim as the bug is assigned to him.
So when the teacher is creating the datasets he see the result of calculated/questiontype.php/ function comment_on_datasetitems($question, $data, $number user )
this function before calling numerical/get_tolerance_interval() add the followiing parameters
$calculated->tolerance = $answer->tolerance;
$calculated->tolerancetype = $answer->tolerancetype;
$calculated->correctanswerlength = $answer->correctanswerlength;
$calculated->correctanswerformat = $answer->correctanswerformat;
$virtualqtype->get_tolerance_interval($calculated);
if ($calculated->min === '') { // This should mean that something is wrong $errors .= " -$calculated->answer"; $stranswers .= $delimiter; } else {
$stranswers .= $delimiter.$calculated->answer;
$strmin .= $delimiter.$calculated->min;
$strmax .= $delimiter.$calculated->max;
expecting that numerical/get_tolerance_interval() wil use the $answer->correctanswerlength and $answer->correctanswerformat the same way that they are used in qtype_calculated_calculate_answer($formula, $individualdata,
$tolerance, $tolerancetype, $answerlength, $answerformat='1', $unit='')
i.e. a somewhat multistep code (see the code in calculated/questiontype.php)
I will try to figure if the modifications should be done in calculated/questiontype.php or in numerical/questiontype.php.
Because a value of tolerance of 0.001 can be represented by 0.001 or 1.0e-3 the code should be able to handle the two solutions with the right significant figures in min and max.

I propose a solution which copy to numerical/questiontype.php with some modifications the qtype_calculated_calculate_answer from calculated/questiontype.php
The resulting function has been tested at http://132.208.141.198/moodle_head/testnumericala.php
There are some problems when the values are near the PHP precision limit. should we test this further?
The code modification have been done on http://132.208.141.198/moodle_head/

So Tim, when you are ready to work on, just add a comment, i am on the watching linst of this bug

Will add some further validation procedure when buiding datasetitems (datasetitems_form.php) so that problems with significant figures and tolerance values are pinpointed and corrected.
see http://moodle.org/mod/forum/discuss.php?d=87939

Similar problem at http://tracker.moodle.org/browse/MDL-14433

Thanks for reporting this issue.

We have detected that this issue has been inactive for over a year has been recorded as affecting versions that are no longer supported.

If you believe that this issue is still relevant to current versions (2.1 and beyond), please comment on the issue. Issues left inactive for a further month will be closed.

Michael d;

lqjjLKA0p6

I'm closing this issue as it has become inactive and does not appear to affect a current supported version. If you are encountering this problem or one similar, please launch a new issue.