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.

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

_______________________________________________

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

_______________________________________________

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

--

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

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

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