15 Reputation

3 Badges

2 years, 111 days

MaplePrimes Activity

These are replies submitted by AOdrzywolek

Finally, the proper way to export symbolic and numeric results to binary hardware float[8] is:

FileTools[Binary][WriteFile]("test.bin", float[8], [evalf[32]( sqrt(2) )], 'byteorder' = 'native')

where evalf digits is 15 or more. 


@vv Indeed, specs say 18 digits ,,at most'' is enough to convert  string to long double binary (they ,,should match''). But in opposite direction you still require 21 digits. That is why I used even more digits, to ,,safely'' transfer floats back and forth. Maybe the phrase ,,at most'' is crucial, because I used more digits to set variables in C, assuming it is harmless. 

@Carl Love Data is transfered to C program. I have started with ASCII, but conversion (not from Maple) sometimes caused 1 ULP error. I'm testing numerical library for rapidly varying function. Must be sure it is evaluated at exactly the same rational value, representable by binary64. So binary export/import looked promising idea, it should guarantee exact bitwise identity. Of course, IEEE 754 specification require this should work if at least 17 significant digits are used in ASCII as well. 

@vv Unfortunately, I'm testing long double version as well, and this require more than 20 digits. Moreover, I'm using polylog, and sometimes to get 18 correct digits you must request few more. 

@vv Thank you for explanation. I've run into this trying to export arbitrary precision/symbolic results to binary:

FileTools[Binary][WriteFile]("test.bin", float[8],





], 'byteorder' = 'native')


Obviously, Binary use evalhf to convert, because last two entries produce the same negative double-precision subnormal. So, what is proper way/workaround? The evalf[15]  produced correct binary output, but I need to be sure that exported number is within 1 ULP. I cannot directly export symbolic numbers, e.g, sqrt(2) because it cause an error:

Error, (in FileTools:-Binary:-WriteFile) float[8] expected

Page 1 of 1