Re: Precision Tail-off?

[Oscar Benjamin]

On Tue, 14 Feb 2023 at 07:12, Stephen Tucker  wrote:
>
> Hi,
>
> I have just produced the following log in IDLE (admittedly, in Python
> 2.7.10 and, yes I know that it has been superseded).
>
> It appears to show a precision tail-off as the supplied float gets bigger.
>
> I have two questions:
> 1. Is there a straightforward explanation for this or is it a bug?
> 2. Is the same behaviour exhibited in Python 3.x?
>
> For your information, the first 20 significant figures of the cube root in
> question are:
>49793385921817447440
>
> Stephen Tucker.
> --
> >>> 123.456789 ** (1.0 / 3.0)
> 4.979338592181744
> >>> 1234567890. ** (1.0 / 3.0)
> 49793385921817.36

You need to be aware that 1.0/3.0 is a float that is not exactly equal
to 1/3 and likewise the other float cannot have as many accurate
digits as is suggested by the number of zeros shown. Therefore you
should compare what exactly it means for the numbers you really have
rather than comparing with an exact cube root of the number that you
intended. Here I will do this with SymPy and calculate many more
digits than are needed. First here is the exact cube root:

In [29]: from sympy import *

In [30]: n = 1234567890

In [31]: cbrt(n).evalf(50)
Out[31]: 49793385921817.447440261250171604380899353243631762

So that's 50 digits of the exact cube root of the exact number and the
first 20 match what you showed. However in your calculation you use
floats so the exact expression that you evaluate is:

In [32]: e = Pow(Rational(float(n)), Rational(1.0/3.0), evaluate=False)

In [33]: print(e)
1234567888830049821836693930508288**(6004799503160661/18014398509481984)

Neither base or exponent is really the number that you intended it to
be. The first 50 decimal digits of this number are:

In [34]: e.evalf(50)
Out[34]: 49793385921817.360106660998131166304296436896582873

All of the digits in the calculation you showed match with the first
digits given here. The output from the float calculation is correct
given what the inputs actually are and also the available precision
for 64 bit floats (53 bits or ~16 decimal digits).

The reason that the results get further from your expectations as the
base gets larger is because the exponent is always less than 1/3 and
the relative effect of that difference is magnified for larger bases.
You can see this in a series expansion of a^x around x=1/3. Using
SymPy again:

In [37]: a, x = symbols('a, x')

In [38]: print(series(a**x, x, Rational(1, 3), 2))
a**(1/3) + a**(1/3)*(x - 1/3)*log(a) + O((x - 1/3)**2, (x, 1/3))

You can see that the leading relative error term from x being not
quite equal to 1/3 is proportional to the log of the base. You should
expect this difference to grow approximately linearly as you keep
adding more zeros in the base.

--
Oscar
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Precision Tail-off?

[Weatherby,Gerard]

Use Python3

Use the decimal module:  https://docs.python.org/3/library/decimal.html


From: Python-list  on 
behalf of Stephen Tucker 
Date: Tuesday, February 14, 2023 at 2:11 AM
To: Python 
Subject: Precision Tail-off?
*** Attention: This is an external email. Use caution responding, opening 
attachments or clicking on links. ***

Hi,

I have just produced the following log in IDLE (admittedly, in Python
2.7.10 and, yes I know that it has been superseded).

It appears to show a precision tail-off as the supplied float gets bigger.

I have two questions:
1. Is there a straightforward explanation for this or is it a bug?
2. Is the same behaviour exhibited in Python 3.x?

For your information, the first 20 significant figures of the cube root in
question are:
   49793385921817447440

Stephen Tucker.
--
>>> 123.456789 ** (1.0 / 3.0)
4.979338592181744
>>> 123456.789 ** (1.0 / 3.0)
49.79338592181744
>>> 123456789. ** (1.0 / 3.0)
497.9338592181743
>>> 123456789000. ** (1.0 / 3.0)
4979.338592181743
>>> 12345678900. ** (1.0 / 3.0)
49793.38592181742
>>> 1234567890. ** (1.0 / 3.0)
497933.8592181741
>>> 123456789. ** (1.0 / 3.0)
4979338.59218174
>>> 123456789000. ** (1.0 / 3.0)
49793385.9218174
>>> 12345678900. ** (1.0 / 3.0)
497933859.2181739
>>> 1234567890. ** (1.0 / 3.0)
4979338592.181739
>>> 123456789. ** (1.0 / 3.0)
49793385921.81738
>>> 123456789000. ** (1.0 / 3.0)
497933859218.1737
>>> 12345678900. ** (1.0 / 3.0)
4979338592181.736
>>> 1234567890. ** (1.0 / 3.0)
49793385921817.36
>>> 123456789. ** (1.0 / 3.0)
497933859218173.56
>>> 123456789000. ** (1.0 / 3.0)
4979338592181735.0
>>> 12345678900. ** (1.0 / 3.0)
4.979338592181734e+16
>>> 1234567890. ** (1.0 / 3.0)
4.979338592181734e+17
>>> 123456789. ** (1.0 /
3.0)
4.979338592181733e+18
>>> 123456789000. ** (1.0 /
3.0)
4.979338592181732e+19
>>> 12345678900. **
(1.0 / 3.0)
4.9793385921817313e+20
--
--
https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!kSE4mNp5KxTEp6SKzpQeBukScLYsmEoDfLpSTuc2Zv8Z3pZQhTm0usq-k4eVquxM08u8VSUX1X6id9IICJHA2B4mzw$
-- 
https://mail.python.org/mailman/listinfo/python-list

Python 3.8 pip installation on Windows 7

[christoph sobotta via Python-list]

Hello,
The installation file Python-3.8.10.exe (last version compatible with 
Windows 7 (32 bit) ? )

does not automatically install pip on Windows 7.
Are there compatibility problems with Windows 7 ?
See attachment log file
Greetings
C.Sobotta

...
MSI (s) (3C:FC) [13:32:28:993]: Hello, I'm your 32bit Impersonated 
custom action server.

CAQuietExec:  Traceback (most recent call last):
CAQuietExec:    File "C:\Program Files\Python38-32\Lib\runpy.py", line 
194, in _run_module_as_main

CAQuietExec:  return _run_code(code, main_globals, None,
CAQuietExec:    File "C:\Program Files\Python38-32\Lib\runpy.py", line 
87, in _run_code

CAQuietExec:  exec(code, run_globals)
CAQuietExec:    File "C:\Program 
Files\Python38-32\Lib\ensurepip\__main__.py", line 5, in 

CAQuietExec:  sys.exit(ensurepip._main())
CAQuietExec:    File "C:\Program 
Files\Python38-32\Lib\ensurepip\__init__.py", line 206, in _main

CAQuietExec:  return _bootstrap(
CAQuietExec:    File "C:\Program 
Files\Python38-32\Lib\ensurepip\__init__.py", line 125, in _bootstrap

CAQuietExec:  return _run_pip(args + , additional_paths)
CAQuietExec:    File "C:\Program 
Files\Python38-32\Lib\ensurepip\__init__.py", line 34, in _run_pip

CAQuietExec:  return subprocess.run(, check=True).returncode
CAQuietExec:    File "C:\Program Files\Python38-32\Lib\subprocess.py", 
line 493, in run

CAQuietExec:  with Popen(*popenargs, **kwargs) as process:
CAQuietExec:    File "C:\Program Files\Python38-32\Lib\subprocess.py", 
line 858, in __init__
CAQuietExec:  self._execute_child(args, executable, preexec_fn, 
close_fds,
CAQuietExec:    File "C:\Program Files\Python38-32\Lib\subprocess.py", 
line 1311, in _execute_child

CAQuietExec:  hp, ht, pid, tid = _winapi.CreateProcess(executable, args,
CAQuietExec:  FileNotFoundError:  Das System kann die angegebene Datei 
nicht finden

CAQuietExec:  Error 0x80070001: Command line returned an error.
CAQuietExec:  Error 0x80070001: QuietExec Failed
CAQuietExec:  Error 0x80070001: Failed in ExecCommon method
MSI (s) (3C:F0) [13:32:29:617]: Executing op: 
End(Checksum=0,ProgressTotalHDWord=0,ProgressTotalLDWord=291152)
CustomAction UpdatePip returned actual error code 1603 but will be 
translated to success due to continue marking

MSI (s) (3C:F0) [13:32:29:617]: User policy value 'DisableRollback' is 0
MSI (s) (3C:F0) [13:32:29:617]: Machine policy value 'DisableRollback' is 0
MSI (s) (3C:F0) [13:32:29:617]: Note: 1: 2318 2:
MSI (s) (3C:F0) [13:32:29:617]: No System Restore sequence number for 
this installation.

MSI (s) (3C:F0) [13:32:29:617]: Unlocking Server
MSI (s) (3C:F0) [13:32:29:914]: PROPERTY CHANGE: Deleting UpdateStarted 
property. Its current value is '1'.

Action ended 13:32:29: InstallFinalize. Return value 1.
Action ended 13:32:29: INSTALL. Return value 1.

...

--
https://mail.python.org/mailman/listinfo/python-list

Changing the original SQLite version to the latest

[jose isaias cabrera]

Greetings.

I have tried both Cygwin and SQLite support, and I have received very
little ideas from them, so I am trying this to see if anyone has dealt
with such a problem before.

If I use Cygwin setup tool and install python39 and thus,

$ python
Python 3.9.10 (main, Jan 20 2022, 21:37:52) [GCC 11.2.0] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sqlite3
>>> sqlite3.sqlite_version
'3.34.0'
>>>

As you can see, the SQlite3 version installed is v3.34.0. Right now,
the version available is 3.40.1. What I would like to do is to work
with the latest SQLite version. I have 4 Cygwin instances, 2 of them
are working ok, 2 are not. This is what I have done to get python to
use 3.41.0:
- downloaded the latest SQlite check-in from the site
- $ tar -xvf SQLite-44200596.tar.gz
- cd to SQLite-44200596
- $ ./configure --prefix=/usr
- $ make install

These steps above have worked on two PCs, but I don't know what is the
difference that makes the other two work, and the other two not work.
I have started a few instances of Cygwin on the PC that is not
working, and I have been trying for a few days, and I am humbling
myself, and asking for help. So, the request is to get python3 to
change the SQLite3 library from 3.34.0 to 3.41.0. Any help would be
greatly appreciated. Since this is Windows 10, it's probably some
SQLite DLL somewhere that is being pulled instead of the one
installed. Perhaps some of you can provide a few suggestions to see
where I can  find a solution. I know the next step is to compile
python, but, I rather try to find how to fix this and get to the
bottom of it. Thanks, thanks and thanks.

josé


-- 

What if eternity is real?  H...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Comparing caching strategies

[Dino]

On 2/10/2023 7:39 PM, Dino wrote:


- How would you structure the caching so that different caching 
strategies are "pluggable"? change one line of code (or even a config 
file) and a different caching strategy is used in the next run. Is this 
the job for a design pattern such as factory or facade?



turns out that the strategy pattern was the right one for me.



--
https://mail.python.org/mailman/listinfo/python-list

LRU cache

[Dino]

Here's my problem today. I am using a dict() to implement a quick and 
dirty in-memory cache.


I am stopping adding elements when I am reaching 1000 elements (totally 
arbitrary number), but I would like to have something slightly more 
sophisticated to free up space for newer and potentially more relevant 
entries.


I am thinking of the Least Recently Used principle, but how to implement 
that is not immediate. Before I embark on reinventing the wheel, is 
there a tool, library or smart trick that will allow me to remove 
elements with LRU logic?


thanks

Dino
--
https://mail.python.org/mailman/listinfo/python-list

Re: LRU cache

[Chris Angelico]

On Wed, 15 Feb 2023 at 09:37, Dino  wrote:
>
>
> Here's my problem today. I am using a dict() to implement a quick and
> dirty in-memory cache.
>
> I am stopping adding elements when I am reaching 1000 elements (totally
> arbitrary number), but I would like to have something slightly more
> sophisticated to free up space for newer and potentially more relevant
> entries.
>
> I am thinking of the Least Recently Used principle, but how to implement
> that is not immediate. Before I embark on reinventing the wheel, is
> there a tool, library or smart trick that will allow me to remove
> elements with LRU logic?
>

Check out functools.lru_cache :)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Precision Tail-off?

[Michael Torrie]

On 2/14/23 00:09, Stephen Tucker wrote:
> I have two questions:
> 1. Is there a straightforward explanation for this or is it a bug?
To you 1/3 may be an exact fraction, and the definition of raising a
number to that power means a cube root which also has an exact answer,
but to the computer, 1/3 is 0.333 repeating in decimal,
which is some other fraction in binary.  And even rational numbers like
0.2, which are precise and exact, are not in binary
(0.01010101010101010101).  0.2 is .0011011011011011011 on and on forever.

IEEE floating point has very well known limitations.  All languages that
use IEEE floating point will be subject to these limitations.  So it's
not a bug in the sense that all languages will exhibit this behavior.

> 2. Is the same behaviour exhibited in Python 3.x?
Yes. And Java, C++, and any other language that uses IEEE floating point.

-- 
https://mail.python.org/mailman/listinfo/python-list

RE: LRU cache

[avi.e.gross]

Dino,

If your question is understood, you want to treat a dictionary as a sort of
queue with a maximum number of entries. And, you want to remove some kind of
least useful item to make room for any new one.

Most dictionaries now have entries in the order they were entered. There may
already be some variant out there that implements this but it should not be
hard to create.

So you could simply change the method that adds an item to the dictionary.
If the new next  item is not already in the dictionary, simply remove the
first item using whatever method you wish. 

Getting all the keys may be avoided by using an iterator once as in:
next(iter( my_dict.keys() )) or something like that. 

You can then remove that item using the key and insert your new item at the
end.

Of course,  that is not least recently used but least recently entered. 

To deal with keeping track of what was accessed last or never, is a problem
not trivially solved with just a dictionary. I mean you could store a tuple
for each item that included a date and a payload as the value, and you could
then search all the values and find the one with the oldest date. That seems
a bit much so another architecture could be to maintain another data
structure holding keys and dates that perhaps you keep sorted by date and
every time the cache accesses a value, it finds the item in the second
storage and updates the date and  moves the item to the end of the
structure. 

But note that some may want to keep an access count so you always know how
many times an item has been re-used and thus not remove them as easily.

The main goal of a dictionary is to speed up access and make it almost
linear. Your algorithm can add so much overhead, depending on how it is
done, that it can defeat the purpose. 

What some might do is skip the dictionary and use some kind of queue like a
dequeue that handles your thousand entries and new items are added at the
end, items accessed moved to the front, and a brute force search is used to
find an entry. But note some algorithms like that may end up removing the
newest item immediately as it is least recently used if placed at the end. 

It may be an Ordered Dict is one solution as shown here:

https://www.geeksforgeeks.org/lru-cache-in-python-using-ordereddict/



-Original Message-
From: Python-list  On
Behalf Of Dino
Sent: Tuesday, February 14, 2023 5:07 PM
To: python-list@python.org
Subject: LRU cache


Here's my problem today. I am using a dict() to implement a quick and dirty
in-memory cache.

I am stopping adding elements when I am reaching 1000 elements (totally
arbitrary number), but I would like to have something slightly more
sophisticated to free up space for newer and potentially more relevant
entries.

I am thinking of the Least Recently Used principle, but how to implement
that is not immediate. Before I embark on reinventing the wheel, is there a
tool, library or smart trick that will allow me to remove elements with LRU
logic?

thanks

Dino
--
https://mail.python.org/mailman/listinfo/python-list

-- 
https://mail.python.org/mailman/listinfo/python-list

RE: LRU cache

[avi.e.gross]

Chris,

That is a nice decorator solution with some extra features.

We don't know if the OP needed a cache that was more general purpose and
could be accessed from multiple points, and shared across multiple
functions.



-Original Message-
From: Python-list  On
Behalf Of Chris Angelico
Sent: Tuesday, February 14, 2023 5:46 PM
To: python-list@python.org
Subject: Re: LRU cache

On Wed, 15 Feb 2023 at 09:37, Dino  wrote:
>
>
> Here's my problem today. I am using a dict() to implement a quick and 
> dirty in-memory cache.
>
> I am stopping adding elements when I am reaching 1000 elements 
> (totally arbitrary number), but I would like to have something 
> slightly more sophisticated to free up space for newer and potentially 
> more relevant entries.
>
> I am thinking of the Least Recently Used principle, but how to 
> implement that is not immediate. Before I embark on reinventing the 
> wheel, is there a tool, library or smart trick that will allow me to 
> remove elements with LRU logic?
>

Check out functools.lru_cache :)

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Changing the original SQLite version to the latest

[Thomas Passin]

On 2/14/2023 3:30 PM, jose isaias cabrera wrote:

Greetings.

I have tried both Cygwin and SQLite support, and I have received very
little ideas from them, so I am trying this to see if anyone has dealt
with such a problem before.

If I use Cygwin setup tool and install python39 and thus,

$ python
Python 3.9.10 (main, Jan 20 2022, 21:37:52) [GCC 11.2.0] on cygwin
Type "help", "copyright", "credits" or "license" for more information.

import sqlite3
sqlite3.sqlite_version

'3.34.0'




As you can see, the SQlite3 version installed is v3.34.0. Right now,
the version available is 3.40.1. What I would like to do is to work
with the latest SQLite version. I have 4 Cygwin instances, 2 of them
are working ok, 2 are not. This is what I have done to get python to
use 3.41.0:
- downloaded the latest SQlite check-in from the site
- $ tar -xvf SQLite-44200596.tar.gz
- cd to SQLite-44200596
- $ ./configure --prefix=/usr
- $ make install

These steps above have worked on two PCs, but I don't know what is the
difference that makes the other two work, and the other two not work.
I have started a few instances of Cygwin on the PC that is not
working, and I have been trying for a few days, and I am humbling
myself, and asking for help. So, the request is to get python3 to
change the SQLite3 library from 3.34.0 to 3.41.0. Any help would be
greatly appreciated. Since this is Windows 10, it's probably some
SQLite DLL somewhere that is being pulled instead of the one
installed. Perhaps some of you can provide a few suggestions to see
where I can  find a solution. I know the next step is to compile
python, but, I rather try to find how to fix this and get to the
bottom of it. Thanks, thanks and thanks.


As a point of reference, the Python installation I've got on my Windows 
box (not a cygwin install) is


Python 3.10.9 (tags/v3.10.9:1dd9be6, Dec  6 2022, 20:01:21) [MSC v.1934 
64 bit (AMD64)] on win32


and the sqlite_version is 3.39.4

--
https://mail.python.org/mailman/listinfo/python-list

Re: Changing the original SQLite version to the latest

[jose isaias cabrera]

On Tue, Feb 14, 2023 at 8:55 PM Thomas Passin  wrote:
>
> As a point of reference, the Python installation I've got on my Windows
> box (not a cygwin install) is
>
> Python 3.10.9 (tags/v3.10.9:1dd9be6, Dec  6 2022, 20:01:21) [MSC v.1934
> 64 bit (AMD64)] on win32
>
> and the sqlite_version is 3.39.4

Thanks, previous to v3.40.1, the released version was v.3.39.4. I wish
it was that one that one. :-)

-- 

What if eternity is real?  H...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Changing the original SQLite version to the latest

[Thomas Passin]

On 2/14/2023 9:29 PM, jose isaias cabrera wrote:

On Tue, Feb 14, 2023 at 8:55 PM Thomas Passin  wrote:


As a point of reference, the Python installation I've got on my Windows
box (not a cygwin install) is

Python 3.10.9 (tags/v3.10.9:1dd9be6, Dec  6 2022, 20:01:21) [MSC v.1934
64 bit (AMD64)] on win32

and the sqlite_version is 3.39.4


Thanks, previous to v3.40.1, the released version was v.3.39.4. I wish
it was that one that one. :-)



I haven't tried it but this may help:

https://stackoverflow.com/questions/61091438/how-to-upgrade-sqlite3-version-in-windows-10

"Download the latest release from http://www.sqlite.org/download.html 
and manually copy sqlite3.dll into Python's DLLs subfolder."


Not sure how you using cygwin might affect this.
--
https://mail.python.org/mailman/listinfo/python-list

Re: Changing the original SQLite version to the latest

[Frank Millman]

On 2023-02-15 5:59 AM, Thomas Passin wrote:
>
> "Download the latest release from http://www.sqlite.org/download.html
> and manually copy sqlite3.dll into Python's DLLs subfolder."
>

I have done exactly this a number of times and it has worked for me.

Frank Millman


--
https://mail.python.org/mailman/listinfo/python-list