Menu
▾
▴
python-control-discuss
|
From: Ryan K. <rk...@si...> - 2013-06-10 15:53:35
|
I probably won't get to this one for a few weeks (I have a conference and another paper coming up), but I would like to contribute a __repr__ method for TransferFunctions if it would be welcome. I personally would prefer that when I type the name of a TransferFunction instance and hit enter that it pretty print an ascii numerator and denominator and a horizontal line. It might be tricky to do it really nicely with exponents, but this is what happend now: In [2]: G = control.TransferFunction(1,[1,2]) In [3]: G Out[3]: <control.xferfcn.TransferFunction instance at 0x10e94cf80> I then have to ask ro G.num and G.den separately, which I personally don't like. I see that there is a __str__ method which pretty much does what I would want, so that "print G" gives me an ascii representation. Is there any reason not to have __repr__ simply call __str__? Is there some historical reason to have one and not the other? -- Ryan Krauss, Ph.D. Associate Professor Mechanical Engineering Southern Illinois University Edwardsville |
|
From: Richard M. <mu...@cd...> - 2013-06-11 15:47:44
|
We should definitely do something nicer than "<control.xferfcn.TransferFunction instance at 0x10e94cf80>". What's standard for scipy objects (or scipy.signal objects)? I can imagine this eventually becoming part of scipy, so perhaps we use whatever standards exist there as a guide? -richard On 10 Jun 2013, at 8:53 , Ryan Krauss <rk...@si...> wrote: > I probably won't get to this one for a few weeks (I have a conference and another paper coming up), but I would like to contribute a __repr__ method for TransferFunctions if it would be welcome. I personally would prefer that when I type the name of a TransferFunction instance and hit enter that it pretty print an ascii numerator and denominator and a horizontal line. It might be tricky to do it really nicely with exponents, but this is what happend now: > > In [2]: G = control.TransferFunction(1,[1,2]) > > In [3]: G > Out[3]: <control.xferfcn.TransferFunction instance at 0x10e94cf80> > > I then have to ask ro G.num and G.den separately, which I personally don't like. > > I see that there is a __str__ method which pretty much does what I would want, so that "print G" gives me an ascii representation. > > Is there any reason not to have __repr__ simply call __str__? Is there some historical reason to have one and not the other? > > -- > Ryan Krauss, Ph.D. > Associate Professor > Mechanical Engineering > Southern Illinois University Edwardsville > ------------------------------------------------------------------------------ > How ServiceNow helps IT people transform IT departments: > 1. A cloud service to automate IT design, transition and operations > 2. Dashboards that offer high-level views of enterprise services > 3. A single system of record for all IT processes > http://p.sf.net/sfu/servicenow-d2d-j_______________________________________________ > python-control-discuss mailing list > pyt...@li... > https://lists.sourceforge.net/lists/listinfo/python-control-discuss |
|
From: Rene v. P. <ren...@gm...> - 2013-06-11 19:37:10
|
__str__ is for pretty printing __repr__ is ideally for printing a representation that can directly be fed back into Python to re-create the object. Many objects don't implement that, though, it is basically limited to the standard Python objects. On 10 June 2013 17:53, Ryan Krauss <rk...@si...> wrote: > I probably won't get to this one for a few weeks (I have a conference and > another paper coming up), but I would like to contribute a __repr__ method > for TransferFunctions if it would be welcome. I personally would prefer > that when I type the name of a TransferFunction instance and hit enter that > it pretty print an ascii numerator and denominator and a horizontal line. > It might be tricky to do it really nicely with exponents, but this is what > happend now: > > In [2]: G = control.TransferFunction(1,[1,2]) > > In [3]: G > Out[3]: <control.xferfcn.TransferFunction instance at 0x10e94cf80> > > I then have to ask ro G.num and G.den separately, which I personally don't > like. > > I see that there is a __str__ method which pretty much does what I would > want, so that "print G" gives me an ascii representation. > > Is there any reason not to have __repr__ simply call __str__? Is there > some historical reason to have one and not the other? > > -- > Ryan Krauss, Ph.D. > Associate Professor > Mechanical Engineering > Southern Illinois University Edwardsville > > > ------------------------------------------------------------------------------ > How ServiceNow helps IT people transform IT departments: > 1. A cloud service to automate IT design, transition and operations > 2. Dashboards that offer high-level views of enterprise services > 3. A single system of record for all IT processes > http://p.sf.net/sfu/servicenow-d2d-j > _______________________________________________ > python-control-discuss mailing list > pyt...@li... > https://lists.sourceforge.net/lists/listinfo/python-control-discuss > > -- René van Paassen | ______o____/_| Ren...@gm... <[___\_\_-----< t: +31 15 2628685 | o' mobile: +31 6 39846891 |
|
From: Ryan K. <rk...@si...> - 2013-06-12 02:26:29
|
> __repr__ is ideally for printing a representation that can directly be fed back into Python to > re-create the object. I guess I didn't realize this convention. Like you said, I don't think it is typically followed. When I want to look at a variable at the IPython prompt, I am not used to having to type print in front of it. -- Ryan Krauss, Ph.D. Associate Professor Mechanical Engineering Southern Illinois University Edwardsville On Tue, Jun 11, 2013 at 2:37 PM, Rene van Paassen <ren...@gm... > wrote: > __str__ is for pretty printing > __repr__ is ideally for printing a representation that can directly be fed > back into Python to re-create the object. Many objects don't implement > that, though, it is basically limited to the standard Python objects. > > > On 10 June 2013 17:53, Ryan Krauss <rk...@si...> wrote: > >> I probably won't get to this one for a few weeks (I have a conference and >> another paper coming up), but I would like to contribute a __repr__ method >> for TransferFunctions if it would be welcome. I personally would prefer >> that when I type the name of a TransferFunction instance and hit enter that >> it pretty print an ascii numerator and denominator and a horizontal line. >> It might be tricky to do it really nicely with exponents, but this is what >> happend now: >> >> In [2]: G = control.TransferFunction(1,[1,2]) >> >> In [3]: G >> Out[3]: <control.xferfcn.TransferFunction instance at 0x10e94cf80> >> >> I then have to ask ro G.num and G.den separately, which I personally >> don't like. >> >> I see that there is a __str__ method which pretty much does what I would >> want, so that "print G" gives me an ascii representation. >> >> Is there any reason not to have __repr__ simply call __str__? Is there >> some historical reason to have one and not the other? >> >> -- >> Ryan Krauss, Ph.D. >> Associate Professor >> Mechanical Engineering >> Southern Illinois University Edwardsville >> >> >> ------------------------------------------------------------------------------ >> How ServiceNow helps IT people transform IT departments: >> 1. A cloud service to automate IT design, transition and operations >> 2. Dashboards that offer high-level views of enterprise services >> 3. A single system of record for all IT processes >> http://p.sf.net/sfu/servicenow-d2d-j >> _______________________________________________ >> python-control-discuss mailing list >> pyt...@li... >> https://lists.sourceforge.net/lists/listinfo/python-control-discuss >> >> > > > -- > René van Paassen | ______o____/_| Ren...@gm... > <[___\_\_-----< t: +31 15 2628685 > | o' mobile: +31 6 39846891 > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > > _______________________________________________ > python-control-discuss mailing list > pyt...@li... > https://lists.sourceforge.net/lists/listinfo/python-control-discuss > > |
|
From: Ryan K. <rk...@si...> - 2013-06-12 02:29:49
|
I guess we are already following the scipy.signal.ltisys convention: In [4]: test = signal.lti([1,2,3],[1,4,5,6,7]) In [5]: test Out[5]: <scipy.signal.ltisys.lti at 0x1129c5510> In [6]: test.num Out[6]: array([ 1., 2., 3.]) In [7]: test.den Out[7]: array([ 1., 4., 5., 6., 7.]) We are even a step ahead of them in user friendliness: In [8]: print test <scipy.signal.ltisys.lti object at 0x1129c5510> That just doesn't seem user friendly to me. -- Ryan Krauss, Ph.D. Associate Professor Mechanical Engineering Southern Illinois University Edwardsville On Tue, Jun 11, 2013 at 9:26 PM, Ryan Krauss <rk...@si...> wrote: > > __repr__ is ideally for printing a representation that can directly be > fed back into Python to > re-create the object. > > I guess I didn't realize this convention. Like you said, I don't think it > is typically followed. When I want to look at a variable at the IPython > prompt, I am not used to having to type print in front of it. > > > -- > Ryan Krauss, Ph.D. > Associate Professor > Mechanical Engineering > Southern Illinois University Edwardsville > > > On Tue, Jun 11, 2013 at 2:37 PM, Rene van Paassen < > ren...@gm...> wrote: > >> __str__ is for pretty printing >> __repr__ is ideally for printing a representation that can directly be >> fed back into Python to re-create the object. Many objects don't implement >> that, though, it is basically limited to the standard Python objects. >> >> >> On 10 June 2013 17:53, Ryan Krauss <rk...@si...> wrote: >> >>> I probably won't get to this one for a few weeks (I have a conference >>> and another paper coming up), but I would like to contribute a __repr__ >>> method for TransferFunctions if it would be welcome. I personally would >>> prefer that when I type the name of a TransferFunction instance and hit >>> enter that it pretty print an ascii numerator and denominator and a >>> horizontal line. It might be tricky to do it really nicely with exponents, >>> but this is what happend now: >>> >>> In [2]: G = control.TransferFunction(1,[1,2]) >>> >>> In [3]: G >>> Out[3]: <control.xferfcn.TransferFunction instance at 0x10e94cf80> >>> >>> I then have to ask ro G.num and G.den separately, which I personally >>> don't like. >>> >>> I see that there is a __str__ method which pretty much does what I would >>> want, so that "print G" gives me an ascii representation. >>> >>> Is there any reason not to have __repr__ simply call __str__? Is there >>> some historical reason to have one and not the other? >>> >>> -- >>> Ryan Krauss, Ph.D. >>> Associate Professor >>> Mechanical Engineering >>> Southern Illinois University Edwardsville >>> >>> >>> ------------------------------------------------------------------------------ >>> How ServiceNow helps IT people transform IT departments: >>> 1. A cloud service to automate IT design, transition and operations >>> 2. Dashboards that offer high-level views of enterprise services >>> 3. A single system of record for all IT processes >>> http://p.sf.net/sfu/servicenow-d2d-j >>> _______________________________________________ >>> python-control-discuss mailing list >>> pyt...@li... >>> https://lists.sourceforge.net/lists/listinfo/python-control-discuss >>> >>> >> >> >> -- >> René van Paassen | ______o____/_| Ren...@gm... >> <[___\_\_-----< t: +31 15 2628685 >> | o' mobile: +31 6 39846891 >> >> >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by Windows: >> >> Build for Windows Store. >> >> http://p.sf.net/sfu/windows-dev2dev >> >> _______________________________________________ >> python-control-discuss mailing list >> pyt...@li... >> https://lists.sourceforge.net/lists/listinfo/python-control-discuss >> >> > |
|
From: Rene v. P. <ren...@gm...> - 2013-06-12 07:16:21
|
Numpy does this:
Imported NumPy 1.6.2, SciPy 0.10.1, Matplotlib 1.0.1
Type "scientific" for more details.
>>> import numpy as np
>>> x = np.arange(0, 9)
>>> x
array([0, 1, 2, 3, 4, 5, 6, 7, 8])
>>> y = array([0, 1, 2, 3, 4, 5, 6, 7, 8])
>>> y
array([0, 1, 2, 3, 4, 5, 6, 7, 8])
>>> print x
[0 1 2 3 4 5 6 7 8]
But for big arrays
>>> y = np.arange(0, 100, 0.01)
>>> y
array([ 0.00000000e+00, 1.00000000e-02, 2.00000000e-02, ...,
9.99700000e+01, 9.99800000e+01, 9.99900000e+01])
I guess for python-control the proper thing is something like:
>>> h
TransferFunction([1], [1, 2, 1])
I wouldn't have known the distinction between __repr__ and __str__ either,
but stumbled upon it since I am currently teaching python to 1st year
undergrads. I also teach control theory to 2nd year, of which a quarter is
using Python (from last year's Python programming trial) and the rest is
using Matlab.
René
Associate Professor
Aerospace Engineering
Delft University of Technology
On 12 June 2013 04:26, Ryan Krauss <rk...@si...> wrote:
> > __repr__ is ideally for printing a representation that can directly be
> fed back into Python to > re-create the object.
>
> I guess I didn't realize this convention. Like you said, I don't think it
> is typically followed. When I want to look at a variable at the IPython
> prompt, I am not used to having to type print in front of it.
>
>
> --
> Ryan Krauss, Ph.D.
> Associate Professor
> Mechanical Engineering
> Southern Illinois University Edwardsville
>
>
> On Tue, Jun 11, 2013 at 2:37 PM, Rene van Paassen <
> ren...@gm...> wrote:
>
>> __str__ is for pretty printing
>> __repr__ is ideally for printing a representation that can directly be
>> fed back into Python to re-create the object. Many objects don't implement
>> that, though, it is basically limited to the standard Python objects.
>>
>>
>> On 10 June 2013 17:53, Ryan Krauss <rk...@si...> wrote:
>>
>>> I probably won't get to this one for a few weeks (I have a conference
>>> and another paper coming up), but I would like to contribute a __repr__
>>> method for TransferFunctions if it would be welcome. I personally would
>>> prefer that when I type the name of a TransferFunction instance and hit
>>> enter that it pretty print an ascii numerator and denominator and a
>>> horizontal line. It might be tricky to do it really nicely with exponents,
>>> but this is what happend now:
>>>
>>> In [2]: G = control.TransferFunction(1,[1,2])
>>>
>>> In [3]: G
>>> Out[3]: <control.xferfcn.TransferFunction instance at 0x10e94cf80>
>>>
>>> I then have to ask ro G.num and G.den separately, which I personally
>>> don't like.
>>>
>>> I see that there is a __str__ method which pretty much does what I would
>>> want, so that "print G" gives me an ascii representation.
>>>
>>> Is there any reason not to have __repr__ simply call __str__? Is there
>>> some historical reason to have one and not the other?
>>>
>>> --
>>> Ryan Krauss, Ph.D.
>>> Associate Professor
>>> Mechanical Engineering
>>> Southern Illinois University Edwardsville
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> How ServiceNow helps IT people transform IT departments:
>>> 1. A cloud service to automate IT design, transition and operations
>>> 2. Dashboards that offer high-level views of enterprise services
>>> 3. A single system of record for all IT processes
>>> http://p.sf.net/sfu/servicenow-d2d-j
>>> _______________________________________________
>>> python-control-discuss mailing list
>>> pyt...@li...
>>> https://lists.sourceforge.net/lists/listinfo/python-control-discuss
>>>
>>>
>>
>>
>> --
>> René van Paassen | ______o____/_| Ren...@gm...
>> <[___\_\_-----< t: +31 15 2628685
>> | o' mobile: +31 6 39846891
>>
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Windows:
>>
>> Build for Windows Store.
>>
>> http://p.sf.net/sfu/windows-dev2dev
>>
>> _______________________________________________
>> python-control-discuss mailing list
>> pyt...@li...
>> https://lists.sourceforge.net/lists/listinfo/python-control-discuss
>>
>>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> python-control-discuss mailing list
> pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-control-discuss
>
>
--
René van Paassen | ______o____/_| Ren...@gm...
<[___\_\_-----< t: +31 15 2628685
| o' mobile: +31 6 39846891
|
|
From: Ryan K. <rk...@si...> - 2013-06-12 15:43:35
|
> >>> h > TransferFunction([1], [1, 2, 1]) This would be a big improvement in my mind and seems simple to implement. -- Ryan Krauss, Ph.D. Associate Professor Mechanical Engineering Southern Illinois University Edwardsville On Wed, Jun 12, 2013 at 2:16 AM, Rene van Paassen <ren...@gm... > wrote: > Numpy does this: > > Imported NumPy 1.6.2, SciPy 0.10.1, Matplotlib 1.0.1 > Type "scientific" for more details. > >>> import numpy as np > >>> x = np.arange(0, 9) > >>> x > array([0, 1, 2, 3, 4, 5, 6, 7, 8]) > >>> y = array([0, 1, 2, 3, 4, 5, 6, 7, 8]) > >>> y > array([0, 1, 2, 3, 4, 5, 6, 7, 8]) > >>> print x > [0 1 2 3 4 5 6 7 8] > > But for big arrays > > >>> y = np.arange(0, 100, 0.01) > > > >>> y > > array([ 0.00000000e+00, 1.00000000e-02, 2.00000000e-02, ..., > > 9.99700000e+01, 9.99800000e+01, 9.99900000e+01]) > > > I guess for python-control the proper thing is something like: > > > >>> h > > TransferFunction([1], [1, 2, 1]) > > > I wouldn't have known the distinction between __repr__ and __str__ either, > but stumbled upon it since I am currently teaching python to 1st year > undergrads. I also teach control theory to 2nd year, of which a quarter is > using Python (from last year's Python programming trial) and the rest is > using Matlab. > > > René > > > Associate Professor > > Aerospace Engineering > > Delft University of Technology > > > On 12 June 2013 04:26, Ryan Krauss <rk...@si...> wrote: > >> > __repr__ is ideally for printing a representation that can directly be >> fed back into Python to > re-create the object. >> >> I guess I didn't realize this convention. Like you said, I don't think >> it is typically followed. When I want to look at a variable at the IPython >> prompt, I am not used to having to type print in front of it. >> >> >> -- >> Ryan Krauss, Ph.D. >> Associate Professor >> Mechanical Engineering >> Southern Illinois University Edwardsville >> >> >> On Tue, Jun 11, 2013 at 2:37 PM, Rene van Paassen < >> ren...@gm...> wrote: >> >>> __str__ is for pretty printing >>> __repr__ is ideally for printing a representation that can directly be >>> fed back into Python to re-create the object. Many objects don't implement >>> that, though, it is basically limited to the standard Python objects. >>> >>> >>> On 10 June 2013 17:53, Ryan Krauss <rk...@si...> wrote: >>> >>>> I probably won't get to this one for a few weeks (I have a conference >>>> and another paper coming up), but I would like to contribute a __repr__ >>>> method for TransferFunctions if it would be welcome. I personally would >>>> prefer that when I type the name of a TransferFunction instance and hit >>>> enter that it pretty print an ascii numerator and denominator and a >>>> horizontal line. It might be tricky to do it really nicely with exponents, >>>> but this is what happend now: >>>> >>>> In [2]: G = control.TransferFunction(1,[1,2]) >>>> >>>> In [3]: G >>>> Out[3]: <control.xferfcn.TransferFunction instance at 0x10e94cf80> >>>> >>>> I then have to ask ro G.num and G.den separately, which I personally >>>> don't like. >>>> >>>> I see that there is a __str__ method which pretty much does what I >>>> would want, so that "print G" gives me an ascii representation. >>>> >>>> Is there any reason not to have __repr__ simply call __str__? Is there >>>> some historical reason to have one and not the other? >>>> >>>> -- >>>> Ryan Krauss, Ph.D. >>>> Associate Professor >>>> Mechanical Engineering >>>> Southern Illinois University Edwardsville >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> How ServiceNow helps IT people transform IT departments: >>>> 1. A cloud service to automate IT design, transition and operations >>>> 2. Dashboards that offer high-level views of enterprise services >>>> 3. A single system of record for all IT processes >>>> http://p.sf.net/sfu/servicenow-d2d-j >>>> _______________________________________________ >>>> python-control-discuss mailing list >>>> pyt...@li... >>>> https://lists.sourceforge.net/lists/listinfo/python-control-discuss >>>> >>>> >>> >>> >>> -- >>> René van Paassen | ______o____/_| Ren...@gm... >>> <[___\_\_-----< t: +31 15 2628685 >>> | o' mobile: +31 6 39846891 >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> This SF.net email is sponsored by Windows: >>> >>> Build for Windows Store. >>> >>> http://p.sf.net/sfu/windows-dev2dev >>> >>> _______________________________________________ >>> python-control-discuss mailing list >>> pyt...@li... >>> https://lists.sourceforge.net/lists/listinfo/python-control-discuss >>> >>> >> >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by Windows: >> >> Build for Windows Store. >> >> http://p.sf.net/sfu/windows-dev2dev >> _______________________________________________ >> python-control-discuss mailing list >> pyt...@li... >> https://lists.sourceforge.net/lists/listinfo/python-control-discuss >> >> > > > -- > René van Paassen | ______o____/_| Ren...@gm... > <[___\_\_-----< t: +31 15 2628685 > | o' mobile: +31 6 39846891 > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > > _______________________________________________ > python-control-discuss mailing list > pyt...@li... > https://lists.sourceforge.net/lists/listinfo/python-control-discuss > > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X