Boost logo

Boost :

From: Peter.Bienstman_at_[hidden]
Date: 2001-07-13 10:04:12


Right, I got rid of the casts (bad remnants from copy and paste) and
replaced PyLong_asLong() to PyLong_asDouble(), for increased safety.

However, I fail to see how we could now lose the *most* significant
digits in this implementation. I agree that this could happen in your
example of long->int. However, for converting to complex numbers,
can't we only lose the *least* significant digits (e.g. when going to
complex<float>), which is something that wasn't even checked for in
your original implementation?

Peter

*** boost_orig/boost_1_22_0/boost/python/conversions.hpp Mon
May 28 17:11:56
 2001
--- boost_1_22_0/boost/python/conversions.hpp Fri Jul 13 15:42:37
2001
***************
*** 93,98 ****
--- 93,105 ----
    template <class T>
    std::complex<T> complex_from_python(PyObject* p,
boost::python::type<T>)
    {
+ if (PyInt_Check(p))
+ return std::complex<T>(PyInt_AS_LONG(p));
+ if (PyLong_Check(p))
+ return std::complex<T>(PyLong_AsDouble(p));
+ if (PyFloat_Check(p))
+ return std::complex<T>(PyFloat_AS_DOUBLE(p));
+
        expect_complex(p);

        return std::complex<T>(

--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> I approve of the functionality, but am a little worried about the
casts in
> the implementation. Wouldn't it be better and simpler to write
something
> like:
>
> if (PyInt_Check(p))
> return std::complex<T>(PyInt_AS_LONG(p));
> if (PyLong_Check(p))
> return static_cast<T>(PyLong_AsLong(p));
> ...
>
> And furthermore, is there not a python routine for converting a
Python Long
> (infinite precision) to a double? That would be less likely to snip
off the
> most significant digits. Hmm, I'm also concerned about the lack of
error
> checks for loss of information. The other numeric conversions try
to make
> sure that the most significant digits aren't lost (e.g. when
converting from
> a Python Long to an integer) IIRC.
>
> -Dave


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk