Re: [Numpy-discussion] proposal: smaller representation of string arrays
I suggest a new data type 'text[encoding]', 'T'. 1. text can be cast to python strings via decoding. 2. Conceptually casting to python bytes first cast to a string then calls encode(); the current encoding in the meta data is used by default, but the new encoding can be overridden. I slightly favour 'T16' as a fixed size, text record backed by 16 bytes. This way over-allocation is forcefully delegated to the user, simplifying numpy array. Yu On Thu, Apr 20, 2017 at 12:17 PM, Robert Kern wrote: > On Thu, Apr 20, 2017 at 12:05 PM, Stephan Hoyer wrote: >> >> On Thu, Apr 20, 2017 at 11:53 AM, Robert Kern >> wrote: >>> >>> I don't know of a format off-hand that works with numpy uniform-length >>> strings and Unicode as well. HDF5 (to my recollection) supports arrays of >>> NULL-terminated, uniform-length ASCII like FITS, but only variable-length >>> UTF8 strings. >> >> >> HDF5 supports two character sets, ASCII and UTF-8. Both come in fixed and >> variable length versions: >> https://github.com/PyTables/PyTables/issues/499 >> https://support.hdfgroup.org/HDF5/doc/Advanced/UsingUnicode/index.html >> >> "Fixed length UTF-8" for HDF5 refers to the number of bytes used for >> storage, not the number of characters. > > Ah, okay, I was interpolating from a quick perusal of the h5py docs, which > of course are also constrained by numpy's current set of dtypes. The > NULL-terminated ASCII works well enough with np.string's semantics. > > -- > Robert Kern > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] NumPy default citation
str(numpy.version.citation) and numpy.version.citation.to_bibtex()? On Tue, Sep 5, 2017 at 2:15 PM, Paul Hobson wrote: > Just a thought that popped into my head: > It'd be cool with the sci/py/data stack had a convention of > .citation so I could look it up w/o leaving my jupyter notebook :) > > -paul > > On Tue, Sep 5, 2017 at 1:29 PM, Stefan van der Walt > wrote: >> >> On Tue, Sep 5, 2017, at 13:25, Charles R Harris wrote: >> >> >> On Tue, Sep 5, 2017 at 12:36 PM, Stefan van der Walt >> wrote: >> >> Shall we add a citation to Travis's "Guide to NumPy (2nd ed.)" on both >> >> >> What is the citation for? >> >> >> It's the suggested reference to add to your paper, if you use the NumPy >> package in your work. >> >> Stéfan >> >> >> ___ >> NumPy-Discussion mailing list >> NumPy-Discussion@python.org >> https://mail.python.org/mailman/listinfo/numpy-discussion >> > > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Deprecate matrices in 1.15 and remove in 1.17?
An NEP on utility functions for structured array definitely sounds appealing to me. On Thu, Nov 30, 2017 at 2:00 PM, Stefan van der Walt wrote: > On Thu, Nov 30, 2017, at 12:02, Marten van Kerkwijk wrote: >> I think Josef specifically meant `recarrays`, which give access to >> elements of a structured array via attribute access. I'd tend to agree >> with him that those turned out not to be such a great idea. But (I >> think) nobody is arguing we should get rid of arrays with structured >> dtypes - I use them regularly myself too. > > Ah, okay, that makes sense! > > Which reminds me: while these are quite useful, they're not always > particularly pleasant to use. A good first improvement would be to > allow columnar printing, and a few utility functions to give you some of > the basic functionality of pandas (calculating descriptive statistics > like mean, dropping NaN rows, some equivalent of groupby). All these > are only a few lines of Python, but can be annoying to figure out. If > this sounds appealing, I'd be willing to put together a small NEP. > > Stéfan > ___ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Helper function for assignment from other structured arrays
Hi, Assignment between structured arrays are matching by the order of fields, not by names of fields. Is there a recommended way of assignment by matching field names? I can see one way is to explicitly looping over the names; another possibility is to use the field names of the target array to index the source array. It would be nice if a recommended practice is provided as example near the documentation on the topic: https://docs.scipy.org/doc/numpy/user/basics.rec.html#assignment-from-other-structured-arrays Thanks, Yu ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Add guaranteed no-copy to array creation and reshape?
Hi, Was it ever brought up the possibility of a new array class (ndrefonly, ndview) that is strictly no copy? All operations on ndrefonly will return ndrefonly and if the operation cannot be completed without making a copy, it shall throw an error. On the implementation there are two choices if we use subclasses: - ndrefonly can be a subclass of ndarray. The pattern would be subclass limiting functionality of super, but ndrefonly is a ndarray. - ndarray as a subclass of ndarray. Subclass supplements functionality of super. : ndarray will not throw an error when a copy is necessary. However ndarray is not a ndarray. If we want to be wild they do not even need to be subclasses of each other, or maybe they shall both be subclasses of something more fundamental. - Yu On Fri, Dec 28, 2018 at 5:45 AM Sebastian Berg wrote: > On Thu, 2018-12-27 at 17:45 -0800, Nathaniel Smith wrote: > > On Thu, Dec 27, 2018 at 3:27 PM Juan Nunez-Iglesias < > > jni.s...@gmail.com> wrote: > > > On Fri, Dec 28, 2018, at 3:40 AM, Sebastian Berg wrote: > > > > > > > It’s consistent with np.newaxis in spelling (modulo the _) > > > > If mistyped, it can be caught easily by IDEs. > > > > It’s typeable with mypy, unlike constant string literals which > > > > currently aren’t > > > > If code written against new numpy is run on old numpy, it will > > > > error > > > > rather than doing the wrong thing > > > > > > I am not sure I think that the above are too strong arguments, > > > since it > > > is not what is typically done for keywords (nobody suggests np.CLIP > > > instead of "clip"). Unless you feel this is different because it is > > > a > > > mix of strings and bools here? > > > > > > > > > :+1: to Eric's list. I don't think it's different because of the > > > mix, I think it's different because deprecating things is painful. > > > But now that we have good typing in Python, I think of string > > > literals as an anti-pattern going forward. > > > > I've certainly seen people argue that it's better to use proper > > enum's > > in this kind of case instead of strings. The 'enum' package is even > > included in the stdlib on all our supported versions now: > > https://docs.python.org/3/library/enum.html > > > > I am sympathetic with that, but it is something we (or scipy, etc.) > currently simply do not use, so I am not sure that I think it has much > validity at this time. That is least unless we agree to aim to use this > more generally in the future. > > > I guess another possibility to throw out there would be a second > > kwarg, require_view=False/True. > > > > My first gut feeling was that it is clumsy at least for `reshape`, but > one will always only use one of the two arguments at a time. > The more I look at it, the better the suggestion seems. Plus it reduces > the possible `copy=False` not meaning "never" confusion. > > I think with a bit more pondering, that will become my favorite > solution. > > - Sebastian > > > > -n > > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Add guaranteed no-copy to array creation and reshape?
Hi Todd, I agree a flag is more suitable than classes. I would add another bonus of a flag than a function argument is to avoid massive contamination of function signatures for a global variation of behavior that affects many functions. Yu On Wed, Jan 9, 2019 at 11:34 PM Todd wrote: > On Mon, Jan 7, 2019, 14:22 Feng Yu >> Hi, >> >> Was it ever brought up the possibility of a new array class (ndrefonly, >> ndview) that is strictly no copy? >> >> All operations on ndrefonly will return ndrefonly and if the operation >> cannot be completed without making a copy, it shall throw an error. >> >> On the implementation there are two choices if we use subclasses: >> >> - ndrefonly can be a subclass of ndarray. The pattern would be subclass >> limiting functionality of super, but ndrefonly is a ndarray. >> - ndarray as a subclass of ndarray. Subclass supplements functionality of >> super. : ndarray will not throw an error when a copy is necessary. However >> ndarray is not a ndarray. >> >> If we want to be wild they do not even need to be subclasses of each >> other, or maybe they shall both be subclasses of something more >> fundamental. >> >> - Yu >> > > I would prefer a flag for this. Someone can make an array read-only by > setting `arr.flags.writable=False`. So along those lines, we could have a > `arr.flags.copyable` flag that if set to `False` would result in an error > of any operation tried to copy the data. > >> ___ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Add guaranteed no-copy to array creation and reshape?
Eric, I agree these are questions that shall be answered. I think issues you raised are toward functions always make a copy -- combining them with NEVERCOPY does sound sane. Your argument is that If the atom of the new behavior is per method, then there is no need to worry about those functions that does not sound sane when combined with NEVERCOPY. Here is a proposal that may address your concerns: 1. The name of the flag does not need to be NEVERCOPY -- especially it sounds insane combined with many methods. I think something like KEEPBASE may be easier to reason. The name KEEPBASE alwsy suggests it shall not be set on an object where base is None; this feature may simplify the matter. 2. Methods that creates copy shall always create a copy, regardless of a flag -- that's the definition of copy. (np.copy) KEEPBASE shall only affect methods that creates a new object object, which may reference the provided base or create a new base. 3. Functions that are not a ndarray method, shall ignore the flag, unless specified otherwise. (np.array) 4. arr + 0 when arr is KEEPBASE. It depends on if we think this triggered np.add(), or ndarray.__add__. I think ndarray.__add__ is a shortcut to call the ufunc np.add(). Thus the result of arr + 0 shall be the behavior on the ufunc np.add, which shall ignore the flag. Notice that in memory tight situations, users can already use inplace operations to avoid copies. This verbose but highly controlled syntax may be preferable than inferring an automated behavior that relies on KEEPBASE of arguments. 5. I think on the operation level, the difference between subclassing(flags) and function arguments would be: array.view(keepbase=True).reshape(-1) vs array.reshape(-1, keepbase=True) The gain is that no array method needs to be modified. The control can still be at the level of the algorithm. On Sat, Jan 12, 2019 at 11:22 PM Eric Wieser wrote: > I don’t think a NEVERCOPY entry in arr.flags would make much sense. > Is this really a sensible limitation to put on how data gets used? Isn’t > it up to the algorithm to decide whether to copy its data, not the original > owner of the data? > > It also leads to some tricky questions of precedence - would np.array(arr, > copy=True) respect the flag or the argument? How about np.array(arr)? Is arr > + 0 considered a copy? > By keeping it as a value passed in via a copy= kwarg, we don’t need to > answer any of those questions. > > Eric > > On Thu, 10 Jan 2019 at 20:28 Ralf Gommers ralf.gomm...@gmail.com > <http://mailto:ralf.gomm...@gmail.com> wrote: > > On Thu, Jan 10, 2019 at 11:21 AM Feng Yu wrote: >> >>> Hi Todd, >>> >>> I agree a flag is more suitable than classes. >>> >>> I would add another bonus of a flag than a function argument is to avoid >>> massive contamination of function signatures for a global variation of >>> behavior that affects many functions. >>> >> >> I like this suggestion. Copy behavior fits very nicely with existing >> flags (e.g. UPDATEIFCOPY, WRITEABLE) and avoids both namespace pollution >> and complication docstrings. >> >> Ralf >> >> >>> Yu >>> >>> On Wed, Jan 9, 2019 at 11:34 PM Todd wrote: >>> >>>> On Mon, Jan 7, 2019, 14:22 Feng Yu >>> >>>>> Hi, >>>>> >>>>> Was it ever brought up the possibility of a new array class >>>>> (ndrefonly, ndview) that is strictly no copy? >>>>> >>>>> All operations on ndrefonly will return ndrefonly and if the operation >>>>> cannot be completed without making a copy, it shall throw an error. >>>>> >>>>> On the implementation there are two choices if we use subclasses: >>>>> >>>>> - ndrefonly can be a subclass of ndarray. The pattern would be >>>>> subclass limiting functionality of super, but ndrefonly is a ndarray. >>>>> - ndarray as a subclass of ndarray. Subclass supplements functionality >>>>> of super. : ndarray will not throw an error when a copy is necessary. >>>>> However ndarray is not a ndarray. >>>>> >>>>> If we want to be wild they do not even need to be subclasses of each >>>>> other, or maybe they shall both be subclasses of something more >>>>> fundamental. >>>>> >>>>> - Yu >>>>> >>>> >>>> I would prefer a flag for this. Someone can make an array read-only by >>>> setting `arr.flags.writable=False`. So along those lines, we could have a >>>> `arr.flags.copyable` flag that if set to `False` wo
Re: [Numpy-discussion] Numpy FFT normalization options issue (addition of new option)
Hi, 1. The wikipedia pages of CFT and DFT refer to norm='ortho' as 'unitary'. Since we are in general working with complex numbers, I do suggest unitary over ortho. (https://en.wikipedia.org/wiki/Fourier_transform#Other_conventions) and ( https://en.wikipedia.org/wiki/Discrete_Fourier_transform#The_unitary_DFT) 2. I share Chris's concern about 'inverse', but I could not come up with a nice name. 3. Now that we are at this, should we also describe the corresponding continuum limit of FFT and iFFT in the documentation? A paragraph doing so could potentially also help people diagnose some of the normalization factor errors. I assumed it is common that one needs to translate a CFT into DFT when coding a paper up, and the correct compensation to the normalization factors will surface if one does the math. -- I had the impression 1 / N corresponds to 1 / 2pi if the variable is angular frequency, but it's been a while since I did that last time. - Yu On Fri, Jun 5, 2020 at 1:16 PM cvav wrote: > Ross Barnowski wrote > > One potential issue that stood out to me was the name of the new keyword > > option. At face value, "inverse" seems like a poor choice given the > > established use of the term in Fourier analysis. For example, one might > > expect `norm="inverse"` to mean that scaling is applied to the ifft, when > > this is actually the current default. > > Yes that's true, the keyword argument name "inverse" is certainly something > I don't feel sure about. It'd be nice if everyone interested could suggest > names that make sense to them and what's their rationale behind them, so > that we pick something that's as self explanatory as possible. > > My thinking was to indicate that it's the opposite scaling to the default > option "None", so maybe something like "opposite" or "reversed" could be > other choices. Otherwise, we can find something that directly describes the > scaling and not its relationship to the default option. > > Chris > > > > -- > Sent from: http://numpy-discussion.10968.n7.nabble.com/ > ___ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy FFT normalization options issue (addition of new option)
Your approach sounds good to me. Thanks, Yu On Tue, Jun 23, 2020 at 11:51 AM Chris Vavaliaris wrote: > Chris Vavaliaris wrote > > Hello, > > > > - my first reaction would be that the less argument names we change at a > > time the better, so that we don't confuse people or cause codes written > > with > > previous NumPy versions to break. Personally I always think of "ortho" as > > "orthonormal", which immediately brings "unit norm" to mind, but I have > no > > problem whatsoever with changing its name to "unitary" or maybe "unit", > > which I'd probably choose if we were writing the routines from scratch. > > > > - In terms of the "inverse" name option, I do believe that it'd be a > > confusing choice since "inverse" is used to describe the inverse FFT; if > > we > > choose to stick with a name that's based on the fact that this scaling is > > opposite to the "norm=None" option, then I'd suggest "norm=opposite" as a > > better choice. However, following Ross' comment, I think we could choose > a > > name based on the fact that the forward transform is now scaled by `n`, > > instead of the backward one as in the default "norm=None". In this case, > > I'd > > suggest "norm=forward", which we can also nicely abbreviate to the > > 4-character form "norm=forw" if desirable. > > > > Chris > > > > > > Feng Yu wrote > >> Hi, > >> > >> 1. The wikipedia pages of CFT and DFT refer to norm='ortho' as > 'unitary'. > >> Since we are in general working with complex numbers, I do suggest > >> unitary > >> over ortho. > >> (https://en.wikipedia.org/wiki/Fourier_transform#Other_conventions) > and ( > >> > https://en.wikipedia.org/wiki/Discrete_Fourier_transform#The_unitary_DFT) > >> > >> 2. I share Chris's concern about 'inverse', but I could not come up with > >> a > >> nice name. > >> > >> 3. Now that we are at this, should we also describe the corresponding > >> continuum limit of FFT and iFFT in the documentation? > >> > >> A paragraph doing so could potentially also help people diagnose some of > >> the normalization factor errors. I assumed it is common that one needs > to > >> translate a CFT into DFT when coding a paper up, and the correct > >> compensation to the normalization factors will surface if one does the > >> math. -- I had the impression 1 / N corresponds to 1 / 2pi if the > >> variable > >> is angular frequency, but it's been a while since I did that last time. > >> > >> - Yu > >> > >> NumPy-Discussion mailing list > > > >> NumPy-Discussion@ > > > >> https://mail.python.org/mailman/listinfo/numpy-discussion > > > > > > > > > > > > -- > > Sent from: http://numpy-discussion.10968.n7.nabble.com/ > > ___ > > NumPy-Discussion mailing list > > > NumPy-Discussion@ > > > https://mail.python.org/mailman/listinfo/numpy-discussion > > Hello all, > the discussion on this topic has been stagnant for the past couple of > weeks, > so I just wanted to ask if anyone has any alternative names for the new > normalization option that would like to share. > > If not, I'd suggest that we move on with "norm=forward", which seems to be > a > more straightforward choice than the "norm=inverse" naming alternative. I > can wait a couple of days for possible new recommendations to be submitted, > and will then recommit to the open PR to account for the new kwarg name. > > In terms of the name for the "norm=ortho" option, I suggest that we keep it > as is for now so that we don't introduce two API changes at once. If > desired, we can discuss it separately and open a new PR introducing a name > such as "norm=unitary" or "unit" as recommended in previous messages. I'm > happy to handle that if you think it'd be a useful change. > > Chris > > > > > > -- > Sent from: http://numpy-discussion.10968.n7.nabble.com/ > ___ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] NumPy dtype API improvement suggestion
Hi,
Would it be possible to also allow a byte offset for the field? e.g.,
class Point(np.struct):
x: np.field('i4', offset=8)
y: np.field('
wrote:
> Better would be to have an object like NamedTuple in typing that would
> allow
>
> class Point(DType):
> x: np.int16
> y: np.int16
>
>
>
> On Sun, Jul 26, 2020 at 3:22 PM Eyal Kutz wrote:
>
>> I am interested in suggesting an API improvement for NumPy.
>> I wish to make it so that the following code:
>> @np.dtype
>> class Point:
>> x: np.int16
>> y: np.int16
>> would be equivalent to the following code:
>> Point = np.dtype([('x', np.int16), ('y', np.int16)])
>>
>> I am willing to submit the code changes required to make this happen.
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@python.org
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Re: Dropping the pdf documentation.
Furthermore, the PDF docs of numpy (and maybe scipy) can be stripped to a
separate project and put on a separate release cycle, not necessarily
tracking the releases.
On Mon, May 23, 2022 at 10:37 AM Ralf Gommers
wrote:
>
>
> On Mon, May 23, 2022 at 10:21 AM Lev Maximov
> wrote:
>
>> What do you guys think of the chm format ("windows help")? This offline
>> documentation format is shipped with all python releases (eg
>> https://www.python.org/downloads/release/python-3913/).
>> It is simple to build from a hierarchy of html files, it is downloadable,
>> searchable, bookmarkable, has index, supports hyperlinks, can be opened on
>> linux as well.
>>
>> One downside of it is that recent Windows versions (=Windows 10) block
>> the "execution" of this file if downloaded from "untrusted source"
>> (=internet), so it needs a checkbox in file properties
>> to lift this "security block".
>>
>> Afaik, NumPy used to ship docs in this format many years ago, but then
>> dropped its support.
>>
>
> Indeed. It's much more niche than pdf, so I'd prefer to not consider it.
> You can easily build it locally though if you'd use it personally.
>
>
>
>>
>> Best regards,
>> Lev
>>
>> On Mon, May 23, 2022 at 1:33 PM Ralf Gommers
>> wrote:
>>
>>>
>>>
>>> On Mon, May 23, 2022 at 6:51 AM Matti Picus
>>> wrote:
>>>
On 23/5/22 01:51, Rohit Goswami wrote:
>
> Being very hard to read should not be reason enough to stop
generating
> them. In places with little to no internet connectivity often the PDF
> documentation is invaluable.
>
> I personally use the PDF documentation both on my phone and e-reader
> when I travel simply because it is more accessible and has better
> search capabilities.
>
> It is true that SciPy has removed them, but that doesn't necessarily
> mean we need to follow suit. Especially relevant (IMO) is that large
> parts of the NumPy documentation still make sense when read
> sequentially (going back to when it was at some point partially
kanged
> from Travis' book).
>
> I'd be happy to spend time (and plan to) working on fixing concrete
> issues other than straw-man and subjective arguments.
>
> Personally I'd like to see the NumPy documentation have PDFs in a
> fashion where each page / chapter can be downloaded individually.
>
> -- Rohit
>
> P.S.: If we have CI timeout issues, for the PDF docs we could also
> have a dedicated repo and only build for releases.
>
> P.P.S: FWIW the Python docs are also still distributed in PDF form.
>
> On 22 May 2022, at 21:41, Stephan Hoyer wrote:
>
> +1 let’s drop the PDF docs. They are already very hard to read.
>
> On Sun, May 22, 2022 at 1:06 PM Charles R Harris
> wrote:
>
> Hi All,
>
> This is a proposal to drop the generation of pdf documentation
> and only generate the html version. This is a one way change
> due to the difficulty maintaining/fixing the pdf versions. See
> minimal discussion here
> <
https://github.com/numpy/numpy/issues/21557#issuecomment-1133920412>.
>
> Chuck
>
Thanks Rohit for the offer to take on this project.
I don't think we should block the release on the existence of PDF
documentation. It is a "nice to have", not a hard requirement.
One strategy to discover problems with the PDF builds in CI would be to
add a weekly build of PDF.
>>>
>>> That would just mean more CI maintenance/breakage, that the same folks
>>> who always take care of CI issues inevitably are going to have to look at.
>>>
>>> I'm +1 for removing pdf builds, they are not worth the maintainer effort
>>> - we shouldn't put them in CI, and they break at release time too often. It
>>> will remain possible for interested users to rebuild the docs themselves -
>>> and we can/will accept patches for docstring issues that trip up the pdf
>>> but not the html build. That's the same support level we have for other
>>> things that we do not run in CI.
>>>
>>> When we removed the SciPy pdf docs, the one concern was that there was
>>> no longer an offline option (by Juan, a very knowledgeable user and
>>> occasional contributor). So I suspect that most of the pdf downloads are
>>> for users who want that offline option, but we don't tell them that
>>> html+zip is the preferred one.
>>>
>>> Another benefit of removal is to slim down our dev Docker images a lot -
>>> right now the numpy-dev image is 300 MB larger than the scipy-dev one
>>> because of the inclusion of TeX Live.
>>>
>>
> I'm not so interested in the detailed discussion later on in this thread
> to be honest. Let me propose a simple solution that should make everyone
> happy:
> 1. We drop pdf builds in CI, the release process and the Docker image, but
> keep support
