Hi, mlab.defaultformatd sets the default float formatter for rec2csv() to be something that doesn't keep the full representation of a floating point number. Obviously, I can pass in my own formatd argument to rec2csv(), but I wonder if there's any reason why defaultformatd shouldn't use repr() for numpy.float32 and numpy.float64?
On Dec 15, 2007 2:13 PM, Andrew Straw <str...@as...> wrote: > Hi, > > mlab.defaultformatd sets the default float formatter for rec2csv() to be > something that doesn't keep the full representation of a floating point > number. Obviously, I can pass in my own formatd argument to rec2csv(), > but I wonder if there's any reason why defaultformatd shouldn't use > repr() for numpy.float32 and numpy.float64? +1 for repr() in general as the default output method, as it is supposed (though not guaranteed) in general to be more faithful to the original object. cheers, f
On Dec 15, 2007 3:13 PM, Andrew Straw <str...@as...> wrote: > mlab.defaultformatd sets the default float formatter for rec2csv() to be > something that doesn't keep the full representation of a floating point > number. Obviously, I can pass in my own formatd argument to rec2csv(), > but I wonder if there's any reason why defaultformatd shouldn't use > repr() for numpy.float32 and numpy.float64? I'll be happy to make repr the default. I was using %g because I mistakenly though this provided the appropriate number of significant digits. I changed this to %r in the csvformat_factory in svn. JDJ
OK, I added unit/mlab_unit.py to svn. This checks that double precision floats can round-trip through rec2csv and csv2rec. To pass requires not only svn matplotlib (due to John's change), but also svn numpy (to be included with 1.0.5). Also, it doesn't seem to me that rec2csv should close a file handle passed to it. This prevents use with StringIO, for example. So, I added a test for that, too. John, if it's not going to break anything for you, I'll go ahead and fix that. John Hunter wrote: > On Dec 15, 2007 3:13 PM, Andrew Straw <str...@as...> wrote: > >> mlab.defaultformatd sets the default float formatter for rec2csv() to be >> something that doesn't keep the full representation of a floating point >> number. Obviously, I can pass in my own formatd argument to rec2csv(), >> but I wonder if there's any reason why defaultformatd shouldn't use >> repr() for numpy.float32 and numpy.float64? >> > > I'll be happy to make repr the default. I was using %g because I > mistakenly though this provided the appropriate number of significant > digits. I changed this to %r in the csvformat_factory in svn. > > JDJ > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services > for just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >
On Dec 16, 2007 1:33 PM, Andrew Straw <str...@as...> wrote: > OK, I added unit/mlab_unit.py to svn. This checks that double precision > floats can round-trip through rec2csv and csv2rec. To pass requires not > only svn matplotlib (due to John's change), but also svn numpy (to be > included with 1.0.5). > > Also, it doesn't seem to me that rec2csv should close a file handle > passed to it. This prevents use with StringIO, for example. So, I added > a test for that, too. John, if it's not going to break anything for you, > I'll go ahead and fix that. Yes, please do. You might want to modify cbook.to_filehandle to optionally return a tuple specifying whether the returned fh is owned by the caller. Something like: fh, owner = cbook.to_filehandle(fname, returnowner=True) and then later if owner: fh.close() JDH
Done in r4748. I added the kwarg "return_opened" to cbook.to_filehandle(). John Hunter wrote: > On Dec 16, 2007 1:33 PM, Andrew Straw <str...@as...> wrote: >> OK, I added unit/mlab_unit.py to svn. This checks that double precision >> floats can round-trip through rec2csv and csv2rec. To pass requires not >> only svn matplotlib (due to John's change), but also svn numpy (to be >> included with 1.0.5). >> >> Also, it doesn't seem to me that rec2csv should close a file handle >> passed to it. This prevents use with StringIO, for example. So, I added >> a test for that, too. John, if it's not going to break anything for you, >> I'll go ahead and fix that. > > Yes, please do. You might want to modify cbook.to_filehandle to > optionally return a tuple specifying whether the returned fh is owned > by the caller. Something like: > > fh, owner = cbook.to_filehandle(fname, returnowner=True) > > and then later > > if owner: > fh.close() > > JDH > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services > for just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Hang on a minute, it looks like numpy.float64.__repr__() itself isn't reproducing all significant digits... I'm writing up a test now and will move this to the numpy list. I'm not sure how much is MPL and how much is numpy at this point. Trying to make a roundtrip through a .csv file not loose precision, Andrew John Hunter wrote: > On Dec 15, 2007 3:13 PM, Andrew Straw <str...@as...> wrote: > >> mlab.defaultformatd sets the default float formatter for rec2csv() to be >> something that doesn't keep the full representation of a floating point >> number. Obviously, I can pass in my own formatd argument to rec2csv(), >> but I wonder if there's any reason why defaultformatd shouldn't use >> repr() for numpy.float32 and numpy.float64? >> > > I'll be happy to make repr the default. I was using %g because I > mistakenly though this provided the appropriate number of significant > digits. I changed this to %r in the csvformat_factory in svn. > > JDJ >
On Dec 15, 2007 2:52 PM, Andrew Straw <str...@as...> wrote: > Hang on a minute, it looks like numpy.float64.__repr__() itself isn't > reproducing all significant digits... I'm writing up a test now and will > move this to the numpy list. I'm not sure how much is MPL and how much > is numpy at this point. you may want to ping also at #scipy on irc.freenode.net, where the sprint participants are all hanging out. cheers, f
OK, I created a test for numpy to isolate an issue: http://scipy.org/scipy/numpy/ticket/629 I think setting MPL's behavior to repr() is good, though. John, I see you did that r4745 -- thanks. -Andrew Fernando Perez wrote: > On Dec 15, 2007 2:52 PM, Andrew Straw <str...@as...> wrote: >> Hang on a minute, it looks like numpy.float64.__repr__() itself isn't >> reproducing all significant digits... I'm writing up a test now and will >> move this to the numpy list. I'm not sure how much is MPL and how much >> is numpy at this point. > > you may want to ping also at #scipy on irc.freenode.net, where the > sprint participants are all hanging out. > > cheers, > > f