Hi,
I have a 8 bytes memoryblock, where I store a double number.
How to convert it to string? The simple assignment to a string, as
shown below does not work (encodings?).

Any ideas?

Thanks!

Dim m as New MemoryBlock(8)
Dim d as Double
Dim s as String
m.DoubleValue(0)=3.141592653589793
d=m.DoubleValue(0)
s=m
MsgBox m

[quote=243060:@Davide Pagano]Hi,
I have a 8 bytes memoryblock, where I store a double number.
How to convert it to string? The simple assignment to a string, as
shown below does not work (encodings?).

Any ideas?

Thanks!

Dim m as New MemoryBlock(8)
Dim d as Double
Dim s as String
m.DoubleValue(0)=3.141592653589793
d=m.DoubleValue(0)
s=m
MsgBox m
[/quote]

Sorry I forgot to mention that I don’t want to use Str as it returns just 7 decimal places for real numbers*…I am actually trying to use MemoryBlock to avoid the use of Str to convert doubles to strings…

unfortunately I tried to use the new “ToText” method but it has the same problem of Str. My problem is the following. You have a double number and you DON’T know the format of that number. It could be 0.00000549875 or 3453.0938450948 or -5.097987987e-4, etc… My problem is how to convert it string preserving ALL digits? If you use Str it will truncate the number to maximum 7 significative digits…

The issue is not with format, it is with Double itself. Norman Palardy explained that many a time. He even linked to an article on Wikipedia that explains the reasons behind it. Unfortunately, I cannot locate it at the moment.

You may want to have a look at Bob Delaney’s Floating Point plugin http://delaneyrm.com/

but that’s just because you specified a format with more than the necessary significative digits.

there’s no issue at all with doubles and indeed they are worldwide used when many precision digits are required. As of today, even double precision is not enough for some scientific applications…but this is another story.
About the OP, in C++, for example, there’s not problem at all to convert a double to string preserving all its precision digits…why has it to be difficult in xojo?

[quote=243083:@Michel Bujardet]
You may want to have a look at Bob Delaney’s Floating Point plugin http://delaneyrm.com/[/quote]

it’s not 64 bit compatible. Moreover it has a strong impact on performance which I cannot justify as I don’t need more than double precision for this particular project.

You are not correct about doubles in C++. It is not possible to store 3.141592653589793. For the same reasons you can not store 0.1 in a double. I binary 0.1 is 0.00011001100110011… and this group 0011 repeats infinitely. So for storing it into double it is rounded down or up or just truncated. Therefore follows that when reading it from memory it won’t be the exact same number.

I’ve posted this many many many times
IEEE format uses powers of 2 to form numeric values
For integers this is fine because you CAN precisely represent all the integers as sums of powers of 2

3 = 2^0 + 2^1

and so on

BUT for fractional values you cannot - you can only approximate certain values

1/2 = 1/2^1

1/3 ? ha no exact representation as successive fractional powers of 2

It’s not
It’s the exact same issue in C++
The question of “how many significant digits are there” is unanswerable for some values
For 1/2 there is 1 after the decimal
For 1/3 you cant tell because its an infinitely long sequence
So IF in C++ it gives you 7 significant digits then there is a “default” that says “no more than 7” - or whatever it is

And quite honestly in Xojo preserving them all would be about as difficult
Use ##############.############## and IF the spot is not 0 then a digit will be there and if its not required it wont be used
Or use a fixed pattern like “0000000000000000000000.00000000000000000000” and strip leading and trailing 0’s

For the sake of intellectual honesty, I must point out that proof that double indeed does not keep the exact mantissa value is relatively simple :

dim d as double = 0.00000549875 // 11 digits mantissa
system.debuglog format(d,"###,###.00000000000")
system.debuglog format(d-0.00000549874,"###,###.######################")

Result is :

0.00000549875
0.0000000000099999999999

This shows that the double does contain an inaccurate representation of the fractional part.

However, you are right to point that setting a precise number of digits can produce the right string.

dim d as double = 0.00000549875 // 11 digits mantissa
system.debuglog format(d,"###,###.00000000000") // 0.00000549875
d = 3453.0938450948 // 10 digits mantissa
system.debuglog format(d,"###,###.0000000000") // 3453.0938450948

Format seems to round the last digit, which in most cases would produce the right string. Now these two examples from your posts illustrate the difficulty in generalizing the method. You say above it can be basically any number. There lies the difficulty. If you know the exact size of the fractional part, then you simply put the adequate number or zeros in the the format, and you’re fine. But how do you guess that from a double that has many more digits ?

[quote=243192:@Michel Bujardet]
Format seems to round the last digit, which in most cases would produce the right string. Now these two examples from your posts illustrate the difficulty in generalizing the method. You say above it can be basically any number. There lies the difficulty. If you know the exact size of the fractional part, then you simply put the adequate number or zeros in the the format, and you’re fine. But how do you guess that from a double that has many more digits ?[/quote]

exactly, there’s no way to guess the number of significative digits.