Ok,
Our messages crossed. I understand now.
Thanks.
Mark
On Jun 11, 2016, at 12:24 PM, josef.p...@gmail.com wrote:
>
>
> On Sat, Jun 11, 2016 at 2:49 PM, Mark Gawron wrote:
> Thanks, Jozef. This is very helpful. And I will direct this
> to one of the other mailing lists,
of the probability axis.
Mark
On Jun 11, 2016, at 10:03 AM, josef.p...@gmail.com wrote:
>
>
> On Sat, Jun 11, 2016 at 8:53 AM, Ralf Gommers wrote:
> Hi Mark,
>
> Note that the scipy-dev or scipy-user mailing list would have been more
> appropriate for this question.
>
gt; vals = dist.ppf(percentiles)
> ax.set_xticks(vals)
> xt = np.array(list(xt)+[3])
> ax.set_xticklabels(xt)
> ax.set_xlabel('Quantile')
> plt.show()
I’ve attached two images to show the difference between the current
visualization and the suggested one.
Mark Gawro
Here's the einsum version:
`es = np.einsum('Na,ab,Nb->N',X,A,X)`
But that's running ~45x slower than your version.
OT: anyone know why einsum is so bad for this one?
Mark Daoust
On Sat, May 28, 2016 at 11:53 PM, Scott Sievert
wrote:
> I recently ran into an
17 AM, Nicolas P. Rougier <
nicolas.roug...@inria.fr> wrote:
>
> Yes, it is the expected result. Thanks.
> Maybe the set(a) & set(b) can be replaced by np.where[np.in1d(a,b)], no ?
>
> > On 30 Dec 2015, at 18:42, Mark Miller wrote:
> >
> > I'm not 1
;>> indices = numpy.where([x in c for x in b])[0]
>>> indices #indices of b where the elements of a in b occur
array([1, 2, 5, 7], dtype=int64)
-Mark
On Wed, Dec 30, 2015 at 6:45 AM, Nicolas P. Rougier <
nicolas.roug...@inria.fr> wrote:
>
> I’m scratching my head around a
tion order is chosen according to
the 'K' rule. The array a suggests to go in 'C' order, while the array b
suggests to go in 'F' order. When there's a conflict/ambiguity such as
this, it's resolved in the directio
alent to
> load external C routines at runtime)
>
I kind of like the path LLVM has chosen here, of a stable C API and an
unstable C++ API. This has both pros and cons though, so I'm not sure what
will be right for DyND in the long term.
-Mark
> Regards
>
> Antoine.
>
ND continues maturing, it can make inroads into places NumPy hasn't been
able to.
Thanks,
Mark
On Wed, Aug 26, 2015 at 9:45 AM, Irwin Zaid wrote:
> Hello everyone,
>
> Mark and I thought it would be good to weigh in here and also be explicitly
> around to discuss DyND. To be c
d the compiled extension.
Does anybody know what other files to include or (better) how to compile a
fortran extension without needing to send any additional files?
Thanks,
Mark
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scip
AMD acml libraries do not include the CBLAS implementation. To build CBLAS
against the libacml.lib requires the Intel Fortran compiler. There is a note in
the mailing list here
http://mail.scipy.org/pipermail/numpy-discussion/2006-February/018379.html
This detail should probably be added to
I am so dumb. It is not using the static libs at all. It is building numpy with
lapack_lite and blas_lite.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Both the /MT and /MD versions of the acml static libraries build, and pass all
tests, except that for me at least there's a weird glitch in the build process.
I have to purposefully add something so that config fails.
EG: In the previous site.cfg, I did not realize that I had mistyped the vector
d the MKL files.
Thanks for your help!
--Mark
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
* Either windows sdk 7 or ms visual studio 2008 is required, however Fortran
compilers are not.* Download acml5.3.1-ifort64.exe from
http://developer.amd.com/tools-and-sdks/cpu-development/amd-core-math-library-acml/acml-downloads-resources/
and it extracts to c:\AMD\acml5.3.1
* NOTE: There is a
the old MKL links point to 404.html
the new MKL link has this link in the right sidebar:
Changes to Intel® Software Development Products | Intel® Developer Zone
Changes to Intel® Software Development Products | Intel® Developer Zone
Intel® Parallel Studio XE simplification Intel® Pa
Note that I would personally not use this type of shorthand syntax for
teaching or presentations. I'd prefer to use proper python syntax myself
from the get go rather than having to start over from square one and teach
a completely different syntax for constructing >2d arrays.
"T
always be very careful when mixing floating point types, but
should numpy prevent (or warn) the user from doing so in this case?
On Wed, Jul 2, 2014 at 10:07 AM, Mark Szepieniec wrote:
> Hi Catherine,
>
> I can't reproduce your issue with bins_list vs. bins_arange, but passing
&g
is being binned differently in the last
case, but I'm not sure why either...
Mark
On Wed, Jul 2, 2014 at 2:05 AM, Chris Barker wrote:
> A few thoughts:
>
> 1) don't use arange() for flaoting point numbers, use linspace().
>
> 2) histogram1d is a floating point function, and
Shawn (Yuxiang) -
The right way to compute this is using Runga-Kutta approximations. I'm not
aware if numpy supports these. -jm
__
John Mark Agosta
650 465-4707
johnmark.ago...@gmail.com *"Unpredictable consequences are the most
expected thin
stands the difference
between a 4D array of scalars, a 3D array of vectors, and a 2D array of
matrices... The difference between the axes that broad-cast and the axes
that can sum when you hit them with an @ ... or something like that.
Just a thought.
Einsum is fantastic by the way, totally wort
On Sun, Sep 22, 2013 at 1:24 PM, wrote:
> On Sat, Sep 21, 2013 at 1:55 PM, Jeremy Hetzel wrote:
> > I've added a trapezoidal distribution to numpy.random for consideration,
> > pull request 3770:
> > https://github.com/numpy/numpy/pull/3770
> >
> > Similar to the triangular distribution, the tra
Now that you mention it, (3L,4L) probably indeed occurs on Windows 64 bit
installations.
Not sure about Mac 64 bit. I haven't tried that.
So, is it desirable that the 32bit returns different integers than the
64bit? I would guess not.
Thanks,
Mark
Are they all using the same platfor
though!
I am not sure that such a PR would get much support
Thanks again,
Mark
Hi Mark,
>
> You're looking for "np.unravel_index" function.
>
> Cheers,
> Gregorio
>
Hello list,
>
> I am trying to find the indices of the maximum value in a 2D array.
>
converted to the row can
column indices (I know, I can write a function for that, but I figure numpy
already has one).
Thanks,
Mark
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
wonder why they don't all get
the same thing. They all installed numpy through Canopy Express. Any
thoughts? Is this a setting in printoptions maybe?
Thanks,
Mark
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/ma
e making the attempt and that
> > discussion petered out.
>
> well, Nathaniel Smith chimed in, and Mark Weibe commented a bit (as he
> wrote the code in the first place). Wes McKinney also chimed in,
> essentially saying that Pandas mostly has to do its own thing, and I'm
Hi All,
I am a bit new to the NumPy C-API and I am having a hard time with placing
results into output arrays... I am using PyArray_TakeFrom to grab an input
dimension of data, then do a calculation, then I want to pack it back to the
output... yet the PutTo function does not have an axis argum
On 27 June 2013 01:48, Frédéric Bastien wrote:
>
>
>
> On Wed, Jun 26, 2013 at 7:30 AM, mark florisson
> wrote:
>>
>> On 26 June 2013 09:05, Dag Sverre Seljebotn
>> wrote:
>> > On 06/25/2013 04:21 PM, Frédéric Bastien wrote:
>> >>
>>
optimization
>> > like using SSE instruction. I think it is great.
>> >
>> > Last year, Mark Florisson released the minivect[1] project that he
>> > worked on during is master thesis. minivect is a compiler for
>> > element-wise expression that do some
est/manpower to maintain support for
> vectorization in the long term (so it was better to not add the feature than
> have a badly supported feature).
>
> My understanding is that Numba is based on minivect and not on dynd, so it's
> more of a competitor.
>
> Perhaps Mark Flori
Mon, Jun 17, 2013 at 5:03 PM, Julian Taylor
>> > wrote:
>> >>
>> >> On 17.06.2013 17:11, Frédéric Bastien wrote:
>> >> > Hi,
>> >> >
>> >> > I saw that recently Julian Taylor is doing many low level
>> optimization
&
the quick reply.
Mark
On Wed, May 1, 2013 at 6:47 PM, Christopher Hanley wrote:
> Mark,
>
> Numpy is not numarray. Numarray is an older package that has long since
> been replaced by numpy. You should only use numpy in any development from
> now on.
>
> Chris
>
>
> O
on on Linux. I assume there
is some path issue, but I'm not clear where to start. If numPy is
installed, how to I point Spyder to the numPy modules so I can get numarray
to work?
Thanks,
Mark
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
h
ould be worth it for those that need it, and
> folks that need performance could use naive datetime64s.
>
> There apparently is also a datetime library in boost that has a nice
> timezone object which could be used as inspiration for an equivalent
> in NumPy. That could be a l
On Wed, Apr 3, 2013 at 4:27 PM, Pauli Virtanen wrote:
> Mark Wiebe gmail.com> writes:
> > It seems to me that adding a time zone to the datetime64
> > metadata might be a good idea, and then allowing it to be
> > None to behave like the Python naive datetimes.
>
spect adding a timezone to the datetime64 metadata is the way to
proceed. We probably need to start up a new NEP about amending datetime64.
The previous one is here:
https://github.com/numpy/numpy/blob/master/doc/neps/datetime-proposal.rst
> That's it for now -- thanks for engaging!
>
cause np.empty and np.zeros covers 95
>> > % usecases !
>>
>> I agree with your summary and conclusion.
>>
>> Eric
>>
>>
> Can we at least have a np.nans() and np.infs() functions? This should
> cover an additional 4% of use-cases.
>
> Ben R
I've tracked down and fixed a memory leak in 1.7 and master. The pull
request to check and backport is here:
https://github.com/numpy/numpy/pull/2928
Thanks,
Mark
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scip
I guess I wasn't explicit enough.
Say I have an array with 100 numbers and I want to write it to a file
with 6 numbers on each line (and hence, only 4 on the last line).
Can I use savetxt to do that?
What other easy tool does numpy have to do that?
Thanks,
Mark
On 5. des. 2012, at 22:35,
Hello List,
Is it possible to turn off printing the square brackets in set_print_options?
Am I overlooking something?
Thanks,
Mark
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Hello List,
I want to write a large array to file, and each line can only be 80
characters long.
Can I use savetxt to do that? Where would I specify the maximum line length?
Or is there a better way to do this?
Thanks,
Mark
___
NumPy-Discussion
Hello List,
I searched the list whether it is possible to use optional arguments in
fortran functions that are compiled with f2py.
In 2008, this feature was not yet included and appeared to be non-trivial.
Does anybody know the status of putting that feature in f2py?
Thanks,
Mark
ver the patch simply doesn't decrease the proper reference, so it
> >> might leak. I've used
> >> bisection (took the whole evening unfortunately...) but the good news
> >> is that I've isolated commits
> >> that actually broke it. See the github issue #3
Shall I file a bug report? Or is this fairly easy to fix?
Mark
>
> On Fri, Aug 10, 2012 at 11:41 AM, wrote:
>
> >
> >
> > On Fri, Aug 10, 2012 at 10:00 AM, Travis Oliphant >wrote:
> >
> >>
> >> On Aug 10, 2012, at 5:37 AM, Paul Anton Letnes
arrays:
>
> a = ones(1)
> b = ones(1)
> a[0] = b
>
> Bug or feature?
>
> Thanks,
>
> Mark
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
--
TypeError Traceback (most recent call last)
in ()
> 1 a[0] = b
TypeError: can't convert complex to float
This works correctly when a and b are real arrays:
a = ones(1)
b = ones(1)
a[0] = b
Bug or feature?
Thanks,
Mark
___
N
Here's a good article on the vagaries of python paths when installing a new
python. Thus you can check exactly how python finds its modules, to assure the
new install is working properly:
https://www.usenix.org/publications/login/august-2012-volume-37-number-4/import
John Mark Agosta
On 5 June 2012 22:36, Dag Sverre Seljebotn wrote:
> On 06/05/2012 10:47 PM, mark florisson wrote:
>> On 5 June 2012 20:17, Nathaniel Smith wrote:
>>> On Tue, Jun 5, 2012 at 7:08 PM, mark florisson
>>> wrote:
>>>> On 5 June 2012 17:38, Nathaniel Smith w
On 5 June 2012 22:29, Nathaniel Smith wrote:
> On Tue, Jun 5, 2012 at 9:47 PM, mark florisson
> wrote:
>> On 5 June 2012 20:17, Nathaniel Smith wrote:
>>> On Tue, Jun 5, 2012 at 7:08 PM, mark florisson
>>> wrote:
>>>> On 5 June 2012 17:38, Nathaniel Sm
On 5 June 2012 20:17, Nathaniel Smith wrote:
> On Tue, Jun 5, 2012 at 7:08 PM, mark florisson
> wrote:
>> On 5 June 2012 17:38, Nathaniel Smith wrote:
>>> On Tue, Jun 5, 2012 at 4:12 PM, mark florisson
>>> wrote:
>>>> On 5 June 2012 14:58, Nathaniel
On 5 June 2012 17:38, Nathaniel Smith wrote:
> On Tue, Jun 5, 2012 at 4:12 PM, mark florisson
> wrote:
>> On 5 June 2012 14:58, Nathaniel Smith wrote:
>>> On Tue, Jun 5, 2012 at 12:55 PM, mark florisson
>>> wrote:
>>>> It would be great if we impl
On 5 June 2012 18:21, Neal Becker wrote:
> Would lazy eval be able to eliminate temps in doing operations such as:
>
> np.sum (u != 23)?
>
> That is, now ops involving selecting elements of matrixes are often performed
> by
> first constructing temp matrixes, and the operating on them.
>
> __
On 5 June 2012 14:58, Nathaniel Smith wrote:
> On Tue, Jun 5, 2012 at 12:55 PM, mark florisson
> wrote:
>> It would be great if we implement the NEP listed above, but with a few
>> extensions. I think Numpy should handle the lazy evaluation part, and
>> determine wh
r to use from the Python perspective.
> >
> > ---
> > Reply to this email directly or view it on GitHub:
> > https://github.com/numpy/numpy/pull/284#issuecomment-6121817
>
> Speaking of which, Mark - what's the status of that nditer_buffer_flag
> branch? Should there
f the
specified size and dtype, and will keep using that hook to build the
expression until evaluated.
Anyway, this is somewhat of a high-level overview. If there is any
interest, we can flesh out the details and extend the NEP.
Mark
___
NumPy-Discu
Why does isscalar('hello') return True?
I thought it would check for a number?
Numpy 1.6.1
Silly question?
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
7;t really new as there was significant disagreement about what
>>> to do when the masked array code was initially checked in to master. So,
>>> in order to move forward, Mark and I are going to work together with
>>> whomever else is willing to help with an effort that is in
On 17 May 2012 23:53, Dag Sverre Seljebotn wrote:
> I'm repeating myself a bit, but my previous thread of this ended up
> being about something else, and also since then I've been on an
> expedition to the hostile waters of python-dev.
>
> I'm crazy enough to believe that I'm proposing a technical
On 14 May 2012 21:54, David Cournapeau wrote:
>
>
> On Mon, May 14, 2012 at 5:31 PM, mark florisson
> wrote:
>>
>> On 12 May 2012 22:55, Dag Sverre Seljebotn
>> wrote:
>> > On 05/11/2012 03:37 PM, mark florisson wrote:
>> >>
>> &
On 14 May 2012 21:36, Dag Sverre Seljebotn wrote:
> On 05/14/2012 06:31 PM, mark florisson wrote:
>>
>> On 12 May 2012 22:55, Dag Sverre Seljebotn
>> wrote:
>>>
>>> On 05/11/2012 03:37 PM, mark florisson wrote:
>>>>
>>>&
On 12 May 2012 22:55, Dag Sverre Seljebotn wrote:
> On 05/11/2012 03:37 PM, mark florisson wrote:
>>
>> On 11 May 2012 12:13, Dag Sverre Seljebotn
>> wrote:
>>>
>>> (NumPy devs: I know, I get too many ideas. But this time I *really*
>>> believe
&g
one from Cython's perspective;
> >>> and I imagine for those writing C extensions against the C API too.
> >>> Having PyType_Check fail for ndmasked is a very good way of having code
> >>> fail that is not written to take masks into account.
> >>
On Fri, May 11, 2012 at 8:37 AM, mark florisson
wrote:
> On 11 May 2012 12:13, Dag Sverre Seljebotn
> wrote:
> > (NumPy devs: I know, I get too many ideas. But this time I *really*
> believe
> > in it, I think this is going to be *huge*. And if Mark F. likes it it's
>
ure alternative would be to add a
> separate method that returns a view.
>
This looks like the best way to deal with it, yes.
Cheers,
Mark
>
> I don't think changing the default behavior in a later release is a good
> idea. It's a sort o
On Fri, May 11, 2012 at 6:13 AM, Dag Sverre Seljebotn <
d.s.seljeb...@astro.uio.no> wrote:
> (NumPy devs: I know, I get too many ideas. But this time I *really*
> believe in it, I think this is going to be *huge*. And if Mark F. likes
> it it's not going to be without manpowe
On 11 May 2012 12:13, Dag Sverre Seljebotn wrote:
> (NumPy devs: I know, I get too many ideas. But this time I *really* believe
> in it, I think this is going to be *huge*. And if Mark F. likes it it's not
> going to be without manpower; and as his mentor I'd pitch in t
On 11 May 2012 12:13, Dag Sverre Seljebotn wrote:
> (NumPy devs: I know, I get too many ideas. But this time I *really* believe
> in it, I think this is going to be *huge*. And if Mark F. likes it it's not
> going to be without manpower; and as his mentor I'd pitch in t
On Thu, May 10, 2012 at 5:47 PM, Dag Sverre Seljebotn <
d.s.seljeb...@astro.uio.no> wrote:
> On 05/11/2012 12:28 AM, Mark Wiebe wrote:
> > I did some searching for typical Cython and C code which accesses numpy
> > arrays, and added a section to the NEP describing h
_DATA will continue to transparently unmask data. However, with
> Travis' proposal of making a new 'ndmasked' type, old code will be
> protected; it will raise an exception for masked arrays instead of
> transparently unmasking, giving the user a chance to work around it (or
> upda
I did some searching for typical Cython and C code which accesses numpy
arrays, and added a section to the NEP describing how they behave in the
current implementation. Cython code which uses either straight Python
access or the buffer protocol is fine (after a bugfix in numpy, it wasn't
failing cu
On Wed, May 9, 2012 at 2:15 PM, Travis Oliphant wrote:
>
> On May 9, 2012, at 2:07 PM, Mark Wiebe wrote:
>
> On Wed, May 9, 2012 at 11:46 AM, Travis Oliphant wrote:
>
>> Hey all,
>>
>> Nathaniel and Mark have worked very hard on a joint document to try and
>
On Wed, May 9, 2012 at 11:46 AM, Travis Oliphant wrote:
> Hey all,
>
> Nathaniel and Mark have worked very hard on a joint document to try and
> explain the current status of the missing-data debate. I think they've
> done an amazing job at providing some context, articula
On Sat, May 5, 2012 at 1:06 PM, Charles R Harris
wrote:
>
> On Sat, May 5, 2012 at 11:19 AM, Mark Wiebe wrote:
>
>> On Sat, May 5, 2012 at 11:55 AM, Charles R Harris <
>> charlesr.har...@gmail.com> wrote:
>>>
>>> On Sat, May 5, 2012 at 5:27 AM, Tom
> Would you be interested in carrying Martin's package forward? I'm not
> opposed to having quaternions in numpy/scipy but there needs to be someone
> to push it and deal with problems if they come up. Martin's package
> disappeared in large part because Martin disapp
On Mon, Apr 30, 2012 at 4:11 PM, Charles R Harris wrote:
>
>
> On Mon, Apr 30, 2012 at 1:19 PM, Mark Wiebe wrote:
>
>> I've done some comparisons of 1.6.1 and 1.7 (master), and written up some
>> key differences in a pull request here:
>>
>> https://git
7;s a bug to do with how flexible types
work. To match how the struct dtypes work with flexible string dtypes, it
should raise an error when trying to create a dtype with just 'M8' and no
unit specified, at In [4].
-Mark
On Fri, Apr 27, 2012 at 3:52 PM, Travis Vaught wrote:
> With Nu
Could someone please ban this person from the mailing list, he keeps
sending spam.
On 6 April 2012 12:41, Jean-Baptiste Rudant wrote:
> http://alumnos.digicap.cl/images/rmngl.html
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> h
On 30 March 2012 21:40, mark florisson wrote:
> On 30 March 2012 21:38, mark florisson wrote:
>> On 30 March 2012 19:53, Chris Barker wrote:
>>> On Fri, Mar 30, 2012 at 10:57 AM, mark florisson
>>> wrote:
>>>> Although the segfault was caused by a bug
On 30 March 2012 21:38, mark florisson wrote:
> On 30 March 2012 19:53, Chris Barker wrote:
>> On Fri, Mar 30, 2012 at 10:57 AM, mark florisson
>> wrote:
>>> Although the segfault was caused by a bug in NumPy, you should
>>> probably also consider using Cython,
On 30 March 2012 19:53, Chris Barker wrote:
> On Fri, Mar 30, 2012 at 10:57 AM, mark florisson
> wrote:
>> Although the segfault was caused by a bug in NumPy, you should
>> probably also consider using Cython, which can make a lot of this pain
>> and boring stuff go a
On 29 March 2012 09:07, Christoph Gohle wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
> Am 08.03.2012 um 20:39 schrieb Pauli Virtanen:
>
>> 08.03.2012 17:37, Christoph Gohle kirjoitti:
>>> thanks for testing. I have now tried on different platforms. I get
>>> all kinds of crashes on
Have you tried to create your arrays with the numpy.zeros functions rather
than the scipy.zeros functions?
I can imagine that something may get confused here. Maybe some version
mismatch or what not.
Mark
From: Ryan Krauss gmail.com>
Subject: Re: problem with dot for complex
matrices&l
tored so
>> that the more essential algorithms working on the syntax tree could be
>> pulled out and shared with cython and numba. Then the question is whether
>> the core of Theano is smart enough to compete with Fortran compilers and
>> support arbitraily strided i
On 21 March 2012 05:20, Dag Sverre Seljebotn wrote:
> On 03/20/2012 12:56 PM, Francesc Alted wrote:
>> On Mar 20, 2012, at 2:29 PM, Dag Sverre Seljebotn wrote:
>>> Francesc Alted wrote:
>>>
>>>> On Mar 20, 2012, at 12:49 PM, mark florisson wrote:
&g
On 13 March 2012 18:18, Travis Oliphant wrote:
>>>
>>> (Mark F., how does the above match how you feel about this?)
>>
>> I would like collaboration, but from a technical perspective I think
>> this would be much more involved than just dumping the AST to an
t useful in C#, maybe it would be useful here too.
Cheers,
Mark
>
> Thanks,
>
> Bryan
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
e-code and does
>
> translation to their intermediate representation for inspiration.
>
>
> Again, the code is not ready for use, it is only proof of concept, but I
>
> would like to get feedback and help especially from people who might
>
> have written compilers before. The
Hi Pierre,
On Tue, Mar 6, 2012 at 5:48 AM, Pierre Haessig wrote:
> Hi Mark,
>
> I went through the NA NEP a few days ago, but only too quickly so that
> my question is probably a rather dumb one. It's about the usability of
> bitpatter-based NAs, based on your recent post :
ests on
an architecture like sparc.
Cheers,
Mark
On Mon, Mar 5, 2012 at 6:39 PM, Matthew Brett wrote:
> And simplifying:
>
> In [1]: import numpy as np
>
> In [2]: control = np.array([(1, 2, 3), (0, 5, 6)], dtype=[('f0',
> bool), ('f1', bool), ('f2&#x
On Sun, Mar 4, 2012 at 10:34 PM, Matthew Brett wrote:
>
> > $ export NPY_SEPARATE_COMPILATION=1
>
> Thanks, that did it:
>
> 9194b3af704df71aa9b1ff2f53f169848d0f9dc7 is the first bad commit
>
> Let me know if I can debug further,
>
That commit was a rewrite of np.concatenate, and I've traced the
On Sun, Mar 4, 2012 at 10:08 PM, Matthew Brett wrote:
> Hi,
>
> On Sun, Mar 4, 2012 at 11:41 AM, Mark Wiebe wrote:
> > On Sun, Mar 4, 2012 at 11:27 AM, Matthew Brett
> > wrote:
> >>
> >> Hi,
> >>
> >> On Sat, Mar 3, 2012 at 12:07 AM, Mat
;
> >>> This on current master : 1.7.0.dev-b9872b4
> >>>
> >>
> >> Hmm, some tests might have been recently enabled. Any chance of doing a
> >> bisection?
>
> Struggling because compilation is very slow and there are lots of
)
>>> np.array([1.0, 2.0, 3.0])
array([ 1., 2., 3.], dtype=float64)
>* there should be some way when using "masks" (even if it's hidden
> from most users) for missing data to separate the low-level ufunc operation
> from the operation
> on th
in the repository uncomfortable. Maybe
alternatives to a git repository for NEPs should be considered. I reported
the bug to github, but they told me that was just how they did things.
Cheers,
Mark
>
> Cheers,
>
> f
> ___
> NumPy-Discuss
Thanks for the reply, Ralf.
Can you point me a bit in the right direction.
Scipy is pretty big.
Thanks,
Mark
--
>
> Message: 2
> Date: Sat, 25 Feb 2012 11:16:50 +0100
> From: Ralf Gommers
> Subject: Re: [Numpy-discussion] distributing pr
Two short questions:
1. When I distribute pre-compiled f2py extensions for OSX, it seems that
the users need gfortran installed, else it cannot find libgfortran.3.dylib.
Is there a way to link that file with the extension?
2. Should extensions compiled on Snowleopard work on Lion?
Thanks,
Mark
On Thu, Feb 23, 2012 at 10:55 AM, Matthew Brett wrote:
> Hi,
>
> On Thu, Feb 23, 2012 at 10:45 AM, Mark Wiebe wrote:
> > On Thu, Feb 23, 2012 at 10:42 AM, Matthew Brett >
> > wrote:
> >>
> >> Hi,
> >>
> >> On Thu, Feb 23, 2012 at 10:1
using, as
> this thread the previous one show.
>
> The question is, what would be less confusing?
>
One approach would be to never alias longdouble as float###. Especially
float128 seems to imply that it's the IEEE standard bina
G is generating is mostly
parameter checking boilerplate, and if Cython lives up to its reputation,
it will be able to easily make this smaller and compile a lot faster. It
looks like neither of those two branches switched this code to Cython,
unfor
1 - 100 of 750 matches
Mail list logo
