I have an excel sheet with the following columns for a stock chart:
Open
High
Low
Close
Day Average
How do i use Fortran to pull only the "Day Average" from the excel file?
I am new to Fortran and haven't been able to find anything that could help except for the link below but its pretty difficult for me to grasp since i am looking for something different than what the link is showing me:
http://en.wikibooks.org/wiki/Fortran/Fortran_simple_input_and_output
No, contrary to the other answers CSV is not the easiest file to read. Go to File/Save as/Other Formats and save it as Formatted text (space delimited). Depending on your locale, you will either have a comma or a full stop as a decimal point, so you'll have to (either use an external editor to do a simple search/replace) or write a fortran subroutine that goes character by character, and replaces every comma with a full stop.
After that it's easy, no ;'s to parse, so you just
program FreeFormat
real(4), dimension(5) :: open, high, low, close, dayaverage
real(4) :: average
open(unit=1, file='filename.prn', status='old')
do i=1,5
read(1,*)open(i), high(i), low(i), close(i), dayaverage(i)
enddo
average = sum(dayaverage)/5
write(*,'("Average is",f5.2)')average
end program FreeFormat
You get the point ...
Here are a few links to get you started (Excel/Fortran DLL related) ...
Trouble with file location in excel/fortran dll connection
Fortran DLL & MS Excel
The native binary format of an Excel file will be very difficult to parse. Export the file to text or CSV, as already suggested. CSV will probably be easiest. You probably want to use "list directed IO", which has the source form:
read (unit-number, *) format-items
Fortran list-directed IO will read into the variables in the list "format-items" is a very flexible manner. The items in the file should be separated by deliminators such as spaces or commas. For your case, have five variables corresponding to the five columns in order to reach the 5th one that you want. Fortran is record-oriented, so you do one read per line.
You'll have to read and parse the Excel file in Fortran to get the values you want. If you are new to the language then this might be very hard to do. Maybe it's easier to save the Excel sheet in a CSV format and parse that? Good luck!
Related
I was curious what the community thinks is the easiest way to take a CSV file and 'save as' a Excel document with only a couple formulas pasted in?
I am trying to do this behind the scenes, and not physically navigating. e.g. opening, selecting save As, etc -- even though this is already VERY simple I **need to do this in code (Think automation)
Background: I have a c++ command line program generating the .csv, and a C# GUI starting this process. Either programs could hold the code, but I figure this is easiest in C# (InterOp?) The reasons I don't directly send code into the csv is because of the amount of comma characters that will mess up the csv and because other Excel documents need to reference the sheets so they need to be in .xls format.
=AVERAGE(C2:C999)
=COUNTIFS(C:C,">0",C:C,"<31")
=COUNTIFS(C:C,">31",C:C,"<55")
=COUNTIF(C:C,">55")
Have a look and see whether command-line scipting of openoffice will do the job. It can do quite a lot of conversions very easily. Otherwise there are a lot of Excel-producing libraries, for example PHPExcel, but you'd need to wrap some programming around them.
I have a CSV that is encoded in Unicode, however lacks a byte order mark at the start. As such Excel (2013) opens without encoding correctly (i think it assumes ASCII if no BOM specified...), meaning that certain characters are displayed incorectly.
From reading around i have read that a BOM of "\uFEFF" should be entered at the start of the CSV file. I have tried opening in txt editor and adding the characters e.g.
\uFEFF
r1test 1, r1text2, r1text3
r2test 1, r2text2, r2text3
However, this does not solve the problem - the characters "\uFEFF" show up on the first row when I open in excel, rather than it beign interpreted as a BOM. I am not sure what I am doing wrong, and the format of how the text should be specified such that it is interpreted as a BOM, rather than text in the the first of the data
I have only very limited experience using CSV, and only just heard of a BOM... and thus I could be implementing this completely wrong!
(for reference, i know that I could specify the encoding if i use the import data option within excel... however I really want to work out how to get it correctly specified in advance such that I can just open the csv... I have several thousand of these files that I am creating and exporting - once I know how to do this 'manually' [i.e. by adding some text at start of a the file], I can configure to automatically do in Python).
Thanks in advance
For someone else wanting to tell Excel to add a BOM: See if you can "Save as Unicode Text".
source
There are some special characters in my .xls file. I am trying to read all lines in .xls and write them into .txt file, but characters are changed. For example: There are ós in the Excel.
TCL Script:
set Channel_Read [open Sample.xls r]
set Channel_Write [open Text.txt a+]
while {[gets $Channel_Read Line]>=0} {
puts $Channel_Write $Line
}
close $Channel_Write
close $Channel_Read
After I open Text.txt, ó is changed to \&\#243;.
Any idea how to avoid this?
The immediate points:
The .xls format is binary, so you should use:
set Channel_Read [open "Sample.xls" rb]
(Or fconfigure $Channel_Read -translation binary straight after opening; it's equivalent.)
Similarly, if you're dumping it to another file, using a+b as the open mode for that — for the same sorts of reasons — will stop output mangling.
For a straight copy from one channel to another, use fcopy instead of a loop. The fcopy command uses some low-level tricks to do things more efficiently.
fcopy $Channel_Read $Channel_Write
However, I really suspect that something is going on other than is directly revealed in the information that you provide. Tcl wouldn't mangle bytes in the way you describe (I know what the encoding engine is doing, and it doesn't work that way for any encoding). What's more, the concept of a “line” in relation to a spreadsheet is distinctly off; spreadsheets don't have lines, they have rows (and columns, and sheets) and they don't need to be arranged in the same way at all. I also fail to see why appending a binary spreadsheet to another file would be a good thing to do.
I think you need to stop, think about the wider task that you are trying to do, and then try to solve that rather than just this little piece. While I could answer your immediate questions in more depth, I suspect that I'd not be giving you genuinely helpful assistance if I did.
No need to reinvent the wheel. Use the TCOM package, which is designed for exactly what you're trying to do. Here are some examples: Tcom examples for Microsoft Excel
I have written matlab programs that produce plots and tables for chemical substances. I get my input mostly from excel tables and a local MySql database. My problem is quite a few substance names contain greek letters.
My problem is I want to create plots that use exactly the names specified by my collegues. And also create tables that show the correct symbol.
An example:
If I create an excel file containing: "α-Methylstyrol" in the first cell and read it with [~,~,tmp] = xlsread('test.xlsx'). tmp will contain '(box with question mark)-Methylstyrol'. If I use the string in a plot (title(tmp)) it will be shown as: '(right arrow)-Methylstyrol'
So far I tried the native2unicode and unicode2native commands on the string but there is no effect. Also I tried replacing the characters but the number of characters I need to replace is growing way too fast for me - so I'm really hoping there would be a more systematic way.
(We know there are also names that wouldn't contain greek letters - but we try to adhere to some guidelines which prefer these names.)
As far as I understand, Matlab does not support unicode nicely. However, it is possible to type greek letters in image titles using LaTex syntax.
title('\alpha-Methanol')
Even though it is not the nicest solution, I think it should be possible to replace unicode symbols with LaTex keywords.
I think, your problem is, that xlsread is not even getting the correct greek letter out of your sheet.
Just give jexcelapi or poi a try. Both links lead to java classes for importing xls-files. In MATLAB you only need to add the jar-file to you path via javaaddpath and the next steps are like basic java coding.
Here's something that's really irked me over the years. I've never used any software that, when importing data from a column-aligned text file, can figure out the column breaks in a correct manner.
Excel 2K3 and a lot of other Microsoft components that seem to share a common codebase (like the import options for SQL2K) attempt to figure out the column breaks for you. Unfortunately, they only look at the first n rows, and are often completely wrong.
OpenOffice.Org 3.1 has a import dialog almost exactly like Excel 2K3 but it doesn't even attempt to guess the column breaks for you. And the latest version of Numbers doesn't appear to handle column-aligned imports at all.
Obviously column-aligned data is undesirable for a number of reasons, but a lot of older software (particularly in-house software various companies have floating around) exports data in this format so I do need to handle it every so often. Surely, somewhere, SOME software imports it well without me coding an import utility myself or manually specifying where twelve zillion columns start and stop?
OSX, Windows, whatever. I'm open to suggestions. Ultimate goal is to get it into a SQL Server table, but simply getting it into a Excel/XML/tab-delimited/etc file in the meantime would be fine because it's easy enough to get into SQL Server from there.
I tend to normalize such data with awk -- perhaps generating a csv file -- before trying to import it into Excel.
See the awk user's manual.
I don't think there is a silver bullet for your request. I think the best you can hope for is to define your input format once and be able to reuse that format when you receive a file with the same format again.
As one poster mentioned you could use awk or, if .NET is more your thing, then you could use FileHelpers. It's an open source .NET library that does a good job reading and writing both Fixed length and delimited files. The downside is that you would be creating a .NET application to do the work (either inserting directly into a DB or perhaps creating an output file. On the plus side, once created, you could reuse the mapping classes again if you get the same file format.
Well obviously no software can be entirely correct in guessing the layout of a fixed column file, since there is no seperator (though variable width columns with higher maximum lengths will often produce enough space on the end to start guessing). For example the following could be anywhere from 1-9 columns (I have personally had to figure out some super packed fixed column layouts like this, only much longer)
135464876
647873159
345467575
If SQL Server is the ultimate destination, have you looked into the SQL Server import wizard?
Right click your database in Management Studio and select Tasks->Import Data. Proceed through and select "Flat File" as your data source. In the format dropdown change from Delimited to Fixed Width. On the left you can now use the Columns screen to draw the column seperators. There is also an advanced and preview screen.
Try out this demo (I was on development team):
Personator 4
Install, run the program, go to Tools | ASCII Conversion | Import from ASCII.
The import will be to DBF/FoxPro, but you can then export that file into one of the formats you mentioned.
The start/stop guesser uses a few statistical formulas to try to get the boundaries correct; you get to verify and/or correct with a graphical editor after analysis.
If you save your file as a text file and attempt to open
it in Microsoft Excel 2007 and select "Fixed Width",
Excel will "guess" where the breaks occur (based on
whitespace), but you can actually change where the column
field breaks will occur. The application has vertical lines that
can be moved left or right X characters. Excel
will "guess" where the breaks occur, but if it
guesses incorrectly, you can still change where the field breaks
should occur. On STEP 2 of the wizard, just move the
vertical lines to the left or right if you need
to change Excel's guesses as to where the field breaks
are. You can see which character number the field
break occurs in before importing.