Thank you Charles for the corrections.
Cheers,
N.Maniteja
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Thu, Jan 15, 2015 at 10:41 PM, Charles R Harris <
charlesr.har...@gmail.co
On Thu, Jan 15, 2015 at 9:44 AM, Maniteja Nandana <
maniteja.modesty...@gmail.com> wrote:
> Hello everyone,
>
> I just wanted to highlight the point made by Charles, it would be great if
> he would clarify any mistakes in the points that I put forward.
>
> Quoting the documentation,
>
> In version
Hello everyone,
I just wanted to highlight the point made by Charles, it would be great if
he would clarify any mistakes in the points that I put forward.
Quoting the documentation,
In versions of NumPy prior to 1.7, this function always returned a
new,independent array containing a copy of the
Hi,
On Sun, Jan 4, 2015 at 4:22 PM, Konrad Hinsen
wrote:
> 2) Changes that yield to different results for unmodified legacy code
> should never be allowed.
I think this is a very reasonable rule.
Case in point - I have some fairly old code in
https://github.com/matthew-brett/transforms3d .
I h
On Mon, Jan 5, 2015 at 11:13 AM, Alan G Isaac wrote:
> On 1/5/2015 10:48 AM, josef.p...@gmail.com wrote:
> > Dtypes are a mess (in terms of code compatibility). Matlab is much
> nicer, it's all just doubles.
>
>
> 1. Thank goodness for dtypes.
> 2. http://www.mathworks.com/help/matlab/numeric-typ
On 1/5/2015 10:48 AM, josef.p...@gmail.com wrote:
> Dtypes are a mess (in terms of code compatibility). Matlab is much nicer,
> it's all just doubles.
1. Thank goodness for dtypes.
2. http://www.mathworks.com/help/matlab/numeric-types.html
3. After translating Matlab code to much nicer NumPy,
On Mon, Jan 5, 2015 at 4:08 AM, Konrad Hinsen
wrote:
> --On 5 janvier 2015 08:43:45 + Sturla Molden
> wrote:
>
> > To me it seems that algorithms in scientific papers and books are
> > described in various forms of pseudo-code.
>
> That's indeed what people do when they write a paper about a
--On 5 janvier 2015 08:43:45 + Sturla Molden
wrote:
> To me it seems that algorithms in scientific papers and books are
> described in various forms of pseudo-code.
That's indeed what people do when they write a paper about an algorithm.
But many if not most algorithms in computational sci
Konrad Hinsen wrote:
> Scientific communication depends more and more on scripts as the only
> precise documentation of a computational method. Our programming
> languages are becoming a major form of scientific notation, alongside
> traditional mathematics.
To me it seems that algorithms in
On 04/01/15 21:28, Sturla Molden wrote:
> A scientific paper or thesis should be written so it is completely
> reproducible. That would include describing the computer, OS, Python
> version and NumPy version, as well as C or Fortran compiler.
I completely agree and we should all work towards this
On 04/01/15 21:55, Sturla Molden wrote:
> On 03/01/15 20:49, Nathaniel Smith wrote:
>
>> OTOH the big problem that motivated his post was that his code is
>> all written against the APIs of the ancient and long-abandoned Numeric
>> project, and he finds the costs of transitioning them to the "new"
On 03/01/15 20:49, Nathaniel Smith wrote:
> i.e., slow-incremental-change has actually worked well in his
> experience. (And in particular, the np.diagonal issue only comes in as
> an example to illustrate what he means by the phrase "slow continuous
> change" -- this particular change hasn't actu
On 04/01/15 17:22, Konrad Hinsen wrote:
> There are two different scenarios to consider here, and perhaps I didn't
> make that distinction clear enough. One scenario is that of a maintained
> library or application that depends on NumPy. The other scenario is a
> set of scripts written for a speci
On 03/01/15 20:49, Nathaniel Smith wrote:
> The post you cite brings this up explicitly:
>
> > [3] http://khinsen.wordpress.com/2014/09/12/the-state-of-numpy/
>
> I have huge respect for the problems and pain that Konrad describes in
> this blog post, but I really can't agree with the argument or
On Sat, Jan 3, 2015 at 11:08 PM, Charles R Harris wrote:
>
>
> On Sat, Jan 3, 2015 at 2:55 PM, Matthew Brett
> wrote:
>
>> Hi,
>>
>> On Thu, Jan 1, 2015 at 9:35 PM, Alexander Belopolsky
>> wrote:
>> > A discussion [1] is currently underway at GitHub which will benefit
>> from a
>> > larger foru
On Sat, Jan 3, 2015 at 2:55 PM, Matthew Brett
wrote:
> Hi,
>
> On Thu, Jan 1, 2015 at 9:35 PM, Alexander Belopolsky
> wrote:
> > A discussion [1] is currently underway at GitHub which will benefit from
> a
> > larger forum.
> >
> > In version 1.9, the diagonal() method was changed to return a re
Hi,
On Thu, Jan 1, 2015 at 9:35 PM, Alexander Belopolsky wrote:
> A discussion [1] is currently underway at GitHub which will benefit from a
> larger forum.
>
> In version 1.9, the diagonal() method was changed to return a read-only
> (non-contiguous) view into the original array instead of a pla
Wasn't all of this discussed way back when the deprecation plan was made?
This was known to happen and was entirely the intent, right? What new
argument is there to deviate from the plan?
As for that particular blog post, I remember reading it back when it was
posted. I, again, sympathize with the
On 1 Jan 2015 21:35, "Alexander Belopolsky" wrote:
>
> A discussion [1] is currently underway at GitHub which will benefit from
a larger forum.
>
> In version 1.9, the diagonal() method was changed to return a read-only
(non-contiguous) view into the original array instead of a plain copy.
Also, i
A discussion [1] is currently underway at GitHub which will benefit from a
larger forum.
In version 1.9, the diagonal() method was changed to return a read-only
(non-contiguous) view into the original array instead of a plain copy.
Also, it has been announced [2] that in 1.10 the view will become
20 matches
Mail list logo
