[Numpy-discussion] Re: `dtype` parameter in `clip` method

[Ralf Gommers]

On Thu, Mar 16, 2023 at 7:57 PM Sergio Callegari 
wrote:

> I am trying to use the `clip` method to transform floats to integers with
> clipping. I was expecting to be able to do both the clipping and the type
> conversion at once, passing the `dtype` parameter to `clip`, together with
> a suitable `casting` param. Such expectation came from reading the
> documentation of the `dtype` param for u-funcs that states that this
> parameter "Overrides the DType of the output arrays". Unfortunately, using
> the `dtype` parameter with `clip` causes the type conversion to be
> practiced before the clipping, not after it.  Is this how it is expected to
> operate?
>

Yes, that's how it is working. The docs (and design) are indeed confusing -
the `dtype` keyword doesn't quite do what you'd expect here. It selects the
internal loops for the specified dtype, rather than only changing the
output dtype. So you get this kind of weirdness:

>>> x = np.array([1, 5, 259], dtype=np.uint16)
>>> np.clip(x, 3, 200, dtype=np.uint8)
array([3, 5, 3], dtype=uint8)
>>> np.clip(x, 3, 200).astype(np.uint8)
array([  3,   5, 200], dtype=uint8)

I don't think the behavior can be changed. The docs already hint at what is
happening: "The exact calculation DTypes chosen may depend on the ufunc and
the inputs may be cast to this DType to perform the calculation."

Cheers,
Ralf
___
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] 15ᵗʰ Advanced Scientific Programming in Python in Heraklion, Crete, Greece, 27 August – 3 September,2023

[Tiziano Zito]

ASPP2023: 15ᵗʰ Advanced Scientific Programming in Python


a Summer School 

https://aspp.school

Scientists spend more and more time writing, maintaining, and
debugging software. While techniques for doing this efficiently have
evolved, only few scientists have been trained to use them. As
a result, instead of doing their research, they spend far too much
time writing deficient code and reinventing the wheel. In this
course we will present a selection of advanced programming
techniques and best practices which are standard in the industry,
but especially tailored to the needs of a programming scientist.
Lectures are interactive and allow students to acquire direct
hands-on experience with the topics. Students will work in pairs
throughout the school and will team up to practice the newly learned
skills in a real programming project — an entertaining computer
game.

We use the Python programming language for the entire course. Python
works as a simple programming language for beginners, but more
importantly, it also works great in scientific simulations and data
analysis. Python is the standard tool for the programming scientist
due to clean language design, ease of extensibility, and the great
wealth of open source libraries for scientific computing and data
visualization.

This school is targeted at PhD students, postdocs and more senior
researchers from all areas of science. Competence in Python or in
another language such as Java, JavaScript, C/C++, MATLAB, or R is
absolutely required. Basic knowledge of Python and git or another
version control system is assumed. Participants without any prior
experience with Python or git should work through the proposed
introductory material before the course.

We care for diversity and inclusion, and strive for a welcoming
atmosphere to programming scientists of all levels. In particular,
we have focused on recruiting an international and gender-balanced
pool of students.

Date & Location
===
27 August – 3 September, 2023. Heraklion, Crete, Greece

Application
===
You can apply online: https://aspp.school

Application deadline: 23:59 UTC, Monday 1 May, 2023. There will be
no deadline extension, so be sure to apply on time. Invitations and
notification of rejection will be sent by Sunday 28 May, 2023.

Participation is for free, i.e. no fee is charged! Participants
however should take care of travel, living, and accommodation
expenses by themselves. 

Program
===
• Large-scale collaborative scientific code development with git and GitHub
• Best practices in data visualization
• Testing and debugging scientific code
• Advanced NumPy
• Organizing, documenting, and distributing scientific code
• Scientific programming patterns in Python
• Writing parallel applications in Python
• Profiling and speeding up scientific code
• Programming in teams

Faculty
===
• Aitor Morales-Gregorio, Theoretical Neuroanatomy, Institute of Neuroscience 
and Medicine (INM-6), Forschungszentrum Jülich Germany
• Guillermo Aguilar, Department of Computational Psychology, Technische 
Universität Berlin Germany
• Jakob Jordan, Department of Physiology, University of Bern Switzerland
• Lisa Schwetlick, Experimental and Biological Psychology, Universität Potsdam 
Germany
• Pamela Hathway, Orange Business, Berlin/Nürnberg Germany
• Pietro Berkes, NAGRA Kudelski, Lausanne Switzerland
• Rike-Benjamin Schuppner, Institute for Theoretical Biology, 
Humboldt-Universität zu Berlin Germany
• Tiziano Zito, innoCampus, Technische Universität Berlin Germany
• Verjinia Metodieva, NeuroCure, Charité – Universitätsmedizin Berlin Germany
• Zbigniew Jędrzejewski-Szmek, Red Hat Inc., Warsaw Poland

Organizers
==
Head of the organization for ASPP and responsible for the scientific program:

• Tiziano Zito, innoCampus, Technische Universität Berlin

Organization team from IMBB/FORTH:

• Athanasia Papoutsi, Institute of Molecular Biology and Biotechnology of the 
Foundation for Research and Technology – Hellas, Heraklion Greece
• Emmanouil Froudarakis, Institute of Molecular Biology and Biotechnology of 
the Foundation for Research and Technology – Hellas, Heraklion

Sponsors

We are able to hold this year's ASPP school thanks to the financial
support of the Tübingen AI Center. The Institute of Molecular
Biology & Biotechnology of the Foundation for Research and
Technology – Hellas is hosting us in Heraklion and is taking care of
the local organization. We also explicitly thank Prof. Felix
Wichmann at the Neural Information Processing Group, Eberhard Karls
Universität Tübingen, Germany, for his invaluable help. 

Website: https://aspp.school
Contact: info@aspp.school
___
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 addre

[Numpy-discussion] Re: `dtype` parameter in `clip` method

[Sebastian Berg]

On Fri, 2023-03-17 at 07:44 +, Ralf Gommers wrote:
> On Thu, Mar 16, 2023 at 7:57 PM Sergio Callegari <
> sergio.calleg...@gmail.com>
> wrote:
> 
> > I am trying to use the `clip` method to transform floats to
> > integers with
> > clipping. I was expecting to be able to do both the clipping and
> > the type
> > conversion at once, passing the `dtype` parameter to `clip`,
> > together with
> > a suitable `casting` param. Such expectation came from reading the
> > documentation of the `dtype` param for u-funcs that states that
> > this
> > parameter "Overrides the DType of the output arrays".
> > Unfortunately, using
> > the `dtype` parameter with `clip` causes the type conversion to be
> > practiced before the clipping, not after it.  Is this how it is
> > expected to
> > operate?
> > 
> 
> Yes, that's how it is working. The docs (and design) are indeed
> confusing -
> the `dtype` keyword doesn't quite do what you'd expect here. It
> selects the
> internal loops for the specified dtype, rather than only changing the
> output dtype. So you get this kind of weirdness:
> 
> > > > x = np.array([1, 5, 259], dtype=np.uint16)
> > > > np.clip(x, 3, 200, dtype=np.uint8)
> array([3, 5, 3], dtype=uint8)
> > > > np.clip(x, 3, 200).astype(np.uint8)
> array([  3,   5, 200], dtype=uint8)
> 
> I don't think the behavior can be changed. The docs already hint at
> what is
> happening: "The exact calculation DTypes chosen may depend on the
> ufunc and
> the inputs may be cast to this DType to perform the calculation."


Maybe it is helpful to you that using `out=`:

x = np.array([1, 5, 259], dtype=np.uint16)
res = np.empty_like(x, np.uint8)
np.clip(x, 3, 200, out=res, casting="unsafe")

will perform the calculation in whatever the inputs are and _then_
cast.  But, in NumPy, unless you have largish arrays, performing the
cast afterwards is likely faster either way (full disclosure: I didn't
try so not 100% sure, also I guess things could improve over time).

- Sebastian


> 
> Cheers,
> Ralf
> ___
> 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: sebast...@sipsolutions.net


___
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