Data Precision
Data Precision
Can anyone tell me whether there is a maximum number of digits (before or after the decimal point) that TM1 can hold in a cell?
thanks ........hugh
thanks ........hugh
-
- Site Admin
- Posts: 1458
- Joined: Wed May 28, 2008 9:09 am
Re: Data Precision
http://www.tm1forum.com/viewtopic.php?p=13746 and similar postings should help.
Re: Data Precision
David
... thanks for that. I had searched the database (and FAQs) but found nothing precise enough. Unless I misread, the one you pointed me to concedes that he has "no idea" where the decimal limit is. He is also talking only about the decimal limit rather than the whole number.
I can follow up with IBM, but was hoping for a quicker route here.
thanks anyway ............hugh
... thanks for that. I had searched the database (and FAQs) but found nothing precise enough. Unless I misread, the one you pointed me to concedes that he has "no idea" where the decimal limit is. He is also talking only about the decimal limit rather than the whole number.
I can follow up with IBM, but was hoping for a quicker route here.
thanks anyway ............hugh
-
- Site Admin
- Posts: 1458
- Joined: Wed May 28, 2008 9:09 am
Re: Data Precision
Hugh, TM1 uses standard 32-bit floating point for numbers. The Wikipedia entries for floating point
http://en.wikipedia.org/wiki/IEEE_754-2008
should give you what you need.
http://en.wikipedia.org/wiki/IEEE_754-2008
should give you what you need.
Re: Data Precision
... the answer, per IBM, is 15 digits. The reply has now been published as a Technote on the IBM website. So if you have 6 digits to the left of the decimal point, you can only have 9 on the right ....etc etc.
- qml
- MVP
- Posts: 1096
- Joined: Mon Feb 01, 2010 1:01 pm
- OLAP Product: TM1 / Planning Analytics
- Version: 2.0.9 and all previous
- Excel Version: 2007 - 2016
- Location: London, UK, Europe
Re: Data Precision
For those interested, the technote is available here:
https://www-304.ibm.com/support/docview ... wg21515228
The technote goes:
https://www-304.ibm.com/support/docview ... wg21515228
The technote goes:
TM1 Precision
Technote (FAQ)
Question
What is the decimal precision of TM1?
Answer
TM1 stores data in IEEE-754 Floating Point Double.
The maximum number of digits is 15+ (almost 16, but some 16 digit number will not fit with full precision).
TM1 will clip to 14 digits for display.
By default Architect will display 9 digits of precision after the decimal point. This can be modified by by defining a custom format for the cell. Of course, the same overall 15 digit limit still applies. If one has 10 digits to the left of the decimal point, there will be only 5 digits to the right.
Kamil Arendt
-
- MVP
- Posts: 2836
- Joined: Tue Feb 16, 2010 2:39 pm
- OLAP Product: TM1, Palo
- Version: Beginning of time thru 10.2
- Excel Version: 2003-2007-2010-2013
- Location: Atlanta, GA
- Contact:
Re: Data Precision
I would caution anyone who is expecting TM1 to maintain this level of precision. I have seen numerous instances when someone enters 5 in a cube and TM1 stores it as 4.99999999, or something to that effect. It's never been a big deal to me because I've never cared about anything beyond three of four decimal places but I see this all the time on both ENTERED values and CALCULATED values. I've never seen any rhyme or reason behind it.hbell wrote:... the answer, per IBM, is 15 digits. The reply has now been published as a Technote on the IBM website. So if you have 6 digits to the left of the decimal point, you can only have 9 on the right ....etc etc.
- Steve Rowe
- Site Admin
- Posts: 2455
- Joined: Wed May 14, 2008 4:25 pm
- OLAP Product: TM1
- Version: TM1 v6,v7,v8,v9,v10,v11+PAW
- Excel Version: Nearly all of them
Re: Data Precision
As per David's comment, the weirdness you talk about Tomok is to do with the fact for some numbers it's not possible to store them with 100% accuracy in base 2 (32-bit floating point base 2 at least). If you input one of these numbers it gets approximated in base 2 and then when you read it back in base 10 it is not exactly the same as the number you entered.Hugh, TM1 uses standard 32-bit floating point for numbers. The Wikipedia entries for floating point
http://en.wikipedia.org/wiki/IEEE_754-2008
should give you what you need.
This isn't a problem unique to TM1 though.
Cheers,
Steve
Technical Director
www.infocat.co.uk
www.infocat.co.uk
-
- Community Contributor
- Posts: 300
- Joined: Mon Mar 23, 2009 10:50 am
- OLAP Product: PAW/PAX 2.0.72 Perspectives
- Version: TM1 Server 11.8.003
- Excel Version: 365 and 2016
- Location: South London
Re: Data Precision
Will actually be 64bit, Double Precision, Floating Point for this level of numeric accuracy (see the Wiki Entry). I am nitpicking a bit since the principle of inexactness applies to all FP arithmetic which is the main point of the poster.
FP Makes for quick calculations but surprisingly there is no provision for exact numbers within TM1 which is interesting seeing as it is primarily used in accounting although 15.9 digits = x,xxx,xxx,xxx,xxx.xx ie 10 Trillion which is even enough to represent the Uk national debt after Gordon Brown has finished with it...
FP Makes for quick calculations but surprisingly there is no provision for exact numbers within TM1 which is interesting seeing as it is primarily used in accounting although 15.9 digits = x,xxx,xxx,xxx,xxx.xx ie 10 Trillion which is even enough to represent the Uk national debt after Gordon Brown has finished with it...
- garry cook
- Community Contributor
- Posts: 209
- Joined: Thu May 22, 2008 7:45 am
- OLAP Product: TM1
- Version: Various
- Excel Version: Various
Re: Data Precision
Yay, I guessed right at 15
And indeed, although that's a high degree of granularity, some calculated allocation splits can fall foul of this when a very high dp calc'd %age is applied to a very large base number (as I indicated in the post linked to above) so it can be an issue occasionally.
Still, multiplying up and then dividing down gets round it so wasn't a huge issue.
And PS - Alistair "I'll read a book on economics for beginners" Darling was probably just as bad for "our" national debt (I'll avoid my Scottish rant on SNP/Labour/Tories given the context).

And indeed, although that's a high degree of granularity, some calculated allocation splits can fall foul of this when a very high dp calc'd %age is applied to a very large base number (as I indicated in the post linked to above) so it can be an issue occasionally.
Still, multiplying up and then dividing down gets round it so wasn't a huge issue.
And PS - Alistair "I'll read a book on economics for beginners" Darling was probably just as bad for "our" national debt (I'll avoid my Scottish rant on SNP/Labour/Tories given the context).