In article ,
Chris Rebert wrote:
>On Thu, Jul 8, 2010 at 8:52 AM, Giacomo Boffi wrote:
>> "Zooko O'Whielacronx" writes:
>>>
>>> I'm starting to think that one should use Decimals by default and
>>> reserve floats for special cases.
>>
>> would you kindly lend me your Decimals ruler? i need to m
David Mainzer wrote:
>
>All your comments helped me and now i know how it works in python !
This has nothing to do with Python. What you're seeing is the way IEEE-754
floating point arithmetic works. You'd see these same results in any
programming language, including a
On Jul 8, 9:52 pm, Wolfram Hinderer
wrote:
> JFTR, it works because a+b == a+b (while I don't think that a+b == b+a
> holds for all a and b).
Actually, that's one of the few identities that's safe. Well, for non-
NaN IEEE 754 floating-point, at any rate. And assuming that there's
no use of exte
Wolfram Hinderer writes:
> JFTR, it works because a+b == a+b (while I don't think that a+b == b+a
> holds for all a and b).
I'm pretty sure IEEE 754 addition is always commutative (except maybe in
the presence of infinity or NaN and maybe not even then). It differs from
rational or real-number
On 8 Jul., 15:10, Ethan Furman wrote:
> Interesting. I knew when I posted my above comment that I was ignoring
> such situations. I cannot comment on the code itself as I am unaware of
> the algorithm, and haven't studied numbers extensively (although I do
> find them very interesting).
>
> So
On Jul 8, 2:00 pm, Stefan Krah wrote:
>
> This whole argument is a misunderstanding. Mark and I argue that correct
> rounding is quite feasible in practice, you argue that you want guaranteed
> execution times and memory usage. This is clear now, but was not so apparent
> in the "impossible" parag
On Thu, Jul 8, 2010 at 11:22 AM, Adam Skutt wrote:
> On Jul 8, 12:38 pm, "Zooko O'Whielacronx" wrote:
>> Now as a programmer you have two choices:
…
>> 1. accept what they typed in and losslessly store it in a decimal:
…
>> 2. accept what they typed in and lossily convert it to a float:
> No, yo
Mark Dickinson wrote:
> On Jul 8, 2:59 pm, Stefan Krah wrote:
> > pow() is trickier. Exact results have to be weeded out before
> > attempting the correction loop for correct rounding, and this is
> > complicated.
> >
> > For example, in decimal this expression takes a long time (in cdecimal
> >
Adam Skutt wrote:
> > > I actually agree with much of what you've said. It was just the
> > "impossible" claim that went over the top (IMO). The MPFR library
> > amply demonstrates that computing many transcendental functions to
> > arbitrary precision, with correctly rounded results, is indeed
On Jul 8, 12:38 pm, "Zooko O'Whielacronx" wrote:
> On Thu, Jul 8, 2010 at 4:58 AM, Adam Skutt wrote:
>
> > I can't think of any program I've ever written where the inputs are
> > actually intended to be decimal. Consider a simple video editing
> > program, and the user specifies a frame rate 23.
On Jul 8, 2:59 pm, Stefan Krah wrote:
> pow() is trickier. Exact results have to be weeded out before
> attempting the correction loop for correct rounding, and this is
> complicated.
>
> For example, in decimal this expression takes a long time (in cdecimal
> the power function is not correctly r
On Jul 8, 11:36 am, Mark Dickinson wrote:
> I think that's because we're talking at cross-purposes.
>
> To clarify, suppose you want to compute some value (pi; log(2);
> AGM(1, sqrt(2)); whatever...) to 1000 significant decimal places.
> Then typically the algorithm (sometimes known as Ziv's onio
On Thu, Jul 8, 2010 at 4:58 AM, Adam Skutt wrote:
>
> I can't think of any program I've ever written where the inputs are
> actually intended to be decimal. Consider a simple video editing
> program, and the user specifies a frame rate 23.976 fps. Is that what
> they really wanted? No, they wan
On Thu, Jul 8, 2010 at 8:52 AM, Giacomo Boffi wrote:
> "Zooko O'Whielacronx" writes:
>> I'm starting to think that one should use Decimals by default and
>> reserve floats for special cases.
>
> would you kindly lend me your Decimals ruler? i need to measure the
> sides of the triangle whose area
"Zooko O'Whielacronx" writes:
> I'm starting to think that one should use Decimals by default and
> reserve floats for special cases.
would you kindly lend me your Decimals ruler? i need to measure the
sides of the triangle whose area i have to compute
--
http://mail.python.org/mailman/listinfo
On Jul 8, 3:29 pm, Adam Skutt wrote:
> On Jul 8, 9:22 am, Mark Dickinson wrote:
> > On Jul 8, 2:00 pm, Adam Skutt wrote:
> > > For some computations, the number of bits required to
> > > get the desired precision can quickly overwhelm the finite limitations
> > > of your machine (e.g., you run o
Zooko O'Whielacronx wrote:
> I'm starting to think that one should use Decimals by default and
> reserve floats for special cases.
Only if one has Power6 (or 7) which has hardware support for BCD.
Otherwise you will have slow applications.
Victor.
--
Victor Eijkhout -- eijkhout at tacc utexas
On Jul 8, 9:22 am, Mark Dickinson wrote:
> On Jul 8, 2:00 pm, Adam Skutt wrote:
>
> > On Jul 8, 7:23 am, Mark Dickinson wrote:> On Jul 8,
> > 11:58 am, Adam Skutt wrote:
>
> > > > accurately. Moreover, in general, it's impossible to even round
> > > > operations involving transcendental funct
Adam Skutt wrote:
> On Jul 8, 7:23 am, Mark Dickinson wrote:
> > On Jul 8, 11:58 am, Adam Skutt wrote:
> >
> > > accurately. Moreover, in general, it's impossible to even round
> > > operations involving transcendental functions to an arbitrary fixed-
> > > precision, you may need effectively i
On Jul 8, 2:00 pm, Adam Skutt wrote:
> On Jul 8, 7:23 am, Mark Dickinson wrote:> On Jul 8,
> 11:58 am, Adam Skutt wrote:
>
> > > accurately. Moreover, in general, it's impossible to even round
> > > operations involving transcendental functions to an arbitrary fixed-
> > > precision, you may n
Wolfram Hinderer wrote:
On 7 Jul., 19:32, Ethan Furman wrote:
Nobody wrote:
On Wed, 07 Jul 2010 15:08:07 +0200, Thomas Jollans wrote:
you should never rely on a floating-point number to have exactly a
certain value.
"Never" is an overstatement. There are situations where you can rely
u
On Jul 8, 7:23 am, Mark Dickinson wrote:
> On Jul 8, 11:58 am, Adam Skutt wrote:
>
> > accurately. Moreover, in general, it's impossible to even round
> > operations involving transcendental functions to an arbitrary fixed-
> > precision, you may need effectively infinite precision in order to t
On 07/07/2010 08:08 PM, Raymond Hettinger wrote:
> On Jul 7, 5:55 am, Mark Dickinson wrote:
>> On Jul 7, 1:05 pm, david mainzer wrote:
>>
>>
>>
>>> Dear Python-User,
>>
>>> today i create some slides about floating point arithmetic. I use
On Jul 8, 12:53 am, "Zooko O'Whielacronx" wrote:
> I don't understand. I described two different problems: problem one is
> that the inputs, outputs and literals of your program might be in a
> different encoding (in my experience they have most commonly been in
> decimal). Problem two is that you
On Thu, 08 Jul 2010 06:04:33 +0200, David Cournapeau wrote:
> On Thu, Jul 8, 2010 at 5:41 AM, Zooko O'Whielacronx
> wrote:
>> I'm starting to think that one should use Decimals by default and
>> reserve floats for special cases.
>>
>> This is somewhat analogous to the way that Python provides
>>
On Wed, Jul 7, 2010 at 10:04 PM, David Cournapeau wrote:
>
> Decimal vs float is a different matter altogether: decimal has
> downsides compared to float. First, there is this irreconcilable fact
> that no matter how small your range is, it is impossible to represent
> exactly all (even most) numb
On Thu, Jul 8, 2010 at 5:41 AM, Zooko O'Whielacronx wrote:
> I'm starting to think that one should use Decimals by default and
> reserve floats for special cases.
>
> This is somewhat analogous to the way that Python provides
> arbitrarily-big integers by default and Python programmers only use
>
I'm starting to think that one should use Decimals by default and
reserve floats for special cases.
This is somewhat analogous to the way that Python provides
arbitrarily-big integers by default and Python programmers only use
old-fashioned fixed-size integers for special cases, such as
interopera
On 7 Jul., 19:32, Ethan Furman wrote:
> Nobody wrote:
> > On Wed, 07 Jul 2010 15:08:07 +0200, Thomas Jollans wrote:
>
> >> you should never rely on a floating-point number to have exactly a
> >> certain value.
>
> > "Never" is an overstatement. There are situations where you can rely
> > upon a fl
On Jul 7, 5:55 am, Mark Dickinson wrote:
> On Jul 7, 1:05 pm, david mainzer wrote:
>
>
>
> > Dear Python-User,
>
> > today i create some slides about floating point arithmetic. I used an
> > example from
>
> >http://docs.python.org/tutorial/floatingpoint
Nobody wrote:
On Wed, 07 Jul 2010 15:08:07 +0200, Thomas Jollans wrote:
you should never rely on a floating-point number to have exactly a
certain value.
"Never" is an overstatement. There are situations where you can rely
upon a floating-point number having exactly a certain value.
It's no
deterministic, and follows relatively simple
rules. Even if the CPU has a built-in random number generator, it will
*not* be used to generate the least-significant bits of a floating-point
arithmetic result.
The second and third cases above assume that floating-point arithmetic
follows IEEE-754 (the s
david mainzer wrote:
sum = 0.0
for i in range(10):
... sum += 0.1
...
sum
0.99989
But thats looks a little bit wrong for me ... i must be a number
greater
then 1.0 because 0.1 =
0.155511151231257827021181583404541015625000
in python ... if i print i
david mainzer wrote:
sum = 0.0
for i in range(10):
... sum += 0.1
...
sum
0.99989
But thats looks a little bit wrong for me ... i must be a number
greater
then 1.0 because 0.1 =
0.155511151231257827021181583404541015625000
in python ... if i print i
On Jul 7, 2010, at 9:08 AM, Thomas Jollans wrote:
On 07/07/2010 02:05 PM, david mainzer wrote:
today i create some slides about floating point arithmetic. I used an
example from
http://docs.python.org/tutorial/floatingpoint.html
so i start the python shell on my linux machine:
d...@maxwell
> can anybody tell me how python internal represent a float number??
It's an IEEE 754 double precision float on all hardware platforms that
support IEEE 754 semantics. Python follows the C99 standards for double
and complex numbers.
Christian
--
http://mail.python.org/mailman/listinfo/python-li
On 07/07/2010 02:05 PM, david mainzer wrote:
> today i create some slides about floating point arithmetic. I used an
> example from
>
> http://docs.python.org/tutorial/floatingpoint.html
>
> so i start the python shell on my linux machine:
>
> d...@maxwell $ python
&
On Jul 7, 1:05 pm, david mainzer wrote:
> Dear Python-User,
>
> today i create some slides about floating point arithmetic. I used an
> example from
>
> http://docs.python.org/tutorial/floatingpoint.html
>
> so i start the python shell on my linux machine:
>
> d...@m
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA384
Dear Python-User,
today i create some slides about floating point arithmetic. I used an
example from
http://docs.python.org/tutorial/floatingpoint.html
so i start the python shell on my linux machine:
d...@maxwell $ python
Python 2.6.5
Dear Python-User,
today i create some slides about floating point arithmetic. I used an
example from
http://docs.python.org/tutorial/floatingpoint.html
so i start the python shell on my linux machine:
d...@maxwell $ python
Python 2.6.5 (release26-maint, May 25 2010, 12:37:06)
[GCC 4.3.4] on
En Tue, 26 Aug 2008 18:11:30 -0300, fred8865 <[EMAIL PROTECTED]> escribi�:
I understand that due to different arithmetic used in floating points
they are just approximations. Hence, 180/100=1 in my python interpreter.
How can I tackle this problem of inaccurate floating point numbers?
thank you
John Machin wrote:
On Aug 27, 7:11 am, fred8865 <[EMAIL PROTECTED]> wrote:
I understand that due to different arithmetic used in floating points
they are just approximations. Hence, 180/100=1 in my python interpreter.
It's not "hence". What you are seeing is truncating integer division.
H
thanks guys
fred8865 wrote:
> Hi all,
>
> I understand that due to different arithmetic used in floating points
> they are just approximations. Hence, 180/100=1 in my python interpreter.
> How can I tackle this problem of inaccurate floating point numbers?
> thank you
>
> regards
> xtd
--
http
On Aug 27, 7:11 am, fred8865 <[EMAIL PROTECTED]> wrote:
> I understand that due to different arithmetic used in floating points
> they are just approximations. Hence, 180/100=1 in my python interpreter.
It's not "hence". What you are seeing is truncating integer division.
> How can I tackle this
On Aug 26, 4:11 pm, fred8865 <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I understand that due to different arithmetic used in floating points
> they are just approximations. Hence, 180/100=1 in my python interpreter.
> How can I tackle this problem of inaccurate floating point numbers?
Try actually
> I understand that due to different arithmetic used in floating points
> they are just approximations. Hence, 180/100=1 in my python interpreter.
No, that's not the reason you get 1, it's because the current version
of python does integer division by default. Try doing 180.0/100 or
including
fro
Hi all,
I understand that due to different arithmetic used in floating points
they are just approximations. Hence, 180/100=1 in my python interpreter.
How can I tackle this problem of inaccurate floating point numbers?
thank you
regards
xtd
--
http://mail.python.org/mailman/listinfo/python-list
47 matches
Mail list logo
