[Numpy-discussion] Re: No credits left in travis for 1.22.0 release

[Peter Cock]

Hello Matti, Charles,

I'm a minor numpy contributor but mostly follow the mailing list with an eye
on any impacts downstream for Biopython. Like numpy and scipy etc, we
had been using TravisCI to build our wheels:

https://github.com/biopython/biopython-wheels

Lots of other projects using multibuild are in a similar situation. It
looks like
we will probably migrate to GitHub actions, but using TravisCI for one
more release is tempting if getting credits is straight forward.

Do you have any advice on how to request TravisCI credits (I'd be happy to
discuss off list), or would you advise us to focus on the migration now (which
pushes back any release plans).

Thank you,

Peter

On Fri, Dec 31, 2021 at 8:36 PM Charles R Harris
 wrote:
>
>
>
> On Fri, Dec 31, 2021 at 12:30 PM matti picus  wrote:
>>
>> We are back in business with 100k credits.
>> Matti
>>
>
> Thanks Matti.
>
> 
>
> Chuck
>
> ___
> 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: p.j.a.c...@googlemail.com
___
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

[Numpy-discussion] Re: No credits left in travis for 1.22.0 release

[Matti Picus]

On 6/1/22 2:15 pm, Peter Cock wrote:


Hello Matti, Charles,

...

Do you have any advice on how to request TravisCI credits (I'd be happy to
discuss off list), or would you advise us to focus on the migration now (which
pushes back any release plans).

Thank you,

Peter

Here is what travis-ci wrote me when I asked about free credits for 
multibuild:


---

We offer an Open Source Subscription for free to non-commercial 
open-source projects. To qualify for an Open Source subscription, the 
project must meet the following requirements:


 * You are a project lead or regular committer (latest commit in the
   last month)
 * Project must be at least 3 months old and is in active development
   (with regular commits and activity)
 * Project meets the OSD  specification
 * Project must not be an expressly commercial project
 * Project can not provide commercial services or distribute paid
   versions of the software





So I wrote to supp...@travis-ci.com:

-

I am one of the project leads and the number 4 contributor to the 
project in 2021


https://github.com/multi-build/multibuild/graphs/contributors?from=2021-01-04&to=2021-10-13&type=c 



The graph above shows that the project is under active development.

The license for the project is BSD 2

https://github.com/multi-build/multibuild/blob/devel/LICENSE

The project is a support framework for open source projects and provides 
no commercial services or paid versions.


Matti

___
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

[Numpy-discussion] Re: No credits left in travis for 1.22.0 release

[Peter Cock]

That's great, thanks! Hopefully I'll get time to sort that out soon.

Peter

On Thu, Jan 6, 2022 at 3:23 PM Matti Picus  wrote:
>
> On 6/1/22 2:15 pm, Peter Cock wrote:
>
> > Hello Matti, Charles,
> >
> > ...
> >
> > Do you have any advice on how to request TravisCI credits (I'd be happy to
> > discuss off list), or would you advise us to focus on the migration now 
> > (which
> > pushes back any release plans).
> >
> > Thank you,
> >
> > Peter
> >
> Here is what travis-ci wrote me when I asked about free credits for
> multibuild:
>
> ---
>
> We offer an Open Source Subscription for free to non-commercial
> open-source projects. To qualify for an Open Source subscription, the
> project must meet the following requirements:
>
>   * You are a project lead or regular committer (latest commit in the
> last month)
>   * Project must be at least 3 months old and is in active development
> (with regular commits and activity)
>   * Project meets the OSD  specification
>   * Project must not be an expressly commercial project
>   * Project can not provide commercial services or distribute paid
> versions of the software
>
> 
>
>
>
> So I wrote to supp...@travis-ci.com:
>
> -
>
> I am one of the project leads and the number 4 contributor to the
> project in 2021
>
> https://github.com/multi-build/multibuild/graphs/contributors?from=2021-01-04&to=2021-10-13&type=c
>
>
> The graph above shows that the project is under active development.
>
> The license for the project is BSD 2
>
> https://github.com/multi-build/multibuild/blob/devel/LICENSE
>
> The project is a support framework for open source projects and provides
> no commercial services or paid versions.
> 
> Matti
>
___
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

[Numpy-discussion] Re: call for contributions – content writers for the NumPy newsletter

[Inessa Pawson]

Hi, Danuta!
This sounds great! I’m excited to team up with you once again!

Every good wish,
Inessa

Inessa Pawson
Contributor Experience Lead | NumPy
ine...@albuscode.org
___
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

[Numpy-discussion] Re: representation of valid float type range

[alejandro . giacometti]

Thanks for your answer.

I think i understand it - is it that `f64_info.max - f64_info.min` does not fit 
in float64? because it approximates `2 * f64_info.max`?

In that case, I agree with Klaus, linspace should be able to handle this?
___
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

[Numpy-discussion] Re: representation of valid float type range

[alejandro . giacometti]

I'm not sure I know what that is? do you have a reference I can follow?
___
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

[Numpy-discussion] Re: representation of valid float type range

[Robert Kern]

On Thu, Jan 6, 2022 at 4:43 PM  wrote:

> Thanks for your answer.
>
> I think i understand it - is it that `f64_info.max - f64_info.min` does
> not fit in float64? because it approximates `2 * f64_info.max`?
>

Well, it "fits" into a float64 by becoming `inf`, which is a valid float64
value, just one that has particular consequences.

In that case, I agree with Klaus, linspace should be able to handle this?
>

I don't particularly agree that linspace() ought to add special-case logic
to handle this. It would be difficult to write logic that reliably
recognizes all the ways that something like this is actually the case and
then does something sensible to recover from it. Lev showed how you can
manually do something sorta reasonable for `np.linspace(f64_info.min,
f64_info.max, num)` because the endpoints are symmetric around 0, but there
is nothing that can really be done for the asymmetric case.

Floating point arithmetic has its limits, and playing with values near the
boundaries is going to make you run into those limits. I would rather have
linspace() do something consistent that gives non-useful results in these
boundary edge cases than try to do a bunch of different logic in these
outer limits. The utility of getting "sensible" results for the extreme
results is fairly limited (not least because any downstream computation
will also be very likely to generate NaNs and infs), so I would happily
trade that to have a more consistent 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