Discover MakerZone

MATLAB and Simulink resources for Arduino, LEGO, and Raspberry Pi

Learn more

Discover what MATLAB® can do for your career.

Opportunities for recent engineering grads.

Apply Today

Thread Subject:
Different precision saving variables as .mat and .txt

Subject: Different precision saving variables as .mat and .txt

From: Nathan

Date: 27 Aug, 2014 20:54:21

Message: 1 of 8

Hello all,

I have come across a peculiar problem I was hoping I could get some insight into. I was saving variables from my workspace to load into another script. I was messing around with saving it as a .mat and an tab separated ascii using the respective formats below:

h = sprintf('peaks1_%d.mat',n);
    
    save(h, 'peaks_1', '-mat');


 and

h = sprintf('peaks1_%d.txt',n);
    
    save(h, 'peaks_1', '-ascii', '-tabs');

When I load them into another script it appears the values from the ascii file have lost a decimal place of precision compared to the .mat which retains its original number format? For example:

.mat value = 1519.73467000000

ascii value = 1519.73470000000

Any thoughts on the loss of precision and how I can prevent this from happening?

Cheers,

Nate

Subject: Different precision saving variables as .mat and .txt

From: Nasser M. Abbasi

Date: 28 Aug, 2014 00:13:20

Message: 2 of 8

On 8/27/2014 3:54 PM, Nathan wrote:
> Hello all,
>
> I have come across a peculiar problem I was hoping I could
>get some insight into. I was saving variables from my workspace
> to load into another script. I was messing around
>with saving it as a .mat and an tab separated ascii using the respective formats below:
>
> h = sprintf('peaks1_%d.mat',n);
>
> save(h, 'peaks_1', '-mat');
>
>
> and
>
> h = sprintf('peaks1_%d.txt',n);
>
> save(h, 'peaks_1', '-ascii', '-tabs');
>
> When I load them into another script it appears the
>values from the ascii file have lost a decimal place of
>precision compared to the .mat which retains its original number format? For example:
>
> .mat value = 1519.73467000000
>
> ascii value = 1519.73470000000
>
> Any thoughts on the loss of precision and how I can prevent this from happening?
>
> Cheers,
>
> Nate
>

try

save(h, 'peaks_1', '-ascii','-tabs','-double');

and see if you still get the same result or not.

--Nasser

Subject: Different precision saving variables as .mat and .txt

From: dpb

Date: 28 Aug, 2014 00:33:13

Message: 3 of 8

On 08/27/2014 3:54 PM, Nathan wrote:
...

> h = sprintf('peaks1_%d.txt',n);
> save(h, 'peaks_1', '-ascii', '-tabs');
>
> When I load them into another script it appears the values from the
> ascii file have lost a decimal place of precision compared to the .mat
> which retains its original number format? For example:
>
> .mat value = 1519.73467000000
>
> ascii value = 1519.73470000000
> Any thoughts on the loss of precision and how I can prevent this from
> happening?
...

If you want to be certain of full machine precision, use a binary
format, not ASCII (although if you do specify sufficient precision,
it'll work but it takes roughly 20 characters/bytes per value (15-16
significant places plus sign, exponent, etc.) as compared to 8 for a
double).

The save function as written is documented to only write 8 digits of
precision.

help save
  ...
  FORMAT
    ...
    '-ascii', '-tabs' Tab-delimited 8-digit ASCII format.
    '-ascii', '-double' 16-digit ASCII format.

Moral of the story -- _always_ read the fine print... :)

--

Subject: Different precision saving variables as .mat and .txt

From: Steven Lord

Date: 28 Aug, 2014 15:40:18

Message: 4 of 8


"dpb" <none@non.net> wrote in message news:ltltcc$sva$1@dont-email.me...
> On 08/27/2014 3:54 PM, Nathan wrote:
> ...
>
>> h = sprintf('peaks1_%d.txt',n);
>> save(h, 'peaks_1', '-ascii', '-tabs');
>>
>> When I load them into another script it appears the values from the
>> ascii file have lost a decimal place of precision compared to the .mat
>> which retains its original number format? For example:
>>
>> .mat value = 1519.73467000000
>>
>> ascii value = 1519.73470000000
>> Any thoughts on the loss of precision and how I can prevent this from
>> happening?
> ...
>
> If you want to be certain of full machine precision, use a binary format,
> not ASCII (although if you do specify sufficient precision, it'll work but
> it takes roughly 20 characters/bytes per value (15-16 significant places
> plus sign, exponent, etc.) as compared to 8 for a double).

Or write strings generated using NUM2HEX to the file and pass those strings
through HEX2NUM once you've read them in. When I can't use MAT-files but
need to control the exact (down to the last bit) value regenerated from a
string, I generally use this approach.

--
Steve Lord
slord@mathworks.com
To contact Technical Support use the Contact Us link on
http://www.mathworks.com

Subject: Different precision saving variables as .mat and .txt

From: dpb

Date: 28 Aug, 2014 16:50:29

Message: 5 of 8

On 08/28/2014 10:40 AM, Steven Lord wrote:
>
> "dpb" <none@non.net> wrote in message news:ltltcc$sva$1@dont-email.me...
...

>> If you want to be certain of full machine precision, use a binary
>> format, not ASCII (although if you do specify sufficient precision,
>> it'll work but it takes roughly 20 characters/bytes per value (15-16
>> significant places plus sign, exponent, etc.) as compared to 8 for a
>> double).
>
> Or write strings generated using NUM2HEX to the file and pass those
> strings through HEX2NUM once you've read them in. When I can't use
> MAT-files but need to control the exact (down to the last bit) value
> regenerated from a string, I generally use this approach.

aka "TRANSFER"... :)

--

Subject: Different precision saving variables as .mat and .txt

From: dpb

Date: 29 Aug, 2014 13:44:31

Message: 6 of 8

On 08/28/2014 10:40 AM, Steven Lord wrote:
...

> Or write strings generated using NUM2HEX to the file and pass those
> strings through HEX2NUM once you've read them in. When I can't use
> MAT-files but need to control the exact (down to the last bit) value
> regenerated from a string, I generally use this approach.

What advantage (if any) do you see in this over fwrite/fread writing
native stream files, Steven? (Which is certainly the way I'm used to
doing such things). Seems like it's an unnecessary translation step the
i/o system will do automagically to build the ascii file and transport it.

--

Subject: Different precision saving variables as .mat and .txt

From: Steven Lord

Date: 29 Aug, 2014 14:07:01

Message: 7 of 8


"dpb" <none@non.net> wrote in message news:ltq03n$t48$1@dont-email.me...
> On 08/28/2014 10:40 AM, Steven Lord wrote:
> ...
>
>> Or write strings generated using NUM2HEX to the file and pass those
>> strings through HEX2NUM once you've read them in. When I can't use
>> MAT-files but need to control the exact (down to the last bit) value
>> regenerated from a string, I generally use this approach.
>
> What advantage (if any) do you see in this over fwrite/fread writing
> native stream files, Steven? (Which is certainly the way I'm used to doing
> such things). Seems like it's an unnecessary translation step the i/o
> system will do automagically to build the ascii file and transport it.

Because often when I'm doing this I'm not writing to a file whose only
contents are the data that I need to reproduce exactly. I NUM2HEX the data
and copy the returned string into a function or class file as the input of a
HEX2NUM call, rather than into a file to be LOADed or FOPENed and read. But
if you're writing the data to a file whose only contents should be something
with which you can exactly reproduce the data, writing to a binary file with
FWRITE or to a text file with FPRINTF and the format specifiers %x (for
unsigned integers), %bx (for doubles), or %tx (for singles) is a more
straightforward approach.

--
Steve Lord
slord@mathworks.com
To contact Technical Support use the Contact Us link on
http://www.mathworks.com

Subject: Different precision saving variables as .mat and .txt

From: dpb

Date: 29 Aug, 2014 14:47:25

Message: 8 of 8

On 08/29/2014 9:07 AM, Steven Lord wrote:
...

> Because often when I'm doing this I'm not writing to a file whose only
> contents are the data that I need to reproduce exactly. ...

That makes sense. Since the subject was a .mat file, wasn't sure where
the NUM2HEX() came from after thinking about it a while after the
original posting...

Being an old fogey, I'd probably not think of the "integrated" solution
and still just deal with the numeric parts as files and fwrite/fread
them in the stream of the rest where/when needed. I suppose if were a
complex-enough app and sufficient to warrant the development the more
"exotic" solution would evolve... :) ["A real programmer can write
FORTRAN in any language..." <vbg>]

--

Tags for this Thread

No tags are associated with this thread.

What are tags?

A tag is like a keyword or category label associated with each thread. Tags make it easier for you to find threads of interest.

Anyone can tag a thread. Tags are public and visible to everyone.

Contact us