On 1/19/23 11:01, Tom Lane wrote:
Andrey Lepikhov writes:
On 1/9/23 23:52, Tom Lane wrote:
BTW, if this does bring the probability of failure down to the
one-in-a-billion range, I think we could also nuke the whole
"ignore:" business, simplifying pg_regress and allowing the
random test to be
Andrey Lepikhov writes:
> On 1/9/23 23:52, Tom Lane wrote:
>> BTW, if this does bring the probability of failure down to the
>> one-in-a-billion range, I think we could also nuke the whole
>> "ignore:" business, simplifying pg_regress and allowing the
>> random test to be run in parallel with
On 1/9/23 23:52, Tom Lane wrote:
BTW, if this does bring the probability of failure down to the
one-in-a-billion range, I think we could also nuke the whole
"ignore:" business, simplifying pg_regress and allowing the
random test to be run in parallel with others.
With 'ignore' option we get used
On Tue, Jan 10, 2023 at 6:34 AM Tom Lane wrote:
>
> Dean Rasheed writes:
> > I double-checked the one-in-a-billion claim, and it looks about right
> > for each test.
>
> Thanks for double-checking my arithmetic.
>
> > The rest looks good to me, except there's a random non-ASCII character
> >
Dean Rasheed writes:
> I double-checked the one-in-a-billion claim, and it looks about right
> for each test.
Thanks for double-checking my arithmetic.
> The rest looks good to me, except there's a random non-ASCII character
> instead of a hyphen in "Kolmogorov-Smirnov" (because I copy-pasted
On Tue, 10 Jan 2023 at 08:33, Dean Rasheed wrote:
>
> The rest looks good to me, except there's a random non-ASCII character
> instead of a hyphen in "Kolmogorov-Smirnov" (because I copy-pasted the
> name from some random website).
>
Oh, never mind. I see you already fixed that.
I should finish
On Mon, 9 Jan 2023 at 23:38, Tom Lane wrote:
>
> I tried this on some 32-bit big-endian hardware (NetBSD on macppc)
> to verify my thesis that the results of random() are now machine
> independent. That part works, but the random_normal() tests didn't;
Ah yes, I wondered about that.
> I saw
Dean Rasheed writes:
> On Mon, 9 Jan 2023 at 18:52, Tom Lane wrote:
>> (We could probably go further
>> than this, like trying to verify distribution properties. But
>> it's been too long since college statistics for me to want to
>> write such tests myself, and I'm not real sure we need them.)
On Mon, 9 Jan 2023 at 18:52, Tom Lane wrote:
>
> I pushed Paul's patch with the previously-discussed tests, but
> the more I look at random.sql the less I like it. I propose
> that we nuke the existing tests from orbit and replace with
> something more or less as attached.
Looks like a definite
I wrote:
> Hmm ... it occurred to me to try the same check on the existing
> random() tests (attached), and darn if they don't fail even more
> often, usually within 50K iterations. So maybe we should rethink
> that whole thing.
I pushed Paul's patch with the previously-discussed tests, but
the
On Mon, 9 Jan 2023 at 15:26, Tom Lane wrote:
>
> Dean Rasheed writes:
> > So IMO all pseudorandom functions should share the same PRNG state and
> > seed-setting functions. That would mean they should all be in the same
> > (new) C file, so that the PRNG state can be kept private to that file.
>
Dean Rasheed writes:
> So IMO all pseudorandom functions should share the same PRNG state and
> seed-setting functions. That would mean they should all be in the same
> (new) C file, so that the PRNG state can be kept private to that file.
I agree with this in principle, but I feel no need to
On Mon, 9 Jan 2023 at 00:20, Tom Lane wrote:
>
> This version seems committable to me, barring objections.
>
Whilst I have no objection to adding random_normal(), ISTM that we're
at risk of adding an arbitrary set of random functions without a clear
idea of where we'll end up, and how they'll
I wrote:
> Also, I tried running the new random.sql regression cases over
> and over, and found that the "not all duplicates" test fails about
> one time in 10 or so. We could probably tolerate that given
> that the random test is marked "ignore" in parallel_schedule, but
> I thought it best
I wrote:
> So the problem in this patch is that it's trying to include
> utils/float.h in a src/common file, where we have not included
> postgres.h. Question is, why did you do that?
(Ah, for M_PI ... but our practice is just to duplicate that #define
where needed outside the backend.)
I spent
I wrote:
> Michael Paquier writes:
>> FYI, here is the failure:
>> [21:23:10.814] In file included from pg_prng.c:27:
>> [21:23:10.814] ../../src/include/utils/float.h:46:16: error: ‘struct
>> Node’ declared inside parameter list will not be visible outside of
>> this definition or declaration
Michael Paquier writes:
> FYI, here is the failure:
> [21:23:10.814] In file included from pg_prng.c:27:
> [21:23:10.814] ../../src/include/utils/float.h:46:16: error: ‘struct
> Node’ declared inside parameter list will not be visible outside of
> this definition or declaration [-Werror]
>
On Fri, Dec 30, 2022 at 09:58:04PM -0600, Justin Pryzby wrote:
> This is still failing tests - did you enable cirrusci on your own github
> account to run available checks on the patch ?
FYI, here is the failure:
[21:23:10.814] In file included from pg_prng.c:27:
[21:23:10.814]
On Thu, Dec 08, 2022 at 02:58:02PM -0800, Paul Ramsey wrote:
> > On Dec 8, 2022, at 2:46 PM, Justin Pryzby wrote:
> >
> > I guess make_interval is a typo ?
> >
> > This is causing it to fail tests:
> > http://cfbot.cputube.org/paul-ramsey.html
> >
>
> Yep, dumb typo, thanks! This bot is
On Wed, Dec 21, 2022 at 08:47:32AM +0100, Fabien COELHO wrote:
> From a typical use case point of view, I'd say uniform, normal and
> exponential would make sense for floats. I'm also okay with generating a
> uniform bytes pseudo-randomly.
I'd agree with this set.
> I'd be more at ease to add
On 12/19/22 04:36, Michael Paquier wrote:
On Sat, Dec 17, 2022 at 05:49:15PM +0100, Fabien COELHO wrote:
Overall, I think that there should be a clearer discussion and plan about
which random functionS postgres should provide to complement the standard
instead of going there… randomly:-)
So,
Bonjour Michaël,
Overall, I think that there should be a clearer discussion and plan about
which random functionS postgres should provide to complement the standard
instead of going there… randomly:-)
So, what does the specification tells about seeds, normal and random
functions? A bunch of
On Sat, Dec 17, 2022 at 05:49:15PM +0100, Fabien COELHO wrote:
> Overall, I think that there should be a clearer discussion and plan about
> which random functionS postgres should provide to complement the standard
> instead of going there… randomly:-)
So, what does the specification tells about
Hello Paul,
My 0.02€ about the patch:
Patch did not apply with "git apply", I had to "patch -p1 <" and there was
a bunch of warnings.
Patches compile and make check is okay.
The first patch adds empty lines at the end of "sql/random.sql", I think
that it should not.
# About
> On Dec 14, 2022, at 9:17 PM, Michael Paquier wrote:
>
> On Tue, Dec 13, 2022 at 03:51:11PM -0800, Paul Ramsey wrote:
>> Clearing up one CI failure.
>
> +-- normal values converge on stddev == 2.0
> +SELECT round(stddev(random_normal(2, 2)))
> + FROM generate_series(1, 1);
>
> I am not
On Tue, Dec 13, 2022 at 03:51:11PM -0800, Paul Ramsey wrote:
> Clearing up one CI failure.
+-- normal values converge on stddev == 2.0
+SELECT round(stddev(random_normal(2, 2)))
+ FROM generate_series(1, 1);
I am not sure that it is a good idea to make a test based on a random
behavior that
> On Dec 9, 2022, at 3:20 PM, Paul Ramsey wrote:
>
>
>
>> On Dec 9, 2022, at 9:17 AM, Paul Ramsey wrote:
>>
>>
>>> On Dec 8, 2022, at 8:29 PM, Michael Paquier wrote:
>>>
>>> On Thu, Dec 08, 2022 at 04:44:56PM -0800, Paul Ramsey wrote:
Final tme, with fixes from cirrusci.
>>>
>>>
> On Dec 9, 2022, at 9:17 AM, Paul Ramsey wrote:
>
>
>> On Dec 8, 2022, at 8:29 PM, Michael Paquier wrote:
>>
>> On Thu, Dec 08, 2022 at 04:44:56PM -0800, Paul Ramsey wrote:
>>> Final tme, with fixes from cirrusci.
>>
>> Well, why not. Seems like you would use that a lot with PostGIS.
>>
> On Dec 9, 2022, at 11:10 AM, Paul Ramsey wrote:
>
>
>
>> On Dec 9, 2022, at 11:01 AM, Joe Conway wrote:
>>
>> On 12/9/22 13:51, Paul Ramsey wrote:
On Dec 9, 2022, at 10:39 AM, Mark Dilger
wrote:
> On Dec 8, 2022, at 1:53 PM, Paul Ramsey wrote:
> Just a utility
> On Dec 9, 2022, at 11:01 AM, Joe Conway wrote:
>
> On 12/9/22 13:51, Paul Ramsey wrote:
>>> On Dec 9, 2022, at 10:39 AM, Mark Dilger
>>> wrote:
On Dec 8, 2022, at 1:53 PM, Paul Ramsey wrote:
Just a utility function to generate random numbers from a normal
distribution. I
On 12/9/22 13:51, Paul Ramsey wrote:
On Dec 9, 2022, at 10:39 AM, Mark Dilger wrote:
On Dec 8, 2022, at 1:53 PM, Paul Ramsey wrote:
Just a utility function to generate random numbers from a normal
distribution. I find myself doing this several times a year, and I am
sure I must not be the
> On Dec 9, 2022, at 10:39 AM, Mark Dilger wrote:
>
>> On Dec 8, 2022, at 1:53 PM, Paul Ramsey wrote:
>>
>> Just a utility function to generate random numbers from a normal
>> distribution. I find myself doing this several times a year, and I am
>> sure I must not be the only one.
>
>
> On Dec 8, 2022, at 1:53 PM, Paul Ramsey wrote:
>
> Just a utility function to generate random numbers from a normal
> distribution. I find myself doing this several times a year, and I am
> sure I must not be the only one.
Thanks for the patch. What do you think about these results?
+--
> On Dec 8, 2022, at 8:29 PM, Michael Paquier wrote:
>
> On Thu, Dec 08, 2022 at 04:44:56PM -0800, Paul Ramsey wrote:
>> Final tme, with fixes from cirrusci.
>
> Well, why not. Seems like you would use that a lot with PostGIS.
>
> #include /* for ldexp() */
> +#include
On Thu, Dec 08, 2022 at 04:44:56PM -0800, Paul Ramsey wrote:
> Final tme, with fixes from cirrusci.
Well, why not. Seems like you would use that a lot with PostGIS.
#include /* for ldexp() */
+#include /* for DBL_EPSILON */
And be careful with the order here.
> On Dec 8, 2022, at 3:25 PM, Paul Ramsey wrote:
>
>>
>> Revised patch attached.
>
> And again, because I think I missed one change in the last one.
>
>
Final tme, with fixes from cirrusci.
random_normal_04.patch
Description: Binary data
>
> Revised patch attached.
And again, because I think I missed one change in the last one.
random_normal_03.patch
Description: Binary data
> On Dec 8, 2022, at 2:46 PM, Justin Pryzby wrote:
>
> I guess make_interval is a typo ?
>
> This is causing it to fail tests:
> http://cfbot.cputube.org/paul-ramsey.html
>
Yep, dumb typo, thanks! This bot is amazeballs, thank you!
P.
> On Dec 8, 2022, at 2:40 PM, David G. Johnston
> wrote:
>
> On Thu, Dec 8, 2022 at 2:53 PM Paul Ramsey wrote:
>
> random_normal(stddev float8 DEFAULT 1.0, mean float8 DEFAULT 0.0)
>
> Any particular justification for placing stddev before mean? A brief survey
> seems to indicate other
On Thu, Dec 08, 2022 at 01:53:23PM -0800, Paul Ramsey wrote:
> Just a utility function to generate random numbers from a normal
> distribution. I find myself doing this several times a year, and I am
> sure I must not be the only one.
>
> random_normal(stddev float8 DEFAULT 1.0, mean float8
On Thu, Dec 8, 2022 at 2:53 PM Paul Ramsey
wrote:
>
> random_normal(stddev float8 DEFAULT 1.0, mean float8 DEFAULT 0.0)
>
Any particular justification for placing stddev before mean? A brief
survey seems to indicate other libraries, as well as (at least for me)
learned convention, has the mean
Just a utility function to generate random numbers from a normal
distribution. I find myself doing this several times a year, and I am
sure I must not be the only one.
random_normal(stddev float8 DEFAULT 1.0, mean float8 DEFAULT 0.0)
random_normal_01.patch
Description: Binary data
42 matches
Mail list logo
