dhis2-devs team mailing list archive

[Calle Hedberg <calle.hedberg@xxxxxxxxx>]

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@xxxxxxxxx> 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@xxxxxxxxx>
> 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@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxx
>>>>>> tel:+46764147049
>>>>>>
>>>>>> _______________________________________________
>>>>>> Mailing list: https://launchpad.net/~dhis2-devs
>>>>>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>>>>>> Unsubscribe : https://launchpad.net/~dhis2-devs
>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Jason P. Pickering
>>>> email: jason.p.pickering@xxxxxxxxx
>>>> tel:+46764147049
>>>>
>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~dhis2-devs
>>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~dhis2-devs
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>
>
> --
> Jason P. Pickering
> email: jason.p.pickering@xxxxxxxxx
> tel:+46764147049
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dhis2-devs
> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxx

Skype: calle_hedberg

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