No scientific numeration

[Alvaro5]

Hi,
For some reasons I need to compute large numbers (like 50 digits or more), but in LabVIEW if you have a number like: 15489948953486486... so on, it will be represented and compute like, for example, 1.5E+48 (48 zeros).

I need help to avoid these zeros and use the "all" number, without any rounding as the attached example lines up.

Thanks in advance.The problem is that the output of the exponential function is not totally accurate, and this rounding effect increase the error on ahead operations 😞

[GerdW]

Hi Alvaro,

you can surely display more than just 3 significant digits:

Just change the formatting of the indicator!

Keep in mind: DBL have a resultion of ~17 decimal digits…

For some reasons I need to compute large numbers (like 50 digits or more)

Then you should look out for "Big numbers" computation libraries!

50 (decimal) digits are NOT supported by DBL or EXT.

[Gregory]

Also look out for your datatypes. Wherever you see a red dot that means LabVIEW is changing the representation of the data to match the terminal you wired it to, and it could certainly coerce your values to unexpected values if you're not careful.

[altenbach]

Your question is not very clear. Are you talking about integers or floating point numbers? Are you talking about significant digits or displayed digits? How precise should the result be? If the input is from an instrument, how many bits does it have? Are you interested in number theory?

You already got a link for the a available data types and their limitations.

Fortunately, LabVIEW is a full featured programming language, so you can write your own, e.g by representing you number as an array or cluster of smaller data types. The sky is the limit! If you know how to do it with paper and pencil, you can program it!

[Alvaro5]

I need to do an RSA algorithm with Labview, a little example of signature and verification.
I test it with very small numbers and it works(example p=11, q=5, e=7 m=2), but if I use higher integrates the signature process doesn't work well, I think that the some arithmetical operation in the signature part could be overflowed. ( because the key generation always do its job well)
I use numbers in integer format, the problem is related to the significant digits (for example, 122222222 number, is operated like 1.2*10^8, this problem occurs in the output of the exponential block, and the output of this exponential operation needs to be totally accurate to do a correct verification later...)

I check the available data type table, and it's said that EXT data support "6.48e–4966" positive number, so is not a variable size problem, I think the problem is related to the exponential operation.
I will attach the program lines down.

[GerdW]

Hi alvaro,

I check the available data type table, and it's said that EXT data support "6.48e–4966" positive number, so is not a variable size problem,

That's the minimal positive number you can represent with an EXT value - but you only have ~20 significant decimal digits available!

I think the problem is related to the exponential operation.

Well, even when you think the exp() function is a problem: the resolution of the EXT values is the underlying problem!

I will attach the program lines down.

Which "lines"? 😄

Your VI features a lot race conditions - you really should avoid local variables when you use them like that!

See this:

(I added the indicator after the first x^y function and removed the Select node in the while loop! The while loop will only stop on TRUE, so there is absolutely no sense in putting a select node in there!)

for example, 122222222 number, is operated like 1.2*10^8

Don't mix up probe displays with underlying data, LabVIEW will handle this number exactly as 122222222!

Using this number as "message" the indermediate result will be ~1e+186, so the next Quotient&Remainder is senseless!

Here is the core of your problem: you are trying to evaluate very big numbers with very small number, different by ~180 powers of ten - but your numbers only support 20 decimal digits!!!

[altenbach]

Are you sure these are not supposed to be integer calculations? As I mentioned, if you need many more significant digits, you need to create your own datatype and program around it. Your problem seems to be related to encryption. That should be all pink/blue and only involve binary operations.

Do you have a link to a website that explains the calculations you are trying to do?

As a very simple example, here is some trivially simple code to calculate factorials of large numbers. It can e.g. quickly calculate all 35660 decimal digits of 10000! (factorial). (Yes, it is primitive and slowish. My original entry to the factorial coding challenge was many orders of magnitude faster, but also much more complicated)