Hello,
On Thu, Sep 25, 2008 at 5:38 PM, David Joyner <[EMAIL PROTECTED]> wrote:
>
> Hi:
>
> I am planning on creating an IncidenceStructures class in a
> module incidence_structues.py which will go in a new subdirectory of
> combinat called designs. Functions specific to block designs
> will go
I just noticed that from sage
x=numpy.mgrid[0.:1.:0.1]
coerces the results to integers.
Is there a work-around?
thanks,
-gerhard
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [E
gerhard wrote:
> I just noticed that from sage
> x=numpy.mgrid[0.:1.:0.1]
> coerces the results to integers.
>
> Is there a work-around?
Using the Numpy 1.2 spkg that will probably be in the next version of
Sage, I get:
sage: import numpy
sage: x=numpy.mgrid[0.:1.:0.1]
sage: x
array([0.0
Hi Gerhard,
On Sat, Sep 27, 2008 at 10:04 AM, gerhard <[EMAIL PROTECTED]> wrote:
>
> I just noticed that from sage
> x=numpy.mgrid[0.:1.:0.1]
> coerces the results to integers.
>
> Is there a work-around?
>
This is due to numpy not recognizing Sage's RealNumber class.
sage: x=numpy.mgrid[0.:1.:
On Saturday 27 September 2008, Tim Abbott wrote:
> The patches for adding sonames that Francois and I wrote were indeed
> not designed with Solaris and BSD's non-GNU toolchain in mind. The
> right way to solve this problem is to use libtool, since that the
> standard way to do portable versioning
On Sep 26, 3:39 pm, mabshoff <[EMAIL PROTECTED]> wrote:
> For example: Take the FLINT.spkg - ever since we used the patches Tim
> submitted the spkg was broken twice by either not adjusting the link
> name for libfint.so or after installing an updated version Sage would
I think this is really the
