Charles R Harris wrote:
>
>
>
> Yes, I was thinking about that too. There was a 1.3 thread a couple of
> weeks ago, we should summarize it, and set a timeline for 1.3 really
> soon. I can do it, unless you want do it it,
>
>
> Why don't you make a start.
Ok,
David
On Thu, Feb 26, 2009 at 1:23 AM, David Cournapeau wrote:
> On Thu, Feb 26, 2009 at 4:32 PM, Charles R Harris
> wrote:
>
> > Sounds good, I don't think the complex functions are a pressing concern.
> But
> > I suspect we should start looking forward to a code freeze in a month or
> so
> > and gett
On Thu, Feb 26, 2009 at 4:32 PM, Charles R Harris
wrote:
> Sounds good, I don't think the complex functions are a pressing concern. But
> I suspect we should start looking forward to a code freeze in a month or so
> and getting the build working is a clear priority.
The build is working more or
On Wed, Feb 25, 2009 at 11:54 PM, David Cournapeau wrote:
> On Tue, Feb 24, 2009 at 7:01 AM, Charles R Harris
> wrote:
> >
> >
> > On Mon, Feb 23, 2009 at 2:02 PM, David Cournapeau
> > wrote:
> >>
> >> On Fri, Feb 20, 2009 at 5:26 PM, Pauli Virtanen wrote:
> >> > Fri, 20 Feb 2009 01:05:03 +0900
On Tue, Feb 24, 2009 at 7:01 AM, Charles R Harris
wrote:
>
>
> On Mon, Feb 23, 2009 at 2:02 PM, David Cournapeau
> wrote:
>>
>> On Fri, Feb 20, 2009 at 5:26 PM, Pauli Virtanen wrote:
>> > Fri, 20 Feb 2009 01:05:03 +0900, David Cournapeau wrote:
>> > [clip]
>> >>> I think they should be. Then we
(AFAIK, inline is not a
> modification of the signature).
Indeed, even more so for C.
Matthieu
--
Information System Engineer, Ph.D.
Website: http://matthieu-brucher.developpez.com/
Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn: http://www.linkedin.com/in/matthi
On Wed, Feb 25, 2009 at 3:26 AM, Charles R Harris
wrote:
>
> Good point. However, most of the ufuncs involving standard functions like
> sin, cos, etc. are implemented as generic loops that are passed a function
> pointer and for such functions the call overhead is probably not significant
> in t
On Tue, Feb 24, 2009 at 11:09 AM, Matthieu Brucher <
matthieu.bruc...@gmail.com> wrote:
> In fact, the __inline is not helpful. It's the static keyword that
> enables the compiler to inline the function if the function is small
> enough. As the static indicates that the function will not be seen
>
The inline keyword is never an obligation to inline, it's only a
proposal. And the compiler in fact doesn't care about it. When using
an optimization mode, the compiler will inline the function if it is
simple enough. It's its call. It will even be easier to do so if the
static keyword is used, as
Matthieu Brucher wrote:
> In fact, the __inline is not helpful. It's the static keyword that
> enables the compiler to inline the function if the function is small
> enough. As the static indicates that the function will not be seen
> from the outside, it can do this.
>
Depends what is meant by
In fact, the __inline is not helpful. It's the static keyword that
enables the compiler to inline the function if the function is small
enough. As the static indicates that the function will not be seen
from the outside, it can do this.
Matthieu
2009/2/24 David Cournapeau :
> On Wed, Feb 25, 2009
On Wed, Feb 25, 2009 at 2:21 AM, Charles R Harris
wrote:
>
> In order to inline, the function definition would need to be in the header
> and a library version would still be required for passing functions by
> address or in case the compiler decided *not* to inline.
I looked more into this while
On Tue, Feb 24, 2009 at 7:04 AM, Neal Becker wrote:
> Pauli Virtanen iki.fi> writes:
>
> ...
> > One question: doesn't this add one extra function call to all umath
> > functions? Could we do '#define npy_XXX XXX' in the npy_math.h header
> > when the appropriate platform-specified functions are
Tue, 24 Feb 2009 14:04:42 +, Neal Becker wrote:
> Pauli Virtanen iki.fi> writes:
>
> ...
>> One question: doesn't this add one extra function call to all umath
>> functions? Could we do '#define npy_XXX XXX' in the npy_math.h header
>> when the appropriate platform-specified functions are ava
Pauli Virtanen iki.fi> writes:
...
> One question: doesn't this add one extra function call to all umath
> functions? Could we do '#define npy_XXX XXX' in the npy_math.h header
> when the appropriate platform-specified functions are available?
There shouldn't be overhead on modern compilers fo
On Mon, Feb 23, 2009 at 2:02 PM, David Cournapeau wrote:
> On Fri, Feb 20, 2009 at 5:26 PM, Pauli Virtanen wrote:
> > Fri, 20 Feb 2009 01:05:03 +0900, David Cournapeau wrote:
> > [clip]
> >>> I think they should be. Then we could easily use C99 complex math
> >>> functions on plaforms on which th
On Fri, Feb 20, 2009 at 5:26 PM, Pauli Virtanen wrote:
> Fri, 20 Feb 2009 01:05:03 +0900, David Cournapeau wrote:
> [clip]
>>> I think they should be. Then we could easily use C99 complex math
>>> functions on plaforms on which they are available (and so get the
>>> "correct" corner-case semantics
Fri, 20 Feb 2009 01:05:03 +0900, David Cournapeau wrote:
[clip]
>> I think they should be. Then we could easily use C99 complex math
>> functions on plaforms on which they are available (and so get the
>> "correct" corner-case semantics for free on these platforms).
>
> maybe we could change the n
On Thu, Feb 19, 2009 at 8:16 AM, David Cournapeau wrote:
> On Sun, Feb 15, 2009 at 5:09 PM, Robert Kern
> wrote:
> > On Sun, Feb 15, 2009 at 01:48, David Cournapeau
> > wrote:
> >
> >> Would people be against this ?
> >
> > Not I.
>
> Ok, I have started this in the coremath branch - it solves th
On Thu, Feb 19, 2009 at 9:32 AM, David Cournapeau wrote:
> On Fri, Feb 20, 2009 at 12:16 AM, David Cournapeau
> wrote:
> > On Sun, Feb 15, 2009 at 5:09 PM, Robert Kern
> wrote:
> >> On Sun, Feb 15, 2009 at 01:48, David Cournapeau
> >> wrote:
> >>
> >>> Would people be against this ?
> >>
> >> N
On Fri, Feb 20, 2009 at 12:16 AM, David Cournapeau wrote:
> On Sun, Feb 15, 2009 at 5:09 PM, Robert Kern wrote:
>> On Sun, Feb 15, 2009 at 01:48, David Cournapeau
>> wrote:
>>
>>> Would people be against this ?
>>
>> Not I.
>
> Ok, I have started this in the coremath branch - it solves the warni
On Fri, Feb 20, 2009 at 1:05 AM, David Cournapeau wrote:
>
> Another argument against the define is that in the future, we could
> load the actual implementation at runtime (SSE, etc...). If we use
> define, that's not possible.
Hm, that's actually a pretty stupid statement - we could certainly
On Fri, Feb 20, 2009 at 12:28 AM, Pauli Virtanen wrote:
> Fri, 20 Feb 2009 00:16:42 +0900, David Cournapeau wrote:
> [clip]
>> Ok, I have started this in the coremath branch - it solves the warning
>> issues we got since the merge of formatting stuff. I tested it on Linux,
>> windows (both mingw a
Fri, 20 Feb 2009 00:16:42 +0900, David Cournapeau wrote:
[clip]
> Ok, I have started this in the coremath branch - it solves the warning
> issues we got since the merge of formatting stuff. I tested it on Linux,
> windows (both mingw and VS - still need to test on Win64), so I think it
> is good to
On Sun, Feb 15, 2009 at 5:09 PM, Robert Kern wrote:
> On Sun, Feb 15, 2009 at 01:48, David Cournapeau
> wrote:
>
>> Would people be against this ?
>
> Not I.
Ok, I have started this in the coremath branch - it solves the warning
issues we got since the merge of formatting stuff. I tested it on
L
On Sun, Feb 15, 2009 at 01:48, David Cournapeau
wrote:
> Would people be against this ?
Not I.
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
-- U
Hi,
While trying to fix some issues on windows 64 bits related to the
float format fixes, I encountered some problems (lack of some basic math
functions, in particular isnan and co for the multiarray module). We
already have the portable replacing code for those functions
(umath_funcs_c99.inc.
27 matches
Mail list logo
