Maybe I found the problems;
1. t0=1.0, t1=3.0, y['1'] = cos(1.0*omega*t): I have to reconstruct the
signal using
> yRec += a * cos(omega*i*(t-t0) + f)
not
> yRec += a * cos(omega*i*t + f)
2. t0=2, t1=3, y['Signal'] = 1.0*cos(1.0*omega*t) + ... +
5.0*cos(5.0*omega*t) + 1.0: starting point a
On May 20, 2016 4:24 PM, "Elliot Hallmark" wrote:
>
> I have a Data Oriented programing library I'm writing that uses the
Entity-Component-System model.
>
> https://github.com/Permafacture/data-oriented-pyglet
>
> I have initially called it Numpy-ECS but I don't know if that name is
okay. The num
On Fri, May 20, 2016 at 6:54 PM, Nathaniel Smith wrote:
> On May 20, 2016 12:44 PM, wrote:
> [...]
> >
> > can numpy cast to float by default for power or **?
>
> Maybe? The question is whether there are any valid use cases for getting
> ints back:
>
> >>> np.array([1, 2, 3]) ** 2
> array([1, 4,
I have a Data Oriented programing library I'm writing that uses the
Entity-Component-System model.
https://github.com/Permafacture/data-oriented-pyglet
I have initially called it Numpy-ECS but I don't know if that name is
okay. The numpy license says:
Neither the name of the NumPy Developers no
On May 20, 2016 12:44 PM, wrote:
[...]
>
> can numpy cast to float by default for power or **?
Maybe? The question is whether there are any valid use cases for getting
ints back:
>>> np.array([1, 2, 3]) ** 2
array([1, 4, 9])
It's not 100% obvious to me but intuitively this seems like an operati
Yes, I was referring to `pow`,
but I had in mind the C++ version,
which is overloaded:
http://www.cplusplus.com/reference/cmath/pow/
Cheers,
Alan
On 5/20/2016 4:27 PM, Warren Weckesser wrote:
C doesn't have an exponentiation operator. The C math library has pow, powf
and powl, which (like an
Hi All,
As a final desired state, always returning float seems the best idea. It
seems quite similar to division in this regard, where integer division
works for some values, but not for all. This means not being quite
consistent with python, but as Nathan pointed out, one cannot have
value-depend
On Fri, May 20, 2016 at 4:27 PM, Warren Weckesser <
warren.weckes...@gmail.com> wrote:
>
>
> On Fri, May 20, 2016 at 4:22 PM, Alan Isaac wrote:
>
>> On 5/19/2016 11:30 PM, Nathaniel Smith wrote:
>>
>>> the last bad
>>> option IMHO would be that we make int ** (negative int) an error in
>>> all ca
On Fri, May 20, 2016 at 4:22 PM, Alan Isaac wrote:
> On 5/19/2016 11:30 PM, Nathaniel Smith wrote:
>
>> the last bad
>> option IMHO would be that we make int ** (negative int) an error in
>> all cases, and the error message can suggest that instead of writing
>>
>> np.array(2) ** -2
>>
>> the
On 5/19/2016 11:30 PM, Nathaniel Smith wrote:
the last bad
option IMHO would be that we make int ** (negative int) an error in
all cases, and the error message can suggest that instead of writing
np.array(2) ** -2
they should instead write
np.array(2) ** -2.0
(And similarly for np.int
On Fri, May 20, 2016 at 3:23 PM, Charles R Harris wrote:
>
>
> On Fri, May 20, 2016 at 1:15 PM, Nathaniel Smith wrote:
>
>> On Fri, May 20, 2016 at 11:35 AM, Charles R Harris
>> wrote:
>> >
>> >
>> > On Thu, May 19, 2016 at 9:30 PM, Nathaniel Smith wrote:
>> >>
>> >> So I guess what makes this
On Fri, May 20, 2016 at 1:15 PM, Nathaniel Smith wrote:
> On Fri, May 20, 2016 at 11:35 AM, Charles R Harris
> wrote:
> >
> >
> > On Thu, May 19, 2016 at 9:30 PM, Nathaniel Smith wrote:
> >>
> >> So I guess what makes this tricky is that:
> >>
> >> - We want the behavior to the same for multipl
On Fri, May 20, 2016 at 11:35 AM, Charles R Harris
wrote:
>
>
> On Thu, May 19, 2016 at 9:30 PM, Nathaniel Smith wrote:
>>
>> So I guess what makes this tricky is that:
>>
>> - We want the behavior to the same for multiple-element arrays,
>> single-element arrays, zero-dimensional arrays, and sca
On Fri, May 20, 2016 at 12:35 PM, Charles R Harris <
charlesr.har...@gmail.com> wrote:
>
>
> On Thu, May 19, 2016 at 9:30 PM, Nathaniel Smith wrote:
>
>> So I guess what makes this tricky is that:
>>
>> - We want the behavior to the same for multiple-element arrays,
>> single-element arrays, zero
On Thu, May 19, 2016 at 9:30 PM, Nathaniel Smith wrote:
> So I guess what makes this tricky is that:
>
> - We want the behavior to the same for multiple-element arrays,
> single-element arrays, zero-dimensional arrays, and scalars -- the
> shape of the data shouldn't affect the semantics of **
>
15 matches
Mail list logo