As of now, the serialisation/deserialisation of QTYPE_FIXEDPOINT is exact the same as for QTYPE_INT
Paul provisioned the field decimal_places in struct question but it is not utilised yet. The decimal info is also not passed on to the client nor stored in the answer
The idea of this type is that the question requires (and validates) a defined accuracy, otherwise it would be just a free float we need to parse at the backend (count decimal point)
This is a special scenario for the serialisation deserialisation
{
value: 314 // lonlon
decimal_places:0 // int
}
json number: 314 // division by zero!
serialised answer: "314"
{
value: 314 // lonlon
decimal_places: 100 // int
}
json number: 3.14
serialised answer: "314"
{
value: 314 // lonlon
decimal_places: 1000 // int
}
json number: 0.314
serialised answer: "0.314"
affected:
- new serialise()
- new deserialise()
- answer_set_value_raw()
- answer_get_value_raw()
- python next_question()?
As of now, the serialisation/deserialisation of
QTYPE_FIXEDPOINTis exact the same as forQTYPE_INTPaul provisioned the field
decimal_placesin structquestionbut it is not utilised yet. The decimal info is also not passed on to the client nor stored in the answerThe idea of this type is that the question requires (and validates) a defined accuracy, otherwise it would be just a free float we need to parse at the backend (count decimal point)
This is a special scenario for the serialisation deserialisation
affected: