Qlik Community

Ask a Question

QlikView App Dev

Discussion Board for collaboration related to QlikView App Development.

Announcements
Join this live chat April 6, 10AM EST - QlikView to Qlik Sense REGISTER
cancel
Showing results for 
Search instead for 
Did you mean: 
Anonymous
Not applicable

Default format for num() changeable?

Hello,

I asked this question yet in the German forum, discussed with swuehl‌ and marcus_sommer‌.

I really like to know where this default format for num() is defined and if it is possible to change it globally?!?

-------------------------------------------------------------------------------------------

If I use an expression like  =num(3/17) , I get the following output in a textbox:

Meanwhile I (we?) suppose that the default format is: =Num(3/17,'##############')

Regards

Robin

my (German) settings:

SET ThousandSep='.';

SET DecimalSep=',';

SET MoneyThousandSep='.';

SET MoneyDecimalSep=',';

SET MoneyFormat='#.##0,00 €;-#.##0,00 €';

SET TimeFormat='hh:mm:ss';

SET DateFormat='DD.MM.YYYY';

SET TimestampFormat='DD.MM.YYYY hh:mm:ss[.fff]';

SET MonthNames='Jan;Feb;Mrz;Apr;Mai;Jun;Jul;Aug;Sep;Okt;Nov;Dez';

SET DayNames='Mo;Di;Mi;Do;Fr;Sa;So';

1 Solution

Accepted Solutions
Peter_Cammaert

This is my guess:

Your suggestion about a most propable internal number format may be slightly incorrect. The num function will easily switch to scientific notation when the mantissa becomes either too large or too small. IMHO there may not be any default format to speak of, just conversion behavior. Which - being more like a "fits all"-solution - might be a good though unpredictable thing.

The number 14 keeps returning. Num will output all digits as long as there aren't more than 14 (zeroes not included). As soon as you cross that limit, num switches to scientific notation with 14 mantissa digits and 5 digits for the exponent.

For example

  =num(30000 / 12345.678912345) displays 2.4300000196831

while

  =num(3000 / 123456789.12345) displays 2.4300000196831e-005

At the other end

  =num(300000 * 123456789.12345) displays 37037036737035

while

   =num(3000000 * 123456789.12345) displays 3.7037036737035e+014

Oh and BTW, it seems that the help is again not very accurate. It says that when omitting parameters 2-4, num will switch to using the Number interpretation variables. But that is not the case...

View solution in original post

7 Replies
Anonymous
Not applicable
Author

any ideas?

awhitfield
Partner
Partner

Hi Robin,

to hazard a guess, it's using

754-2008 - IEEE Standard for Floating-Point Arithmetic


http://ieeexplore.ieee.org/document/4610935/

Abstract:

This standard specifies interchange and arithmetic formats and methods for binary and decimal floating-point arithmetic in computer programming environments. This standard specifies exception conditions and their default handling. An implementation of a floating-point system conforming to this standard may be realized entirely in software, entirely in hardware, or in any combination of software and hardware. For operations specified in the normative part of this standard, numerical results and exceptions are uniquely determined by the values of the input data, sequence of operations, and destination formats, all under user control.

HTH

Andy

Peter_Cammaert

This is my guess:

Your suggestion about a most propable internal number format may be slightly incorrect. The num function will easily switch to scientific notation when the mantissa becomes either too large or too small. IMHO there may not be any default format to speak of, just conversion behavior. Which - being more like a "fits all"-solution - might be a good though unpredictable thing.

The number 14 keeps returning. Num will output all digits as long as there aren't more than 14 (zeroes not included). As soon as you cross that limit, num switches to scientific notation with 14 mantissa digits and 5 digits for the exponent.

For example

  =num(30000 / 12345.678912345) displays 2.4300000196831

while

  =num(3000 / 123456789.12345) displays 2.4300000196831e-005

At the other end

  =num(300000 * 123456789.12345) displays 37037036737035

while

   =num(3000000 * 123456789.12345) displays 3.7037036737035e+014

Oh and BTW, it seems that the help is again not very accurate. It says that when omitting parameters 2-4, num will switch to using the Number interpretation variables. But that is not the case...

View solution in original post

Peter_Cammaert

The number 14 is also a "Galactic QlikView Constant" when playing with num#(). You can stuff large numbers with up to 14 digits into num#() for proper conversion. But any number with 15 digits will be treated as text...

Anonymous
Not applicable
Author

could you explain your statement please... for me (from Germany) dot and comma are exchanged... as you see in my example


Oh and BTW, it seems that the help is again not very accurate. It says that when omitting parameters 2-4, num will switch to using the Number interpretation variables. But that is not the case...

Anonymous
Not applicable
Author

ok, I understand what you mean, if I set

SET ThousandSep=',';

SET DecimalSep='.';

then I still see a comma for num(3/14)

It's a bit confusing...

Peter_Cammaert

(Sorry for the late reply)

Yes, you are right. QlikView number formatting variables don't seem to have any effect on num() ouput. But the system settings do...

Another thought: the multi-parameter version of num() seems to fit well in the collection of controlled formatting/interpretation functions. But maybe we should see the one-parameter version of num() not as a formatting function, but more like the logical counterpart of text().

While text() can be said to "give you the string version of any dual value", num() without further specs can be said to "give you just the numerical part of a dual value", and without any formatting fuss whatsoever. Just the number, no other string--related properties... And then it becomes logical that the raw binary value will be presented using system settings only.