On Sat, 18 Feb 2023 at 11:19, Peter J. Holzer wrote:
>
> 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
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.
On Sat, 18 Feb 2023 at 01:47, Chris Angelico wrote:
>
> 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
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,
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
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,
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
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
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
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
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
On 2023-02-17 08:38:58 -0700, Michael Torrie wrote:
> On 2/17/23 03:27, 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.
>
> No matter
On Fri, 17 Feb 2023 at 10:29, 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.
[snip]
>
> Perhaps this observation should be brought to the
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.
On 2/17/23 03:27, 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.
No matter how you do it, there are always tradeoffs and inaccuracies
moving
On Fri, 17 Feb 2023 10:27:08, Stephen Tucker wrote:[Head-posting undone.]
> 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
?
-Original Message-
From: Python-list On
Behalf Of Stephen Tucker
Sent: Friday, February 17, 2023 5:27 AM
To: python-list@python.org
Subject: Re: Precision Tail-off?
Thanks, one and all, for your reponses.
This is a hugely controversial claim, I know, but I would consider this
behaviour
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
On 2/17/2023 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
As a follow-up to my previous message, I have just produced the following
log on IDLE, for your information:
--
>>> math.e ** (math.log
(12345678900) / 3)
4.979338592181741e+16
>>> 10 ** (math.log10
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.
Consider the infinitely-precise cube root
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 to show a precision tail-off as
)
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
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
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
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:
>
Às 23:29 de 11-03-2017, Erik escreveu:
> Hi Paulo,
>
> On 11/03/17 22:01, Paulo da Silva wrote:
...
>> Now my question is: Is it possible the occurrence of successive
>> cumulative errors? I mean reading a file, adding lines or change few
>> ones but keeping the most of the other lines untouched
Hi Paulo,
On 11/03/17 22:01, Paulo da Silva wrote:
I have a dir with lots of csv files. These files are updated +- once a
day. I could see that some values are converted, during output, to very
close values but with lots of digits. I understand that is caused by the
internal bits'
On 2017-03-11 22:01, Paulo da Silva wrote:
Hi!
I have a dir with lots of csv files. These files are updated +- once a
day. I could see that some values are converted, during output, to very
close values but with lots of digits. I understand that is caused by the
internal bits' representation of
On Feb 20, 11:17 am, mukesh tiwari mukeshtiwari.ii...@gmail.com
wrote:
Hello everyone. I think it is related to the precision with double
arithmetic so i posted here.I am trying with this problem
(https://www.spoj.pl/problems/CALCULAT) and the problem say that Note : for
all test cases whose
A quick solution I came out with, no stirling numbers and had tried to avoid
large integer multiplication as much as possible.
import math
for i in range(int(raw_input())):
n, k, l = [int(i) for i in raw_input().split()]
e = sum(math.log10(i) for i in range(1, n+1))
frac_e = e -
On Feb 20, 5:44 pm, Mark Dickinson dicki...@gmail.com wrote:
On Feb 20, 11:17 am, mukesh tiwari mukeshtiwari.ii...@gmail.com
wrote:
Hello everyone. I think it is related to the precision with double
arithmetic so i posted here.I am trying with this problem
On Feb 20, 8:13 pm, mukesh tiwari mukeshtiwari.ii...@gmail.com
wrote:
On Feb 20, 5:44 pm, Mark Dickinson dicki...@gmail.com wrote:
On Feb 20, 11:17 am, mukesh tiwari mukeshtiwari.ii...@gmail.com
wrote:
Hello everyone. I think it is related to the precision with double
arithmetic
I don't know if is possible to import this decimal module but kindly
tell me.Also a bit about log implementation
Why don't you read about decimal module (there is log too in it) and try
writing your approach here in case it does not work? Or you insist someone
to rewrite your code using decimal
On Feb 20, 3:37 pm, mukesh tiwari mukeshtiwari.ii...@gmail.com
wrote:
I don't know if is possible to import this decimal module but kindly
tell me.Also a bit about log implementation
The decimal module is part of the standard library; I don't know what
the rules are for SPOJ, but you're
On Sat, Feb 20, 2010 at 2:42 PM, Shashwat Anand
anand.shash...@gmail.com wrote:
A quick solution I came out with, no stirling numbers and had tried to avoid
large integer multiplication as much as possible.
import math
for i in range(int(raw_input())):
n, k, l = [int(i) for i in
@Mark,
The str(...).split('.') here doesn't do a good job of extracting the
integer part when its argument is = 1e12, since Python produces a
result in scientific notation. I think you're going to get strange
results when k = 13.
Yeah, you were correct. I tested it for k = 13, and there
On Mon, 28 Nov 2005 07:58:37 -0800, [EMAIL PROTECTED] (Alex Martelli) wrote:
Anton81 [EMAIL PROTECTED] wrote:
Hi!
When I do simple calculation with float values, they are rarely exactly
equal even if they should be. What is the threshold and how can I change
it?
Python's builtin floats
Anton81 wrote:
Hi!
When I do simple calculation with float values, they are rarely exactly
equal even if they should be. What is the threshold and how can I change
it?
e.g. if f1==f2: will always mean if abs(f1-f2)1e-6:
Anton
googled for floating point comparison tolerance
On Tue, 29 Nov 2005 14:31:46 GMT,
[EMAIL PROTECTED] (Bengt Richter) wrote:
On Mon, 28 Nov 2005 07:58:37 -0800, [EMAIL PROTECTED] (Alex Martelli) wrote:
Python's builtin floats compare for exact bit-by-bit equality -- no
threshold. You may want to look at the allclose function in the
Does
Anton81 [EMAIL PROTECTED] wrote:
Hi!
When I do simple calculation with float values, they are rarely exactly
equal even if they should be. What is the threshold and how can I change
it?
Python's builtin floats compare for exact bit-by-bit equality -- no
threshold. You may want to look at
Anton81 wrote:
When I do simple calculation with float values, they are rarely exactly
equal even if they should be. What is the threshold
http://www.lahey.com/float.htm
http://docs.python.org/tut/node16.html
and how can I change it?
you cannot.
e.g. if f1==f2: will always mean if
Anton81 [EMAIL PROTECTED] writes:
When I do simple calculation with float values, they are rarely exactly
equal even if they should be. What is the threshold and how can I change
it?
Implementation dependent, because floats use an underlying C type, and
there's no portable way to do that.
On Mon, 28 Nov 2005 12:35:16 -0500, Mike Meyer wrote:
e.g. if f1==f2: will always mean if abs(f1-f2)1e-6:
This is a *bad* idea. What happens if f1=1e-12 and f2=1e-112? Do you
really want to values that 100 orders of magnitude different to
compare as equal?
Sure, if f1 and f2 represent
Raymond Hettinger wrote:
For a simple example, convert both 10247448370872321 and
10247448370872319 from base ten to 4 digits of hex. The calculations
need to be carried out to 15 places of hex (or 17 places of decimal)
just to determine whether the fourth hex digit is a 7 or 8:
[Terry Hancock]
Needless to say, the conventional floating point numbers in Python
are actually stored as *binary*, which is why there is a decimal
module (which is new).
If you're going to be converting between bases anyway, it probably
makes little difference whether you are using
Raymond Hettinger wrote:
[Terry Hancock]
Needless to say, the conventional floating point numbers in Python
are actually stored as *binary*, which is why there is a decimal
module (which is new).
If you're going to be converting between bases anyway, it probably
makes little
For a simple example, convert both 10247448370872321 and
10247448370872319 from base ten to 4 digits of hex. The calculations
need to be carried out to 15 places of hex (or 17 places of decimal)
just to determine whether the fourth hex digit is a 7 or 8:
hex(10247448370872321)
On Monday 04 July 2005 06:11 am, Brian van den Broek wrote:
As a self-directed learning exercise I've been working on a script to
convert numbers to arbitrary bases. It aims to take any of whole
numbers (python ints, longs, or Decimals), rational numbers (n / m n,
m whole) and floating
Brian van den Broek wrote:
Hi all,
I guess it is more of a maths question than a programming one, but it
involves use of the decimal module, so here goes:
As a self-directed learning exercise I've been working on a script to
convert numbers to arbitrary bases. It aims to take any of whole
Terry Hancock said unto the world upon 05/07/2005 11:49:
On Monday 04 July 2005 06:11 am, Brian van den Broek wrote:
As a self-directed learning exercise I've been working on a script to
convert numbers to arbitrary bases. It aims to take any of whole
numbers (python ints, longs, or
Brian van den Broek wrote:
Hi all,
I guess it is more of a maths question than a programming one, but it
involves use of the decimal module, so here goes:
As a self-directed learning exercise I've been working on a script to
convert numbers to arbitrary bases. It aims to take any of whole
So for using the python-interpreter as a simple calculator using
'print' seems to be the simplest and still exact way...
Thanks for clarification
Steffen
--
http://mail.python.org/mailman/listinfo/python-list
tiissa wrote:
Steffen Glückselig wrote:
1.0 + 3.0 + 4.6
8.5996
Ehm, how could I get the intuitively 'correct' result of - say - 8.6?
;-)
You may find annex B of the python tutorial an interesting read:
http://docs.python.org/tut/node16.html
Yes, the simplest way to get
tiissa wrote:
Steffen Glückselig wrote:
1.0 + 3.0 + 4.6
8.5996
Ehm, how could I get the intuitively 'correct' result of - say - 8.6?
;-)
You may find annex B of the python tutorial an interesting read:
http://docs.python.org/tut/node16.html
In addition to what you find in
If you want to do decimal arithmetic, use the decimal module which is
new in Python 2.4.
Python 2.4 (#1, Jan 22 2005, 20:45:18)
[GCC 3.3.3 20040412 (Red Hat Linux 3.3.3-7)] on linux2
Type help, copyright, credits or license for more information.
from decimal import Decimal as D
D(1.0) + D(3.0)
Steffen Glckselig [EMAIL PROTECTED] writes:
Hello,
I've just wanted to check Python's abilities as a calculator and this
is what came out:
1.0 + 3.0 + 4.6
8.5996
Ehm, how could I get the intuitively 'correct' result of - say - 8.6?
;-)
This is as correct as your computer's
On 5/15/05, Ron Adam [EMAIL PROTECTED] wrote:
x
321.61
Here the error has been kept to a minimum. In most cases, it isn't a
problem, but it is something to be aware of. It does matter in banking
and I beleive there are standard ways of dealing with it.
Yes, use Decimal:
58 matches
Mail list logo
