fprintf file timestamp to csv

Question

Tammy Chen 2016-9-12

0
链接

此问题的直接链接

https://ww2.mathworks.cn/matlabcentral/answers/302811-fprintf-file-timestamp-to-csv

评论： dpb 2016-9-16

采纳的回答： dpb

在 MATLAB Online 中打开

Hi All, I have a directory with unknown number of text files.

fid = dir('*.txt');

How do I fprintf the timestamps (file.date) of all of these files to a csv file? I tried using the datestr() function,datetime(),cell2mat(), brackets {} and [], & cell2str() functions but they don't work and generate errors when I tried to fprinf it to the csv.

Any pointers would help.

Thanks,

0 个评论
显示 -2更早的评论隐藏 -2更早的评论

请先登录，再进行评论。

请先登录，再回答此问题。

Answer 1

dpb 2016-9-12

0
链接

此回答的直接链接

https://ww2.mathworks.cn/matlabcentral/answers/302811-fprintf-file-timestamp-to-csv#answer_234518

编辑：dpb 2016-9-12

在 MATLAB Online 中打开

fid isn't good variable name for a directory list; too much associated with a file handle.

d=dir('*.txt');              % the directory structure
fid=fopen('file.date','w');  % open an output file
cellfun(@(s) fprintf(fid,'"%s"\n',s),cellstr(char(d.date)))  % and write them out quote-delimited
fid=fclose(fid);             % done--close file

2 个评论
显示无隐藏无

Tammy Chen 2016-9-13

在 MATLAB Online 中打开

Thanks! I was able to incorporate this line into another series of loops so I can print the timestamp out with other stats and file info I need from the data.

cellfun(@(s) fprintf(fid,'"%s"\n',s),cellstr(char(d.date)))

Several questions though, 1. Why do I need to use the cell function for fprintf the "s"? 2. What makes datetime special that it has to be quote delimited in order to be printed as a string? Sorry if my question doesn't make any sense, since I'm still a novice in cell-handling.

Walter Roberson 2016-9-13

You do not need to use a cellfun to handle the printing: the solution I gave using a temporary variable handles the task without using cellfun.

The timestamps include characters such as '-' and ':' and spaces that are not valid numbers. The format for csv files requires that strings in csv files be enclosed in double-quotes. The double-quotes being used there are not for the purpose of getting MATLAB to emit strings: they are there to get MATLAB to emit strings that are properly-formatted csv

请先登录，再进行评论。

Answer 2

Walter Roberson 2016-9-13

1
链接

此回答的直接链接

https://ww2.mathworks.cn/matlabcentral/answers/302811-fprintf-file-timestamp-to-csv#answer_234551

在 MATLAB Online 中打开

d = dir('*.txt');
dates = {d.date};
fid = fopen('file.csv', 'wt');
fprintf(fid, '"%s"\n', dates{:});
fclose(fid);

No loop is needed.

19 个评论
显示 17更早的评论隐藏 17更早的评论

dpb 2016-9-13

编辑：dpb 2016-9-14

在 MATLAB Online 中打开

The "curlies" are to dereference a cell array's content; it's not specific to strings, it's Matlab syntax to access cell array content. See the doc for cell arrays and links therefrom on accessing cell array data for the details.

The ":" colon operator is simply again Matlab syntax for arrays in general; it's shorthand for "all elements in the array irrespective of size and shape". Again, see the documentation under

doc colon % for specifics.

I'd recommend opening the online documentation and working thru the "Getting Started" section tutorials to get these most basic syntax elements down first--your progress will be much faster for the investment of a little time up front learning the basics and certainly far faster than waiting for somebody here to answer every detail.

As for using cellfun vis a vis not, it's a stylistic choice; I prefer when possible to not create extra named temporaries in the workspace but use anonymous ones which will automagically be discarded. In a single-purpose function it doesn't really make a lot of difference as the temporary will also be destroyed when the function exits but in a script or a larger function it's convenient to not necessarily "clutter up" the name space with stuff that's only needed temporarily.

ADDENDUM

Some additional amplification on the expression cellstr(char(d.date), the argument to cellfun. d.date by itself returns the multiple values returned as a comma-separated list (and yes, you need to look that up in the documentation, too :) ) rather than an array; char turns that list into a character string array and cellstr collects that into a cellstring array. cellfun then process each of those elements in turn.

The reason for this is owing to the difference between cell strings and character strings; the latter is a 1D array of characters and one must reference each string within the array as the (row,:) to get all the characters in each row. OTOH, cell strings are stored as the whole string in each cell and so referring to element (1) returns the string (as cell string); using the {} as {1} gets the whole string as the underlying characters.

Example...

>> d=dir('*.m');    % a local directory listing just for show...
>> d                % show what dir returns is struct array
d = 
113x1 struct array with fields:
    name
    date
    bytes
    isdir
    datenum
>> d.date   % what struc array altogether returns...
ans =
27-Apr-2016 08:40:50
ans =
24-May-2014 13:03:30
ans =
24-May-2014 16:49:24
...
ans =
08-Dec-2014 10:37:18
>>

Note the multiple answers -- 113 of 'em in this case.

>> dates=char(d.date);  % return the dates as char() array
>> whos dates
  Name         Size            Bytes  Class    Attributes
  dates      113x20             4520  char               
>> dates(1,:)  % note the trailing colon and that dates is 2D array
ans =
27-Apr-2016 08:40:50
>> dates(1)    % if just use one subscript; get just one character
ans =
2
>> dates=cellstr(dates);  % OK, that's inconvenient so convert to cellstr
>> whos dates  % now see it's a cell array of 113 length
  Name         Size            Bytes  Class    Attributes
  dates      113x1             11300  cell               
>> dates(1)  % and the single subscript returns the cell string
ans = 
    '27-Apr-2016 08:40:50'
>> whos dates  % what's the class???
Name       Size            Bytes  Class    Attributes
dates      1x1               100  cell               
>>

OK, note that is a single cell and also note that the display is surrounded by single quotes--this is a key item to note; whenever you see that in the command window it's the klew that the object is a cell string, not a character string and fprintf and friends will have to use the dereferencing operator {} in order to use them...

>> dates{1}  % OK, now use the curlies, Luke!  :)
ans =
27-Apr-2016 08:40:50
>> whos ans
Name      Size            Bytes  Class    Attributes
ans       1x20               40  char               
>>

Now note that the string content alone is shown without the quotes and the class is char.

Here's where we were heading from the git-go as that's what fprintf needs as its input.

dpb 2016-9-15

Sure there are small areas that may be problematical but the amount of code extant with try/catch as compared to that without (and even that which uses it it's generally pretty isolated) is miniscule so would still seem there's much room for expansion in the area. Anyway, that's why TMW developers "get the big bucks!" :)

I'm still surprised by a 10X penalty on the cellfun in the example here---I expected and willing to accept some owing to the indirect addressing implied but that seems like a lot and that there should be solutions to address ("should" in the theoretical sense implied more than as immediate altho it does seem worthy of a look-see if that is a general result and not specific which doesn't seem should be anything that unique here).

While I've not tried now for a while and should, after the switch to HG2 and other implementations of more and more of the object-oriented stuff, recent implementations have been unusable on my old machine here which is max-ed out on memory and while pretty competitive at the time it was new, it's now quite long-in-the-tooth as computer hardware goes. It's clear from that that performance has taken a hit in implementing much of the new paradigm and by adding so many features; new hardware can mask some of that but there are many complaints on performance so clearly it's an area TMW needs to concentrate on (not that they aren't, I'm sure).

Walter Roberson 2016-9-16

They are not fixed length.

dpb 2016-9-16

I had presumed not; wondered, though, about an array then...guess they're more classes/objects overhead to deal with, then. At this stage of the game I wonder why also but would likely have been preference over the cellstr route they took first...

请先登录，再进行评论。