Do not input private or sensitive data. View Qlik Privacy & Cookie Policy.
Skip to main content

Announcements
Write Table now available in Qlik Cloud Analytics: Read Blog
cancel
Showing results for 
Search instead for 
Did you mean: 
luissss
Contributor II
Contributor II

Strange behavior when using Num() in the load script

Hi everyone,
I’m facing a strange issue in Qlik Sense and I’m not sure whether it’s expected or a bug.

In my load script I format a numeric field like this:

Num([Field], '#.##0') as FormattedField

When I display this field in a table in the front-end, the value appears in a weird format (almost like scientific notation).
If I take the original field and apply Num() only in the front-end, the number looks correct.

What’s even stranger is that if I do something like:

[FormattedField] + 1

the value suddenly becomes normal again, as if the raw number was still there and the script formatting wasn’t interpreted properly.

Has anyone seen this behavior before?
Is this a known issue or is there something I’m missing?

Thanks!

Labels (3)
8 Replies
Lech_Miszkiewicz
Partner Ambassador/MVP
Partner Ambassador/MVP

Hi. 

What are your thousand and decimal delimiters in Main section of the script? you are using a dot "." as a thousand delimiter where typically depending on regional settings it is a character representing decimal delimiter, so things to check would be:

  • screenshot of regional settings delimiters
  • screenshot of system variables in that app
  • then next thing is whether you load this field only once or multiple times in your script as format needs to be applied from the very first time field is loaded with that particular field name.

Those are the basic things I would check. Num() function only applies format/mask but does not change actual value of the field so I am not sure as to why you would apply it in the script to what seems to be column with a measure?. 

cheers Lech, When applicable please mark the correct/appropriate replies as "solution" (you can mark up to 3 "solutions". Please LIKE threads if the provided solution is helpful to the problem.
Nagaraju_KCS
Specialist III
Specialist III

@luissss  - As far as I know, this is a known and occasionally encountered behavior in Qlik Sense, and it is almost always related to the interaction between the script's num() formatting and the internal data type handling in the Qlik engine, especially with respect to large numbers or specific locale settings.

I don't think this is a "bug", it indicates a conflict in how the data format is being saved and how it is being read back by the front-end rendering engine.

  • When you use Num(YourField, '#.##0') in a load script, you are trying to force a specific text representation (#.##0) onto a numeric value before saving it to the Qlik app model.
  • When the front-end looks at a field, it tries to read the text representation saved by the script, but if that representation is flawed or conflicts with the user's browser/app locale, it defaults to displaying a raw, unformatted numeric value, often in the strange scientific notation you describe.
[FormattedField] + 1

When you perform an arithmetic operation (such as adding 1), you force the Qlik engine to ignore the problematic text representation and work exclusively with the raw, underlying numeric value. After the calculation is complete, Qlik defaults to a simple, clean numeric format for the result, which is why it appears "normal" again. 

luissss
Contributor II
Contributor II
Author

@Nagaraju_KCS @Lech_Miszkiewicz - Hi both,
first of all, thank you very much for your support and for the detailed explanations — really appreciated.

As requested, here is the context of my app settings.
These are the regional and numeric variables defined at the top of my script:

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 FirstWeekDay=0;
SET BrokenWeeks=0;
SET ReferenceDay=4;
SET FirstMonthOfYear=1;
SET CollationLocale='it-IT';
SET CreateSearchIndexOnReload=1';
SET MonthNames='gen;feb;mar;apr;mag;giu;lug;ago;set;ott;nov;dic';
SET LongMonthNames='gennaio;febbraio;marzo;aprile;maggio;giugno;luglio;agosto;settembre;ottobre;novembre;dicembre';
SET DayNames='lun;mar;mer;gio;ven;sab;dom';
SET LongDayNames='lunedì;martedì;mercoledì;giovedì;venerdì;sabato;domenica';
SET NumericalAbbreviation='3:k;6:M;9:G;12:T;15:P;18:E;21:Z;24:Y;-3:m;-6:μ;-9:n;-12:p;-15:f;-18:a;-21:z;-24:y';

Now, the part I still don’t understand is the following:
this strange scientific-notation behaviour happens only for some numbers, not all (as shown in my screenshot).

 

c51f4fa8-5660-4dfe-a306-4c2b1538dce5.png

Most values are displayed correctly, but only specific ones are shown as something like 1254e+01.

Do you have any idea why this inconsistent behavior happens only on certain values?
Is it related to the size of the number, the string length of the formatted field, or how Qlik internally stores some dual values?

Thanks again for your help — your insights are extremely useful.

marcus_sommer

It might be related to the used binary number-system which couldn't store always exact values. This means the "normal" looking value of 42 might be stored as 41.9999999999998 - and this may enforce the scientific representation.

Within the most scenarios the n. digits aren't needed and therefore they could be just cut with a rounding-function, maybe like: round(MyValue, 0.01). More background is here:

Rounding Errors - Qlik Community - 1468808

Lech_Miszkiewicz
Partner Ambassador/MVP
Partner Ambassador/MVP

Ok..

This is interesting and I am not an expert in this but maybe @rwunderlich or @marcus_sommer  can comment more on that?

My suspicion is that the underlying value you are loading may have a precision grater than 15 digits??? and since Qlik engine internally stores numbers using the 64-bit binary data type, which means only 14-15 valid decimal digits - maybe that play a role or what I think was called "floating decimal point" - https://community.qlik.com/t5/Official-Support-Articles/Decimal-Values-In-Qlik-Sense-And-QlikView-Ju...

anyway - those are my suspicions but others may explain it better than I can?

cheers

cheers Lech, When applicable please mark the correct/appropriate replies as "solution" (you can mark up to 3 "solutions". Please LIKE threads if the provided solution is helpful to the problem.
Lech_Miszkiewicz
Partner Ambassador/MVP
Partner Ambassador/MVP

there you go - @marcus_sommer is a champ and he commented as I was typing my previous comment 🤣

cheers Lech, When applicable please mark the correct/appropriate replies as "solution" (you can mark up to 3 "solutions". Please LIKE threads if the provided solution is helpful to the problem.
Nagaraju_KCS
Specialist III
Specialist III

I think main reason for this inconsistent scientific notation (e.g., 1254e+01 instead of 12,540 or 12.540) is almost certainly related to the NumericalAbbreviation setting you have defined

SET NumericalAbbreviation='3:k;6:M;9:G;12:T;15:P;18:E;21:Z;24:Y;-3:m;-6:μ;-9:n;-12:

Comment this one and check once 

brunobertels
Master
Master