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]
s = str(d) or s = strl( m.doublevalue(0) )
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…
I am not sure why you need a memoryblock to store a double. However, maybe the new framework can help:
http://developer.xojo.com/double$ToText
[quote=243074:@Rob Egal]I am not sure why you need a memoryblock to store a double. However, maybe the new framework can help:
http://developer.xojo.com/double$ToText[/quote]
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…
http://documentation.xojo.com/index.php/format
But the examples you give are perfect to demonstrate the kind of issues that spring from using double for such mantissas.
dim d as double = 0.00000549875
system.debuglog format(d,"###,###.###############")
Result = 0.0000054987499999999996572034623
3453.0938450948 - > 3,453.093845094800144579494372010231
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/
[quote=243083:@Michel Bujardet]http://documentation.xojo.com/index.php/format
But the examples you give are perfect to demonstrate the kind of issues that spring from using double for such mantissas.
dim d as double = 0.00000549875
system.debuglog format(d,"###,###.###############")
Result = 0.0000054987499999999996572034623
3453.0938450948 - > 3,453.093845094800144579494372010231
[/quote]
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.
Have fun.
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.
you can define the format for str and use the format that you need.
str(m.DoubleValue(0),"-#.###############")
in you example:
dim s2 as String=str(m.DoubleValue(0))
dim s3 as String=str(m.DoubleValue(0),"-#.###############")
dim d2 as double = d-s2.val =>0.0000003464102067
dim d3 as double = d-s3.val =>0.
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
Have fun
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 ?
thank you all for the replies.
[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.