Default format for num() changeable?

[Anonymous]

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';

[Anonymous]

any ideas?

[awhitfield]

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 · Accepted solution]

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...

[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]

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]

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.