Hi Pauli,
On Thu, Dec 10, 2009 at 12:34 PM, Pauli Virtanen wrote:
> to, 2009-12-10 kello 10:18 -0600, Robert Kern kirjoitti:
> > On Thu, Dec 10, 2009 at 04:24, Pauli Virtanen
> > >
> wrote:
> > > Thu, 10 Dec 2009 09:54:32 +0100, Dag Sverre Seljebotn wrote:
> > > [clip]
> > >> At this point I wa
to, 2009-12-10 kello 10:18 -0600, Robert Kern kirjoitti:
> On Thu, Dec 10, 2009 at 04:24, Pauli Virtanen wrote:
> > Thu, 10 Dec 2009 09:54:32 +0100, Dag Sverre Seljebotn wrote:
> > [clip]
> >> At this point I want to remind us about Charles Harris' very workable
> >> proposal: Raise a warning. Tha
On Thu, Dec 10, 2009 at 2:54 AM, Dag Sverre Seljebotn
wrote:
> Anne Archibald wrote:
>> 2009/12/9 Dr. Phillip M. Feldman :
>>
>>
>>> When I recently tried to validate a code, the answers were wrong, and it
>>> took two full days to track down the cause. I am now forced to reconsider
>>> carefully
On Thu, Dec 10, 2009 at 04:24, Pauli Virtanen wrote:
> Thu, 10 Dec 2009 09:54:32 +0100, Dag Sverre Seljebotn wrote:
> [clip]
>> At this point I want to remind us about Charles Harris' very workable
>> proposal: Raise a warning. That should both keep backward compatability
>> and prevent people fro
Thu, 10 Dec 2009 09:54:32 +0100, Dag Sverre Seljebotn wrote:
[clip]
> At this point I want to remind us about Charles Harris' very workable
> proposal: Raise a warning. That should both keep backward compatability
> and prevent people from wasting days. (Hopefully, we can avoid wasting
> days discu
Anne Archibald wrote:
> 2009/12/9 Dr. Phillip M. Feldman :
>
>
>> When I recently tried to validate a code, the answers were wrong, and it
>> took two full days to track down the cause. I am now forced to reconsider
>> carefully whether Python/NumPy is a suitable platform for serious scientific
2009/12/9 Dr. Phillip M. Feldman :
>
>
> Pauli Virtanen-3 wrote:
>>
>> Nevertheless, I can't really regard dropping the imaginary part a
>> significant issue.
>>
>
> I am amazed that anyone could say this. For anyone who works with Fourier
> transforms, or with electrical circuits, or with electro
On Wed, Dec 09, 2009 at 05:54:07PM -0800, Dr. Phillip M. Feldman wrote:
>
> Pauli Virtanen-3 wrote:
> >
> > Nevertheless, I can't really regard dropping the imaginary part a
> > significant issue.
> >
>
> I am amazed that anyone could say this. For anyone who works with Fourier
> transforms, o
Pauli Virtanen-3 wrote:
>
> Nevertheless, I can't really regard dropping the imaginary part a
> significant issue.
>
I am amazed that anyone could say this. For anyone who works with Fourier
transforms, or with electrical circuits, or with electromagnetic waves,
dropping the imaginary part is
Pauli Virtanen-3 wrote:
>
> I'd think that downcasting is different from dropping the imaginary part.
>
There are many ways (in fact, an unlimited number) to downcast from complex
to real. Here are three possibilities:
- Take the real part.
- Take the magnitude (root-mean-square of the real
On Wed, Dec 9, 2009 at 2:04 AM, Pauli Virtanen wrote:
> ti, 2009-12-08 kello 22:26 -0800, Dr. Phillip M. Feldman kirjoitti:
> > Darren Dale wrote:
> > > On Sat, Mar 7, 2009 at 5:18 AM, Robert Kern
> wrote:
> > >> On Sat, Mar 7, 2009 at 04:10, Stéfan van der Walt
> > >> wrote:
> > >> > 2009/3/7
On Wed, Dec 9, 2009 at 9:46 AM, Ryan May wrote:
> On Wed, Dec 9, 2009 at 3:51 AM, David Warde-Farley
> wrote:
>> On 9-Dec-09, at 1:26 AM, Dr. Phillip M. Feldman wrote:
>>> Unfortunately, NumPy seems to be a sort of step-child of Python,
>>> tolerated,
>>> but not fully accepted. There are a numb
On Wed, Dec 9, 2009 at 3:51 AM, David Warde-Farley wrote:
> On 9-Dec-09, at 1:26 AM, Dr. Phillip M. Feldman wrote:
>> Unfortunately, NumPy seems to be a sort of step-child of Python,
>> tolerated,
>> but not fully accepted. There are a number of people who continue to
>> use Matlab,
>> despite all
On 9-Dec-09, at 1:26 AM, Dr. Phillip M. Feldman wrote:
> NumPy and Python are somewhat out of step. The NumPy approach
> is stricter and more likely to catch errors than Python. Python
> tends to be
> somewhat laissez-faire about numerical errors and the correctness of
> results.
The bug/quirk
Pauli Virtanen wrote:
> ti, 2009-12-08 kello 22:26 -0800, Dr. Phillip M. Feldman kirjoitti:
>
>> Darren Dale wrote:
>>
>>> On Sat, Mar 7, 2009 at 5:18 AM, Robert Kern wrote:
>>>
On Sat, Mar 7, 2009 at 04:10, Stéfan van der Walt
wrote:
> 2009/3/7 Robert K
ti, 2009-12-08 kello 22:26 -0800, Dr. Phillip M. Feldman kirjoitti:
> Darren Dale wrote:
> > On Sat, Mar 7, 2009 at 5:18 AM, Robert Kern wrote:
> >> On Sat, Mar 7, 2009 at 04:10, Stéfan van der Walt
> >> wrote:
> >> > 2009/3/7 Robert Kern :
> >> >> In [5]: z = zeros(3, int)
> >> >>
> >> >> In [6]
Darren Dale wrote:
>
> On Sat, Mar 7, 2009 at 5:18 AM, Robert Kern wrote:
>
>> On Sat, Mar 7, 2009 at 04:10, Stéfan van der Walt
>> wrote:
>> > 2009/3/7 Robert Kern :
>> >> In [5]: z = zeros(3, int)
>> >>
>> >> In [6]: z[1] = 1.5
>> >>
>> >> In [7]: z
>> >> Out[7]: array([0, 1, 0])
>> >
>> >
Stéfan van der Walt wrote:
>
>
> Would it be possible to, optionally, throw an exception?
>
> S.
> ___
> Numpy-discussion mailing list
> Numpy-discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
I'm certain that it i
On 12/08/09 02:32, David Warde-Farley wrote:
> On 7-Dec-09, at 11:13 PM, Dr. Phillip M. Feldman wrote:
>
> > Example #1:
> > IPython 0.10 [on Py 2.5.4]
> > [~]|1> z= zeros(3)
> > [~]|2> z[0]= 1+1J
> >
> > TypeError: can't convert complex to float; use abs(z)
>
> The problem is that you're using
On Tue, Dec 08, 2009 at 10:17:20AM -0800, Dr. Phillip M. Feldman wrote:
>
>
>
> David Warde-Farley-2 wrote:
> >
> >
> > A less harmful solution (if a solution is warranted, which is for the
> > Council of the Elders to
> > decide) would be to treat the Python complex type as a special case,
David Warde-Farley-2 wrote:
>
>
> A less harmful solution (if a solution is warranted, which is for the
> Council of the Elders to
> decide) would be to treat the Python complex type as a special case, so
> that the .real attribute is accessed instead of trying to cast to float.
>
>
There
>> At a minimum, this inconsistency needs to be cleared up. My
>> preference
>> would be that the programmer should have to explicitly downcast from
>> complex to float, and that if he/she fails to do this, that an
>> exception be
>> triggered.
>
> That would most likely break a *lot* of deployed
On 7-Dec-09, at 11:13 PM, Dr. Phillip M. Feldman wrote:
> Example #1:
> IPython 0.10 [on Py 2.5.4]
> [~]|1> z= zeros(3)
> [~]|2> z[0]= 1+1J
>
> TypeError: can't convert complex to float; use abs(z)
The problem is that you're using Python's built-in complex type, and
it responds to type coerci
Robert Kern-2 wrote:
>
>
>
> Downcasting data is a necessary operation sometimes. We explicitly
> made a choice a long time ago to allow this.
>
> Robert Kern
>
>
This might be the time to recognize that that was a bad choice and reverse
it. It is not clear to me why downcasting from comp
Robert Kern-2 wrote:
>
>
>
> Downcasting data is a necessary operation sometimes. We explicitly
> made a choice a long time ago to allow this.
>
> Robert Kern
>
>
This might be the time to recognize that that was a bad choice and reverse
it. It is not clear to me why downcasting from comp
On Sat, Mar 7, 2009 at 5:18 AM, Robert Kern wrote:
> On Sat, Mar 7, 2009 at 04:10, Stéfan van der Walt
> wrote:
> > 2009/3/7 Robert Kern :
> >> In [5]: z = zeros(3, int)
> >>
> >> In [6]: z[1] = 1.5
> >>
> >> In [7]: z
> >> Out[7]: array([0, 1, 0])
> >
> > Blind moment, sorry. So, what is your
2009/3/7 Robert Kern :
> On Sat, Mar 7, 2009 at 04:10, Stéfan van der Walt wrote:
>> 2009/3/7 Robert Kern :
>>> In [5]: z = zeros(3, int)
>>>
>>> In [6]: z[1] = 1.5
>>>
>>> In [7]: z
>>> Out[7]: array([0, 1, 0])
>>
>> Blind moment, sorry. So, what is your take -- should this kind of
>> thing pass
On Sat, Mar 7, 2009 at 04:10, Stéfan van der Walt wrote:
> 2009/3/7 Robert Kern :
>> In [5]: z = zeros(3, int)
>>
>> In [6]: z[1] = 1.5
>>
>> In [7]: z
>> Out[7]: array([0, 1, 0])
>
> Blind moment, sorry. So, what is your take -- should this kind of
> thing pass silently?
Downcasting data is a n
2009/3/7 Robert Kern :
> In [5]: z = zeros(3, int)
>
> In [6]: z[1] = 1.5
>
> In [7]: z
> Out[7]: array([0, 1, 0])
Blind moment, sorry. So, what is your take -- should this kind of
thing pass silently?
Regards
Stéfan
___
Numpy-discussion mailing list
N
On Sat, Mar 7, 2009 at 03:30, Stéfan van der Walt wrote:
> 2009/3/7 Charles R Harris :
>>> a = np.zeros(6) # real
>>> b= np.arange(6)*(2+3j) # complex
>>> a[1] = b[1] # shouldn't this break?
>>>
>>> What is the rationale behind this behaviour?
>>
>> The same as this:
>>
>> In [1]: a = zeros(2)
>>
2009/3/7 Charles R Harris :
>> a = np.zeros(6) # real
>> b= np.arange(6)*(2+3j) # complex
>> a[1] = b[1] # shouldn't this break?
>>
>> What is the rationale behind this behaviour?
>
> The same as this:
>
> In [1]: a = zeros(2)
>
> In [2]: a[0] = '1'
>
> In [3]: a
> Out[3]: array([ 1., 0.])
This d
On Fri, Mar 6, 2009 at 6:18 PM, Stéfan van der Walt wrote:
> Hi all,
>
> The following code succeeds, while I thought it should fail:
>
> a = np.zeros(6) # real
> b= np.arange(6)*(2+3j) # complex
> a[1] = b[1] # shouldn't this break?
>
> What is the rationale behind this behaviour?
>
The same as
Hi all,
The following code succeeds, while I thought it should fail:
a = np.zeros(6) # real
b= np.arange(6)*(2+3j) # complex
a[1] = b[1] # shouldn't this break?
What is the rationale behind this behaviour?
Cheers
Stéfan
___
Numpy-discussion mailing li
33 matches
Mail list logo
