Il Thu, 24 Jun 2021 18:07:07 +0200, Julio Di Egidio ha scritto:
> On 24/06/2021 16:23, jo wrote:
>> Hi,
>>
>> this code generate 4 values with gaussian distribution (mu=5, sigma=1):
>>
>> import numpy as np x = np.random.normal(5, 1, 4)
>> print(x)
>>
>> Output:
>> [5.87879753 3.29162433 3.8302
On Thu, 07 Jun 2018 13:09:18 +0200, ast wrote:
> Hi
>
> round is supposed to provide an integer when called without any
> precision argument.
True, but that's really under the control of the object you feed it to.
It would be possible for round() to enforce that, but it might break code
that r
ast wrote:
> Hi
>
> round is supposed to provide an integer when
> called without any precision argument.
>
> here is the doc:
>
> >>> help(round)
>
> round(number[, ndigits]) -> number
>
> Round a number to a given precision in decimal digits (default 0 digits).
> This returns an int when c
M = np.array([[0, 9],[2, 7]], dtype=int)
np.linalg.det(M)
-18.004
round(np.linalg.det(M))
np.linalg.det(M) has type numpy.float64, not float. Try this:
round(float(np.linalg.det(M)))
-18
Lutz
--
https://mail.python.org/mailman/listinfo/python-list
On Thu, 7 Dec 2017 01:31 pm, nick martinez wrote:
> interesting, what version of python are you using? Tried it multiple times
> and it still isn't working.
Please launch a terminal window, copy this command exactly into the terminal
and hit ENTER. You should have a $ or maybe % prompt for this
On Thu, 7 Dec 2017 11:58 am, nick martinez wrote:
> I'm stuck. I need my program to round the end solution to 2 decimal places
> but cant figure it out. Can someone help? I've been trying between printf
> and round() but cant seem to get either to work.
It might help if you show exactly what valu
On Wednesday, December 6, 2017 at 9:32:27 PM UTC-5, nick martinez wrote:
> On Wednesday, December 6, 2017 at 9:03:27 PM UTC-5, ssghot...@gmail.com wrote:
> > On Thursday, December 7, 2017 at 12:39:38 PM UTC+11, nick martinez wrote:
> > > On Wednesday, December 6, 2017 at 8:13:36 PM UTC-5, ssghot...
On Wednesday, December 6, 2017 at 9:03:27 PM UTC-5, ssghot...@gmail.com wrote:
> On Thursday, December 7, 2017 at 12:39:38 PM UTC+11, nick martinez wrote:
> > On Wednesday, December 6, 2017 at 8:13:36 PM UTC-5, ssghot...@gmail.com
> > wrote:
> > > The following works:
> > >
> > > import math
> >
On 2017-12-07 01:39, nick martinez via Python-list wrote:
On Wednesday, December 6, 2017 at 8:13:36 PM UTC-5, ssghot...@gmail.com wrote:
The following works:
import math
print("This program will calculate the surface area and volume of a 3-dimensional
cone: ")
print()
print()
r = input("What
On Thursday, December 7, 2017 at 12:39:38 PM UTC+11, nick martinez wrote:
> On Wednesday, December 6, 2017 at 8:13:36 PM UTC-5, ssghot...@gmail.com wrote:
> > The following works:
> >
> > import math
> >
> > print("This program will calculate the surface area and volume of a
> > 3-dimensional co
On Wednesday, December 6, 2017 at 8:13:36 PM UTC-5, ssghot...@gmail.com wrote:
> The following works:
>
> import math
>
> print("This program will calculate the surface area and volume of a
> 3-dimensional cone: ")
> print()
> print()
> r = input("What is the radius in feet? (no negatives): ")
>
import math
print("This program will calculate the surface area and volume of a
3-dimensional cone: ")
print()
print()
r = input("What is the radius in feet? (no negatives): ")
h = input("What is the height in feet? (no negatives): ")
r = float(r)
h = float(h)
if r > 0 and h > 0:
surfacearea
The following works:
import math
print("This program will calculate the surface area and volume of a
3-dimensional cone: ")
print()
print()
r = input("What is the radius in feet? (no negatives): ")
h = input("What is the height in feet? (no negatives): ")
r = float(r)
h = float(h)
if r > 0 and h
On Saturday 30 March 2013 03:14 PM, Peter Otten wrote:
> style = xlwt.XFStyle()
> style.num_format_str = "0.00"
Yes. That was really helpful & what I expected.
Thank you.
--
http://mail.python.org/mailman/listinfo/python-list
On 03/30/2013 10:41 AM, Dennis Lee Bieber wrote:
> On Sat, 30 Mar 2013 13:22:59 +0530, ??? declaimed
> the following in gmane.comp.python.general:
>
>> Consider the scenario,
>>
>> >> a = 10
>> >> "{0:.2f}".format(a)
>> '10.00'
>>
>> This returns a string 10.00. But what is the preferred me
On 2013-03-30, ? wrote:
> On Saturday 30 March 2013 02:58 PM, Roland Mueller wrote:
>>
>>
>>
>> I assume you have a numeric value a and want to have a float with 2
>> decimals. This can be achieved with the function round():
>
> But I need 10.00 and not 10.0
They're the same
2013/3/30 Roland Mueller
> Hello,
>
> 2013/3/30 ஆமாச்சு
>
>> Consider the scenario,
>>
>> >> a = 10
>> >> "{0:.2f}".format(a)
>> '10.00'
>>
>> This returns a string 10.00. But what is the preferred method to retain
>> 10.0 (float) as 10.00 (float)?
>>
>> I assume you have a numeric value a and w
ஆமாச்சு wrote:
> Consider the scenario,
>
>>> a = 10
>>> "{0:.2f}".format(a)
> '10.00'
>
> This returns a string 10.00. But what is the preferred method to retain
> 10.0 (float) as 10.00 (float)?
You can use round() to convert 1.226 to 1.23
>>> round(1.225, 2)
1.23
for example, but 10.0 and 1
On Saturday 30 March 2013 02:58 PM, Roland Mueller wrote:
>
>
>
> I assume you have a numeric value a and want to have a float with 2
> decimals. This can be achieved with the function round():
But I need 10.00 and not 10.0
--
http://mail.python.org/mailman/listinfo/python-list
Hi Sri.
I'm not familiar with the xlwt module, but I think you are confusing two
different things here.
Generally spreadsheets separate out how they handle the value in a cell (the
value) and how that value is displayed (the format). This means that the you
leave the cell value unchanged when
Hello,
2013/3/30 ஆமாச்சு
> Consider the scenario,
>
> >> a = 10
> >> "{0:.2f}".format(a)
> '10.00'
>
> This returns a string 10.00. But what is the preferred method to retain
> 10.0 (float) as 10.00 (float)?
>
> I assume you have a numeric value a and want to have a float with 2
decimals. This c
Terry Reedy writes:
> On 2/9/2012 8:23 PM, noydb wrote:
>> So how would you round UP always? Say the number is 3219, so you want
(//100+1)*100
> 3400
Note that that doesn't work for numbers that are already round:
>>> (3300//100+1)*100
3400# 3300 would be correct
I'd go with Chri
On Thu, 9 Feb 2012 17:43:58 -0800
Chris Rebert wrote:
> On Thu, Feb 9, 2012 at 5:23 PM, noydb wrote:
> > hmmm, okay.
> >
> > So how would you round UP always? Say the number is 3219, so you
> > want 3300 returned.
>
> http://stackoverflow.com/questions/17944/how-to-round-up-the-result-of-integ
On Feb 10, 4:58 am, Arnaud Delobelle wrote:
> On 10 February 2012 06:21, Ian Kelly wrote:
>
>
>
>
>
> > (3219 + 99) // 100 * 100
> >> 3300
> > (3289 + 99) // 100 * 100
> >> 3300
> > (328678 + 99) // 100 * 100
> >> 328700
> > (328 + 99) // 100 * 100
> >> 400
>
> >> Those are all ro
o.O
Very nice
On Fri, Feb 10, 2012 at 8:58 PM, Arnaud Delobelle wrote:
> On 10 February 2012 06:21, Ian Kelly wrote:
>> (3219 + 99) // 100 * 100
>>> 3300
>> (3289 + 99) // 100 * 100
>>> 3300
>> (328678 + 99) // 100 * 100
>>> 328700
>> (328 + 99) // 100 * 100
>>> 400
>>>
>>> Thos
On 10 February 2012 06:21, Ian Kelly wrote:
> (3219 + 99) // 100 * 100
>> 3300
> (3289 + 99) // 100 * 100
>> 3300
> (328678 + 99) // 100 * 100
>> 328700
> (328 + 99) // 100 * 100
>> 400
>>
>> Those are all rounded up to the nearest 100 correctly.
>
> One thing to be aware of though
On Thu, Feb 9, 2012 at 8:36 PM, MRAB wrote:
> On 10/02/2012 02:25, noydb wrote:
>>
>> That {>>> (3219 + 99) // 100} doesnt work if the number is other then
>> 4 digits.
>>
>>
>> (for rounding up to nearest 100):
>
> (3219 + 99)//100
>>
>> 33
>
> (3289 + 99)//100
>>
>> 33
>
>
On 10/02/2012 03:29, Terry Reedy wrote:
On 2/9/2012 8:23 PM, noydb wrote:
So how would you round UP always? Say the number is 3219, so you want
>>> (//100+1)*100
3400
Doing it that way doesn't always work. For example:
>>> (3400 // 100 + 1) * 100
3500
However:
>>> (3400 + 99) // 1
On 10/02/2012 02:25, noydb wrote:
That {>>> (3219 + 99) // 100} doesnt work if the number is other then
4 digits.
(for rounding up to nearest 100):
(3219 + 99)//100
33
(3289 + 99)//100
33
(328678 + 99)//100
3287
(328 + 99)//100
4
>>> (3219 + 99) // 100 * 100
3300
>>> (3289 + 99)
On 2/9/2012 8:23 PM, noydb wrote:
So how would you round UP always? Say the number is 3219, so you want
>>> (//100+1)*100
3400
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
That {>>> (3219 + 99) // 100} doesnt work if the number is other then
4 digits.
(for rounding up to nearest 100):
>>> (3219 + 99)//100
33
>>> (3289 + 99)//100
33
>>> (328678 + 99)//100
3287
>>> (328 + 99)//100
4
--
http://mail.python.org/mailman/listinfo/python-list
On Thu, Feb 9, 2012 at 6:43 PM, Chris Rebert wrote:
> On Thu, Feb 9, 2012 at 5:23 PM, noydb wrote:
>> hmmm, okay.
>>
>> So how would you round UP always? Say the number is 3219, so you want
>> 3300 returned.
>
> http://stackoverflow.com/questions/17944/how-to-round-up-the-result-of-integer-divis
On Thu, Feb 9, 2012 at 5:23 PM, noydb wrote:
> hmmm, okay.
>
> So how would you round UP always? Say the number is 3219, so you want
> 3300 returned.
http://stackoverflow.com/questions/17944/how-to-round-up-the-result-of-integer-division/96921
Thus: (3219 + 99) // 100
Slight tangent: Beware ne
On Thu, Feb 9, 2012 at 5:40 PM, Chris Kaynor wrote:
> On Thu, Feb 9, 2012 at 5:23 PM, noydb wrote:
>
>> hmmm, okay.
>>
>> So how would you round UP always? Say the number is 3219, so you want
>> 3300 returned.
>>
>
> You may want to look into the mathematical floor and ceiling functions[1].
> Py
On Thu, Feb 9, 2012 at 5:23 PM, noydb wrote:
> hmmm, okay.
>
> So how would you round UP always? Say the number is 3219, so you want
> 3300 returned.
>
You may want to look into the mathematical floor and ceiling functions[1].
Python exposes them in the math module as floor and ceil[2].
[1] ht
hmmm, okay.
So how would you round UP always? Say the number is 3219, so you want
3300 returned.
--
http://mail.python.org/mailman/listinfo/python-list
On Thu, Feb 9, 2012 at 5:30 PM, noydb wrote:
> How do you round down ALWAYS to nearest 100? Like, if I have number
> 3268, I want that rounded down to 3200. I'm doing my rounding like
round(3268, -2)
> But, how to round DOWN?
>>> 3268 // 100 * 100
3200
For more complicated cases, Decimal
On Dec 28, 9:47 pm, "Martin v. Loewis" wrote:
> >> "Float-to-string and string-to-float conversions are correctly rounded.
> >> The round() function is also now correctly rounded."
>
> >> Not sure that this is correct English; I think it means that the
> >> round() function is now correct.
>
> > W
On 12/28/2010 4:47 PM, Martin v. Loewis wrote:
"Float-to-string and string-to-float conversions are correctly rounded.
The round() function is also now correctly rounded."
The second line was written to be parallel to the first, but the first
is slightly ambiguous in that 'conversions' can ref
>> "Float-to-string and string-to-float conversions are correctly rounded.
>> The round() function is also now correctly rounded."
>>
>> Not sure that this is correct English; I think it means that the
>> round() function is now correct.
>
> Well, the correct result of the example the OP gave woul
On Dec 23, 6:57 pm, Hrvoje Niksic wrote:
> I stumbled upon this. Python 2.6:
>
> >>> round(9.95, 1)
>
> 10.0
>
> So it seems that Python is going out of its way to intuitively round
> 9.95, while the repr retains the unnecessary digits.
No, Python's not doing anything clever here. Python 2.6 us
"Martin v. Loewis" writes:
>> Type "help", "copyright", "credits" or "license" for more information.
> 9.95
>> 9.9493
> "%.16g" % 9.95
>> '9.949'
> round(9.95, 1)
>> 10.0
>>
>> So it seems that Python is going out of its way to intuitively round
>> 9.95, while
Am 23.12.2010 19:57, schrieb Hrvoje Niksic:
I stumbled upon this. Python 2.6:
Python 2.6.6 (r266:84292, Sep 15 2010, 15:52:39)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
9.95
9.9493
"%.16g" % 9.95
'9.949'
round(9.95,
> Type "help", "copyright", "credits" or "license" for more information.
9.95
> 9.9493
"%.16g" % 9.95
> '9.949'
round(9.95, 1)
> 10.0
>
> So it seems that Python is going out of its way to intuitively round
> 9.95, while the repr retains the unnecessary digit
On Dec 23, 4:57 pm, Hrvoje Niksic wrote:
> I stumbled upon this. Python 2.6:
>
> Python 2.6.6 (r266:84292, Sep 15 2010, 15:52:39)
> [GCC 4.4.5] on linux2
> Type "help", "copyright", "credits" or "license" for more information.>>> 9.95
> 9.9493
> >>> "%.16g" % 9.95
> '9.949
On Nov 19, 11:05 am, Eric Frederich wrote:
> I have a proprietary software PropSoft that I need to extend.
> They support extensions written in C that can link against PropLib to
> interact with the system.
>
> I have a Python C module that wraps a couple PropLib functions that I
> call PyProp.>Fr
Eric Frederich writes:
> I have a proprietary software PropSoft that I need to extend.
> They support extensions written in C that can link against PropLib to
> interact with the system.
>
> I have a Python C module that wraps a couple PropLib functions that I
> call PyProp.
>>From an interactive
On 7/13/2010 9:06 AM Robin Becker said...
Anyhow does anyone have a good algorithm for ensuring rounded
percentages do add up to 100%? :) How about grouped percentages ie
ensure the group sums and the groups display correctly in rounded form.
I generally do the calculations in memory then set
On 12/07/2010 19:59, Mark Dickinson wrote:
It does look inconsistent however, and it seems to me rounding and
interpolation should behave similarly.
Agreed. In this case it's a minor bug that round(-9.85, 1)
produces -9.9 instead of -9.8; both string formatting
and round should g
Emile van Sebille fenx.com> writes:
>
> On 7/12/2010 2:52 AM Robin Becker said...
>
> > What value should round(-9.85,1) return?
>
> Per round's definition, -9.9.
No. The float that's represented by the literal '-9.85' *isn't*
exactly -9.85, for all the usual binary floating-point reasons.
T
On 7/12/2010 2:52 AM Robin Becker said...
What value should round(-9.85,1) return?
Per round's definition, -9.9. String interpolation for %n.mf doesn't
appear to define it's rounding behavior, so a peek at the source would
answer what's being done.
It does look inconsistent however, and i
On 07/12/2010 02:52 AM, Robin Becker wrote:
A client wants to know why his db number -9.85 gets displayed by some
simple code as -9.8
I looked at the number and see that
>>> -9.85
-9.8496
ie I expect simple rounding to produce the observed result and indeed
>>> '%.1f' % -9.85
'-9
On Jul 12, 10:52 am, Robin Becker wrote:
> What value should round(-9.85,1) return? Is the result explainable in python
> (ie
> without resort to the internal FP representations etc etc)?
As you observe, the closest float to -9.85 is actually just a little
smaller (i.e., closer to 0) than -9.85:
Am 25.02.2010 16:39, schrieb Tracubik:
hi all, i've this sample code:
n = 4.499
str(round(n,2))
'4.5'
that's right, but what i want is '4.50' to be displayed instead of '4.5'.
Off course i know that 4.5 = 4.50, still i'ld like to have 4.50.
How can I solve this?
Thanks in advance
Nico
Thi
Tracubik, 25.02.2010 16:39:
> hi all, i've this sample code:
>
n = 4.499
str(round(n,2))
> '4.5'
>
> that's right, but what i want is '4.50' to be displayed instead of '4.5'.
> Off course i know that 4.5 = 4.50, still i'ld like to have 4.50.
>
> How can I solve this?
Format the number
On 25.2.2010. 16:39, Tracubik wrote:
hi all, i've this sample code:
n = 4.499
str(round(n,2))
'4.5'
that's right, but what i want is '4.50' to be displayed instead of '4.5'.
Off course i know that 4.5 = 4.50, still i'ld like to have 4.50.
How can I solve this?
Thanks in advanc
Tracubik wrote:
n = 4.499
str(round(n,2))
'4.5'
that's right, but what i want is '4.50' to be displayed instead of '4.5'.
Off course i know that 4.5 = 4.50, still i'ld like to have 4.50.
Use string formatting:
>>> "%0.2f" % round(4.499, 2)
'4.50'
-tkc
--
http://mail.python.org/mailma
On Jul 21, 12:56 am, Mark Dickinson <[EMAIL PROTECTED]> wrote:
> On Jul 19, 12:20 am, John Machin <[EMAIL PROTECTED]> wrote:
>
> > On Jul 19, 8:05 am, Mark Dickinson <[EMAIL PROTECTED]> wrote:
> > > for more information. But I'm guessing that you're
> > > questioning the fact that a value that's a
On Jul 19, 12:20 am, John Machin <[EMAIL PROTECTED]> wrote:
> On Jul 19, 8:05 am, Mark Dickinson <[EMAIL PROTECTED]> wrote:
> > for more information. But I'm guessing that you're
> > questioning the fact that a value that's apparently
> > *less* than 3499.35 is rounded up to 3499.4, rather
> > tha
On Jul 19, 8:05 am, Mark Dickinson <[EMAIL PROTECTED]> wrote:
> On Jul 18, 10:17 pm, Anthony <[EMAIL PROTECTED]> wrote:
>
> > Isn't this a mistake???
>
> Which 'this'? That is, what were you expecting?
>
> If you're objecting to the fact that the second result
> produces 3499.34999 instead
On Jul 18, 11:15 pm, Terry Reedy <[EMAIL PROTECTED]> wrote:
> No, round() return binary floats that, in general, cannot represent
> decimal floats exactly. Formatted printing gives what you expect.
> >>> '%8.2f' % x
> ' 3499.35'
Sure. But it's still true that the second printed value
(printed a
Anthony wrote:
Isn't this a mistake???
round(3499.349439034,44)
3499.3494390340002
round(_,2)
3499.34999
round(_,1)
3499.40001
My Python 2.5.1 spat that out..
No, round() return binary floats that, in general, cannot represent
decimal floats exactly. Formatted printi
On Jul 18, 10:17 pm, Anthony <[EMAIL PROTECTED]> wrote:
> Isn't this a mistake???
Which 'this'? That is, what were you expecting?
If you're objecting to the fact that the second result
produces 3499.34999 instead of 3499.35, then
no, that's not a mistake; see
http://www.python.org/doc/
Bruno Desthuilliers wrote:
> Catherine a écrit :
>> Three possibilities come to mind -
>>
>> 1. I'm missing something simple
>
> Probably. I'd say, something like unzip .egg !-)
That's generally the solution to "egg" files. They usually
do the wrong thing, and the "egg" system is still in be
Catherine a écrit :
> I'd like to use Scriptaculous with TurboGears on Python 2.5.
> Unfortunately, Scriptaculous is currently in the Cheese Shop only as a
> Python 2.4 egg.
>
> If I had the setup.py that was used to generate the egg, I think it
> would be really easy to generate a new Python 2.5
In article <[EMAIL PROTECTED]>,
Tim Leslie <[EMAIL PROTECTED]> wrote:
>On 16 Aug 2006 00:19:24 -0700, Fuzzydave <[EMAIL PROTECTED]> wrote:
>> I have been using a round command in a few places to round
>> a value to zero decimal places using the following format,
>>
>> round('+value+', 0)
>>
>> but
> Sybren Stuvel wrote:
> round returns a float. Use
> int(round('+value+', 0))
> to get an integer.
> Sybren
ahh of course it does, slaps own forehead sorted
thanks :)
David P
--
http://mail.python.org/mailman/listinfo/python-list
On 16 Aug 2006 00:19:24 -0700, Fuzzydave <[EMAIL PROTECTED]> wrote:
> I have been using a round command in a few places to round
> a value to zero decimal places using the following format,
>
> round('+value+', 0)
>
> but this consistantly returns the rounded result of the value
> to one decimal pl
Fuzzydave wrote:
> I have been using a round command in a few places to round
> a value to zero decimal places using the following format,
>
> round('+value+', 0)
>
> but this consistantly returns the rounded result of the value
> to one decimal place with a zero
>
> EG:
>
> 4.97 is returned as 5.0
"Paul McGuire" <[EMAIL PROTECTED]> writes:
> ... or if you prefer the functional approach (using map)...
>
> roundToInt = lambda z : int(z+0.5)
> Topamax = map( roundToInt, map( float, map(str, Topamax) ) )
>
> (Python also has a built-in round() function, but this returns floats, not
> ints - if
Paul McGuire wrote:
> ... or if you prefer the functional approach (using map)...
>
> roundToInt = lambda z : int(z+0.5)
> Topamax = map( roundToInt, map( float, map(str, Topamax) ) )
Somehow, the list comprehension looks simpler and clearer to me:
Topamax = [int(float(uni) + .5) for uni in
"Lance Hoffmeyer" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> The array comes out as unicode. This is probably because I am grabbing
the numbers
> from a Word Doc using regex's.
>
> So, before rounding I perform the following:
> # Convert to String
> Topamax = [str(x) for x in To
"Lance Hoffmeyer" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> The array comes out as unicode. This is probably because I am grabbing
the numbers
> from a Word Doc using regex's.
>
> So, before rounding I perform the following:
> # Convert to String
> Topamax = [str(x) for x in To
The array comes out as unicode. This is probably because I am grabbing the
numbers
from a Word Doc using regex's.
So, before rounding I perform the following:
# Convert to String
Topamax = [str(x) for x in Topamax]
# Convert to floating
Topamax = [float(x) for x in Topamax]
# Finally, round the
On Tue, 16 May 2006 13:41:37 -0500,
Lance Hoffmeyer <[EMAIL PROTECTED]> wrote:
> May have a complicating issue with the array? Have
> the numbers have been interpreted as strings? I have
> been pulling them from a Word doc using regex's
> print Test
> [u'9.0', u'58.6', u'97.8', u'10.0', u'9.6',
Lance> May have a complicating issue with the array? Have the numbers
Lance> have been interpreted as strings? I have been pulling them from
Lance> a Word doc using regex's
[int(float(x)+0.5) for x in Test]
S
--
http://mail.python.org/mailman/listinfo/python-list
May have a complicating issue with the array? Have
the numbers have been interpreted as strings? I have
been pulling them from a Word doc using regex's
print Test
[u'9.0', u'58.6', u'97.8', u'10.0', u'9.6', u'28.1']
Lance
Alexander Schmolck wrote:
> Lance Hoffmeyer <[EMAIL PROTECTED]> writes
Lance Hoffmeyer <[EMAIL PROTECTED]> writes:
> Is there an easy way to round numbers in an array?
>
> I have
> Test = [1.1,2.2,3.7]
>
> and want to round so the values are
>
> print Test [1,2,4]
[int(x+0.5) for x in Test]
'as
--
http://mail.python.org/mailman/listinfo/python-list
thank you very much to you
i wish you a nice sunday...
cu
Heidi
--
http://mail.python.org/mailman/listinfo/python-list
No! That is NOT correct Python. For one thing, you do not declare the
types in dynamically typed languages. Secondly, if you want floating
point division, you need to enter atleast one of the numbers as float.
For example
10.0/6
or
10./6
or
float(10)/6
You will find the following helpful.
http://
HeidiWeber wrote:
> Hello
>
> i´m a beginner in python. With version 14 in SPSS (statistic software)
> there are the posibility to use python.
>
> i want do the following:
>
> double NCases
> NCases=10/6
>
> is this correct in python? Because in SPSS there are an error message.
No, its not co
Op 2005-09-14, Robert Kern schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> Op 2005-09-13, Robert Kern schreef <[EMAIL PROTECTED]>:
>>
>>>Jeremy Sanders wrote:
>>>
Nils Grimsmo wrote:
>Why did round() change in Python 2.4?
It the usual floating point representation prob
Robert Kern wrote:
> Reinhold Birkenfeld wrote:
>
>>Robert Kern wrote:
>
>>>Antoon:
>>>"Python 2.3 isn't rounding 0.0225 up while pyton 2.4 rounds it down."
>>
>>Written in Pseudocode:
>>
>>not (Py2.3 rounding up and Py2.4 rounding down)
>
> I presumed the "isn't" was a typo given the "while."
Reinhold Birkenfeld wrote:
> Robert Kern wrote:
>>Antoon:
>>"Python 2.3 isn't rounding 0.0225 up while pyton 2.4 rounds it down."
>
> Written in Pseudocode:
>
> not (Py2.3 rounding up and Py2.4 rounding down)
I presumed the "isn't" was a typo given the "while."
--
Robert Kern
[EMAIL PROTECTED
Robert Kern wrote:
> Grant Edwards wrote:
>> On 2005-09-14, Robert Kern <[EMAIL PROTECTED]> wrote:
>>
>>>Antoon Pardon wrote:
>>
0.0225 isn't representable and it happens that the actual number
you get differ. Now which number python should choose when it is
fed 0.0225, I don't know.
Grant Edwards wrote:
> On 2005-09-14, Robert Kern <[EMAIL PROTECTED]> wrote:
>
>>Antoon Pardon wrote:
>
>>>0.0225 isn't representable and it happens that the actual number
>>>you get differ. Now which number python should choose when it is
>>>fed 0.0225, I don't know. But expressing the different
Nils Grimsmo wrote:
> (Is this due to the different GCC used?)
Yes, but there are probably other nasty values with the
other CGG. Basically, what the code does, for a positive
number, is to calculate floor(0.0225*1000.0+0.5)/1000.0.
As others have said: Don't trust this. If you use Python 2.4,
yo
On 2005-09-14, Robert Kern <[EMAIL PROTECTED]> wrote:
> Antoon Pardon wrote:
>> 0.0225 isn't representable and it happens that the actual number
>> you get differ. Now which number python should choose when it is
>> fed 0.0225, I don't know. But expressing the different behaviour
>> as a change in
Antoon Pardon wrote:
> Op 2005-09-13, Robert Kern schreef <[EMAIL PROTECTED]>:
>
>>Jeremy Sanders wrote:
>>
>>>Nils Grimsmo wrote:
>>>
Why did round() change in Python 2.4?
>>>
>>>It the usual floating point representation problem. 0.0225 cannot be
>>>represented exactly:
>>
>>That's not what
Op 2005-09-13, Robert Kern schreef <[EMAIL PROTECTED]>:
> Jeremy Sanders wrote:
>> Nils Grimsmo wrote:
>>
>>>Why did round() change in Python 2.4?
>>
>> It the usual floating point representation problem. 0.0225 cannot be
>> represented exactly:
>
> That's not what he's asking about. He's asking
Robert Kern wrote:
> That's not what he's asking about. He's asking why his Python 2.3 rounds
> 0.0225 *up* to 0.023 while his Python 2.4 rounds *down* to 0.022. It's
> the change in behavior that he's concerned with and isn't just the usual
> floating point problem.
You can't rely on either bein
I am running Debian unstable for 386. Python 2.4 is from the official
package archive, and seems to be compiled with GCC 4.0.2.
$ dpkg -l python2.4
ii python2.4 2.4.1-4 ...
$ python2.4
Python 2.4.1+ (#2, Sep 4 2005, 21:58:51)
[GCC 4.0.2 20050821 (prerelease) (Debian 4.0.1-6)] on l
Nils Grimsmo <[EMAIL PROTECTED]> wrote:
>Why did round() change in Python 2.4?
>
>$ python2.3
>Python 2.3.5 (#2, Jun 19 2005, 13:28:00)
>[GCC 3.3.6 (Debian 1:3.3.6-6)] on linux2
round(0.0225, 3)
>0.023
"%.3f" % round(0.0225, 3)
>'0.023'
>$ python2.4
>Python 2.4.1 (#2, Jul 12 2005, 09
Jeremy Sanders wrote:
> Nils Grimsmo wrote:
>
>>Why did round() change in Python 2.4?
>
> It the usual floating point representation problem. 0.0225 cannot be
> represented exactly:
That's not what he's asking about. He's asking why his Python 2.3 rounds
0.0225 *up* to 0.023 while his Python 2.4
Nils Grimsmo wrote:
> Why did round() change in Python 2.4?
It the usual floating point representation problem. 0.0225 cannot be
represented exactly:
xpc20:~> python
Python 2.3.4 (#1, Mar 14 2005, 16:47:22)
[GCC 3.4.3 20041212 (Red Hat 3.4.3-9.EL4)] on linux2
Type "help", "copyright", "credits"
On Tue, 06 Sep 2005 09:27:48 +0200, mg <[EMAIL PROTECTED]> wrote:
>Hi everybody...
>
>We try to white scripts with Pyrhon 2.4 for an acoustic simulation and
>we wrote these follow lines :
>
>
>c = 340
340 is an integer, which is different from 340.
>i =j=k= 1
>sum_ = 23
also an integer
>table = [
mg wrote:
> The problem is simple. The function 'round' allow to obtain the value
> with the specified number of digits after the ",". Then, when the
> variable 'freq' is printed, there is no problem; but when freq is set in
> the table and the table printed, all the digits are come back.
>
> I
mg wrote:
> Is it a bug or a control behavour ? I don't understand ?!?!?!?!...
It's a case of applying different float-to-text rounding in different
situations, on a variable that (even after round()) is not representable
in binary floatingpoint.
"print var" does one sort of string conversion
"mg" wrote:
> We try to white scripts with Pyrhon 2.4 for an acoustic simulation and
> we wrote these follow lines :
>
>
> c = 340
> i =j=k= 1
> sum_ = 23
> table = []
> freq = round((c/2*(sum_)**0.5),2)
> print freq
> table.append([freq,(i,j,k)])
> print i,j,k,' freq',freq
> for item in table: p
99 matches
Mail list logo
