Exponential notation


#1

I am having issues with dropsource showing large numbers with exponential notation such as 3.65e+6 when I displayed it in a text view or field.

This happens when we pull data from api such as data in bubble or through math js API. Is there a way to show the data in real numbers?

Second issue is if we performed another calculations based on the first data I pulled. For example I pulled data from the first API, say, 3.65e+6. I then try to perform another calculation from that number by multiplying it by 3. The results I have then 12, because it calculates 3.6*4. It should’ve been 3.6 millions times 4. Not 3.6 times 4.

Can anyone suggest how to handle this? How should I store these values in variable? What data types should I assign?

@sue when will the dropsource calculation be implemented? We are just trying to do simple calc and we hve to use outside API to do this and it handles numbers with exponential notation. This is quite frustrating.


#2

Hello @rkresnadi,

Engineering is getting closer to our 1st implementation of math into our platform and we’re just as excited and anxious as you to debut this. We’re only a couple weeks away. Stay tuned as when we roll out new functionality, we accompany it with an announcement here in our forum and documentation to assist in its introduction and inception. Thank you for your patience while we round out this huge new feature and get it tested properly before it is live.

To answer the datatype question, how large do your numbers get in your context? Based on memory requirements and that it also seems that your example includes decimals, Floats are roughly 3.4 * 10^38 and Doubles are 1.79 * 10^308 respectively. When you present these numbers in a label or textview, these are converted to their String value. For now however, since the math is occurring on the server side, you can handle the data type on that side and pass the number as a String data type in your API response, That would eliminate any possibility of truncating on our side since the type would remain a String from API Response to binding it with a String property in a Label, Textview, etc in your app. Beware that elements like these will add an ellipsis (…) if the string is too long to fit given the constraints of these elements.

As for the incorrect calculations, those calculations today will still need to be handled on your server side but as I said in the above paragraph, we’re nearing closer to our new math feature coming live. Please stay tuned for more detailed information on this as we’re ready to share it with you and your fellow Dropsource developer community.


#3

Thanks @wade. The numbers are in millions and should not have decimals. It is returned with decimals with exponential notation when received in dropsource. Because of that the calculation thinks the value is only 3.6, although in actuality it is 3600000. Therefore, because it thinks the value is 3.6, when I multiply it by 4, it gives me a result of 14.4. While it should’ve been 14400000 (3600000*4). Makes sense?

Any idea to solve this?


#4

Hi @rkresnadi,

I think this strategy of exponential notation return values is going to give you some unnecessary challenges in working with them in Dropsource. I would adjust your return value here and send the numbers written out. Even when our ability to calculate math operations in the platform arrives, I don’t think we’re setup to receive numbers in exponential notation in the 1st iteration here. If you want to receive Integers in the millions, I would send them written out in either Int form (drop the decimal) or I would send the number as a String.


#5

One thing that @rkresnadi hasn’t made clear is that he doesn’t have control over the format returned from the api.
He’s using the maths.js api as a workaround to perform calculations in dropsource.
And this is the way maths.js return large numbers and as far as I know there is no way to change it (I may be wrong on this).

Maybe if we had some ETA of the native calculations feature in dropsource he could decide to wait instead of spending so much time trying to get some workaround.


#6

Our math feature implementation is in its testing phases. It won’t be long now. Look for more details from us within the next week or 2. We’re super thrilled to bring this forward. We have to make sure we’ve done our due diligence given the nature and importance of the feature here.

Thanks for informing me on the nature of the mathjs output format. This is not an area of expertise for me. I did a little digging after reading this. I am seeing that mathjs uses JavaScript’s toPrecision internally. This allows for numeric precision up to 21 digits. If the returns are in the millions, they should fall within the precision bounds and have the capability to return in long form. There may be a setup step involved to ensure precise digits within the < 21 digit range though but I’m unsure on that level of detail. I found an issue on the repo the author explains and when I read that, I went and checked what the toPrecision() method details had as well. I’ll leave some links below. I hope it might help to find out how to deliver numbers within the < 21 digit bound to a long format instead.

Issue in Github Repo:

Number.toPrecision() method definition:


#7

Thanks @wade. I don’t think we can modify the output from math js.

Regarding the simple calc, when would that be available?

Thanks