turn dict(bg_state=bg_state, seed_seq=ss_dict)
def rng_fromdict(d):
bg_state = d['bg_state']
ss = np.random.SeedSequence(**d['seed_seq'])
bg = getattr(np.random, bg_state['bit_generator'])(ss)
bg.state = bg_state
rng = np.random.Generator(bg)
program code. NEP 19 doesn't need an update for us to endorse SPEC
7 (whether it needs one, separately, to clarify its intent is another
question).
--
Robert Kern
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send
se and leave the 0-length-axis case
alone.
3. Fix the 0-length-axis case to use the following `# shape=...` comment
too.
--
Robert Kern
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@
tor
>
>>> rng = np.random.default_rng()
>>> rng.bit_generator.seed_seq
SeedSequence(
entropy=186013007116029215180532390504704448637,
)
In some older versions of numpy, the attribute was semi-private as
_seed_seq, if you're still using one of those.
--
Robert Kern
__
lues to "func". The result
> value at position (1,1,1) in the output array would be y = func(X). The
> same would apply for all entries excluding the padding area (or according
> to some padding policy).
>
scipy.ndimage.generic_filter()
<https://docs.scipy.org/doc/scipy/reference
ely
desired, so it can be rarely requested in an explicit manner.
For `np.heaviside()`, a default value was intentionally left unspecified
because of the multiple conventions that people want. In the face of
ambiguity, refuse the temptation to guess.
I think we're comfortable with these cho
ainers). If it gets picked up by a bunch of other
array implementations, then you can make a proposal to have them added to
the Array API standard. numpy probably won't add them unless if that
happens first.
--
Robert Kern
___
NumPy-Discussion ma
oing the type inference yourself and implement that in the
`PyObjectArray.__array__()` implementation and avoid implementing
`__array_interface__` for that object. Then `np.asarray()` will just
delegate to `PyObjectArray.__array__()`.
--
Robert Kern
___
On Tue, Mar 26, 2024 at 3:39 PM Luca Bertolotti
wrote:
> Thanks for your reply yes it seems more appropriate a cubic spline but how
> can i get what they call SC
>
I don't think any of us has enough context to know what "SC" is. It's not a
standard term that I
ure JSON. Consider looking at
BJData, but it's "JSON-based" and not quite pure JSON.
https://neurojson.org/
--
Robert Kern
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussio
t from
an array to a reasonable JSONable encoding (e.g. base64). The time you are
seeing is the time it takes to encode that amount of data, period. That
said, if you want to use a quite inefficient hex encoding, `a.data.hex()`
is somewhat faster than the ba
vor of functions. A general way to add some kind of fluency cheaply in
an Array API-agnostic fashion might be helpful to people trying to make
their numpy-only code that uses our current set of methods in this way a
bit easier. But you'll have to make the proposal to them, I thi
ually sorted to).
Either way, we probably aren't going to add this as its own function. Both
options are straightforward combinations of existing primitives.
--
Robert Kern
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe
rwise difficult to
> work with since it compares equal to 0.0. I would find it surprising
> for copysign to do a numeric calculation on complex numbers. Also,
> your suggested definition would be wrong for 0.0 and -0.0, since
> sign(0) is 0, and this is precis
ng of
the assertion of correctness (`random()`, as used in that StackOverflow
demonstration, does *not* exercise a lot of the important edge cases in the
floating point format). But if your true concern is that 9% of disk space,
you probably don't want to be using `savetxt()` in any case.
-
subarrays
<https://numpy.org/doc/stable/reference/arrays.dtypes.html#index-7> (e.g.
`np.dtype((np.int32, (2,2)))`), that info here.
3. If there are fields, a tuple of the names of the fields
4. If there are fields, the field descriptor dict.
5. If extended dtype (e.g. fields, strings, void, etc.
et()
while len(seen) < size:
dsize = size - len(seen)
seen.update(map(tuple, rng.integers(0, ashape, size=(dsize,
len(shape)
return list(seen)
That optimistic optimization makes this the fastest solution.
--
Robert Kern
___
NumP
just
doing set-checking anyways, so no loss.
--
Robert Kern
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com
On Fri, Nov 17, 2023 at 4:15 PM Aaron Meurer wrote:
> On Fri, Nov 17, 2023 at 12:10 PM Robert Kern
> wrote:
> >
> > If the arrays you are drawing indices for are real in-memory arrays for
> present-day 64-bit computers, this should be adequate. If it's a notional
&g
integer
sampling. The builtin `random.randrange()` will do arbitrary-sized integers
and is quite reasonable for this task. If you want it to use our
BitGenerators underneath for clean PRNG state management, this is quite
doable with a simple subclass of `random.Random`:
https://github.com/num
it this
problem. I.e. if you use pickling, you're told to use it only for transient
data with the same versions of libraries on both ends of the pipe, but the
reality is that it's too useful to avoid in creating files with arbitrarily
long lives. Not their fault; they warned us!
--
Robe
e the rest of the information in `__array_interface__`, and I think
you should be good to go. I don't think you'll need to infer or represent
the precise path of Python-level operations (slices, transposes, reshapes,
etc.) to which it got to that point.
--
Robert Kern
__
f a plain function like `fix()` and has a (strict, I believe)
superset of functionality. You can ignore `fix()`, more or less. I'm not
sure if it's on the list for deprecation/removal in numpy 2.0, but it
certainly could be.
--
Robert Kern
_
ave it at that and not extend the `Generator`
interface.
https://github.com/numpy/numpy/issues/24458#issuecomment-1685022258
--
Robert Kern
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-
21])
> ```
> which matches your example in the cumsum0() documentation. Did something
> change in a recent release?
>
That's not what's in his example.
--
Robert Kern
___
NumPy-Discussion mailing list -- numpy-discussion@python
g
> To unsubscribe send an email to numpy-discussion-le...@python.org
> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> Member address: robert.k...@gmail.com
>
--
Robert Kern
___
NumPy-Discussion mailing list -- numpy-discus
iding such an `out=`) will fall down
to the `ff->f` loop and cause upcasting of the operands, which is not what
they want. But notionally one could add an `ee->f` loop between those two
that would catch this case when `dtype=np.float32` is requested.
--
Robert Kern
otion scheme.
`np.dot()` is kind of an oddball already, and "half-precision inputs ->
full-precision outputs" might be a worthwhile use case given hardware
accelerators. Given that this largely affects non-numpy implementations of
the Array API, you probably want to raise it with that group.
]
|21> x = np.arange(2*3).reshape((2, 3))
[~]
|22> x
array([[0, 1, 2],
[3, 4, 5]])
[~]
|23> x.flat[[0, 1, 2, 3]]
array([0, 1, 2, 3])
```
--
Robert Kern
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send
rticularly
special values at places in between adjacent representable floating point
numbers.
> I'm ambivalent about reverting. I know I would love speed improvements
> because transformation calculations in GIS is slow using numpy, but also
> some coordinate transformations might break
On Wed, May 31, 2023 at 5:01 PM David Menéndez Hurtado <
davidmen...@gmail.com> wrote:
> On Wed, 31 May 2023, 22:41 Robert Kern, wrote:
>
>> Not sure anyone really uses tanh for serious work.
>>
>
> At the risk of derailing the discussion, the case I can think of
n trig functions because of their role in ML and
statistics (I'd still *prefer* to opt in, though). They don't have many
special values (which usually have alternates like expm1 and log1p to get
better precision in any case). But for trig functions, I'm much
On Wed, May 31, 2023 at 10:40 AM Ralf Gommers
wrote:
>
>
> On Wed, May 31, 2023 at 4:19 PM Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>>
>>
>> On Wed, May 31, 2023 at 8:05 AM Robert Kern
>> wrote:
>>
>>> I w
rs,
>
> Sebastian
>
>
> ___
> NumPy-Discussion mailing list -- numpy-discussion@python.org
> To unsubscribe send an email to numpy-discussion-le...@python.org
> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
case ("start", "exact"):
> result = np.arange(start, stop + step, step)
> result[-1] = stop
> return result
> case ("stop", "open"):
> return np.flip(np.arange(stop, start, -step))
>
/gcc/Integer-Overflow-Builtins.html
https://github.com/pytorch/pytorch/blob/main/c10/util/safe_numerics.h
https://github.com/dcleblanc/SafeInt
--
Robert Kern
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email
y-Discussion mailing list -- numpy-discussion@python.org
> To unsubscribe send an email to numpy-discussion-le...@python.org
> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> Member address: robert.k...@gmail.com
>
--
Robert Kern
__
a positive use case for this behavior,
or were they just reflecting NumPy's behavior?
AFAICR, the main reasoning on our side was that there was an unambiguous
value that we _could_ return, so we might as well. And in our later
experience, it was more trouble than i
case, and that looks a little
ugly, but overall it's less cognitive load on the user to just reuse the
common convention of broadcasting than to record the special case.
--
Robert Kern
___
NumPy-Discussion mailing list -- numpy-discussion@python.or
s embedded in it. But it's absolutely a free choice for you to
precondition things for your clustering algorithm.
--
Robert Kern
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@pyt
d eigenvectors would match the
unnormalized eigenvectors of any other implementation.
--
Robert Kern
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mai
genvectors come _from_)
doesn't actually help narrow anything down. The only application of
eigenvector magnitudes of graph Laplacians that I am aware of is the
Fiedler vector, and that actually requires unit eigenvectors.
--
Robert Kern
___
Nu
I meant by the original eigenvector and sorry
> for the confusion the confusion. Most eigenvalues/eigenvalues calculators
> will give you 1 for first eigenvector
>
I'm afraid that doesn't really narrow anything down for us.
--
Robert Kern
to? It's
possible that there are specific procedures that happen to spit out vectors
that are eigenvectors but have semantics about the magnitude, but
`np.linalg.eig()` does not implement that procedure. The semantics about
the magnitude would be supplied by that specific procedure.
--
Ro
xactly `a[2, 4]`. `a[2,
4]` translates to `a.__getitem__((2, 4))`. So there's no way for the array
to know whether it got `a[2, 4]` or `a[(2, 4)]`.
--
Robert Kern
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsu
on give
some more information:
https://stackoverflow.com/questions/1303182/how-does-blas-get-such-extreme-performance
--
Robert Kern
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le
On Thu, Aug 25, 2022 at 3:47 PM Qianqian Fang wrote:
> On 8/25/22 12:25, Robert Kern wrote:
>
> I don't quite know what this means. My installed version of `jq`, for
> example, doesn't seem to know what to do with these files.
>
> ❯ jq --version
> jq-1.6
>
>
db'); *# loading/decoding*
> newx = np.concatenate(newy);*# regroup chunks*
> newx.dtype
>
>
> here are the output file sizes in bytes:
>
> 8000128 eye5chunk.npy
> 5004297 eye5chunk_bjd_raw.jdb
>
Just a note: This difference is solely due to a special r
e past, I have seen *each* of
those processes trying to use *all* of the main memory for their backlog of
old pages), but there are configuration tweaks that you can make.
--
Robert Kern
___
NumPy-Discussion mailing list -- numpy-discussion@
the data.
The alternative is to use `np.lib.format.open_memmap(filename, mode='w+',
dtype=dtype, shape=shape)`, then assign slices sequentially to the returned
memory-mapped array. A memory-mapped array is usually going to be
friendlier to whatever memory limits you are running into than
.@python.org
> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> Member address: robert.k...@gmail.com
>
--
Robert Kern
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-di
tate
I do recommend moving to passing around a Generator when you can; even in
the older system, we've always recommended passing around a RandomState
instance.
--
Robert Kern
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscrib
ned to use np.random.seed(), it is almost certainly not
one of these tasks.
If you want to describe your use case more specifically, I can give you
some more guidance on good patterns to replace it with the new system.
--
Robert Kern
___
NumPy-Discussio
, near as I can tell.
https://xarray.pydata.org/en/stable/index.html
--
Robert Kern
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailm
(c.f. discussion of a previous suggested addition[1]). This would be a good
multivariate distribution to add to scipy.stats, though.
[1] https://www.mail-archive.com/numpy-discussion@python.org/msg04724.html
--
Robert Kern
___
NumPy-Discussion mai
>
Computing the left-eigenvectors is no real problem. The underlying _GEEV
LAPACK routine can do it if asked. It's the same routine under
scipy.linalg.eig().
--
Robert Kern
___
NumPy-Discussion mailing list -- numpy-discussion@pyth
mber
of elements changes.
https://numpy.org/doc/stable/user/basics.indexing.html#boolean-array-indexing
--
Robert Kern
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.
on can be converted to Rhino NURBS or if
Rhino itself can do a periodic parametric NURBS and do the fitting itself,
I don't know.
--
Robert Kern
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an ema
ow.com/questions/20618804/how-to-smooth-a-curve-in-the-right-way
--
Robert Kern
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/nu
ent mental model about what linspace()
does.
--
Robert Kern
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com
we have no control over that inside of numpy.
--
Robert Kern
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com
bout serialization of arrays. If the json module
did have some way for us to specify a default representation for our
objects, then that would be a different matter. But for the present
circumstances, I'm not seeing a substantial benefit to moving this code
inside of numpy. Outside of numpy, yo
On Tue, Oct 19, 2021 at 8:54 PM Hongyi Zhao wrote:
> On Wed, Oct 20, 2021 at 8:29 AM Robert Kern wrote:
> >
> > On Tue, Oct 19, 2021 at 8:22 PM wrote:
> >>
> >> Do I have to use it this way?
> >
> >
> > Nothing is forcing you to, but everyo
der why you wrote
it that way and if you meant something else and will have trouble reading
your code.
--
Robert Kern
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@pytho
On Tue, Oct 5, 2021 at 4:07 AM wrote:
[spam]
Okay, now, they're just messing with us.
--
Robert Kern
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
nk" and "alias" are probably not the best analogies. The
implementation of `np.ndarry.__invert__` simply calls `np.invert` to do the
actual computation.
--
Robert Kern
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubs
ors are not names that can
be resolved to objects that can be compared with the `is` operator.
Instead, when that operator is evaluated in an expression, the Python
interpreter will look up a specially-named method on the operand object (in
this case `__invert__`
is the one that gets expaneded to `BOOL_logical_not`:
https://github.com/numpy/numpy/blob/main/numpy/core/src/umath/loops.c.src#L493-L510
--
Robert Kern
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email t
c.src#L612-L626
--
Robert Kern
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com
7;t go away for a
> while.
>
Given that we've had a literal order of magnitude more messages about the
spam than the spam itself, maybe it's just a blip?
I will suggest that spam management is probably not a strong, much less a
decisive, argument for migrating to
t, or is otherwised
>> >> deemed undesirable, perhaps just a note in the Project Description at
>> >> https://pypi.org/project/numpy/ to say that, if you want to run tests,
>> >> those two packages will be needed?
>> >>
>> >> Thanks,-- bennet
&g
less to juggle if you just compute it from the key each time.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
ngle `Generator` instance.
Instead, you can just make the ~200-1000 `Generator` instances.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
s :" He asked for the
> finger... and took the whole arm" .
>
Well, when I craft an overly-complicated system, I feel responsible to help
shepherd people along in using it well. :-)
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
ent `seed`, they
>> will get another set of results (this is why you don't want to just use
>> `SeedSequence(stronghash(key))` all by itself).
>>
>> I put the job-specific seed data ahead of the main program's seed to be
>> on the super-safe side. The spaw
ahead of the main program's seed to be on
the super-safe side. The spawning mechanism will append integers to the
end, so there's a super-tiny chance somewhere down a long line of
`root_ss.spawn()`s that there would be a collision (and I mean
super-extra-t
public; the PR is as simple as
> removing the underscores and adding a docstring.
>
Delightful!
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
nd cos() are often not implemented in
software, but by CPU instructions, so you don't want to reimplement them.
There is likely not a large accuracy win by removing the final
multiplication.
We do have sindg(), cosdg(), and tandg() in scipy.special that work
sim
ctionality (and thus all of these aliases in
`numpy.random`) are now frozen in functionality (per NEP 19), so we will
not be adding this functionality to them. If the `__array_function__`
developments eventually work out a good way to wrap methods, then we can
think about using that on
ould prefer the bottom-up description
style of naming. However, we are also in the midst of a diversifying
ecosystem of array libraries, largely driven by the ML domain, and adopting
some of that terminology when we try to enhance our interoperability wi
PI surface has declined even from its anemic starting point, now that deep
learning frameworks with ndarray-mimicking APIs have taken off.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
n out, set
> out[row,x[row]] = 1. Here is working code:
> def orthogonal_mod (x, nbits):
> out = np.zeros ((len(x), 1< for e in range (len (x)):
> out[e,x[e]] = 1
> return out
>
> Any idea to do this without an explicit python loop?
>
i = np.arange(
passing an
> array will be prohibited (as far as type checkers are concerned).*
>
> *The docs do mention that the outermost container should be a list or
> tuple anyway, so I’m not convinced that this new typing restriction would
> be a huge loss.*
>
; np.choose(a, (0,range(8)) #array([0, 1, 2, 0, 0, 0, 6, 7])
>>
>
This is equivalent to `np.choose(a, (np.zeros(8, dtype=int), range(8)))`
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
On Wed, Apr 14, 2021 at 6:16 PM Andrew Nelson wrote:
> On Thu, 15 Apr 2021 at 07:15, Robert Kern wrote:
>
>> On Wed, Apr 14, 2021 at 4:37 PM Joachim Wuttke
>> wrote:
>>
>>> Regarding numpy, I'd propose a bolder measure:
>>> To let savetxt(fname
On Wed, Apr 14, 2021 at 6:20 PM Derek Homeier <
de...@astro.physik.uni-goettingen.de> wrote:
> On 14 Apr 2021, at 11:15 pm, Robert Kern wrote:
> >
> > On Wed, Apr 14, 2021 at 4:37 PM Joachim Wuttke
> wrote:
> > Regarding numpy, I'd propose a bolder m
to follow up with a pull request, but I am unable to
> find out how numpy.savetxt is invoking gzip.
>
`savetxt` uses the abstractions in this module to invoke gzip when the
filename calls for it:
https://github.com/numpy/numpy/blob/main/numpy/lib/_datasourc
i in F]`
list comprehension for data of this size. You aren't getting any benefit
trying to convert to arrays and using our array set operations. They are
written for 1D arrays of numbers, not 2D arrays (attempting to treat them
as 1D arrays of lists) and won't really work on your data.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
On Sat, Mar 13, 2021 at 4:18 PM wrote:
> So is it right that 100 arrays of one element is smaller than one array
> with size of 100 elements?
>
No, typically the opposite is true.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-D
up
significantly more memory than the actual single number itself.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
ange is more work than changing just the function call.
>
Does it make a big difference? Per NEP 19, even in `Generator`, we do weigh
the cost of changing the stream reasonably highly. Improved accuracy is
likely worthwhile, but a minor performance improvement is proba
On Fri, Feb 12, 2021 at 3:42 PM Ralf Gommers wrote:
>
> On Fri, Feb 12, 2021 at 9:21 PM Robert Kern wrote:
>
>> On Fri, Feb 12, 2021 at 1:47 PM Ralf Gommers
>> wrote:
>>
>>>
>>> On Fri, Feb 12, 2021 at 7:25 PM Sebastian Berg <
>>> s
On Fri, Feb 12, 2021 at 1:47 PM Ralf Gommers wrote:
>
> On Fri, Feb 12, 2021 at 7:25 PM Sebastian Berg
> wrote:
>
>> On Fri, 2021-02-12 at 10:08 -0500, Robert Kern wrote:
>> > On Fri, Feb 12, 2021 at 9:45 AM Joseph Fox-Rabinovitz <
>&g
On Fri, Feb 12, 2021 at 9:45 AM Joseph Fox-Rabinovitz <
jfoxrabinov...@gmail.com> wrote:
>
>
> On Fri, Feb 12, 2021, 09:32 Robert Kern wrote:
>
>> On Fri, Feb 12, 2021 at 5:15 AM Eric Wieser
>> wrote:
>>
>>> > There might be some linear algebrai
, W, 1)` images so that they can be
> broadcast against `(H, W, 3)` RGB images.
>
Correct. If you do introduce atleast_nd(), I'm not sure why you'd deprecate
and remove the one existing function that *isn't* made redundant thereby.
--
Robert Kern
_
is ever relevant)
>
Both are probably useful. Good ideas.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
so some subtle issues involved in ziggurat method
implementations that go beyond just the marginal distributions. I'm not
sure, even, that our current implementation deals with the issues raised in
the following paper, but I'd like to do no worse.
https://www.doornik.com/researc
y what was actually done.
>
But I did run the built-in benchmark: ./runtests.py --bench
> bench_random.RNG.time_normal_zig and the results are:
>
>
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
results are:
>>
>>
>> new old
>> PCG64 589±3μs 1.06±0.03ms
>> MT19937 985±4μs 1.44±0.01ms
>> Philox 981±30μs1.39±0.01ms
>> SFC64 508±4μs 900±4μs
>&
-coded
values in TestRandomDist to match whatever you are generating.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
1 - 100 of 266 matches
Mail list logo
