Precision lost with xlswrite?
in [Matlab]
|
Prev: java and simulink
Next: mincx to gevp
From: dpb on 2 Dec 2009 09:32 Jos wrote: > So what you are saying is that you would also expect the correct data to be written to xls? > Is there a way to format tha data when using xlswrite? Did you look at the results I posted at all????? I'm saying if you were to use the optional second argument to numstr() instead of default you would be able to obtain the full precision that you're not now by default in the character representation. _THEN_, yes, I'm quite confident the xlswrite() function would write the data given it as given (just as it is currently). doc numstr NOTA BENE: _PLEASE_ do not top post in the future. It make following conversations logically much more difficult than need be. Look again at the previous example of numstr() below... > dpb <none(a)non.net> wrote in message <hf3vb8$20f$1(a)news.eternal-september.org>... >> Jos wrote: >>> The input was transformed (in a for loop) to a string using (simplified code): >>> tab_strings=cellstr(num2str(input)) >>> And tab_strings has what I expect from it (so a cell array of strings >>> with the correct numbers). It is only when using >>> xlswrite('path',tab_strings) that something goes wrong. >> That certainly isn't what the output you showed previously >> indicates...nor what I would expect the result of num2str() to be w/ the >> default formatting. >> >> ... >> >> >> x=pi >> x = >> 3.1416 >> >> num2str(x) >> ans = >> 3.1416 >> >> format long >> >> x >> x = >> 3.14159265358979 >> >> num2str(x) >> ans = >> 3.1416 >> >> length(ans) >> ans = >> 6 >> >> num2str(x,15) >> ans = >> 3.14159265358979 >> >> >> >> -- --
From: Jos on 2 Dec 2009 10:27 dpb <none(a)non.net> wrote in message <hf5tq2$o5q$1(a)news.eternal-september.org>... > Jos wrote: > > So what you are saying is that you would also expect the correct data to be written to xls? > > Is there a way to format tha data when using xlswrite? > > Did you look at the results I posted at all????? > > I'm saying if you were to use the optional second argument to numstr() > instead of default you would be able to obtain the full precision that > you're not now by default in the character representation. > > _THEN_, yes, I'm quite confident the xlswrite() function would write the > data given it as given (just as it is currently). > > doc numstr > > NOTA BENE: _PLEASE_ do not top post in the future. It make following > conversations logically much more difficult than need be. > > Look again at the previous example of numstr() below... > > > dpb <none(a)non.net> wrote in message <hf3vb8$20f$1(a)news.eternal-september.org>... > >> Jos wrote: > >>> The input was transformed (in a for loop) to a string using (simplified code): > >>> tab_strings=cellstr(num2str(input)) > >>> And tab_strings has what I expect from it (so a cell array of strings > >>> with the correct numbers). It is only when using > >>> xlswrite('path',tab_strings) that something goes wrong. > >> That certainly isn't what the output you showed previously > >> indicates...nor what I would expect the result of num2str() to be w/ the > >> default formatting. > >> > >> ... > >> > >> >> x=pi > >> x = > >> 3.1416 > >> >> num2str(x) > >> ans = > >> 3.1416 > >> >> format long > >> >> x > >> x = > >> 3.14159265358979 > >> >> num2str(x) > >> ans = > >> 3.1416 > >> >> length(ans) > >> ans = > >> 6 > >> >> num2str(x,15) > >> ans = > >> 3.14159265358979 > >> >> > >> > >> -- > > -- Okay, I see what happened. I didn't post my question clear enough :p. My question was about precision, but I did not mean the number of digits displayed. The problem that I have is that when going from the table (of strings) to xls, some positions of the . (dot) move, changing the value of the number completely :s Sorry for the misunderstanding (and thx for the effort so far!)
From: dpb on 2 Dec 2009 10:39 Jos wrote: .... > Okay, I see what happened. I didn't post my question clear enough :p. .... > The problem that I have is that when going from the table (of > strings) to xls, some positions of the . (dot) move, changing the value of the > number completely :s > Sorry for the misunderstanding (and thx for the effort so far!) Then I think you'd best post/show the problem again. That seems more than strange; that would seem to be a bug. --
From: Jos on 2 Dec 2009 11:20 dpb <none(a)non.net> wrote in message <hf61o9$cr1$2(a)news.eternal-september.org>... > Jos wrote: > ... > > Okay, I see what happened. I didn't post my question clear enough :p. > ... > > The problem that I have is that when going from the table (of > > strings) to xls, some positions of the . (dot) move, changing the value of the > > number completely :s > > > Sorry for the misunderstanding (and thx for the effort so far!) > > Then I think you'd best post/show the problem again. That seems more > than strange; that would seem to be a bug. > > -- This is the sequence of data processing: this is the input: 4 3,69599639557127 188,410000000000 86,0893000000000 6 7,08828645208912 274,569000000000 97,3328000000000 8 9,38747390641889 349,375000000000 102,099000000000 10 10,9083049302071 447,311000000000 120,367000000000 12 11,3831813630739 448,195000000000 157,617000000000 14 12,9220834663217 452,480000000000 159,910000000000 16 15,2383797236977 459,235000000000 327,560000000000 18 22,1045498361762 483,264000000000 346,441000000000 20 37,8022334739675 486,764000000000 452,589000000000 22 55,6718604320812 519,297000000000 479,373000000000 24 76,8186179083778 557,011000000000 510,505000000000 And this is what appears in the table of strings (using num2str): ' 4' ' 3.696' ' 188.41' '86.0893' ' 6' '7.08829' '274.569' '97.3328' ' 8' '9.38747' '349.375' '102.099' '10' '10.9083' '447.311' '120.367' '12' '11.3832' '448.195' '157.617' '14' '12.9221' ' 452.48' ' 159.91' '16' '15.2384' '459.235' ' 327.56' '18' '22.1045' '483.264' '346.441' '20' '37.8022' '486.764' '452.589' '22' '55.6719' '519.297' '479.373' '24' '76.8186' '557.011' '510.505' But when I use xlswrite, the excel file gives this: 4 3.696 188.41 860.893 6 708.829 274.569 973.328 8 938.747 349.375 102.099 10 109.083 447.311 120.367 12 113.832 448.195 157.617 14 129.221 452.48 159.91 16 152.384 459.235 327.56 18 221.045 483.264 346.441 20 378.022 486.764 452.589 22 556.719 519.297 479.373 24 768.186 557.011 510.505 The problem is that in the last step, the position of the dot changes (except on the first line)
From: dpb on 2 Dec 2009 11:24
Jos wrote: .... > this is the input: > 4 3,69599639557127 188,410000000000 86,0893000000000 > 6 7,08828645208912 274,569000000000 97,3328000000000 .... > And this is what appears in the table of strings: > ' 4' ' 3.696' ' 188.41' '86.0893' > ' 6' '7.08829' '274.569' '97.3328' .... > > But when I use xlswrite, the excel file gives this: > 4 3.696 188.41 860.893 > 6 708.829 274.569 973.328 .... > Anyone with an idea of why this happens? OK, I came back and I see what your complaint is now--I looked too quickly earlier and just noticed the difference in precision, not paying any attention to actual values. Looks to me like the adjustment by either Excel or xlswrite() (can't tell which for absolute sure from just this) of the decimal placement to the fixed number of decimal digits (3) is munged. Whether xlswrite did it internally on the write or whether it also wrote some spreadsheet formatting information incorrectly that Excel is interpreting I don't know. Since I don't have a version of ML that supports xlswrite I can't test it. Try using sprintf() w/ a fixed format of '%10.5f' or somesuch to do the string conversion and then try that w/ xlswrite() as a workaround. I'd say it appears a reasonable chance you've uncovered a bug--I'd suggest a very small sample case and submit to TMS support. -- |