Rounding of numbers in tracker

Support - Assistance technique
1

Hi Devs,
We have some data values which are numerically precise to two decimal places. In the trackedentitydatavalue table, the numbers are correct as they should be, but in the UI, they appear to be truncated or possibly rounded to the nearest integer. Could someone confirm this is the case? If so, I think it is a bug, as the data elements have been defined to be numeric, and not integers.

Best regards,
Jason

···

Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

2

Hi Jason,

Yes, they were converted to Integer. This is fixed now in trunk.

···

On Tue, Jan 20, 2015 at 12:03 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

Hi Devs,
We have some data values which are numerically precise to two decimal places. In the trackedentitydatavalue table, the numbers are correct as they should be, but in the UI, they appear to be truncated or possibly rounded to the nearest integer. Could someone confirm this is the case? If so, I think it is a bug, as the data elements have been defined to be numeric, and not integers.

Best regards,
Jason

–
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Thank you,

Abyot.

3

Hi Abyot,
Thanks for the quick fix.

It is a bit confusing from the API I must admit. In the UI, these data elements are defined as “Value type” = Number and Number type = “Number”, but in the API JSON response, it comes out as “int” for the “type”.

It might be work considering to change the Number type to “Real” instead of “Number”. It is fairly obvious it is a number. :slight_smile:

Regards,

Jason

···

On Tue, Jan 20, 2015 at 12:47 PM, Abyot Gizaw abyota@gmail.com wrote:

Hi Jason,

Yes, they were converted to Integer. This is fixed now in trunk.

–

Thank you,

Abyot.

On Tue, Jan 20, 2015 at 12:03 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

Hi Devs,
We have some data values which are numerically precise to two decimal places. In the trackedentitydatavalue table, the numbers are correct as they should be, but in the UI, they appear to be truncated or possibly rounded to the nearest integer. Could someone confirm this is the case? If so, I think it is a bug, as the data elements have been defined to be numeric, and not integers.

Best regards,
Jason

–
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

4

Yes kind of confusing … that is why I ended up with the bug. Since I was getting int through the web-api, I simply used parseInt … hence the rounding.

···

On Tue, Jan 20, 2015 at 1:58 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

Hi Abyot,
Thanks for the quick fix.

It is a bit confusing from the API I must admit. In the UI, these data elements are defined as “Value type” = Number and Number type = “Number”, but in the API JSON response, it comes out as “int” for the “type”.

It might be work considering to change the Number type to “Real” instead of “Number”. It is fairly obvious it is a number. :slight_smile:

Regards,

Jason

Thank you,

Abyot.

On Tue, Jan 20, 2015 at 12:47 PM, Abyot Gizaw abyota@gmail.com wrote:

Hi Jason,

Yes, they were converted to Integer. This is fixed now in trunk.

–
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

Thank you,

Abyot.

On Tue, Jan 20, 2015 at 12:03 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

Hi Devs,
We have some data values which are numerically precise to two decimal places. In the trackedentitydatavalue table, the numbers are correct as they should be, but in the UI, they appear to be truncated or possibly rounded to the nearest integer. Could someone confirm this is the case? If so, I think it is a bug, as the data elements have been defined to be numeric, and not integers.

Best regards,
Jason

–
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

5

I think Jason’s suggestion makes good sense. It doesn’t make intuitive sense that people should interpret Number to mean real number as distinct to integer. Though maybe “real number” is slightly too mathematical a term for some users. I wonder is “floating point” less technical or moreso? Either way lets try and agree on an alternative to just Number.

···

On 20 January 2015 at 13:17, Abyot Gizaw abyota@gmail.com wrote:

Yes kind of confusing … that is why I ended up with the bug. Since I was getting int through the web-api, I simply used parseInt … hence the rounding.

Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Thank you,

Abyot.

On Tue, Jan 20, 2015 at 1:58 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

Hi Abyot,
Thanks for the quick fix.

It is a bit confusing from the API I must admit. In the UI, these data elements are defined as “Value type” = Number and Number type = “Number”, but in the API JSON response, it comes out as “int” for the “type”.

It might be work considering to change the Number type to “Real” instead of “Number”. It is fairly obvious it is a number. :slight_smile:

Regards,

Jason

On Tue, Jan 20, 2015 at 12:47 PM, Abyot Gizaw abyota@gmail.com wrote:

Hi Jason,

Yes, they were converted to Integer. This is fixed now in trunk.

–
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

Thank you,

Abyot.

On Tue, Jan 20, 2015 at 12:03 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

Hi Devs,
We have some data values which are numerically precise to two decimal places. In the trackedentitydatavalue table, the numbers are correct as they should be, but in the UI, they appear to be truncated or possibly rounded to the nearest integer. Could someone confirm this is the case? If so, I think it is a bug, as the data elements have been defined to be numeric, and not integers.

Best regards,
Jason

–
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

6

Dunno. Floating point sounds much geekier than “real number”, although it is of course technically more correct. Maybe “Decimal number”?

I think the more problematic issue is the API and how decimals appear to be “int”, which led to this bug, which of course is misleading.

Regards,

Jason

···

On Tue, Jan 20, 2015 at 4:12 PM, Bob Jolliffe bobjolliffe@gmail.com wrote:

I think Jason’s suggestion makes good sense. It doesn’t make intuitive sense that people should interpret Number to mean real number as distinct to integer. Though maybe “real number” is slightly too mathematical a term for some users. I wonder is “floating point” less technical or moreso? Either way lets try and agree on an alternative to just Number.

–

On 20 January 2015 at 13:17, Abyot Gizaw abyota@gmail.com wrote:

Yes kind of confusing … that is why I ended up with the bug. Since I was getting int through the web-api, I simply used parseInt … hence the rounding.

Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Thank you,

Abyot.

On Tue, Jan 20, 2015 at 1:58 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

Hi Abyot,
Thanks for the quick fix.

It is a bit confusing from the API I must admit. In the UI, these data elements are defined as “Value type” = Number and Number type = “Number”, but in the API JSON response, it comes out as “int” for the “type”.

It might be work considering to change the Number type to “Real” instead of “Number”. It is fairly obvious it is a number. :slight_smile:

Regards,

Jason

On Tue, Jan 20, 2015 at 12:47 PM, Abyot Gizaw abyota@gmail.com wrote:

Hi Jason,

Yes, they were converted to Integer. This is fixed now in trunk.

–
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

Thank you,

Abyot.

On Tue, Jan 20, 2015 at 12:03 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

Hi Devs,
We have some data values which are numerically precise to two decimal places. In the trackedentitydatavalue table, the numbers are correct as they should be, but in the UI, they appear to be truncated or possibly rounded to the nearest integer. Could someone confirm this is the case? If so, I think it is a bug, as the data elements have been defined to be numeric, and not integers.

Best regards,
Jason

–
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

7

Hi devs,

Using version 2.17 (build 17708) it seems like even if data values will be imported, the Dry Run reports that these values will be “Ignored”. If you then run the import ,the values are actually imported. Is this new behaviour from 2.17?

8

Wouldn’t it make sense to follow the Java convention so at least there is a clear way to understand what “number” means?

http://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html

···

On Tue, Jan 20, 2015 at 4:12 PM, Bob Jolliffe bobjolliffe@gmail.com wrote:

I think Jason’s suggestion makes good sense. It doesn’t make intuitive sense that people should interpret Number to mean real number as distinct to integer. Though maybe “real number” is slightly too mathematical a term for some users. I wonder is “floating point” less technical or moreso? Either way lets try and agree on an alternative to just Number.

–

On 20 January 2015 at 13:17, Abyot Gizaw abyota@gmail.com wrote:

Yes kind of confusing … that is why I ended up with the bug. Since I was getting int through the web-api, I simply used parseInt … hence the rounding.

Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp

Thank you,

Abyot.

On Tue, Jan 20, 2015 at 1:58 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

Hi Abyot,
Thanks for the quick fix.

It is a bit confusing from the API I must admit. In the UI, these data elements are defined as “Value type” = Number and Number type = “Number”, but in the API JSON response, it comes out as “int” for the “type”.

It might be work considering to change the Number type to “Real” instead of “Number”. It is fairly obvious it is a number. :slight_smile:

Regards,

Jason

On Tue, Jan 20, 2015 at 12:47 PM, Abyot Gizaw abyota@gmail.com wrote:

Hi Jason,

Yes, they were converted to Integer. This is fixed now in trunk.

–
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

Thank you,

Abyot.

On Tue, Jan 20, 2015 at 12:03 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

Hi Devs,
We have some data values which are numerically precise to two decimal places. In the trackedentitydatavalue table, the numbers are correct as they should be, but in the UI, they appear to be truncated or possibly rounded to the nearest integer. Could someone confirm this is the case? If so, I think it is a bug, as the data elements have been defined to be numeric, and not integers.

Best regards,
Jason

–
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp

Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

9

This makes sense for the API,but the other issue here is what is displayed in the UI. So we need to find some reasonably comprehensible terms for these primitives.

···

On Tue, Jan 20, 2015 at 4:12 PM, Bob Jolliffe bobjolliffe@gmail.com wrote:

I think Jason’s suggestion makes good sense. It doesn’t make intuitive sense that people should interpret Number to mean real number as distinct to integer. Though maybe “real number” is slightly too mathematical a term for some users. I wonder is “floating point” less technical or moreso? Either way lets try and agree on an alternative to just Number.

–
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

On 20 January 2015 at 13:17, Abyot Gizaw abyota@gmail.com wrote:

Yes kind of confusing … that is why I ended up with the bug. Since I was getting int through the web-api, I simply used parseInt … hence the rounding.

Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp

Thank you,

Abyot.

On Tue, Jan 20, 2015 at 1:58 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

Hi Abyot,
Thanks for the quick fix.

It is a bit confusing from the API I must admit. In the UI, these data elements are defined as “Value type” = Number and Number type = “Number”, but in the API JSON response, it comes out as “int” for the “type”.

It might be work considering to change the Number type to “Real” instead of “Number”. It is fairly obvious it is a number. :slight_smile:

Regards,

Jason

On Tue, Jan 20, 2015 at 12:47 PM, Abyot Gizaw abyota@gmail.com wrote:

Hi Jason,

Yes, they were converted to Integer. This is fixed now in trunk.

–
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

Thank you,

Abyot.

On Tue, Jan 20, 2015 at 12:03 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

Hi Devs,
We have some data values which are numerically precise to two decimal places. In the trackedentitydatavalue table, the numbers are correct as they should be, but in the UI, they appear to be truncated or possibly rounded to the nearest integer. Could someone confirm this is the case? If so, I think it is a bug, as the data elements have been defined to be numeric, and not integers.

Best regards,
Jason

–
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp

10

In rural and tribals ‘Hindi’ language, “DeciMal” word does’t sounds effective and standard, and in some of the DHIS implementing states, users had already had requested to customise data entry form with massage like “DeciMal Values Are Not Allowed For Data Entry Form”, specially in case, if any user will try to enter decimal value with dot in data entry screen. I think Bob suggestion makes effective sense to use “number” instead, because if we can’t use ‘Real Number’ than we also can’t use ‘non complex number’.

Let,s see how About is preparing to fix this controversial bug.

Regards

Brajesh Murari

Dunno. Floating point sounds much geekier than “real number”, although it is of course technically more correct. Maybe “Decimal number”?

I think the more problematic issue is the API and how decimals appear to be “int”, which led to this bug, which of course is misleading.

Regards,

Jason

···

On Tue, Jan 20, 2015 at 4:12 PM, Bob Jolliffe bobjolliffe@gmail.com wrote:

I think Jason’s suggestion makes good sense. It doesn’t make intuitive sense that people should interpret Number to mean real number as distinct to integer. Though maybe “real number” is slightly too mathematical a term for some users. I wonder is “floating point” less technical or moreso? Either way lets try and agree on an alternative to just Number.

–
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

On 20 January 2015 at 13:17, Abyot Gizaw abyota@gmail.com wrote:

Yes kind of confusing … that is why I ended up with the bug. Since I was getting int through the web-api, I simply used parseInt … hence the rounding.

Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Thank you,

Abyot.

On Tue, Jan 20, 2015 at 1:58 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

Hi Abyot,
Thanks for the quick fix.

It is a bit confusing from the API I must admit. In the UI, these data elements are defined as “Value type” = Number and Number type = “Number”, but in the API JSON response, it comes out as “int” for the “type”.

It might be work considering to change the Number type to “Real” instead of “Number”. It is fairly obvious it is a number. :slight_smile:

Regards,

Jason

On Tue, Jan 20, 2015 at 12:47 PM, Abyot Gizaw abyota@gmail.com wrote:

Hi Jason,

Yes, they were converted to Integer. This is fixed now in trunk.

–
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

Thank you,

Abyot.

On Tue, Jan 20, 2015 at 12:03 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

Hi Devs,
We have some data values which are numerically precise to two decimal places. In the trackedentitydatavalue table, the numbers are correct as they should be, but in the UI, they appear to be truncated or possibly rounded to the nearest integer. Could someone confirm this is the case? If so, I think it is a bug, as the data elements have been defined to be numeric, and not integers.

Best regards,
Jason

–
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

11

Hi,

I agree with Jason - "real number" or even worse "floating point
number" are not in common use. "Decimal number" is much better. The
use of TEXT versus STRING is similar - everybody understand what
'Text' means, but for a lot of people "String" is something is
something physical you can stretch...

The number of decimals allowed for any specific data element /
category etc should be user-specified in the relevant meta-data sheet
- with the default being 0 (similar to what was recently introduced
for indicators). Error messages during data entry can then be
standardised.

The bulk of DHIS data tend to be counts of people/patients, and for
most of those you cannot have decimals - the main exception being
weighted counts like when a day patient (somebody admitted and
discharged on the same day) is counted as 0.5 inpatient days.

It also makes sense to enforce whole numbers only for data elements
like population mid-year estimates or prevalence/incidence estimates,
even if the original model-based numbers from e.g. a statistical
agency or UNAIDS might have 10 decimals due to the use of statistical
models.

I would prefer to standardise other types of data too: use max 2
decimals for financial data, use max 3 decimals for work days (the
latter is due to the fact that less than one work day would/should be
initially rounded to work hours, with each hours representing 0.125
work days), use max 1 decimal for ambulance fuel used, and so forth.

Regards
calle

···

On 20/01/2015, Brajesh Murari <bramurari@gmail.com> wrote:

In rural and tribals 'Hindi' language, "DeciMal" word does't sounds
effective and standard, and in some of the DHIS implementing states, users
had already had requested to customise data entry form with massage like
"DeciMal Values Are Not Allowed For Data Entry Form", specially in case, if
any user will try to enter decimal value with dot in data entry screen. I
think Bob suggestion makes effective sense to use "number" instead,
because if we can't use 'Real Number' than we also can't use 'non complex
number'.

Let,s see how About is preparing to fix this controversial bug.

Regards
Brajesh Murari
Dunno. Floating point sounds much geekier than "real number", although it
is of course technically more correct. Maybe "Decimal number"?

I think the more problematic issue is the API and how decimals appear to be
"int", which led to this bug, which of course is misleading.

Regards,
Jason

On Tue, Jan 20, 2015 at 4:12 PM, Bob Jolliffe <bobjolliffe@gmail.com> > wrote:

I think Jason's suggestion makes good sense. It doesn't make intuitive
sense that people should interpret Number to mean real number as distinct
to integer. Though maybe "real number" is slightly too mathematical a
term
for some users. I wonder is "floating point" less technical or moreso?
Either way lets try and agree on an alternative to just Number.

On 20 January 2015 at 13:17, Abyot Gizaw <abyota@gmail.com> wrote:

Yes kind of confusing ... that is why I ended up with the bug. Since I
was getting int through the web-api, I simply used parseInt ... hence
the
rounding.

---
Thank you,
Abyot.

On Tue, Jan 20, 2015 at 1:58 PM, Jason Pickering < >>> jason.p.pickering@gmail.com> wrote:

Hi Abyot,
Thanks for the quick fix.

It is a bit confusing from the API I must admit. In the UI, these data
elements are defined as "Value type" = Number and Number type =
"Number",
but in the API JSON response, it comes out as "int" for the "type".

It might be work considering to change the Number type to "Real"
instead
of "Number". It is fairly obvious it is a number. :slight_smile:

Regards,
Jason

On Tue, Jan 20, 2015 at 12:47 PM, Abyot Gizaw <abyota@gmail.com> wrote:

Hi Jason,

Yes, they were converted to Integer. This is fixed now in trunk.

---
Thank you,
Abyot.

On Tue, Jan 20, 2015 at 12:03 PM, Jason Pickering < >>>>> jason.p.pickering@gmail.com> wrote:

Hi Devs,
We have some data values which are numerically precise to two decimal
places. In the trackedentitydatavalue table, the numbers are correct
as
they should be, but in the UI, they appear to be truncated or
possibly
rounded to the nearest integer. Could someone confirm this is the
case? If
so, I think it is a bug, as the data elements have been defined to be
numeric, and not integers.

Best regards,
Jason

--
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

_______________________________________________
Mailing list: DHIS 2 developers in Launchpad
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : DHIS 2 developers in Launchpad
More help : ListHelp - Launchpad Help

--
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

_______________________________________________
Mailing list: DHIS 2 developers in Launchpad
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : DHIS 2 developers in Launchpad
More help : ListHelp - Launchpad Help

--
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

_______________________________________________
Mailing list: DHIS 2 developers in Launchpad
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : DHIS 2 developers in Launchpad
More help : ListHelp - Launchpad Help

--

*******************************************

Calle Hedberg

46D Alma Road, 7700 Rosebank, SOUTH AFRICA

Tel/fax (home): +27-21-685-6472

Cell: +27-82-853-5352

Iridium SatPhone: +8816-315-19274

Email: calle.hedberg@gmail.com

Skype: calle_hedberg

*******************************************