Skip to main content
Solved

Scripting block parsedContent putting long numbers into scientific notation

  • July 24, 2020
  • 5 replies
  • 23 views
S
Forum|alt.badge.img+17

Hello, I’ve posted a related discussion to this one, wondering if there was any way, through the scripting block, I could break out numbers that were in scientific notation into long strings from .csv files that I was importing. Unfortunately, none of my potential solutions worked out.

I’ve started trying to figure out at what point these files get converted to scientific notation. When I view the .csv as text, I can see the long numbers as I would expect them to be uploaded. But when I upload the file via the scripting block, they are formatted in scientific notation. This is starting to make me think that the parsedContents function takes some liberties with the data and converting it. While it is tremendously helpful for a lot of my purposes this is a roadblock I’m not sure how to get passed yet.

My question would be whether or not there is a way to prevent the automatic file parsing in the scripting block from changing my fields and data? If there were some way that the file could be parsed while treating everything as a text string instead of automatically converting some things to numbers, that would be great.

I apologize in advance for any oversight or anything I might have missed in this post, I’m still new to coding and scripting. Thanks in advance!

Best answer by Billy_Littlefie

Yes, I have. When I try to stringify the input, it just changes the already formatted scientific notation numbers into a string. Unfortunately, the automatic parsing in the script block seems to run prior to me being able to run any code in the same script. It seems that as soon as you do the input.fileAsync function and upload the file, the automatic parsing happens as part of the upload process, turning my field with long numbers, into a number field and formatting it as scientific notation that I can’t translate back to a string of numbers.


Hi @Sam_Cederwall,

I believe this is an artifact of the file parser seeing a number, and representing it as such. In JavaScript, if a number is longer than 21 digits, JS will use exponential notation to represent it. Somewhat relatedly, the Number.MAX_SAFE_INTEGER in JavaScript is +/- 9007199254740991 - for numbers greater than / less than this, you’ll see JavaScript start rounding things. You can test this yourself in your browser console with the following snippet:

const foo = 12345678901234567890;
console.log(foo); // not the same digits

Getting back to your issue, there’s not currently any way to opt-out of the auto-parsing with fileAsync, but it sounds like this could be a useful feature to add - I’ll log a request. I envision this as a useRawValues or similar option, which causes parsedContent to return just the raw string values for all cells in the CSV (e.g. no date parsing, no number parsing, etc.).

As a temporary workaround for the near term, you could “trick” the parser into thinking the value is a string prefixing another character (e.g. “num1234567890…”), then stripping it out of the parsedContents result, leaving you with just the string representation of the number.

5 replies

B
Forum|alt.badge.img+19
  • Bill_French
  • Inspiring
  • 3263 replies
  • July 24, 2020

Without seeing the code, it’s difficult to advise.

Have you tried converting the values to a string and then to a number? value.toString() should expand the exponentiation to a raw number (string), and then converting to a number using parseInt() or parseFloat() might fix this.

S
Forum|alt.badge.img+17
  • Sam_Cederwall
  • Author
  • Inspiring
  • 55 replies
  • July 24, 2020

Without seeing the code, it’s difficult to advise.

Have you tried converting the values to a string and then to a number? value.toString() should expand the exponentiation to a raw number (string), and then converting to a number using parseInt() or parseFloat() might fix this.


Yes, I have. When I try to stringify the input, it just changes the already formatted scientific notation numbers into a string. Unfortunately, the automatic parsing in the script block seems to run prior to me being able to run any code in the same script. It seems that as soon as you do the input.fileAsync function and upload the file, the automatic parsing happens as part of the upload process, turning my field with long numbers, into a number field and formatting it as scientific notation that I can’t translate back to a string of numbers.

B
Forum|alt.badge.img+19
  • Bill_French
  • Inspiring
  • 3263 replies
  • July 24, 2020

Yes, I have. When I try to stringify the input, it just changes the already formatted scientific notation numbers into a string. Unfortunately, the automatic parsing in the script block seems to run prior to me being able to run any code in the same script. It seems that as soon as you do the input.fileAsync function and upload the file, the automatic parsing happens as part of the upload process, turning my field with long numbers, into a number field and formatting it as scientific notation that I can’t translate back to a string of numbers.


I cannot imagine a case where this is impossible to overcome. Share some code and let the experts take a look.

B
Forum|alt.badge.img+4
  • Billy_Littlefie
  • Inspiring
  • 58 replies
  • Answer
  • July 29, 2020

Yes, I have. When I try to stringify the input, it just changes the already formatted scientific notation numbers into a string. Unfortunately, the automatic parsing in the script block seems to run prior to me being able to run any code in the same script. It seems that as soon as you do the input.fileAsync function and upload the file, the automatic parsing happens as part of the upload process, turning my field with long numbers, into a number field and formatting it as scientific notation that I can’t translate back to a string of numbers.


Hi @Sam_Cederwall,

I believe this is an artifact of the file parser seeing a number, and representing it as such. In JavaScript, if a number is longer than 21 digits, JS will use exponential notation to represent it. Somewhat relatedly, the Number.MAX_SAFE_INTEGER in JavaScript is +/- 9007199254740991 - for numbers greater than / less than this, you’ll see JavaScript start rounding things. You can test this yourself in your browser console with the following snippet:

const foo = 12345678901234567890;
console.log(foo); // not the same digits

Getting back to your issue, there’s not currently any way to opt-out of the auto-parsing with fileAsync, but it sounds like this could be a useful feature to add - I’ll log a request. I envision this as a useRawValues or similar option, which causes parsedContent to return just the raw string values for all cells in the CSV (e.g. no date parsing, no number parsing, etc.).

As a temporary workaround for the near term, you could “trick” the parser into thinking the value is a string prefixing another character (e.g. “num1234567890…”), then stripping it out of the parsedContents result, leaving you with just the string representation of the number.

S
Forum|alt.badge.img+17
  • Sam_Cederwall
  • Author
  • Inspiring
  • 55 replies
  • July 29, 2020

Hi @Sam_Cederwall,

I believe this is an artifact of the file parser seeing a number, and representing it as such. In JavaScript, if a number is longer than 21 digits, JS will use exponential notation to represent it. Somewhat relatedly, the Number.MAX_SAFE_INTEGER in JavaScript is +/- 9007199254740991 - for numbers greater than / less than this, you’ll see JavaScript start rounding things. You can test this yourself in your browser console with the following snippet:

const foo = 12345678901234567890;
console.log(foo); // not the same digits

Getting back to your issue, there’s not currently any way to opt-out of the auto-parsing with fileAsync, but it sounds like this could be a useful feature to add - I’ll log a request. I envision this as a useRawValues or similar option, which causes parsedContent to return just the raw string values for all cells in the CSV (e.g. no date parsing, no number parsing, etc.).

As a temporary workaround for the near term, you could “trick” the parser into thinking the value is a string prefixing another character (e.g. “num1234567890…”), then stripping it out of the parsedContents result, leaving you with just the string representation of the number.


Thanks Billy, I think that will definitely work as a temporary workaround.

While the parser is super useful for a lot of cases, having the useRawValues would be super helpful for cases like this and I’m sure has applications that extend beyond just large numbers.

Thank you for all the help, much appreciated.


Terms & ConditionsAccessibility statement