s]
>
> gives me a (N, k, k) array, while
>
> new_dists = np.take(indexs, axis=1)
>
> gives me a (N, N, k) array.
>
> What am I missing?
Broadcasting!
new_dists = distances[np.arange(N)[:, np.newaxis], indexs]
--
Robert Kern
___
is used for to interoperate with a Python builtin
function, that's probably the more important consistency to worry about.
As for the backwards compatibility concern, I don't think it would matter
much. Everyone who has written code that expects round(np.float64(...)) to
return a np.fl
On Mon, Mar 26, 2018 at 10:03 PM, wrote:
>
> On Mon, Mar 26, 2018 at 10:29 PM, Robert Kern
wrote:
> > On Mon, Mar 26, 2018 at 6:28 PM, Nathaniel Smith wrote:
> >>
> >> On Mon, Mar 26, 2018 at 6:24 PM, Nathaniel Smith wrote:
> >> > Even knowing that,
infinite
recursion.
--
Robert McLeod, Ph.D.
robbmcl...@gmail.com
robbmcl...@protonmail.com
robert.mcl...@hitachi-hhtc.ca
www.entropyreduction.al
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
two lists of methods that we still
would make strict compatibility guarantees for.
---
==
Random Number Generator Policy
==
:Author: Robert Kern
:Status: Draft
:Type: Standards Track
:Created: 2018-05-24
Abstract
For the past
ts of this form”
>
I do! Search for "unit test" or "StableRandom". :-)
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
list was just off the top of my head for methods that I think
were actually used in test suites, so I'd be happy to be shown live tests
that use other methods. I'd like to be a *little* conservative about what
methods we stick in here, but we don't have to be *too* conservative, since
ed once we did make these (*cough*extravagant*cough*)
guarantees, though, as people started to rely on it, and I hope that my
StableRandom proposal addresses it to your satisfaction. I could add some
more details about that history if you think it would be useful.
--
Robert Kern
_
On Sun, Jun 3, 2018 at 5:23 PM Stephan Hoyer wrote:
> On Sat, Jun 2, 2018 at 12:06 PM Robert Kern wrote:
>
>> We propose first freezing ``RandomState`` as it is and developing a new
>> RNG
>> subsystem alongside it. This allows anyone who has been relying on our
>&g
On Sun, Jun 3, 2018 at 6:01 PM wrote:
>
>
> On Sun, Jun 3, 2018 at 8:36 PM, Robert Kern wrote:
>
>> On Sun, Jun 3, 2018 at 4:35 PM Eric Wieser
>> wrote:
>>
>>> You make a bunch of good points refuting reproducible research as an
>>> arg
On Sun, Jun 3, 2018 at 5:46 PM wrote:
>
>
> On Sun, Jun 3, 2018 at 8:21 PM, Robert Kern wrote:
>
>>
>> The list of ``StableRandom`` methods should be chosen to support unit
>>> tests:
>>>
>>> * ``.randint()``
>>> * ``.unif
On Sun, Jun 3, 2018 at 6:26 PM wrote:
>
>
> On Sun, Jun 3, 2018 at 9:04 PM, Robert Kern wrote:
>
>> On Sun, Jun 3, 2018 at 6:01 PM wrote:
>>
>>>
>>>
>>> On Sun, Jun 3, 2018 at 8:36 PM, Robert Kern
>>> wrote:
>>>
>>>
On Sun, Jun 3, 2018 at 9:24 PM Charles R Harris
wrote:
>
> On Sat, Jun 2, 2018 at 1:04 PM, Robert Kern wrote:
>>
>> This policy was first instated in Nov 2008 (in essence; the full set of
>> weasel
>>
>
> Instituted?
>
I meant "instated"; c.f. f
On Sun, Jun 3, 2018 at 10:29 PM Charles R Harris
wrote:
>
>
> On Sun, Jun 3, 2018 at 11:03 PM, Robert Kern
> wrote:
>
>> On Sun, Jun 3, 2018 at 9:24 PM Charles R Harris <
>> charlesr.har...@gmail.com> wrote:
>>
>>>
>>> On Sat, Jun 2
on the rest first, as the higher level decisions
will tell us more about what we want to do for numpy.random.seed().
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
se
would be for people with legacy packages that cannot upgrade (other than
changing some imports) and for unit tests that require precise streams for
a full breadth of distributions. We would still leave it in numpy.random
for a deprecation period, but maybe we would be noisy about it soone
7;s likely "good
enough" if the integer distributions now return uint64 arrays instead of
uint32 arrays on Windows.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
eir reliance on such stability
and SHOULD limit their usage to distribution methods that have fewer
cross-platform stability risks.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
al is the best
way forward.
The mere usage of np.random.seed() doesn't imply that these packages
actually require stream-compatibility. Some might, for sure, like where
they are used in the unit tests, but that's not what you counted. At best,
these numbers ju
On Sun, Jun 10, 2018 at 5:27 PM Ralf Gommers wrote:
>
> On Mon, Jun 4, 2018 at 3:18 PM, Robert Kern wrote:
>>
>> On Sun, Jun 3, 2018 at 8:22 PM Ralf Gommers
wrote:
>>>
>>> It may be worth having a look at test suites for scipy, statsmodels,
scikit-learn, etc.
On Sun, Jun 10, 2018 at 7:46 PM wrote:
>
> On Sun, Jun 10, 2018 at 9:08 PM, Robert Kern
wrote:
>>
>> On Sun, Jun 10, 2018 at 5:27 PM Ralf Gommers
wrote:
>> >
>> > On Mon, Jun 4, 2018 at 3:18 PM, Robert Kern
wrote:
>> >>
>> >> On Sun,
On Sun, Jun 10, 2018 at 8:04 PM Ralf Gommers wrote:
>
> On Sun, Jun 10, 2018 at 6:08 PM, Robert Kern
wrote:
>>
>> On Sun, Jun 10, 2018 at 5:27 PM Ralf Gommers
wrote:
>> >
>> > On Mon, Jun 4, 2018 at 3:18 PM, Robert Kern
wrote:
>> >>
>>
On Sun, Jun 10, 2018 at 8:11 PM Ralf Gommers wrote:
>
> On Sun, Jun 10, 2018 at 5:57 PM, Robert Kern
wrote:
>>
>> On Sun, Jun 10, 2018 at 5:47 PM Ralf Gommers
wrote:
>> >
>> > On Sun, Jun 3, 2018 at 9:23 PM, Warren Weckesser <
warren.weckes...@gmail.com
deprecate the name RandomState in that drafting, but it's not
really necessary, and you've convinced me that we shouldn't do it.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
On Sun, Jun 10, 2018 at 11:54 PM Ralf Gommers
wrote:
>
> On Sun, Jun 10, 2018 at 11:15 PM, Robert Kern
wrote:
>> Puzzlingly, the root sin of unconditionally and unavoidably reseeding
for some of these functions is still there even though I showed how and why
to avoid it. This is on
umpy.random
per se rather than a third party package.
https://bashtage.github.io/randomgen/devel/legacy.html
---
==
Random Number Generator Policy
==
:Author: Robert Kern
:Status: Draft
:Type: Standards Track
:Created: 2018-05-24
Abstra
On Sat, Jun 16, 2018 at 11:02 AM Ralf Gommers
wrote:
>
>
> On Sat, Jun 16, 2018 at 12:38 AM, Robert Kern
> wrote:
>
>> I have incorporated the feedback from this thread, and have significantly
>> altered the proposal. I think this version will be more palatable to
hese in following releases.
>>
>
> This already read a little strangely to me -- it sounded like an
> indefinite pronouncement. It would be good to clarify :).
>
Fair enough. How does this language strike you?
https://github.com/numpy/numpy/pull/11356/commits/15af58f7b1
elastodynamics solvers
- terms for dispersion in fluids
- caching of reference coordinates for faster repeated use of probes
- new wrapper of MUMPS linear solver for parallel runs
For full release notes see http://docs.sfepy.org/doc/release_notes.html#id1
(rather long and technical).
Cheers,
Robert
uld
reserve warnings for the cases where the current behavior is something no
one really wants, like mixing slices and integer arrays.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
ne of the more easily noticed things. These are not silent
errors that would motivate adding a new warning.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
On Tue, Jun 26, 2018 at 12:46 AM Robert Kern wrote:
> On Tue, Jun 26, 2018 at 12:13 AM Eric Wieser
> wrote:
>
>> > I would reserve warnings for the cases where the current behavior is
>> something no one really wants, like mixing slices and integer arrays.
>>
>
with errors/warnings.
>
It's not necessarily hard; it's just churn for no benefit to the downstream
code. They didn't get a new feature; they just have to run faster to stay
in the same place.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
On Tue, Jun 26, 2018 at 1:26 AM Travis Oliphant
wrote:
> I like the proposal generally. NumPy could use a good orthogonal indexing
> method and a vectorized-indexing method is fine too.
>
> Robert Kern is spot on with his concerns as well. Please do not change
> what arr[idx]
On Tue, Jun 26, 2018 at 1:49 AM Hameer Abbasi
wrote:
>
> On 26. Jun 2018 at 10:33, Robert Kern wrote:
>
> > I'd suggest that the NEP explicitly disclaim deprecating current
behavior. Let the NEP just be about putting the new features out there.
Once we have some experience
On Tue, Jun 26, 2018 at 1:36 AM Sebastian Berg
wrote:
> On Tue, 2018-06-26 at 01:21 -0700, Robert Kern wrote:
> > On Tue, Jun 26, 2018 at 12:58 AM Sebastian Berg
> > wrote:
>
>
>
> > >
> > > Yes, that is true, but I doubt you will find a lot of c
On Tue, Jun 26, 2018 at 3:50 AM Sebastian Berg
wrote:
>
> On Tue, 2018-06-26 at 02:27 -0700, Robert Kern wrote:
> > On Tue, Jun 26, 2018 at 1:36 AM Sebastian Berg > s.net> wrote:
> > > On Tue, 2018-06-26 at 01:21 -0700, Robert Kern wrote:
> > > > On Tue,
On Tue, Jun 26, 2018 at 6:14 PM Stephan Hoyer wrote:
> On Tue, Jun 26, 2018 at 4:34 PM Robert Kern wrote:
>
>> I maintain that considering deprecation is premature at this time. Please
>> take it out of this NEP. Let us get a feel for how people actually use
>> .oindex/.
On Tue, Jun 26, 2018 at 6:47 PM Stephan Hoyer wrote:
>
> On Tue, Jun 26, 2018 at 6:39 PM Robert Kern wrote:
>
>> I'd still prefer not talking deprecation, per se, in this NEP (but my
>> objection is weaker). I would definitely start adding in informative, noisy
On Tue, Jun 26, 2018 at 9:50 PM Stephan Hoyer wrote:
> On Tue, Jun 26, 2018 at 12:46 AM Robert Kern
> wrote:
>
>> I think having more self-contained descriptions of the semantics of each
>> of these would be a good idea. The current description of `.vindex` spends
>&
On Tue, Jun 26, 2018 at 10:21 PM Juan Nunez-Iglesias
wrote:
> Let me start by thanking Robert for articulating my viewpoints far better
> than I could have done myself. I want to explicitly flag the following
> statements for endorsement:
>
> *I would still reserve warnings and
com/bashtage/randomgen
[2] Sorry, Kevin.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
days from this email, then
the NEP will be accepted; see NEP 0 for more details:
http://www.numpy.org/neps/nep-.html
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
avoid them.
https://github.com/numpy/numpy/pull/11475
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
rom PyPI as well (but not for RC releases):
http://pypi.python.org/pypi/numexpr
Documentation is hosted at:
http://numexpr.readthedocs.io/en/latest/
Share your experience
-
Let us know of any bugs, suggestions, gripes, kudos, etc. you may
have.
Enjoy data!
--
Rob
se unwelcoming behavior, and I think
maybe we should be explicit about that. Our diversity statement is an
aspiration, not a suicide pact. Religion, neurotype, national origin, and
subculture (4chan is a subculture, God help us), at minimum, are all items
on that list that I have personally seen used t
sn't give them any tools to
be better at welcoming a broader diversity in our community. They will read
that and carry on with their own personal status quo with no more
reflection. And this requires reflection and work.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
I think I'm going to leave it there for the time being and mute this thread
until I get back from vacation. I know that's terribly rude, and you all
have my abject apologies.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@
On Thu, Aug 2, 2018 at 11:01 PM Robert Kern wrote:
> Nope, concision is definitely not my strength. But I hope I
> made the argument clear, at least.
>
No, wait. I got it:
Bad actors use "diversity of political beliefs" in bad faith as cover for
undermining the goa
--
Let us know of any bugs, suggestions, gripes, kudos, etc. you may
have.
Enjoy data!
--
Robert McLeod, Ph.D.
robbmcl...@gmail.com
robbmcl...@protonmail.com
robert.mcl...@hitachi-hhtc.ca
www.entropyreduction.al
___
NumPy-Discussion
rfectly on-topic for that article.
You don't have to be the one that writes it, though, if you just want to
cover pybind11.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
tp://pypi.python.org/pypi/numexpr
Documentation is hosted at:
http://numexpr.readthedocs.io/en/latest/
Share your experience
-
Let us know of any bugs, suggestions, gripes, kudos, etc. you may
have.
Enjoy data!
--
Robert McLeod, Ph.D.
robbmcl...@gmail.com
robbmcl...@
that prepend/append behavior manually (and less
readably, possibly inefficiently, but most importantly annoyingly).
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
Hi,
it was originally used in other functions of arraysetops (culprit yours truly)
which used to use the padding functionality. Nowadays the only use I can see
git-grepping the numpy sources is in the tests, so +1 for deprecating.
Cheers,
r.
On 08/27/2018 07:28 PM, Tyler Reddy wrote:
Chuck
script for outline edge extraction
- new example: homogenization of a piezoelectric heterogeneous structure
For full release notes see http://docs.sfepy.org/doc/release_notes.html#id1
(rather long and technical).
Cheers,
Robert Cimrman
---
Contributors to this release in alphabetical order
On Tue, Sep 25, 2018 at 9:59 AM Stefan van der Walt
wrote:
> PR 4808 [0] asks whether `np.pad` should have a default mode. The
> proposal is to make the defaul `constant`, with a value of 0. This is
> common in many signal processing applications.
>
+1 for that proposal.
--
pular terminology is `tensors` for `multidimensional
> arrays`. Note that matrices are a different type of object.
>
Popular, but quite misleading, in the same way that not every 2-dim array
is a matrix. As someone who works on tensor machine learning methods once
complained to me.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
On Tue, Nov 6, 2018 at 3:55 PM Stefan van der Walt
wrote:
> On Tue, 06 Nov 2018 12:11:13 -0800, Robert Kern wrote:
> > Popular, but quite misleading, in the same way that not every 2-dim array
> > is a matrix. As someone who works on tensor machine learning methods once
>
umPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
much closer to the release when most of the PRs are merged
already merged and it's just last minute fixes and release-specific changes
(e.g. bumping version numbers, etc.) to do.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
/numexpr
You can get the packages from PyPI as well (but not for RC releases):
http://pypi.python.org/pypi/numexpr
Documentation is hosted at:
http://numexpr.readthedocs.io/en/latest/
Share your experience
-
Let us know of any bugs, suggestions, gripes, kudos, etc. you may
have.
- improved MUMPS solver interface
- support for logging and plotting of complex values
For full release notes see [1].
Cheers,
Robert Cimrman
[1] http://docs.sfepy.org/doc/release_notes.html#id1
---
Contributors to this release in alphabetical order:
Robert Cimrman
Vladimir Lukes
Matyas Novak
Jan
now Cython is a route, but I am asking about
> numba specifically).
>
> Thanks,
> - Stuart
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
--
mpy?
>
> Thanks in advance for any comments or suggestions.
>
> Best regards,
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
--
Robert McLeod, Ph.
sue causing bugs in real code, so I would submit that if there
is a lack (or benefit) compared to other languages, it is small.
That said, Python is not alone here. Perl and Ruby have Python's semantics.
R introduces NaNs but does not raise an error. Matlab and Julia do raise
errors.
--
Robert
- quadratic eigenvalue problem solver
For full release notes see [1].
Cheers,
Robert Cimrman
[1] http://docs.sfepy.org/doc/release_notes.html#id1
---
Contributors to this release in alphabetical order:
Robert Cimrman
Lubos Kejzlar
Vladimir Lukes
___
NumPy
n numpy should be implemented as ufuncs or regular functions".
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
st have to unpack anyways, and at
that point, it's just not *that* much more convenient than calling `min()`
and `max()` separately. So every time we write `xmin, xmax = x.min(),
x.max()`, we grumble a little bit, but it's just a grumble, not a
significant pain.
pandas has other consideration
On Fri, May 24, 2019 at 9:33 PM C W wrote:
> Thank you, Robert. I will take it up to the Pandas-dev mailing list.
>
> I'm not sure if I follow you on "right semantics for the shape of the
> output." Range is just a summary statistic which is a number.
>
>
of O'Neill is what enables this
kind of API, which is a sea change in how one can safely build reproducible
parallel stochastic programs and libraries.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org
homogenization problems,
- Python 3.7 compatibility
For full release notes see [1].
Cheers,
Robert Cimrman
[1] http://docs.sfepy.org/doc/release_notes.html#id1
---
Contributors to this release in alphabetical order:
Robert Cimrman
Jan Heczko
Lubos Kejzlar
Vladimir Lukes
ages from PyPI as well (but not for RC releases):
http://pypi.python.org/pypi/numexpr
Documentation is hosted at:
http://numexpr.readthedocs.io/en/latest/
Share your experience
-
Let us know of any bugs, suggestions, gripes, kudos, etc. you may
have.
Enjoy data!
--
Robert Mc
I can tell (which may be fine, if the only
> goal is to let people write new generators rather than use the existing
> ones from Cython without the Python overhead)
>
Using the existing distributions from Cython was a requested feature and an
explicit goal, yes. There are users waiting for this.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
On Thu, Sep 19, 2019 at 11:04 PM Ralf Gommers
wrote:
>
>
> On Thu, Sep 19, 2019 at 4:53 PM Robert Kern wrote:
>
>> On Thu, Sep 19, 2019 at 5:24 AM Ralf Gommers
>> wrote:
>>
>>>
>>> On Thu, Sep 19, 2019 at 10:28 AM Kevin Sheppard <
>>>
On Fri, Sep 20, 2019 at 6:09 AM Ralf Gommers wrote:
>
>
> On Fri, Sep 20, 2019 at 5:29 AM Robert Kern wrote:
>
>>
>> We might end up with more than 2 implementations if we need to change
>> something about the function signature, for whatever reason, and we
On Fri, Sep 20, 2019 at 11:33 PM Ralf Gommers
wrote:
>
>
> On Fri, Sep 20, 2019 at 7:09 AM Robert Kern wrote:
>
>>
>>
>> On Fri, Sep 20, 2019 at 6:09 AM Ralf Gommers
>> wrote:
>>
>>>
>>>
>>> On Fri, Sep 20, 2019 at 5:29 AM R
SLEPc
- new Python 3 enabled Timer class and other Python 3 compatibility fixes
For full release notes see [1].
Cheers,
Robert Cimrman
[1] http://docs.sfepy.org/doc/release_notes.html#id1
---
Contributors to this release in alphabetical order:
Robert Cimrman
Vladimir Lukes
On Wed, Sep 25, 2019, 12:56 PM Stefan van der Walt
wrote:
> On Fri, Sep 20, 2019, at 21:30, Robert Kern wrote:
>
> Given the prevalence of Cython, it's actually really easy to use the
> Python API pretty easily in "C", so it's actually a huge waste if the C
- improved Gmsh mesh format support (write .msh files)
- new updating procedure in nonlinear homogenization
- improved/faster log plotter
For full release notes see [1].
Cheers,
Robert Cimrman
[1] http://docs.sfepy.org/doc/release_notes.html#id1
---
Contributors to this release in alphabetical order
variance matrices are typically
small. And where they are large (e.g. Gaussian processes), you should
probably be doing your own decompositions instead of using
`multivariate_normal()`.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discus
can get the packages from PyPI as well (but not for RC releases):
http://pypi.python.org/pypi/numexpr
Documentation is hosted at:
http://numexpr.readthedocs.io/en/latest/
Share your experience
-
Let us know of any bugs, suggestions, gripes, kudos, etc. you may
have.
Enjoy
ave more
trouble dealing with the OS (or lack of OS, if that's the case) than the
architecture itself.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
le by itself to see if this
is a platform-specific problem with the general Cython-generated code for
initializing the module or a problem that we can fix in the mtrand code.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
m or how you want to implement them,
a third-party module is the right place for them.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
e to returning an
integer type, it should be a Python int.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
ated just by rounding for an example. Or numpy array size growing for no
>> apparent reason
>>
>> I am not really sure if I understand why LSP should hold in this case to
>> be honest. Rounding is an operation specific for the number instance and
>> not for the generic cl
nd
> not for the generic class.
>
The type of the return value is part of the type's interface, not the
specific instance.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
n and not
numpy, there is nothing in numpy to be consistent with. We only implement
__round__() for the scalar types.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
On Wed, Feb 26, 2020 at 6:59 PM wrote:
>
>
> On Wed, Feb 26, 2020 at 6:09 PM Robert Kern wrote:
>
>> On Wed, Feb 26, 2020 at 5:27 PM wrote:
>>
>>> great another object array
>>>
>>> np.asarray([round(x_i.item()) for x_i in np
27;s not about what I want but this changes the output of round. In my
> example I didn't use any arrays but a scalar type which looks like will
> upcasted.
>
> On Wed, Feb 26, 2020, 23:04 Robert Kern wrote:
>
>> On Wed, Feb 26, 2020 at 5:41 PM wrote:
>>
>>>
&g
tatypes they would have a silent upcasting.
>
>
>
> No they won’t. The only affected types would be scalars, and that too only
> with the built-in Python round.
>
Just to be clear, his example _did_ use numpy scalars.
--
Robert Kern
__
have significant impact.
>
np.round()/np.around() will still exist and behave as you would want it to
in such cases (float32->float32, float64->float64).
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.p
using meshio [2]
- Python 3 only from now on
For full release notes see [1].
Cheers,
Robert Cimrman
[1] http://docs.sfepy.org/doc/release_notes.html#id1
[2] https://github.com/nschloe/meshio
---
Contributors to this release in alphabetical order:
Robert Cimrman
Lubos Kejzlar
Vladimir Lukes
ing list
>
> --
> Sargam Monga
> 2018262
> CSAM Undergraduate | IIIT-D
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-
suggestions and tips are always welcome.
>
Welcome! Do you have an idea what you would like to work on?
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
(maybe even the switching behaviour).
> I am not sure anyone actually uses those, so it may not be a good idea
> to use them to be honest.
>
The versions in `np.lib.scimath` behave like this. Of course, people do use
them when they want to deal with real numbers as subsets of the complex
On Mon, May 25, 2020 at 11:17 AM Sebastian Berg
wrote:
> On Mon, 2020-05-25 at 11:10 -0400, Robert Kern wrote:
> > On Mon, May 25, 2020 at 10:36 AM Sebastian Berg <
> > sebast...@sipsolutions.net>
> > wrote:
> >
> > > On Mon, 2020-05-25 at 10:09 -0400, B
some advanced use cases (mostly involving de/serialization and
similar kinds of meta-programming tasks). It's also been helpful for me to
construct worst-case scenarios for testing parallel streams. But it quite
deliberately bypasses the notion of deriving the state from a
human-friendly
e isn't a
persistent Generator object between these runs, that's probably better.
It's a code smell if you can't just pass in a fresh Generator; in general,
it means that your code is harder to use, not just because we don't expose
an in-pla
-paste comfortably.
We have thought about wrapping that up in a numpy.random function (e.g.
`np.random.simple_seed()` or something like that) for convenience, but we
wanted to wait a bit before commiting to an API.
--
Robert Kern
___
NumPy-Discussion m
101 - 200 of 326 matches
Mail list logo
