Matt Clinton wrote: > > NumPy is largely about speed, and going through extra interop layers > can really bite into that (my $0.02). >
The reason that Numpy is much faster is because most of the work happens inside the C code, so a minor performance hit on the way in and out isn't necessarily a problem. > I think the suggestion for a smaller module to start with was about > learning about compatibility with a more manageable chunk of code than > the many, many lines of deep number-crunching that NumPy has > accumulated, but maybe a few sections of compatibility there (i.e. > limited part of the API) would be a similarly tractable goal? > Possibly. > > Wrapping the plain-C in COM would be a good way to test implementation > compatibility, > I'm not sure that COM is the way to go (because it does seem to insert an extra layer into the equation) - but it is certainly on the table. > if your plan is to ported raw C to C++, > That wasn't at all the *original* plan. :-) > so that the DLR/CLR can get some hooks in and go-quicka: > > the COM-wrapped CPy extensions may be faster to develop, if not > performing as quickly, > > and if your C++ ports behave the same, you have pretty good confidence. > > Along the way, they’ll help point out what’s the framework and what’s > your code, especially if you can run the same test-cases through > straight CPy. > > Wrapping all the way back through Mono seems an odd goal – isn’t IPy > compatible enough with CPy in source that your business apps would be > light to port back to Cpy-land, if you’re on Posix already anyway? > No - our application is currently a .NET only (not Mono) application, with a heavy dependency on .NET for the user interface layer. So back porting the whole app. to CPython is not on the cards (for business reasons as well - getting the finance sector to install new technology is difficult, so a .NET based application will more easily be accepted by companies than a CPython one). > For some purposes, it really makes sense, but a NumPy implementation > for IPy for Mono? > We are not talking particularly about a new implementation, but finding a way of getting the current implementation to work. > Seem to me that going that deep this soon will make you a valuable > contributor to low-level compatibility testing… but I don’t have the > whole picture of where you’re going. > > If you’re going to alloy FePy, would that make a type of SteelPython? > – a happier compound than Rust! > RustPython is one of the possible names (what happens when you introduce Iron to the Sea... Moray would be another one - a kind of Python that lives in the sea... better names solicited...) :-) Michael http://www.manning.com/foord > Cheers, > > -- Matt > > ------------------------------------------------------------------------ > > *From:* [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] *On Behalf Of *Giles Thomas > *Sent:* Monday, October 15, 2007 9:17 AM > *To:* Discussion of IronPython > *Subject:* Re: [IronPython] Announcement: Project to get some CPython > C extensions running under IronPython > > Davy, > > What would the issues be with NumPy - just the size of the API that > would have to be wrapped? I must admin that my biggest concern with > this would be getting everything running under Mono... > > > Cheers, > > Giles > > > Davy Mitchell wrote: > > On 10/12/07, Giles Thomas <[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED]> > wrote: > >> Python and .NET, but also the existing CPython C extensions. >> > > Hi Giles, > > Sounds like a good idea and the approaches mentioned seemed solid. > > One strategy I was considering for a port of my Mood News site to > Ironpython (but not tried yet!) is wrapping a CPython Lib into a COM > object using the win32 stuff and getting it into .Net via the COM > interop support. > > Maybe not practical for Numpy :-) Does have the advantage of not > having to modify the original lib... > > Cheers, > Davy > > > > > > -- > Giles Thomas > MD & CTO, Resolver Systems Ltd. > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > +44 (0) 20 7253 6372 > > We're hiring! http://www.resolversystems.com/jobs/ > > 17a Clerkenwell Road, London EC1M 5RD, UK > VAT No.: GB 893 5643 79 > Registered in England and Wales as company number 5467329. > Registered address: 843 Finchley Road, London NW11 8NA, UK > ------------------------------------------------------------------------ > > _______________________________________________ > Users mailing list > [email protected] > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ Users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
