CSV file
Chappman
I am having trouble trying to save a matrix P as a CSV file in Sage:
Def function(A,D):
(sage syntax for creating a matrix P)
return P
and then using a function which opens up the CSV file and utilizes the
entires in the matrix P, from the CSV file.
Is there a method for this?
Kind Regards
Chappman
Harald Schilly
On Friday, February 24, 2012 11:13:53 AM UTC+1, Chappman wrote:
and then using a function which opens up the CSV file and utilizes the
entires in the matrix P, from the CSV file.
Is there a method for this?
Volker Braun
Chappman
You answered I should of phrased that question better, but lets say I
created a matrix in Sage, and I want to save it as a csv file how do I
do that?
The matrix is made from the following function below
Def function(A,D)
(syntex for making matrix P)
return P
Kind Regards
Chappman
Dima Pasechnik
> Hi Harald,
>
> You answered I should of phrased that question better, but lets say I
> created a matrix in Sage, and I want to save it as a csv file how do I
> do that?
>
> The matrix is made from the following function below
>
> Def function(A,D)
> (syntex for making matrix P)
> return P
>
http://docs.python.org/library/csv.html
it's not clear what these A and D are supposed to be,
and how this would be different
from creating a Sage matrix like this, for instance:
M=matrix([[1,2],[3,4]])
and then writing entries of M, i.e. M[0,0], M[0,1], etc,
into CSV file using csv.writer().
Dmitrii
> --
> To post to this group, send email to sage-s...@googlegroups.com
> To unsubscribe from this group, send email to sage-support...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-support
> URL: http://www.sagemath.org
>
Jason Grout
> We do get questions about "how to read matrix from csv" quite regularly.
> Of course its just a few lines of code, but I think it would be nice to
> have a matrix_from_file('fname.csv') function that imports csv and
> perhaps others (gnumeric/ooffice/excel). Any volunteers? ;-)
>
How about the matrix constructor reads from an iterator and recognizes
csv? We could even use the numpy savetxt and loadtxt functions to more
sophisticated parsing.
So:
with open('mymatrix.csv','r') as f:
m=matrix(f)
or
m.save('test.csv') # or m.save('test.csv', format='csv')
I'm not volunteering in these suggestions...
Thanks,
Jason
Nils Bruin
> How about the matrix constructor reads from an iterator and recognizes
> csv? We could even use the numpy savetxt and loadtxt functions to more
> sophisticated parsing.
sage: import csv
sage: M=matrix(RR,list(csv.reader(open("m.csv"))))
sage: csv.writer(open("c.csv","w")).writerows(list(M^2))
I think it would be possible to accept matrix(R,<iterable>) as a
generalization of matrix(R,<list>), which would save 6 characters in
the second line above.
Personally, I think apart from the "list" call, the line
"M=matrix(RR,list(csv.reader(open("m.csv"))))" carries no extraneous
cognitive ballast. All steps are meaningful and leaving any of them
out requires "magic" functionality that tends to break in corner
cases. (csv files can be tricky beasts, so having an extra call that
tells how to interpret the file as a csv makes good sense; requiring
the ring also makes good sense, because it's difficult to see from a
string what ring exactly the elements should lie in). Another
advantage of this incantation is that it's easily discovered by
someone familiar with python and that the logic behind it is entirely
transferable. A novice will have to look up how to do it anyway, so if
we just use this as doc for how to read csv files into a matrix, we're
done.
The writer looks a little less logical to me. I don't have a good
alternative for that. Perhaps your "m.save(...,format='csv')" is a
reasonable alternative.
Chappman
Thank you very much for that code. Just to clarify, I'm using the sage
notebook (running on my machine), will the code still work? I.e. be
able to read where the files are on my machine even when using the
notebook interface?
Thank you very much for your help.
Chappman
Robert Bradshaw
unclear if each item corresponds to a row or an element. But I would
be in favor of rather liberal string parsing, so one could do
matrix(open("test.csv").read())
just like
matrix("""
1,2,3
4,5,5
""")
Nils Bruin
wrote:
> unclear if each item corresponds to a row or an element. But I would
> be in favor of rather liberal string parsing, so one could do
in
matrix( [ c for c in iterator ])
than it is in
matrix( ( c for c in iterator ) )
I agree that this problem arises if we would allow the c's themselves
to just be generic iterators, which would include strings.
(although you could argue that if no dimensions are given, matrix
should insist on [ [...], [...] , ... , [...]] rather than
interpreting [1,2,3] as [[1,2,3]]).
Of course, accepting iterators would be at odds with accepting strings
straight away, as in matrix("1,2,3\n4,5,6"), so we'd have to make a
choice between those two. Currently strings nor iterators are accepted
by a bare matrix. However, for related objects the choice has already
been made in favor of iterators:
sage: M22=MatrixSpace(Integers(),2,2)
sage: M22([1,2,3,4])
[1 2]
[3 4]
sage: M22( i for i in [1,2,3,4] )
[1 2]
[3 4]
sage: M22("1 2 3 4")
TypeError: entries has the wrong length
sage: M22("1234")
[1 2]
[3 4]
sage: matrix(QQ,2,2, (i for i in [1,2,3,4]) )
[1 2]
[3 4]
Especially the last example makes me hesitant about letting matrix
parse strings.
Robert Bradshaw
> On Mar 2, 12:28 am, Robert Bradshaw <rober...@math.washington.edu>
> wrote:
>> The difficulty with accepting an iterator (of strings) is that it is
>> unclear if each item corresponds to a row or an element. But I would
>> be in favor of rather liberal string parsing, so one could do
>
> Why is it easier to decide if the items correspond to rows or elements
> in
>
> matrix( [ c for c in iterator ])
>
> than it is in
>
> matrix( ( c for c in iterator ) )
That's not the difference.
> I agree that this problem arises if we would allow the c's themselves
> to just be generic iterators, which would include strings.
Yep. I don't like matrix(["1 2", "3 4"]) because that's impossible to
distinguish (using types alone) from matrix(["1", "2", "3", "4"]) (or
the same replacing lists with iterators). Iterating over open("file"))
iterates over the lines which would typically be entire rows.
Interpreting strings as a 1-digit decimal list seems more broken to me
sage: MatrixSpace(SR, 2, 2)("1234")
[1234 0]
[ 0 1234]
sage: MatrixSpace(ZZ, 2, 2)("1234")
[1 2]
[3 4]
I think it's fair to test for strings first, trying to parse, before
testing if it's an iterator. This is consistant with many other
objects that try to "parse" their string representations.
sage: ZZ['x']([1,2,3])
3*x^2 + 2*x + 1
sage: ZZ['x']("123")
123
sage: ZZ['x']("x^2 + 5")
x^2 + 5
- Robert
Nils Bruin
wrote:
> testing if it's an iterator. This is consistant with many other
> objects that try to "parse" their string representations.
>
> sage: ZZ['x']([1,2,3])
> 3*x^2 + 2*x + 1
> sage: ZZ['x']("123")
> 123
> sage: ZZ['x']("x^2 + 5")
> x^2 + 5
I guess matrix(S) would do:
if isinstance(S,basestring):
<do our best to parse S as a string rep of a matrix>
else:
try:
V=iter(S)
#figure out how to interpret the elements of V
#(are they rows or elements?)
#should we accept strings at this point?
#the CSV example above indicates that with a known base ring,
#allowing elements of V to be iterables of strings representing
elements
#seems a good idea.
except TypeError:
#do whatever we do with non-iterable matrix initializers
Robert Bradshaw
Yep, that's the basic idea, though I might test for the non-iterable
matrix initializers first, so something like matrix(QQ['x'], 2, x^2)
becomes
[x^2, 0]
[0, x^2]
rather than using list(x^2), and an iterable of strings is always
considered an iterator of elements, not an iterator of rows.
- Robert