From: <bc...@wo...> - 2001-01-25 20:07:08
|
Hi, I have been working on a change to the coercion model that matches the change that CPython 2.1 have introduced. The change only affect the implementation of PyObject and its subclasses. It have no effect on python objects that define __coerce__ or any of the other __XXX__ number methods. The effect of the change is that the __XXX__ number methods can receive argument(s) that aren't of the same type as itself. It is then the (new) responsibility of each __XXX__ method to check its argument and return Py.NotImplemented if the operation cannot be done with such an argument. As a result the __coerce_ex__ is no longer called. The patch, as I have it now, does not supply a backward compatiblity mode and that is subject on which I'm seeking feedback: I would like to hear from you if you have coded your own PyObject subclass which override any of the number methods. Take a look at the "new" way that this can be coded (example below is taken from PyFloat) and send me your feedback and comments. Adding backward compatibility is ofcourse possible, but it would mean we have to carry around some kind of flag around (NEW_STYLE_NUMBER) and I would rather avoid that if possible. I would also like to get rid of the currect coercion code because it complicated and there are bugs in it. The benefit of the new coercion model is improved speed when mixing object types in operations because it isn't necessary to create a temporary object and improved control from an extension type because it now gets the unmodified arguments pass to it. The full patch can be found here: http://sourceforge.net/patch/index.php?func=detailpatch&patch_id=103419&group_id=12867 A few example methods taken from PyFloat. It showns how the numeric methods can be implemented under the new coercion mode: public PyObject __add__(PyObject right) { if (!canCoerce(right)) return Py.NotImplemented; double rightv = coerce(right); return new PyFloat(value + rightv); } public PyObject __radd__(PyObject left) { return __add__(left); } public PyObject __sub__(PyObject right) { if (!canCoerce(right)) return Py.NotImplemented; double rightv = coerce(right); return new PyFloat(value - rightv); } public PyObject __rsub__(PyObject left) { if (!canCoerce(left)) return Py.NotImplemented; double leftv = coerce(left); return new PyFloat(leftv - value); } private static final boolean canCoerce(PyObject other) { return other instanceof PyFloat || other instanceof PyInteger || other instanceof PyLong; } private static final double coerce(PyObject other) { if (other instanceof PyFloat) return ((PyFloat) other).value; else if (other instanceof PyInteger) return ((PyInteger) other).getValue(); else if (other instanceof PyLong) return ((PyLong) other).doubleValue(); else throw Py.TypeError("xxx"); } regards, finn |
From: Brad B. <bbu...@uc...> - 2001-01-26 03:57:47
|
Hi, On the topic of coercion, currently (correct me if I'm wrong) when a java numeric primitive (it, double, etc.) is accessed from jython code a conversion takes place from the native java type to a PyNumber object. Now, since Python offers many features (slicing, operator overloading, function pointers, etc.) that are extremely useful from a numerical computing standpoint (hence the success of NumPy) and Java offers excellent and robust Matrix libraries, 2D & 3D graphics, excellent gui, an advanced imaging package -- and so on -- Jython holds a lot of potential in the numerical computing arena (see ViSad, a scientific visualization package which has incorporated JPython as a scripting feature). That said, the current treatment of java primitives as PyObjects is a barrier to jython emerging as a (fast) platform for numerical computing. Is there any way that java primitives could be accessed "as-is" from within Jython? Note that Numerical Python suffers from requiring a rag-bag of supplementary tools for graphing, imaging, etc. -- which are not generally cross-platform -- while Java offers all these things in existing libraries either put out by Sun or downloadable off the web and, of course, fully cross-platform. So, to me, Jython has vastly more potential as a numerical computing language than Python proper. Moreover, proprietary computing environments like Matlab, Mathematica, and S-Plus are all scrambling to provide "java links" into their own languages. None of these links will ever be as good as the Jython-Java connection, nor will those scripting languages ever be as good as Python for general computing. (See www.omegahat.org for a project that is trying to integrate the S language and java at the cost of considerable complexity). Brad Buchsbaum ----- Original Message ----- From: "Finn Bock" <bc...@wo...> To: <jyt...@li...> Cc: <jyt...@li...>; <jpy...@py...> Sent: Thursday, January 25, 2001 12:06 PM Subject: [JPython] New Coercion Model > Hi, > > I have been working on a change to the coercion model that matches the > change that CPython 2.1 have introduced. The change only affect the > implementation of PyObject and its subclasses. It have no effect on > python objects that define __coerce__ or any of the other __XXX__ number > methods. > > The effect of the change is that the __XXX__ number methods can receive > argument(s) that aren't of the same type as itself. It is then the (new) > responsibility of each __XXX__ method to check its argument and return > Py.NotImplemented if the operation cannot be done with such an argument. > As a result the __coerce_ex__ is no longer called. > > The patch, as I have it now, does not supply a backward compatiblity > mode and that is subject on which I'm seeking feedback: > > I would like to hear from you if you have coded your own PyObject > subclass which override any of the number methods. Take a look at the > "new" way that this can be coded (example below is taken from PyFloat) > and send me your feedback and comments. > > Adding backward compatibility is ofcourse possible, but it would mean we > have to carry around some kind of flag around (NEW_STYLE_NUMBER) and I > would rather avoid that if possible. I would also like to get rid of the > currect coercion code because it complicated and there are bugs in it. > > The benefit of the new coercion model is improved speed when mixing > object types in operations because it isn't necessary to create a > temporary object and improved control from an extension type because it > now gets the unmodified arguments pass to it. > > The full patch can be found here: > > http://sourceforge.net/patch/index.php?func=detailpatch&patch_id=103419&grou p_id=12867 > > A few example methods taken from PyFloat. It showns how the numeric > methods can be implemented under the new coercion mode: > > > public PyObject __add__(PyObject right) { > if (!canCoerce(right)) > return Py.NotImplemented; > double rightv = coerce(right); > return new PyFloat(value + rightv); > } > > public PyObject __radd__(PyObject left) { > return __add__(left); > } > > public PyObject __sub__(PyObject right) { > if (!canCoerce(right)) > return Py.NotImplemented; > double rightv = coerce(right); > return new PyFloat(value - rightv); > } > > public PyObject __rsub__(PyObject left) { > if (!canCoerce(left)) > return Py.NotImplemented; > double leftv = coerce(left); > return new PyFloat(leftv - value); > } > > private static final boolean canCoerce(PyObject other) { > return other instanceof PyFloat || other instanceof PyInteger || > other instanceof PyLong; > } > > private static final double coerce(PyObject other) { > if (other instanceof PyFloat) > return ((PyFloat) other).value; > else if (other instanceof PyInteger) > return ((PyInteger) other).getValue(); > else if (other instanceof PyLong) > return ((PyLong) other).doubleValue(); > else > throw Py.TypeError("xxx"); > } > > > regards, > finn > > _______________________________________________ > JPython-Interest maillist - JPy...@py... > http://mail.python.org/mailman/listinfo/jpython-interest > |
From: <bc...@wo...> - 2001-01-26 11:52:31
|
[Brad Buchsbaum] >On the topic of coercion, currently (correct me if I'm wrong) when a java >numeric primitive (it, double, etc.) is accessed from jython code a >conversion takes place from the native java type to a PyNumber object. Correct. The concrete classes are PyInteger and PyFloat. [Description of jython's coolness snipped] >Is there any way that java primitives could be accessed "as-is" from within >Jython? I'm no expert on language implementation and I'm sure the types-sig have stronger and more well-founded opinions than I, but I don't think we can do it transparently. The tools I have seen described on c.l.py which performed analysis of the control flow and data types suggested that such analysis are dificult for python code both in theory and in practice. I know JimH felt very strongly about this topic (he was very numerical) and he might have been able to add some improvements. I can't. Doing it through some kind of explicit type syntax that is added to the python code is OTOH possible, but I'm not going to spearhead a syntax change to python. When the types-sig have convinced Guido of a design for explicit types, we will ofcourse add it to jython in a way that takes advantage of the possible speed improvements. regards, finn |