Re: Precision Tail-off?

000 >>> sympy.root(n, 6) 10*13717421**(1/6)*3**(1/3) >>> sympy.root(n, 6).evalf(50) 22314431635.562095902499928269233656421704825692573 >>> mpmath.root(n, 6) mpf('22314431635.562096') >>> mpmath.mp.dps = 50 >>> mpmath.

Re: Precision Tail-off?

On 2023-02-18 03:52:51 +, Oscar Benjamin wrote: > On Sat, 18 Feb 2023 at 01:47, Chris Angelico wrote: > > On Sat, 18 Feb 2023 at 12:41, Greg Ewing via Python-list > > > To avoid it you would need to use an algorithm that computes nth > > > roots directly rather than raising to the power 1/n.

Re: Precision Tail-off?

valuate any rational power either exactly or to any desired accuracy. Under the hood SymPy uses mpmath for the approximate numerical evaluation part of this and mpmath can also be used directly with its cbrt and nthroot functions to do this working with any desired precision. > But maybe, in pract

Re: Precision Tail-off?

On 2/17/23 15:03, Grant Edwards wrote: > Every fall, the groups were again full of a new crop of people who had > just discovered all sorts of bugs in the way > implemented floating point, and pointing them to a nicely written > document that explained it never did any good. But to be fair,

Re: Precision Tail-off?

On Sat, 18 Feb 2023 at 12:41, Greg Ewing via Python-list wrote: > > On 18/02/23 7:42 am, Richard Damon wrote: > > On 2/17/23 5:27 AM, Stephen Tucker wrote: > >> None of the digits in RootNZZZ's string should be different from the > >> corresponding digits in RootN. > > > > Only if the storage

Re: Precision Tail-off?

On 18/02/23 7:42 am, Richard Damon wrote: On 2/17/23 5:27 AM, Stephen Tucker wrote: None of the digits in RootNZZZ's string should be different from the corresponding digits in RootN. Only if the storage format was DECIMAL. Note that using decimal wouldn't eliminate this particular problem,

Re: Precision Tail-off?

On 2023-02-17, Mats Wichmann wrote: > And... this topic as a whole comes up over and over again, like > everywhere. That's an understatement. I remember it getting rehashed over and over again in various USENET groups 35 years ago when when the VAX 11/780 BSD machine on which I read news

Re: Precision Tail-off?

On 2/17/23 11:42, Richard Damon wrote: On 2/17/23 5:27 AM, Stephen Tucker wrote: The key factor here is IEEE floating point is storing numbers in BINARY, not DECIMAL, so a multiply by 1000 will change the representation of the number, and thus the possible resolution errors. Store you

Re: Precision Tail-off?

On 2023-02-17, Richard Damon wrote: > [...] > >> Perhaps this observation should be brought to the attention of the IEEE. I >> would like to know their response to it. > > That is why they have developed the Decimal Floating point format, to > handle people with those sorts of problems. > > They

Re: Precision Tail-off?

On 2023-02-17 14:39:42 +, Weatherby,Gerard wrote: > IEEE did not define a standard for floating point arithmetics. They > designed multiple standards, including a decimal float point one. > Although decimal floating point (DFP) hardware used to be > manufactured, I couldn’t find any current

Re: Precision Tail-off?

On 2023-02-17 10:27:08 +, Stephen Tucker wrote: > This is a hugely controversial claim, I know, but I would consider this > behaviour to be a serious deficiency in the IEEE standard. > > Consider an integer N consisting of a finitely-long string of digits in > base 10. > > Consider the

Re: Precision Tail-off?

e) is just a convenient way to write a small subset of real numbers. By using any base you limit yourself to rational numbers (no e or π or √2) and in fact only those rational numbers where the denominator is a power of the base. Converting numbers from one base to another with any finite precision wil

Re: Precision Tail-off?

n [9]: e.evalf(50) Out[9]: 49793385921817.447440261250171604380899353243631762 Because the *entire* expression is represented here *exactly* as e it is then possible to evaluate different parts of the expression repeatedly with different levels of precision and it is necessary to do that for full acc

Re: Precision Tail-off?

On 2/17/23 5:27 AM, Stephen Tucker wrote: Thanks, one and all, for your reponses. This is a hugely controversial claim, I know, but I would consider this behaviour to be a serious deficiency in the IEEE standard. Consider an integer N consisting of a finitely-long string of digits in base 10.

Re: Precision Tail-off?

ftware. It's the way your CPU represents floating point numbers in silicon. And in your GPUs (where speed is preferred to precision). So it's not like Python could just arbitrarily do something different unless you were willing to pay a huge penalty for speed. For example the decimal module which

Re: Precision Tail-off?

[snip] >> >> 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. >&g

RE: Precision Tail-off?

are ones. For more complex calculations where the errors can accumulate, you may need to choose a small number with more such bits near the end. Extended precision arithmetic is perhaps cheaper now and can be done for a reasonable number of digits. It probably is not realistic to do most

Re: Precision Tail-off?

until a few years ago, but they seem to have gone dark: https://twitter.com/SilMinds From: Python-list on behalf of Thomas Passin Date: Friday, February 17, 2023 at 9:02 AM To: python-list@python.org Subject: Re: Precision Tail-off? *** Attention: This is an external email. Use caution

Re: Precision Tail-off?

. What you are not considering is that the IEEE standard is about trying to achieve a balance between resource use (memory and registers), precision, speed of computation, reliability (consistent and stable results), and compatibility. So there have to be many tradeoffs. One of them

Re: Precision Tail-off?

cker. > > > On Thu, Feb 16, 2023 at 6:49 PM Peter Pearson > wrote: > >> On Tue, 14 Feb 2023 11:17:20 +, Oscar Benjamin wrote: >> > On Tue, 14 Feb 2023 at 07:12, Stephen Tucker >> wrote: >> [snip] >> >> I have just produced the following log i

Re: Precision Tail-off?

en Tucker > wrote: > [snip] > >> 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. > [snip]

Re: Precision Tail-off?

On Tue, 14 Feb 2023 11:17:20 +, Oscar Benjamin wrote: > On Tue, 14 Feb 2023 at 07:12, Stephen Tucker wrote: [snip] >> 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 t

Re: Precision Tail-off?

) 8.881784197001252e-16 1E-99 From: Python-list on behalf of Michael Torrie Date: Tuesday, February 14, 2023 at 5:52 PM To: python-list@python.org Subject: Re: Precision Tail-off? *** Attention: This is an external email. Use caution responding, opening attachments or clicking on links. *** On 2

Re: Precision Tail-off?

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

Re: Precision Tail-off?

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

Re: Precision Tail-off?

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. > >

Precision Tail-off?

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

[issue217305] Limited precision enter 3.14 you get 3.1400000000000001

Change by admin : ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue454891] loss of precision in float marshaling

Change by admin : -- github: None -> 35039 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue421384] bad floating point precision

Change by admin : -- github: None -> 34457 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue217305] Limited precision enter 3.14 you get 3.1400000000000001

Change by admin : -- github: None -> 33373 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46525] datetime.timestamp() lose precision when the time is too large

amp() 18839548800.96 I believe this is an issue caused by using `double` in the C implementation. -- components: Library (Lib) messages: 411676 nosy: yilei priority: normal severity: normal status: open title: datetime.timestamp() lose precision when the time is too large type: beh

Re: neonumeric - C++ arbitrary precision arithmetic library

On 2021-03-08 09:29:31 +0100, Mirko via Python-list wrote: > Am 07.03.2021 um 21:52 schrieb Avi Gross via Python-list: > > The precedence example used below made a strange assumption that the > > imaginary program would not be told up-front what computer language it was > > being asked to convert

Re: neonumeric - C++ arbitrary precision arithmetic library

Am 07.03.2021 um 21:52 schrieb Avi Gross via Python-list: > The precedence example used below made a strange assumption that the > imaginary program would not be told up-front what computer language it was > being asked to convert from. That is not the scenario being discussed as we > have

Re: neonumeric - C++ arbitrary precision arithmetic library

Am 07.03.21 um 20:42 schrieb Peter J. Holzer: The second part is converting a parse tree into code. I am quite sure that it is possible to devise a formal language to specify the semantics of any programming language and then to use this to generate the code. However, I strongly suspect that

RE: neonumeric - C++ arbitrary precision arithmetic library

on breaking anything, but I think a universal translator may not be imminent. -Original Message- From: Python-list On Behalf Of Peter J. Holzer Sent: Sunday, March 7, 2021 2:43 PM To: python-list@python.org Subject: Re: neonumeric - C++ arbitrary precision arithmetic library On 2021-03-06 23:4

Re: neonumeric - C++ arbitrary precision arithmetic library

On 2021-03-06 23:41:10 +0100, Mirko via Python-list wrote: > I even wonder why they have tried. Writing a universal > compiler/interpreter sounds logically impossible to me, Here's a > simple Python expression: > > >>> 3+3*5 > 18 > > And here's the same expression in (GNU) Smalltalk: > > st>

Re: neonumeric - C++ arbitrary precision arithmetic library

On Sun, Mar 7, 2021 at 9:42 AM Mirko via Python-list wrote: > I even wonder why they have tried. Writing a universal > compiler/interpreter sounds logically impossible to me, Here's a > simple Python expression: > > >>> 3+3*5 > 18 > > And here's the same expression in (GNU) Smalltalk: > > st>

Re: neonumeric - C++ arbitrary precision arithmetic library

Am 06.03.2021 um 22:24 schrieb Ben Bacarisse: > Mr Flibble writes: > >>> Someone who says that he is capable of writing a compiler that >>> translates every language has megalomania. No one can do this. >> >> Just because you can't make one it doesn't follow that nobody else >> can. > > True,

Re: neonumeric - C++ arbitrary precision arithmetic library

On 3/5/2021 8:51 AM, Mr Flibble wrote: neonumeric - C++ arbitrary precision arithmetic library with arbitrary precision integers, floats and rationals: https://github.com/i42output/neonumeric It hasn't been formally released yet as it still requires more extensive testing.  It will be used

RE: neonumeric - C++ arbitrary precision arithmetic library

Of Bonita Montero Sent: Saturday, March 6, 2021 2:12 PM To: python-list@python.org Subject: Re: neonumeric - C++ arbitrary precision arithmetic library >> There is no projection. >> _You_ have megalomania, not me. >> And there's also no Dunning Kruger effect. >> You can't assess

Re: neonumeric - C++ arbitrary precision arithmetic library

Mr Flibble writes: >> Someone who says that he is capable of writing a compiler that >> translates every language has megalomania. No one can do this. > > Just because you can't make one it doesn't follow that nobody else > can. True, but lots of very knowledgeable people have tried and failed.

Re: neonumeric - C++ arbitrary precision arithmetic library

On 3/6/2021 11:35 AM, Mr Flibble wrote: On 06/03/2021 19:11, Bonita Montero wrote: There is no projection. _You_ have megalomania, not me. And there's also no Dunning Kruger effect. You can't assess your capabilites, not me. no u Someone who says that he is capable of writing a compiler

Re: neonumeric - C++ arbitrary precision arithmetic library

There is no projection. _You_ have megalomania, not me. And there's also no Dunning Kruger effect. You can't assess your capabilites, not me. no u Someone who says that he is capable of writing a compiler that translates every language has megalomania. No one can do this. --

Re: neonumeric - C++ arbitrary precision arithmetic library

On Sun, Mar 7, 2021 at 4:51 AM Bonita Montero wrote: > > > Whilst you need to read the following: > > * https://en.wikipedia.org/wiki/Psychological_projection > > * https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect > > There is no projection. > _You_ have megalomania, not me. > And

Re: neonumeric - C++ arbitrary precision arithmetic library

Whilst you need to read the following: * https://en.wikipedia.org/wiki/Psychological_projection * https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect There is no projection. _You_ have megalomania, not me. And there's also no Dunning Kruger effect. You can't assess your capabilites, not

Re: neonumeric - C++ arbitrary precision arithmetic library

It hasn't been formally released yet as it still requires more extensive testing. It will be used as part of my universal compiler, neos, that can compile any programming language ... You will get the same room in the same psychiatric ward like Amine Moulay Ramdane. --

[issue40668] Catastrophic loss of precision in colorsys module

Serhiy Storchaka added the comment: It is correct. Colorspaces for RGB an YIQ are different. Not all RGB colors can be represented in YIQ and vice versa. For YIQ color (0, 1, 0) you need RGB color (0.9468822170900693, -0.27478764629897834, -1.1085450346420322), but the G and B components

[issue40668] Catastrophic loss of precision in colorsys module

Raymond Hettinger added the comment: See https://bugs.python.org/issue14323 -- nosy: +rhettinger, serhiy.storchaka ___ Python tracker ___

[issue40668] Catastrophic loss of precision in colorsys module

b.com/Zac-HD/stdlib-property-tests/pull/13 -- components: Library (Lib) messages: 369197 nosy: Zac Hatfield-Dodds priority: normal severity: normal status: open title: Catastrophic loss of precision in colorsys module type: behavior versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8

[issue32790] Keep trailing zeros in precision for string format option g

Stéphane Wirtel added the comment: Thank you for your PR and this issue, the PR is merged into master, 3.8 and 3.7. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.9 ___ Python tracker

[issue32790] Keep trailing zeros in precision for string format option g

miss-islington added the comment: New changeset e6b14c026fd9045a0d460b62dbcb512fca4c64ec by Miss Islington (bot) in branch '3.8': bpo-32790: Add info about alt format using GH- for 'g' in chart (GH-6624) https://github.com/python/cpython/commit/e6b14c026fd9045a0d460b62dbcb512fca4c64ec

[issue32790] Keep trailing zeros in precision for string format option g

miss-islington added the comment: New changeset 77878cadc58aaca234482dffbb5fe89c74c026fa by Miss Islington (bot) in branch '3.7': bpo-32790: Add info about alt format using GH- for 'g' in chart (GH-6624) https://github.com/python/cpython/commit/77878cadc58aaca234482dffbb5fe89c74c026fa

[issue32790] Keep trailing zeros in precision for string format option g

Change by miss-islington : -- pull_requests: +15734 pull_request: https://github.com/python/cpython/pull/16121 ___ Python tracker ___

[issue32790] Keep trailing zeros in precision for string format option g

Change by miss-islington : -- pull_requests: +15735 pull_request: https://github.com/python/cpython/pull/16122 ___ Python tracker ___

[issue32790] Keep trailing zeros in precision for string format option g

Stéphane Wirtel added the comment: New changeset d44542f9a231bf725ecd82eb640a672c759a8227 by Stéphane Wirtel (bchhabra2490) in branch 'master': bpo-32790: Add info about alt format using # for 'g' in chart (GH-6624)

[issue33731] string formatting that produces floats with preset precision while respecting locale

Cédric Krier added the comment: I think PR-15275 will solves this issue also as you could use: >>> locale.setlocale(locale.LC_ALL, 'fr_FR') >>> locale.localize('{:.2f}'.format(1.891)) '1,89' -- nosy: +ced ___ Python tracker

[issue13889] str(float) and round(float) issues with FPU precision

Change by Mark Dickinson : -- pull_requests: -13812 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue13889] str(float) and round(float) issues with FPU precision

Change by STINNER Victor : -- pull_requests: +13812 pull_request: https://github.com/python/cpython/pull/13946 ___ Python tracker ___

[issue36655] Division Precision Problem

Eric V. Smith added the comment: Also see https://docs.python.org/3/tutorial/floatingpoint.html for some Python-specific details. -- nosy: +eric.smith ___ Python tracker ___

[issue36655] Division Precision Problem

Christian Heimes added the comment: This is the expected and correct behavior. Python's float are IEEE 754 floats, https://en.wikipedia.org/wiki/IEEE_754. IEE 754 have a limited precision. 224847175712806907706081280 / 4294967296 is not exactly dividable under IEEE 754 semantics

[issue36655] Division Precision Problem

ority: normal severity: normal status: open title: Division Precision Problem type: behavior versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue36655> ___ __

[issue11580] Add width and precision formatters to PyBytes_FromFormatV()

Change by Mark Lawrence : -- nosy: -BreamoreBoy ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33731] string formatting that produces floats with preset precision while respecting locale

Change by Stefan Krah : -- nosy: +skrah ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33731] string formatting that produces floats with preset precision while respecting locale

James Emerton added the comment: @rhettinger See #34311 about formatting Decimals using locale.format(). I'd like to see the problem fixed in one place or the other. Also, this is seems relatively straightforward to implement as it's really just a combination of the fixed precision 'f

[issue33731] string formatting that produces floats with preset precision while respecting locale

Raymond Hettinger added the comment: I would like to see locale() remain somewhat decoupled from the rest of string formatting. IIRC locale() is finicky especially when concurrency is involved. I think a best practice is for an app to address locale issues explicitly rather than inside

[issue33731] string formatting that produces floats with preset precision while respecting locale

James Emerton added the comment: So far, I've implemented this for Decimal -- ___ Python tracker ___ ___ Python-bugs-list mailing

[issue33731] string formatting that produces floats with preset precision while respecting locale

Change by Roundup Robot : -- keywords: +patch pull_requests: +8118 stage: -> patch review ___ Python tracker ___ ___

[issue33731] string formatting that produces floats with preset precision while respecting locale

Change by James Emerton : -- nosy: +jemerton ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33731] string formatting that produces floats with preset precision while respecting locale

Eric V. Smith added the comment: You can always use the locale module, although of course that's not as convenient: >>> locale.format('%.2f', 1.891) '1.89' I'm open to suggests on backward compatible ways to implement this for python 3.8. It would probably involve a new letter, and need to

[issue33731] string formatting that produces floats with preset precision while respecting locale

, eric.smith priority: normal severity: normal status: open title: string formatting that produces floats with preset precision while respecting locale type: enhancement versions: Python 3.6 ___ Python tracke

[issue33730] string format 'n' produces numbers with incorrect precision

Eric V. Smith added the comment: I'm going to close this. If you still think there's an issue, we can re-open it. -- assignee: -> eric.smith components: +Interpreter Core -Extension Modules resolution: -> not a bug stage: -> resolved status: open -> closed

[issue33730] string format 'n' produces numbers with incorrect precision

Eric V. Smith added the comment: 'n' is defined as the same as 'g', for floats (modulo the locale-specific characters, of course): >>> format(1.89, '.2n') '1.9' >>> format(1.89, '.2g') '1.9' -- ___ Python tracker

[issue33730] string format 'n' produces numbers with incorrect precision

;.format(1.89)) 1.9 >>> print ("{:.2f}".format(1.89)) 1.89 -- components: Extension Modules messages: 318388 nosy: Jakub Szewczyk, eric.smith priority: normal severity: normal status: open title: string format 'n' produces numbers with incorrect precision type: behavior versio

[issue33296] datetime.datetime.utcfromtimestamp call decimal causes precision loss

Shlomo Anglister added the comment: This issue is in review stage for a long time. What's holding it? On Wed, May 9, 2018 at 8:24 AM, Shlomo Anglister wrote: > > Shlomo Anglister added the comment: > > Thanks

[issue33296] datetime.datetime.utcfromtimestamp call decimal causes precision loss

Shlomo Anglister added the comment: Thanks @serhiy.storchaka and @corona10 ! I read it, documented the relation and failed to see the duplication. -- ___ Python tracker

[issue33296] datetime.datetime.utcfromtimestamp call decimal causes precision loss

Serhiy Storchaka added the comment: I think this issue is not just related to issue23607, but a duplicate of it. -- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Inconsistency in datetime.utcfromtimestamp(Decimal)

[issue33296] datetime.datetime.utcfromtimestamp call decimal causes precision loss

Dong-hee Na added the comment: Looks like this issue is related with bpo-23607. Since a decimal object is failed on PyFloat_Check(obj) of _PyTime_ObjectToDenominator, This regression bug is happened due to no chance to get float value from a Decimal object.

[issue32790] Keep trailing zeros in precision for string format option g

Change by Bharat Chhabra : -- keywords: +patch pull_requests: +6320 stage: needs patch -> patch review ___ Python tracker ___

[issue32790] Keep trailing zeros in precision for string format option g

Change by Cheryl Sabella : -- keywords: +easy stage: -> needs patch versions: +Python 3.8 ___ Python tracker ___

[issue33296] datetime.datetime.utcfromtimestamp call decimal causes precision loss

Shlomo Anglister added the comment: The test code demonstrates that fromutctimestamp(1523510588.436252000) != fromutctimestamp(Decimal(1523510588.436252000)) This is related to issues: 22627 and 23607 but not a duplicate --

[issue33296] datetime.datetime.utcfromtimestamp call decimal causes precision loss

files: timestamp_decimal_test.py messages: 315385 nosy: anglister priority: normal severity: normal status: open title: datetime.datetime.utcfromtimestamp call decimal causes precision loss type: behavior versions: Python 3.4, Python 3.5, Python 3.6 Added file: https://bugs.python.org/file47538/timestamp_decimal_t

[issue32790] Keep trailing zeros in precision for string format option g

Mark Dickinson added the comment: > Maybe the documentation could also add this information in the chart for 'g' > here: Agreed that that would make sense. All the information is *there* in the docs (the alternate format is described a bit above that table), but it's not

[issue32790] Keep trailing zeros in precision for string format option g

Severin Wünsch added the comment: This meet my needs. Maybe the documentation could also add this information in the chart for 'g' here: https://docs.python.org/3.7/library/string.html#format-specification-mini-language as only into the running text. As I did not notice

[issue32790] Keep trailing zeros in precision for string format option g

Mark Dickinson added the comment: The behaviour here is intentional, though the reasons for doing it this way are at least partly historical: it's the way that %g formatting works in C's *printf functions (see C99 7.19.6.1p8 for details), and as a direct result of that

[issue32790] Keep trailing zeros in precision for string format option g

New submission from Severin Wünsch <swuen...@gmail.com>: The documentation starts the the string format parameter 'g': General format. For a given precision p >= 1, this rounds the number to **p significant digits** and then formats the result in either fixed-point format or in s

[issue32522] Add precision argument to datetime.now

Paul Ganssle added the comment: > Still, this feature is not appealing enough to try to squeeze into 3.7 > release schedule. I think this should go through a round of discussion > either on datetime-sig or python-ideas. Agreed. I will put together some summary in the

[issue32522] Add precision argument to datetime.now

Alexander Belopolsky added the comment: > (And, honestly, `dateutil` would provide a version-independent backport > anyway). Why not start with that? Remember: python standard library is where code goes to die. By implementing this feature in dateutil you

[issue32522] Add precision argument to datetime.now

Alexander Belopolsky <alexander.belopol...@gmail.com> added the comment: I am about +0 on adding a keyword argument to datetime.now. Note that as I wrote in issue 19475 (msg202242), "precision" may be a misleading name because python makes no guarantee about the precision

[issue32522] Add precision argument to datetime.now

Paul Ganssle <p.gans...@gmail.com> added the comment: > This can be accomplished rather efficiently by truncating a time tuple: This will not preserve tzinfo, and (though this is not a concern unless nanosecond precision is added), I don't believe it preserves microseconds either.

[issue32522] Add precision argument to datetime.now

Alexander Belopolsky added the comment: > replacing all elements of a datetime below a certain level is a very common > idiom This can be accomplished rather efficiently by truncating a time tuple: >>> t = datetime.now() >>> datetime(*t.timetuple()[:6])

[issue32522] Add precision argument to datetime.now

Alexander Belopolsky added the comment: > I think that a "truncate to rrule" function is *way* beyond the scope of the > standard library I agree and I did not propose that. What I said was that in the process of implementing truncate to rrule in dateutil you

[issue32522] Add precision argument to datetime.now

def truncate(dt, timespec): return dt.fromisoformat(dt.isoformat(timespec=timespec)) I think the fact that `timespec` is useful indicates why this is useful even before serialization - a lot of times you want a datetime *up to a specific precision*. I would also argue that the fa

[issue32522] Add precision argument to datetime.now

Alexander Belopolsky added the comment: The problem that I have with the round/truncate proposal is that it is not general enough. Days, hours, minutes etc. are just arbitrary intervals that became popular for obscure historical and astronomical reasons. In

[issue32522] Add precision argument to datetime.now

Barry A. Warsaw added the comment: On Jan 9, 2018, at 08:33, Paul Ganssle wrote: > @Barry I don't think it's a good idea to duplicate the `replace` > functionality in `datetime` like that. I think the main problem isn't the > `.replace`, it's the

[issue32522] Add precision argument to datetime.now

Paul Ganssle added the comment: > In my experience, when dealing with temporal data truncation (rounding > towards -infinity) is more useful than any other form of rounding. See also > issue 19475. Ah, I agree - if you see that's how my __round__ implementation works. I

[issue32522] Add precision argument to datetime.now

Alexander Belopolsky added the comment: In my experience, when dealing with temporal data truncation (rounding towards -infinity) is more useful than any other form of rounding. See also issue 19475. -- ___ Python

[issue32522] Add precision argument to datetime.now

Paul Ganssle added the comment: One thing to note, the "example implementation" of __round__ above is an actual working prototype*: >>> round(Datetime.now(), 'second') Datetime(2018, 1, 9, 11, 59, 35) >>> round(Datetime.now(), 'day') Datetime(2018, 1, 9, 0, 0) >>>

[issue32522] Add precision argument to datetime.now

edelta` is a bit of a stretch in my opinion, and also is limited to well-defined units (and as such you can't round to the nearest month or year). I think a `round` taking either a string or an enum is the simplest, easiest to understand implementation (and/or adding a precision argument t

[issue32522] Add precision argument to datetime.now

Alexander Belopolsky added the comment: Maybe __round__ can be generalized to take a timedelta instead of ndigits? For some related prior art, take a look at . -- ___

  1   2   3   4   5   6   7   8   >