pyginac-users Mailing List for PyGiNaC
Status: Alpha
Brought to you by:
jbrandmeyer
Menu
▾
▴
pyginac-users — General discussion about the PyGiNaC interface.
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
(1) |
Mar
(3) |
Apr
(5) |
May
(1) |
Jun
(2) |
Jul
|
Aug
|
Sep
(7) |
Oct
(7) |
Nov
|
Dec
|
|---|
|
From: Jonathan B. <jbr...@ea...> - 2005-10-11 00:29:04
|
On Mon, 2005-10-10 at 19:13 +0300, Matti Peltom=E4ki wrote: > Hi,=20 >=20 > On Tue, 4 Oct 2005, Jonathan Brandmeyer wrote: >=20 > > In the current fix, if the test fails one way, it is retried with the > > second option. >=20 > Based on Richard Kreckel's insight on what the problem may be on=20 > ginac-list, I propose to work around this such that all the exam_* test=20 > suites are run before the check_* ones, since the latter ones are those > who introduce a random number of new symbols and affect the canonical=20 > ordering giving the irritating results we had. >=20 > This workaround also has the advantage that it more precisely mimicks=20 > GiNaC's test suites' behavior, which, I guess, in some loose sense, is ou= r=20 > goal. My original goal was to use the ability to run a similar test suite as a measure of PyGiNaC's completeness. So, I'm not particularly concerned about relatively minor differences like this. > I have committed these changes to the CVS.=20 > On the other hand, I'm quite puzzled with your changes in exam_lsolve > between revisions 1.1 and 1.2. From my point of view the tests passed > cleanly before tha changes but not after. Is it the other way around for > you? Yes it was. > If so, do we have some differences in our environments? Probably. Upon investigation, I found that str(numeric(1)) =3D=3D '1.0' on my Sid machine and '1' on my Sarge machine. So I changed that particular test to operate exactly like the others in that file. It should work fine in both environments now. -Jonathan |
|
From: <pp...@fy...> - 2005-10-10 16:15:16
|
Hi, On Tue, 4 Oct 2005, Jonathan Brandmeyer wrote: > In the current fix, if the test fails one way, it is retried with the > second option. Based on Richard Kreckel's insight on what the problem may be on ginac-list, I propose to work around this such that all the exam_* test suites are run before the check_* ones, since the latter ones are those who introduce a random number of new symbols and affect the canonical ordering giving the irritating results we had. This workaround also has the advantage that it more precisely mimicks GiNaC's test suites' behavior, which, I guess, in some loose sense, is our goal. I have committed these changes to the CVS. On the other hand, I'm quite puzzled with your changes in exam_lsolve between revisions 1.1 and 1.2. From my point of view the tests passed cleanly before tha changes but not after. Is it the other way around for you? If so, do we have some differences in our environments? Thanks, Matti -- Matti Peltomaki, Graduate Student Laboratory of Physics Helsinki University of Technology 040 7576977, room Y308B |
|
From: Jonathan B. <jbr...@ea...> - 2005-10-04 23:51:09
|
On Tue, 2005-10-04 at 20:14 +0300, Matti Peltom=E4ki wrote: > Hi,=20 >=20 > > I think that this is a canonicalization issue. If hash(x) is greater > > than hash(y) (when reinterpret_cast'ed back to unsigned ints), then > > pow(x - y, 2) normalizes to pow(y - x, 2) > >=20 > > I'm not sure if this behavior is deliberate so I'm bringing it up on > > ginac-list. In the meantime, a patch has been committed to CVS that > > works around the error. >=20 > I'm afraid there is something wrong in the workaround. I did a cvs update= =20 > getting your changes (bin/exam_normalization.py and ChangeLog) and rerun=20 > the test (again several times since it does not fail every time), and I=20 > still get the error sometimes.=20 >=20 > Are you still able to reproduce the error or is it just me?=20 I guess I didn't run the test often enough before I committed the fix last night, because you are right. Whatever the cause of the error, I'm inclined to let it slide since this is mathematically correct, and because (pow(x-y, 2)/pow(y-x,2)).normal() evaluates to numeric(1). In the current fix, if the test fails one way, it is retried with the second option. -Jonathan |
|
From: <pp...@fy...> - 2005-10-04 17:16:06
|
Hi, > I think that this is a canonicalization issue. If hash(x) is greater > than hash(y) (when reinterpret_cast'ed back to unsigned ints), then > pow(x - y, 2) normalizes to pow(y - x, 2) > > I'm not sure if this behavior is deliberate so I'm bringing it up on > ginac-list. In the meantime, a patch has been committed to CVS that > works around the error. I'm afraid there is something wrong in the workaround. I did a cvs update getting your changes (bin/exam_normalization.py and ChangeLog) and rerun the test (again several times since it does not fail every time), and I still get the error sometimes. Are you still able to reproduce the error or is it just me? Regards, Matti -- Matti Peltomaki, Graduate Student Laboratory of Physics Helsinki University of Technology 040 7576977, room Y308B |
|
From: Jonathan B. <jbr...@ea...> - 2005-10-03 18:38:58
|
On Mon, 2005-10-03 at 20:27 +0300, Matti Peltom=E4ki wrote: > Hi, >=20 > while playing around with pyginac, I found some strange behavior with > the regression test suite. The reason to this behavior escapes me.=20 >=20 > When running ./run python2.3 bin/checkall.py most of the time=20 > everything goes ok, but every now and then an error occurs as follows. >=20 > ***************************************************************** > Failure in example: exam_normal2() > from line #1 of exam_normalization.exam_normal2 > Expected: 0 > Got: > normal form of (-y+x)**(-3)*(x**2-y**2) returned (y-x)**(-2)*(y+x) wh= ile=20 > it should be (-y+x)**(-2)*(y+x) > normal form of (x**2-y**2)*(-1/2*y+1/2*x)**(-3) returned =20 > (y-x)**(-2)*(8*y+8*x) while it should be (-y+x)**(-2)*(8*y+8*x) I think that this is a canonicalization issue. If hash(x) is greater than hash(y) (when reinterpret_cast'ed back to unsigned ints), then pow(x - y, 2) normalizes to pow(y - x, 2) I'm not sure if this behavior is deliberate so I'm bringing it up on ginac-list. In the meantime, a patch has been committed to CVS that works around the error. -Jonathan |
|
From: Ondrej C. <on...@ce...> - 2005-10-03 17:37:08
|
Yes, we created another ginac bindings in swig, swiginac.berlios.de, and we have the same problems - they seem to be in ginac. Ondrej On Mon, Oct 03, 2005 at 08:27:02PM +0300, Matti Peltom=E4ki wrote: >=20 > Hi, >=20 > while playing around with pyginac, I found some strange behavior with > the regression test suite. The reason to this behavior escapes me.=20 >=20 > When running ./run python2.3 bin/checkall.py most of the time=20 > everything goes ok, but every now and then an error occurs as follows. >=20 > ***************************************************************** > Failure in example: exam_normal2() > from line #1 of exam_normalization.exam_normal2 > Expected: 0 > Got: > normal form of (-y+x)**(-3)*(x**2-y**2) returned (y-x)**(-2)*(y+x) wh= ile=20 > it should be (-y+x)**(-2)*(y+x) > normal form of (x**2-y**2)*(-1/2*y+1/2*x)**(-3) returned =20 > (y-x)**(-2)*(8*y+8*x) while it should be (-y+x)**(-2)*(8*y+8*x) > 2 > ***************************************************************** > 1 items had failures: > 1 of 1 in exam_normalization.exam_normal2 > ***Test Failed*** 1 failures. >=20 > To get an idea how often this happens, I ran the test 100 times, giving 4= 3=20 > fails and 57 clean passes. The interesting part is that when I run >=20 > ./run python2.3 exam_normalization.py >=20 > I am totally unable to reproduce the error above, leading to a guess that= this=20 > might have something to do with bin/checkall.py and/or the doctest module= =2E=20 > However, I have not been able to point any other reason as to why this wo= uld=20 > be so. I also checked with python 2.4 (Debian-packaged 2.4.1-2) with the = same=20 > results.=20 >=20 > I am using an up-to-date cvs of PyGiNaC, GiNaC 1.3.2, boost.python 1.33.0, > gcc 4.0.2 and python 2.3.5 (all of which except PyGiNaC are the=20 > Debian-packaged versions).=20 >=20 > So, does anybody have any idea? Can anyone else reproduce this? >=20 > Best Regards, > Matti >=20 > --=20 > Matti Peltomaki, Graduate Student > Laboratory of Physics=20 > Helsinki University of Technology > 040 7576977, room Y308B >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Pyginac-users mailing list > Pyg...@li... > https://lists.sourceforge.net/lists/listinfo/pyginac-users |
|
From: <pp...@fy...> - 2005-10-03 17:28:13
|
Hi, while playing around with pyginac, I found some strange behavior with the regression test suite. The reason to this behavior escapes me. When running ./run python2.3 bin/checkall.py most of the time everything goes ok, but every now and then an error occurs as follows. ***************************************************************** Failure in example: exam_normal2() from line #1 of exam_normalization.exam_normal2 Expected: 0 Got: normal form of (-y+x)**(-3)*(x**2-y**2) returned (y-x)**(-2)*(y+x) while it should be (-y+x)**(-2)*(y+x) normal form of (x**2-y**2)*(-1/2*y+1/2*x)**(-3) returned (y-x)**(-2)*(8*y+8*x) while it should be (-y+x)**(-2)*(8*y+8*x) 2 ***************************************************************** 1 items had failures: 1 of 1 in exam_normalization.exam_normal2 ***Test Failed*** 1 failures. To get an idea how often this happens, I ran the test 100 times, giving 43 fails and 57 clean passes. The interesting part is that when I run ./run python2.3 exam_normalization.py I am totally unable to reproduce the error above, leading to a guess that this might have something to do with bin/checkall.py and/or the doctest module. However, I have not been able to point any other reason as to why this would be so. I also checked with python 2.4 (Debian-packaged 2.4.1-2) with the same results. I am using an up-to-date cvs of PyGiNaC, GiNaC 1.3.2, boost.python 1.33.0, gcc 4.0.2 and python 2.3.5 (all of which except PyGiNaC are the Debian-packaged versions). So, does anybody have any idea? Can anyone else reproduce this? Best Regards, Matti -- Matti Peltomaki, Graduate Student Laboratory of Physics Helsinki University of Technology 040 7576977, room Y308B |
|
From: Jonathan B. <jbr...@ea...> - 2005-09-19 03:19:02
|
On Mon, 2005-09-19 at 00:27 +0200, Richard B. Kreckel wrote: > Hi! > > Is there a place where I can read more about how the lookup of the > library works, when one invokes a Python 'from ginac import...' command? Libraries in Python are called "modules", initially covered in Section 6 of the Python Tutorial. See also "Creating Packages" in the Boost.Python tutorial, sys.path in the Python Library Reference, and "Modifying Python's Search Path" in the Installing Python Modules manual. If it isn't clear from the Boost.Python docs, the entry point function in a Boost.Python extension is identified with the BOOST_PYTHON_MODULE macro. > I guess it is not possible to use any of this stuff with static library. Compiled Python modules are typically dynamically loaded shared libraries. There is a mechanism for preloading a static lib into the Python interpreter if you _really_ need to do so, but it requires relinking the interpreter every time you rebuild the extension module and is generally a royal PITA to use. > PS: The top-level run script has PYTHONPATH misspelled as PYHTONPATH. Fixed, thanks. HTH, -Jonathan |
|
From: Jonathan B. <jbr...@ea...> - 2005-09-18 22:41:46
|
On Sat, 2005-09-17 at 23:26 +0200, Richard B. Kreckel wrote:
> > This is because 'l' is actually a Python list, it isn't a GiNaC::exlist
> > (sp?) pretending to be a Python list. The python list's __str__ method
> > (invoked by the print statement) annoyingly invokes the __repr__ method
> > of its containees rather than __str__.
>
> Let me try to understand: Is this a feature?
I can only guess that some Python developers think it is a feature. The
language has a general trend of simplicity and ease of use, but
controversies like this exist.
> > __repr__ isn't defined by
> > PyGiNaC's classes, so you get the default behavior: the address of the
> > wrapping PyObject.
>
> Why not define it?
Because repr(x) is supposed to return a string that can be used to
re-create x.
"repr(...)
repr(object) -> string
Return the canonical string representation of the object.
For most object types, eval(repr(object)) == object."
So, the correct behavior of, "repr(numeric(1, 2))" would be to return
the string "numeric(1,2)", not "1/2" or "1.0/2.0". I haven't written
the code that would provide this behavior.
> > There are (at least) two workarounds.
> [...]
>
> Both workarounds appear cumbersome to me.
You can modify the definition of the basic class by inserting the
relevant code in site-packages/ginac/__init__.py and it will apply to
all of your programs.
HTH,
-Jonathan
|
|
From: Richard B. K. <kr...@gi...> - 2005-09-18 22:27:41
|
Hi! Is there a place where I can read more about how the lookup of the library works, when one invokes a Python 'from ginac import...' command? I guess it is not possible to use any of this stuff with static library. TIA -richy. PS: The top-level run script has PYTHONPATH misspelled as PYHTONPATH. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/> |
|
From: Richard B. K. <kr...@gi...> - 2005-09-17 21:27:07
|
Hi! On Wed, 14 Sep 2005, Jonathan Brandmeyer wrote: [...] > The ex will be automatically converted back to a numeric when wrapping > it as an object, and list::append() automatically attempts to > wrap/convert any argument it gets in/to a Python object, so just use > result.append( -GiNaC::numeric(x_split.quotient)); Okay, thanks a lot. It works just fine with your suggestions applied. [...] > If you saw manual refcount management in the PyGiNaC code it should be > limited to the custom rvalue converter registration code. In general, > you can just rely on class object's automatic refcount management. Yeah, I came across this stuff in PyGiNaC's file lst.cpp. lst_to_python::convert(const GiNaC::lst&) is where I copied from. > This is because 'l' is actually a Python list, it isn't a GiNaC::exlist > (sp?) pretending to be a Python list. The python list's __str__ method > (invoked by the print statement) annoyingly invokes the __repr__ method > of its containees rather than __str__. Let me try to understand: Is this a feature? > __repr__ isn't defined by > PyGiNaC's classes, so you get the default behavior: the address of the > wrapping PyObject. Why not define it? > There are (at least) two workarounds. [...] Both workarounds appear cumbersome to me. Best wishes -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/> |
|
From: Jonathan B. <jbr...@ea...> - 2005-09-14 23:10:36
|
On Wed, 2005-09-14 at 23:55 +0200, Richard B. Kreckel wrote:
> Hi,
>
> I've just tried to hack a continued fraction routine into PyGiNaC:
>
> diff -r1.7 numeric.cpp
> 17a18
> > #include <cln/real.h>
> 111a113,146
For cleanliness, you probably just want to return a
boost::python::object...
> > static PyObject*
> > do_contfrac(const GiNaC::numeric x, unsigned len)
> > {
> > boost::python::list result;
> > if (!x.is_real()) {
> > // Complex?
> > Py_INCREF(result.ptr());
> > return result.ptr();
which makes this statement "return result;" without the Py_INCREF
business.
> > }
> > cln::cl_R x_ = cln::the<cln::cl_R>(x.to_cl_N());
> > bool negative = false;
> > if (cln::minusp(x_)) {
> > negative = true;
> > x_ = -x_;
> > }
> > for (unsigned r=0; r<len; ++r) {
> > // Split x into integral and fractional part.
> > cln::cl_R_div_t x_split = cln::floor2(x_);
> > if (negative) {
> > result.append(boost::python::object(GiNaC::ex(-GiNaC::numeric(x_split.quotient))));
The ex will be automatically converted back to a numeric when wrapping
it as an object, and list::append() automatically attempts to
wrap/convert any argument it gets in/to a Python object, so just use
result.append( -GiNaC::numeric(x_split.quotient));
> > negative = false;
> > } else {
> > result.append(boost::python::object(GiNaC::ex(GiNaC::numeric(x_split.quotient))));
Same here.
> > }
> > x_ = x_split.remainder;
> > if (cln::zerop(x_))
> > break;
> > // Invert x.
> > x_ = cln::recip(x_);
> > }
> > Py_INCREF(result.ptr());
> > return result.ptr();
Again, you don't need to do this. Just "return result;" and allow class
boost::python::object to manage the refcount.
If you saw manual refcount management in the PyGiNaC code it should be
limited to the custom rvalue converter registration code. In general,
you can just rely on class object's automatic refcount management.
> > }
> >
> 156a192
> > def( "contfrac", &do_contfrac, "continued fraction of a real number.");
>
> However, when I use it:
>
> >>> l=contfrac(3.1415926,2)
> >>> print l
> [<cginac.numeric object at 0xb7dbf974>, <cginac.numeric object at 0xb7dbf9bc>]
This is because 'l' is actually a Python list, it isn't a GiNaC::exlist
(sp?) pretending to be a Python list. The python list's __str__ method
(invoked by the print statement) annoyingly invokes the __repr__ method
of its containees rather than __str__. __repr__ isn't defined by
PyGiNaC's classes, so you get the default behavior: the address of the
wrapping PyObject. There are (at least) two workarounds.
You can force conversion to a string every time you want to display the
members when at print time with a list comprehension.
You can modify the definition of class 'basic' (at runtime!) such that
it has a non-default __repr__ method.
Python 2.3.5 (#2, Aug 30 2005, 15:50:26)
[GCC 4.0.2 20050821 (prerelease) (Debian 4.0.1-6)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from ginac import *
>>> l = [numeric(1), numeric(3)]
>>> isinstance(l, list)
True
>>> print l
[<cginac.numeric object at 0xb7d25c84>, <cginac.numeric object at
0xb7d34c34>]
>>> print [str(x) for x in l] # so-called "list comprehension"
['1.0', '3.0']
>>> # Change the definition of class cginac.basic
>>> basic.__repr__ = basic.__str__
>>> print l
[1.0, 3.0]
>>> del basic.__repr__ # Restore default behavior
>>> print l
[<cginac.numeric object at 0xb7d25c84>, <cginac.numeric object at
0xb7d34c34>]
HTH,
-Jonathan
|
|
From: Ondrej C. <on...@ce...> - 2005-09-14 22:41:15
|
> >>> l=contfrac(3.1415926,2) > >>> print l > [<cginac.numeric object at 0xb7dbf974>, <cginac.numeric object at 0xb7dbf9bc>] > >>> print l[0] > 3 > >>> print l[1] > 7 > >>> print l[0:1] > [<cginac.numeric object at 0xb7dbf974>] > > I wish to print [3,7]. What am I missing? You need to do something like this (see unittests for more info): print [str(x) for x in l] this should print [3,7] Ondrej Certik |
|
From: Richard B. K. <kr...@gi...> - 2005-09-14 21:56:03
|
Hi,
I've just tried to hack a continued fraction routine into PyGiNaC:
diff -r1.7 numeric.cpp
17a18
> #include <cln/real.h>
111a113,146
> static PyObject*
> do_contfrac(const GiNaC::numeric x, unsigned len)
> {
> boost::python::list result;
> if (!x.is_real()) {
> // Complex?
> Py_INCREF(result.ptr());
> return result.ptr();
> }
> cln::cl_R x_ = cln::the<cln::cl_R>(x.to_cl_N());
> bool negative = false;
> if (cln::minusp(x_)) {
> negative = true;
> x_ = -x_;
> }
> for (unsigned r=0; r<len; ++r) {
> // Split x into integral and fractional part.
> cln::cl_R_div_t x_split = cln::floor2(x_);
> if (negative) {
> result.append(boost::python::object(GiNaC::ex(-GiNaC::numeric(x_split.quotient))));
> negative = false;
> } else {
> result.append(boost::python::object(GiNaC::ex(GiNaC::numeric(x_split.quotient))));
> }
> x_ = x_split.remainder;
> if (cln::zerop(x_))
> break;
> // Invert x.
> x_ = cln::recip(x_);
> }
> Py_INCREF(result.ptr());
> return result.ptr();
> }
>
156a192
> def( "contfrac", &do_contfrac, "continued fraction of a real number.");
However, when I use it:
>>> l=contfrac(3.1415926,2)
>>> print l
[<cginac.numeric object at 0xb7dbf974>, <cginac.numeric object at 0xb7dbf9bc>]
>>> print l[0]
3
>>> print l[1]
7
>>> print l[0:1]
[<cginac.numeric object at 0xb7dbf974>]
I wish to print [3,7]. What am I missing?
Thanks in advance
-richy.
--
Richard B. Kreckel
<http://www.ginac.de/~kreckel/>
|
|
From: <pp...@fy...> - 2005-06-30 20:27:59
|
Dear All, due to a request, I have prepared a short and quickly written but hopefully informative web page for PyGiNaC and uploaded it to SF.net. http://pyginac.sourceforge.net/ If there is anything that is wrong about it or missing, please let me know. Regards, Matti -- Matti Peltomaki, Graduate Student Laboratory of Physics Helsinki University of Technology 040 7576977, room Y308B |
|
From: <pp...@fy...> - 2005-06-14 21:20:14
|
Hi, Ondrej Certik wrote: > Here is the patch for the latter aproach. I modified lst.cpp, maybe > you move it somewhere else. I have now applied parts of your patches (the parts related to class indexed), they look good to me, and committed them together with a couple of other changes related to indexed to CVS. Thanks for the patches. Regards, Matti -- Matti Peltomaki, Graduate Student Laboratory of Physics Helsinki University of Technology 040 7576977, room Y308B |
|
From: <pp...@fy...> - 2005-05-18 18:31:10
|
Hi All, > > The latex patch should have been implemented like this. Maybe you > > could embed it in a better way. > > O. Certik > I'll take a look at the patch this weekend. I've been meaning to > revisit the way stringification is done, anyway. Jonathan, are you working on this. If it's ok with you I could take a look at Ondrej's patch for indexed and eventually commit it. I ask beforehand since I don't want to step on your toes. And how about the stringification business? What are your plans about it? Best wishes, Matti -- Matti Peltomaki, Graduate Student Laboratory of Physics Helsinki University of Technology 040 7576977, room Y308B |
|
From: Ondrej C. <ond...@gm...> - 2005-04-28 15:28:13
|
I was rejected by a spam filter. Trying again...
Here is the patch for the latter aproach. I modified lst.cpp, maybe
you move it somewhere else.
--- pyginac-orig/src/lst.cpp 2005-03-07 17:38:59.000000000 +0100
+++ pyginac/src/lst.cpp 2005-04-28 17:17:59.945485288 +0200
@@ -62,6 +62,22 @@
}
};
+struct exvector_to_python
+{
+ static PyObject* convert( const GiNaC::exvector& obj)
+ {
+ boost::python::list ret;
+ GiNaC::exvector::const_iterator i =3D obj.begin();
+ GiNaC::exvector::const_iterator i_end =3D obj.end();
+ while (i !=3D i_end) {
+ ret.append( boost::python::object(*i));
+ ++i;
+ }
+ Py_INCREF(ret.ptr());
+ return ret.ptr();
+ }
+};
+
} // !namespace pyginac::(unnamed)
void
@@ -128,6 +144,8 @@
to_python_converter<GiNaC::lst, lst_to_python>();
// TODO: Implement implicit conversions from Python lists of expressio=
ns
// to GiNaC::lst 's.
+ //
+ to_python_converter<GiNaC::exvector, exvector_to_python>();
}
On 4/28/05, Ondrej Certik <ond...@gm...> wrote:
> Hello,
> I would like to implement indexed objects, because I need them. But I
> have some problems with boost.python. I would like to use
> basic::get_free_indices, which returns std::vector<ex>,
> so I would like to implicitly convert std::vector<ex> to python list.
> I found vector_wrapper in cctbx:
>
> http://cvs.sourceforge.net/viewcvs.py/*checkout*/cctbx/scitbx/include/sci=
tbx/stl
> /vector_wrapper.h?rev=3D1.4
>
> but unfortunately it uses many headers from cctbx. Maybe it is easier to
> convert it like you do in lst.cpp? I try the latter approach.
>
> O. Certik
>
|
|
From: Ondrej C. <ond...@gm...> - 2005-04-28 15:14:14
|
Hello, I would like to implement indexed objects, because I need them. But I have some problems with boost.python. I would like to use basic::get_free_indices, which returns std::vector<ex>, so I would like to implicitly convert std::vector<ex> to python list. I found vector_wrapper in cctbx: http://cvs.sourceforge.net/viewcvs.py/*checkout*/cctbx/scitbx/include/scitb= x/stl /vector_wrapper.h?rev=3D1.4 but unfortunately it uses many headers from cctbx. Maybe it is easier to convert it like you do in lst.cpp? I try the latter approach. O. Certik |
|
From: Jonathan B. <jbr...@ea...> - 2005-04-27 02:43:29
|
On Tue, 2005-04-26 at 12:55 +0200, Ondrej Certik wrote:
> The latex patch should have been implemented like this. Maybe you
> could embed it in a better way.
> O. Certik
I'll take a look at the patch this weekend. I've been meaning to
revisit the way stringification is done, anyway.
-Jonathan
> --- pyginac-orig/src/basic.cpp 2005-03-30 22:55:17.000000000 +0200
> +++ pyginac/src/basic.cpp 2005-04-26 12:47:31.176443904 +0200
> @@ -397,6 +397,27 @@
> return converter.returned_hash;
> }
>
> +//template< typename GinacPrintable>
> +//print_to_string_latex(const GinacPrintable & This)
> +/*std::string
> +print_to_string_latex(const GiNaC::basic& This)
> +{
> + std::ostringstream output;
> + output << GiNaC::latex;
> + output << This;
> + return output.str();
> +}*/
> +template< typename GinacPrintable>
> +std::string
> +print_to_string_latex( GinacPrintable* object)
> +{
> + std::ostringstream output;
> + GiNaC::print_latex context( output);
> + object->print( context);
> + return output.str();
> +}
> +
> +
> } // !namespace anonymous
>
> void
> @@ -524,6 +545,7 @@
>
> // Overrides for special Python object behavior
> .def( "__str__", &print_to_string<basic>)
> + .def( "print_latex", &print_to_string_latex<basic>)
> .def( "__hash__", wrap_hash, "Compute a hash of an expression.")
> ;
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Tell us your software development plans!
> Take this survey and enter to win a one-year sub to SourceForge.net
> Plus IDC's 2005 look-ahead and a copy of this survey
> Click here to start! http://www.idcswdc.com/cgi-bin/survey?id5hix
> _______________________________________________
> Pyginac-users mailing list
> Pyg...@li...
> https://lists.sourceforge.net/lists/listinfo/pyginac-users
|
|
From: Ondrej C. <ond...@gm...> - 2005-04-26 10:55:12
|
The latex patch should have been implemented like this. Maybe you
could embed it in a better way.
O. Certik
--- pyginac-orig/src/basic.cpp 2005-03-30 22:55:17.000000000 +0200
+++ pyginac/src/basic.cpp 2005-04-26 12:47:31.176443904 +0200
@@ -397,6 +397,27 @@
return converter.returned_hash;
}
+//template< typename GinacPrintable>
+//print_to_string_latex(const GinacPrintable & This)
+/*std::string
+print_to_string_latex(const GiNaC::basic& This)
+{
+ std::ostringstream output;
+ output << GiNaC::latex;
+ output << This;
+ return output.str();
+}*/
+template< typename GinacPrintable>
+std::string
+print_to_string_latex( GinacPrintable* object)
+{
+ std::ostringstream output;
+ GiNaC::print_latex context( output);
+ object->print( context);
+ return output.str();
+}
+
+
} // !namespace anonymous
void
@@ -524,6 +545,7 @@
// Overrides for special Python object behavior
.def( "__str__", &print_to_string<basic>)
+ .def( "print_latex", &print_to_string_latex<basic>)
.def( "__hash__", wrap_hash, "Compute a hash of an expression.")
;
|
|
From: Ondrej C. <ond...@gm...> - 2005-04-26 10:28:43
|
Hi,
I am sending a few patches to implement latex output and a class indexed
in order to create indexed objects.
Ondrej Certik
--- pyginac-orig/src/basic.cpp 2005-03-30 22:55:17.000000000 +0200
+++ pyginac/src/basic.cpp 2005-04-26 10:38:57.978028296 +0200
@@ -397,6 +397,17 @@
return converter.returned_hash;
}
+//template< typename GinacPrintable>
+//print_to_string_latex(const GinacPrintable & This)
+std::string
+print_to_string_latex(const GiNaC::basic& This)
+{
+ std::ostringstream output;
+ output << GiNaC::latex;
+ output << This;
+ return output.str();
+}
+
} // !namespace anonymous
void
@@ -524,6 +535,7 @@
// Overrides for special Python object behavior
.def( "__str__", &print_to_string<basic>)
+ .def( "print_latex", print_to_string_latex)
.def( "__hash__", wrap_hash, "Compute a hash of an expression.")
;
--- pyginac-orig/src/idx.cpp 2004-11-13 14:58:38.000000000 +0100
+++ pyginac/src/idx.cpp 2005-04-26 11:48:45.977355624 +0200
@@ -17,7 +17,9 @@
#include <boost/python/class.hpp>
#include <boost/python/implicit.hpp>
+#include <boost/python.hpp>
#include <ginac/idx.h>
+#include <ginac/indexed.h>
namespace pyginac {
@@ -30,6 +32,17 @@
using GiNaC::varidx;
using GiNaC::spinidx;
using GiNaC::ex;
+ using GiNaC::indexed;
+
+ class_<indexed, bases<basic> >("indexed",
+ "This class holds an indexed expression.\n"
+ "It consists of a 'base' expression (the expression
being indexed) "
+ "which can be accessed as op(0), and n (n >=3D 0)"
+ "indices (all of class idx), accessible as op(1)..op(n).",
+ init<const ex&>())
+ .def( init<const ex&, const ex&>())
+ .def( init<const ex&, const ex&, const ex&>())
+ ;
class_<idx, bases<basic> >("idx",
"This class holds one index of an indexed object.\n"
@@ -82,6 +95,7 @@
implicitly_convertible<idx, ex>();
implicitly_convertible<varidx, ex>();
implicitly_convertible<spinidx, ex>();
+ implicitly_convertible<indexed, ex>();
}
} // !namespace pyginac
--- pyginac-orig/src/symbol.cpp 2004-11-14 04:03:14.000000000 +0100
+++ pyginac/src/symbol.cpp 2005-04-26 10:43:29.009825200 +0200
@@ -52,6 +52,7 @@
class_<symbol, bases<basic> >("symbol", "An algebraic
symbol.", init<std::string>())
.def( init<std::string, domain>())
+ .def( init<std::string, std::string>())
.def( init<const symbol&>())
.def( "assign", &symbol::assign,
"Temporarily assign an expression to this symbol.")
|
|
From: Jonathan B. <jbr...@ea...> - 2005-03-28 16:07:31
|
As a heads-up, I have corrected the ASCII/binary property of the ChangeLog file to ASCII in CVS. This change is not versioned. -Jonathan |
|
From: <pp...@fy...> - 2005-03-08 23:22:00
|
Hi, I would like to suggest the attached patch, which exports the wildcard utility functions wild() and haswild() and moves the wrapping of the wildcard class to a new location (a new file called wildcard.cpp). The latter choice is based on the TODO-note in ncmul.cpp Best regards, Matti -- Matti Peltomaki, M.Sc. (Tech.) Laboratory of Physics Helsinki University of Technology 040 7576977, room Y308B |
|
From: Jonathan B. <jbr...@ea...> - 2005-03-07 16:41:05
|
On Sat, 2005-02-26 at 23:59 +0200, Matti Peltom=E4ki wrote: > Hi,=20 >=20 > I would like to suggest the attached patch (matrixutils.patch) which=20 > exports the matrix utility functions unit_matrix and symbolic_matrix. I made a small change to use lst_from_py_list for more robust conversion from a Python list to a GiNaC::lst. Otherwise, it looks good. > The=20 > exporting is made by using the GiNaC equivalents, although at least the=20 > former one could also be readily implemented in Python.=20 >=20 > I also pythonized some new GiNaC regression tests, which are attached. Committed to CVS. Thanks! -Jonathan Brandmeyer |
