[Numpy-discussion] Newcomer's meeting: TODAY, 4PM UTC
Hi all! Sorry for the late notice: our next Newcomer's Meeting is on *Today, Thursday October 7* *, at 4pm UTC.* This is an informal meeting with no agenda to ask questions, get to know other people and (hopefully) figure out ways to contribute to NumPy. Feel free to join if you are lurking around but found it hard to start contributing - we'll do our best to support you. If you wish to join on Zoom, use this link: https://zoom.us/j/6345425936 Hope to see you around! ** You can click this link to get the correct time at your timezone: https://www.timeanddate.com/worldclock/fixedtime.html?msg=NumPy+Newcomers%27+Meeting&iso=20211007T16&p1=1440&ah=1 *** You can add the NumPy community calendar to your google calendar by clicking this link: https://calendar.google.com/calendar /r?cid=YmVya2VsZXkuZWR1X2lla2dwaWdtMjMyamJobGRzZmIyYzJqODFjQGdyb3VwLmNhbGVuZGFyLmdvb2dsZS5jb20 - Melissa ___ 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: ENH: Extended choose -- add an implementation of the choose function which supports more than 32 choices
Very informative https://bit.ly/3BazIBL ___ 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: A bite of C++
On Wed, 2021-08-25 at 17:50 -0500, Sebastian Berg wrote: > On Wed, 2021-08-25 at 17:48 +0200, Serge Guelton wrote: > > Hi folks, > > > > https://github.com/numpy/numpy/pull/19713 showcases what *could* be > > a > > first step > > toward getting rid of generated C code within numpy, in favor of > > some > > C++ code, > > coupled with a single macro trick. A brief update on this: The current plan would be to include this in the next release. Largely as a trial balloon, so we see if there are any issues, e.g. with deployment, and can revert the changes if there are. That would mean that some time within the next release cycle using C++ for more things could be on the table and less difficult to discuss. Not knowing the C++ much myself, I assume that the current approach is fine and the only remaining thing is a brief review of the new code to ensure correct translation from C. (Which does not preclude refining the C++ code later.) Cheers, Sebastian > > > > Basically, templated code is an easy and robust way to replace > > generated code > > (the C++ compiler becomes the code generator when instantiating > > code), and a > > single X-macro takes care of the glue with the C world. > > I am not a C++ export, and really have to get to used to this code. > So > I would prefer if some C++ experts can look at it and give feedback. > > This will be a bit harder to read for me than our `.c.src` code for a > while. But on the up-side, I am frustrated by my IDE not being able > to > deal with the `c.src` templating. > > One reaction reading the X-macro trick is that I would be more > comfortable with a positive list rather than block-listing. It just > felt a bit like too much magic and I am not sure how good it is to > assume we usually want to export everything (for one, datetimes are > pretty special). > > Even if it is verbose, I would not mind if we just list everything, > so > long we have short-hands for all-integers, all-float, all-inexact, > etc. > > > > > > Some changes in distutils were needed to cope with C++-specific > > flags, and > > extensions that consist in mixed C and C++ code. > > > > > Potential follow-ups : > > > > - do we want to use -nostdlib, to be sure we don't bring any C++ > > runtime dep? > > What does this mean for compatibility? It sounds reasonable to me > for > now if it increases systems we can run on, but I really don't know. > > > - what about -fno-exception, -fno-rtti? > > How do C++ exceptions work at run-time? What if I store a C++ > function > pointer that raises an exception and use it from a C program? Does > it > add run-time overhead, do we need that `no-exception` to define that > our functions are actually C "calling convention" in this regard?! > > Run-time calling convention changes worry me, because I am not sure > C++ > exception have a place in the current or even future ABI. All our > current API use a `-1` return value for exceptions. > > This is just like Python's type slots, so there must be "off the > shelve" approaches for this? > > Embracing C++ exceptions seems a bit steep to me right now, unless I > am > missing something awesome? > > I will note that a lot of the functions that we want to template like > this, are – and should be – accessible as public API (i.e. you can > ask > NumPy to give you the function pointer). > > Cheers, > > Sebastian > > > > - coding style? > > - (I'm-not-a-farseer-I-don-t-know-all-topics) > > > > ___ > > 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 signature.asc Description: This is a digitally signed message part ___ 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: A bite of C++
Will this have any impact on the difficulty of finding "where is np.foo or ndarray.bar implemented"? On Thu, Oct 7, 2021 at 3:02 PM Sebastian Berg wrote: > On Wed, 2021-08-25 at 17:50 -0500, Sebastian Berg wrote: > > On Wed, 2021-08-25 at 17:48 +0200, Serge Guelton wrote: > > > Hi folks, > > > > > > https://github.com/numpy/numpy/pull/19713 showcases what *could* be > > > a > > > first step > > > toward getting rid of generated C code within numpy, in favor of > > > some > > > C++ code, > > > coupled with a single macro trick. > > > A brief update on this: The current plan would be to include this in > the next release. Largely as a trial balloon, so we see if there are > any issues, e.g. with deployment, and can revert the changes if there > are. > > That would mean that some time within the next release cycle using C++ > for more things could be on the table and less difficult to discuss. > > Not knowing the C++ much myself, I assume that the current approach is > fine and the only remaining thing is a brief review of the new code to > ensure correct translation from C. (Which does not preclude refining > the C++ code later.) > > Cheers, > > Sebastian > > > > > > > > Basically, templated code is an easy and robust way to replace > > > generated code > > > (the C++ compiler becomes the code generator when instantiating > > > code), and a > > > single X-macro takes care of the glue with the C world. > > > > I am not a C++ export, and really have to get to used to this code. > > So > > I would prefer if some C++ experts can look at it and give feedback. > > > > This will be a bit harder to read for me than our `.c.src` code for a > > while. But on the up-side, I am frustrated by my IDE not being able > > to > > deal with the `c.src` templating. > > > > One reaction reading the X-macro trick is that I would be more > > comfortable with a positive list rather than block-listing. It just > > felt a bit like too much magic and I am not sure how good it is to > > assume we usually want to export everything (for one, datetimes are > > pretty special). > > > > Even if it is verbose, I would not mind if we just list everything, > > so > > long we have short-hands for all-integers, all-float, all-inexact, > > etc. > > > > > > > > > > Some changes in distutils were needed to cope with C++-specific > > > flags, and > > > extensions that consist in mixed C and C++ code. > > > > > > > > > Potential follow-ups : > > > > > > - do we want to use -nostdlib, to be sure we don't bring any C++ > > > runtime dep? > > > > What does this mean for compatibility? It sounds reasonable to me > > for > > now if it increases systems we can run on, but I really don't know. > > > > > - what about -fno-exception, -fno-rtti? > > > > How do C++ exceptions work at run-time? What if I store a C++ > > function > > pointer that raises an exception and use it from a C program? Does > > it > > add run-time overhead, do we need that `no-exception` to define that > > our functions are actually C "calling convention" in this regard?! > > > > Run-time calling convention changes worry me, because I am not sure > > C++ > > exception have a place in the current or even future ABI. All our > > current API use a `-1` return value for exceptions. > > > > This is just like Python's type slots, so there must be "off the > > shelve" approaches for this? > > > > Embracing C++ exceptions seems a bit steep to me right now, unless I > > am > > missing something awesome? > > > > I will note that a lot of the functions that we want to template like > > this, are – and should be – accessible as public API (i.e. you can > > ask > > NumPy to give you the function pointer). > > > > Cheers, > > > > Sebastian > > > > > > > - coding style? > > > - (I'm-not-a-farseer-I-don-t-know-all-topics) > > > > > > ___ > > > 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 > To unsubscribe send an email to numpy-discussion-le...@python.org > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ > Member address: jbrockmen...@gmail.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] [JOBS] Solar & Storage Energy Analyst
Dear Pythonistas, If you're an experienced solar energy analyst looking to accelerate the energy transition & make a bigger impact on the climate crisis by using your Python analytical skills to help deploy more solar power & energy storage cheaper, better, & faster, then please come join my team at DNV. I'm not looking for superstars. I just need a few friendly folks who value diversity & are open to using the best tools to save our planet. Please follow the links below or email me for more info: US: https://careers-dnv.icims.com/jobs/16829/job Canada: https://careers-dnv.icims.com/jobs/16831/job Thanks, Mark -- Mark Mikofski, PhD (2005) *Fiat Lux* ___ 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
