[Numpy-discussion] Re: How is "round to N decimal places" defined for binary floating point numbers?

[george trojan]

With regard to CPython, there is a recent discussion on this topic:
https://discuss.python.org/t/trying-to-understand-rounding-in-python/28014

Le jeu. 28 déc. 2023, à 21 h 43, Stefano Miccoli via NumPy-Discussion <
numpy-discussion@python.org> a écrit :

> I have always been puzzled about how to correctly define the python
> built-in `round(number, ndigits)` when `number` is a binary float and
> `ndigits` is greater than zero.
> Apparently CPython and numpy disagree:
> >>> round(2.765, 2)
> 2.77
> >>> np.round(2.765, 2)
> 2.76
>
> My question for the numpy devs are:
> - Is there an authoritative source that explains what `round(number,
> ndigits)` means when the digits are counted in a base different from the
> one used in the floating point representation?
> - Which was the first programming language to implement an intrinsic
> function `round(number, ndigits)` where ndgits are always decimal,
> irrespective of the representation of the floating point number? (I’m not
> interested in algorithms for printing a decimal representation, but in
> languages that allow to store and perform computations with the rounded
> value.)
> - Is `round(number, ndigits)` a useful function that deserves a rigorous
> definition, or is its use limited to fuzzy situations, where accuracy can
> be safely traded for speed?
>
> Personally I cannot think of sensible uses of `round(number, ndigits)` for
> binary floats: whenever you positively need `round(number, ndigits)`, you
> should use a decimal floating point representation.
>
> Stefano___
> 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: george.tro...@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] Re: Improved 2DFFT Approach

[george trojan]

I think the argument nworkers = -1 to scipy.fft.fft2 and scipy.fft.ifft2 is
in the wrong places in the notebook.

Le lun. 11 mars 2024, à 21 h 25, via NumPy-Discussion <
numpy-discussion@python.org> a écrit :

> Good afternoon, Ralf.
>
> We have done some of the measurements you recommended, for your
> convenience we have created a separate folder with notebooks where we
> measured memory usage and performance of our interpretation against Scipy.
> Separately you can run the tests on your hardware and separately measure
> memory. I've left the link below.
>
> https://github.com/2D-FFT-Project/2d-fft/tree/main/notebooks
>
> We measured efficiency for 4 versions - with multithreading and data type
> conversion. According to the results of the tests, our algorithm has the
> greatest lead in the case with multithreading and without data type
> conversion - 75%, the worst performance without multithreading and with
> data type conversion - 14%. In terms of memory usage we beat NumPy and
> Scipy by 2 times in all cases, I think this is a solid achievement at this
> point.
>
> I can generalise that our mathematical approach still has a serious
> advantage, nevertheless we lose always to Scipy in inverse operation case,
> we haven't figured out the reasons yet, we are discussing it at the moment,
> but we will fix it.
>
> It is important to note that at this stage our algorithm shows the above
> perfomance on matrices of size powers of two.
> This is a specificity of the mathematical butterfly formula. We are
> investigating ways to remove this limitation, we already assessed the
> effect of element imputation and column dropping, the result is not
> accurate enough. Otherwise, we can suggest putting our version to work only
> in cases of the mentioned matrices, it'll still be an upgrade for NumPy.
>
> At this point I can say that we are willing to work and improve the
> existing version within our skills, knowledge and available resources. We
> still live with the idea of adding our interpretation or idea to the
> existing NumPy package, as in theoretical perspective within the memory
> usage and efficiency, it can give a serious advantage on other projects
> built on NumPy.
>
> Thank you for your time, we will continue our work and look forward to
> your review.
> ___
> 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: george.tro...@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] Re: Adding bfill() to numpy.

[george trojan]

xarray has both bfill and ffill for DataArrays. The implementation useless
bottleneck https://github.com/pydata/bottleneck.

Le lun. 20 mai 2024, à 13 h 22, Warren Weckesser 
a écrit :

> On Mon, May 20, 2024 at 9:06 AM Raquel Braunschweig via
> NumPy-Discussion  wrote:
> >
> > Hello everyone,
> >
> > My colleague and I will be opening a Pull Request (PR) about adding
> bfill() (backward fill) function to NumPy. This function is designed to
> fill NaN values in an array by propagating the next valid observation
> backward along a specified axis. We believe this addition will be highly
> useful for data preprocessing and manipulation tasks.
>
>
> This was proposed earlier this year in this issue:
> https://github.com/numpy/numpy/issues/25823
>
> Take note of rkern's comment in that issue; I think most NumPy
> developers will agree with what he says there.
>
> Warren
>
>
> >
> > Here are some key points regarding our proposed implementation:
> >
> > Function Explanation: The bfill() function identifies NaN values in an
> array and replaces them by copying the next valid value in the array
> backwards. Users can specify the axis along which the filling should be
> performed, providing flexibility for different data structures.
> > Use Cases: This function is particularly beneficial in time series
> analysis, data cleaning, and preparing datasets for machine learning models.
> >
> > We are looking forward to your feedback and suggestions.
> >
> > Thank you for your attention and we appreciate your support.
> >
> > Best regards,
> > Raquel and Gonçalo
> > ___
> > 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: warren.weckes...@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: george.tro...@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

Re: [Numpy-discussion] deprecating float(x) for ndim > 0

[george trojan]

Responding to the post by nico.schloe...@gmail.com (I subscribe to the
digest).

I just wrote the following code:

twb = scipy.optimize.fsolve(phi, tdb, args=(tdb, p, w, hd_tdb, hg_tdb),
xtol=1e-8)
tdb, p, w, hd_tdb, hg_tdb
twb.shape
print("wet-bulb temperature {:.5f} [deg K]".format(float(twb)))

The output is

(313.15, 101325.0, 0.009200033532084696, 40182.343155896095, 2573510.322137241)

(1,)

wet-bulb temperature 295.17583 [deg K]

All arguments are floats, the function phi returns float as well. I did
expect the output to be float. Instead I got a 1d array. Were my
expectations wrong? The print statement would stop working after
deprecation.

George
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] deprecating float(x) for ndim > 0

[george trojan]

To Andrew Nelson:

> In the return section for fsolve the documentation states that the return
> value, `x`, is an `ndarray`.

True, my bad. There is another issue with `fsolve`: it implicitly changes
the argument  passed to `func`. Consider

def func(x):
# x = float(x)
if not np.isscalar(x) and x.shape != ():
raise ValueError('The argument must be a number or a 0-d array')
return x - 1

fsolve(func, np.array(2.0))

---ValueError
   Traceback (most recent call
last)/tmp/ipykernel_1017360/2091764495.py in   5
return x - 1  6 > 7 fsolve(func, np.array(2.0))
. . .
 ValueError: The argument must be a number or a 0-d array

I had the commented out line in my code (in real life I am calling a
library function that accepts only
numeric types, not arrays). Changing this to line to x = x.item() makes sense.
The documentation states that `func` takes at least one (possibly
vector) argument. It must take a vector.
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] numpy defaults to free-threaded version on conda-forge

[george trojan via NumPy-Discussion]

My apologies if this is a wrong venue. Is this a conda-forge problem?
When I run

mamba create -n foo meson-python numpy 'python>=3.13'

the free-threaded python is selected:

 + python 3.13.0  h6355ac2_0_cp313tconda-forge
Cached
 + numpy   2.1.3  py313hb01392b_0  conda-forge
Cached

When python spec is moved to the front, I do get the "usual" version.
However, when I build a python extension with conda-build, I do not control
the order. The extension is created for the free-threaded version. Here is
my requirements section in recipe/meta.yaml:

requirements:
  build:
- {{ compiler('c') }}
- {{ compiler('fortran') }}
  host:
- python >=3.13
- python_abi =3.13.* *_cp313  # needed to prevent selection of
freethreaded python
- meson-python
- numpy >=2.0
- pip
  run:
- python >=3.13
- numpy >=2.0

I did manage to find a workaround, which is the python_abi line. Am I doing
it right?
___
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: numpy defaults to free-threaded version on conda-forge

[george trojan via NumPy-Discussion]

It looks similar as
https://github.com/conda-forge/python-feedstock/issues/738, but the issue
shows up only when installing numpy.

mamba create -n pybug python
mamba activate pybug
mamba update --all

all work fine. Then

mamba install cython is OK

mamba install numpy wants to change python to free-threaded.

mamba --version
mamba 1.5.10
conda 24.9.2


Le mar. 26 nov. 2024, à 17 h 44, Ralf Gommers  a
écrit :

> Yes, that does look like a conda-forge issue. I think it's this one:
> https://github.com/conda-forge/python-feedstock/issues/738
>
> On Tue, Nov 26, 2024 at 6:06 PM george trojan via NumPy-Discussion <
> numpy-discussion@python.org> wrote:
>
>> My apologies if this is a wrong venue. Is this a conda-forge problem?
>> When I run
>>
>> mamba create -n foo meson-python numpy 'python>=3.13'
>>
>> the free-threaded python is selected:
>>
>>  + python 3.13.0  h6355ac2_0_cp313tconda-forge
>> Cached
>>  + numpy   2.1.3  py313hb01392b_0  conda-forge
>> Cached
>>
>> When python spec is moved to the front, I do get the "usual" version.
>> However, when I build a python extension with conda-build, I do not control
>> the order. The extension is created for the free-threaded version. Here is
>> my requirements section in recipe/meta.yaml:
>>
>> requirements:
>>   build:
>> - {{ compiler('c') }}
>> - {{ compiler('fortran') }}
>>   host:
>> - python >=3.13
>> - python_abi =3.13.* *_cp313  # needed to prevent selection of
>> freethreaded python
>> - meson-python
>> - numpy >=2.0
>> - pip
>>   run:
>> - python >=3.13
>> - numpy >=2.0
>>
>> I did manage to find a workaround, which is the python_abi line. Am I
>> doing it right?
>>
>>
>>
>>
>>
>> ___
>> 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: ralf.gomm...@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