I have a large/long array of numbers in an external file. The numbers look like this:
-64550.727
-64511.489
-64393.637
-64196.763
-63920.2
When I bring the numbers into my code, they are Strings. To use the
numbers in my code, I want to change the Strings to Float type
because the code will not work with Strings but I do not want
to change the numbers in any other way.
I have a large/long array of numbers in an external file. The numbers[...]
look like this:
-64550.727
-64511.489
-64393.637
When I bring the numbers into my code, they are Strings. To use the-64550.727
numbers in my code, I want to change the Strings to Float type because
the code will not work with Strings but I do not want to change the
numbers in any other way.
s = "-64550.727"
f = float(s)
f
<class 'float'>type(f)
I have a large/long array of numbers in an external file. The numbers look like this:
-64550.727
-64511.489
-64393.637
-64196.763
-63920.2
-63563.037
-63124.156
-62602.254
-61995.895
-61303.548
-60523.651
-59654.66
...
When I bring the numbers into my code, they are Strings. To use the numbers in my code, I want to change the Strings to Float type because the code will not work with Strings but I do not want to change the numbers in any other way.
So, I want my Strings (above) to be these numbers.
-64550.727
-64511.489
-64393.637
-64196.763
-63920.2
-63563.037
-63124.156
-62602.254
-61995.895
-61303.548
-60523.651
-59654.66
...
Please help!
I have a large/long array of numbers in an external file. The numbers =
look like this:
-64550.727
-64511.489
-64393.637
On 12/17/22 07:15, Thomas Passin wrote:
You have strings, and you want to end up with numbers. The numbers
are not integers. Other responders have gone directly to whether you
should use float or decimal as the conversion, but that is a secondary
matter.
If you have integers, convert with
integer = int(number_string)
-64550.727
they pretty clearly aren't integers:
-64511.489
-64393.637
-64196.763
-63920.2
-63563.037
-63124.156
-62602.254
-61995.895
-61303.548
-60523.651
-59654.66
You have strings, and you want to end up with numbers. The numbers are
not integers. Other responders have gone directly to whether you should use float or decimal as the conversion, but that is a secondary matter.
If you have integers, convert with
integer = int(number_string)
-64550.727
-64511.489
-64393.637
-64196.763
-63920.2
-63563.037
-63124.156
-62602.254
-61995.895
-61303.548
-60523.651
-59654.66
On 17 Dec 2022, at 13:11, Alan Gauld <learn2program@gmail.com> wrote:
On 17/12/2022 11:51, Paul St George wrote:
I have a large/long array of numbers in an external file. The numbers look like this:
-64550.727
-64511.489
-64393.637
-64196.763
-63920.2
When I bring the numbers into my code, they are Strings. To use the
numbers in my code, I want to change the Strings to Float type
because the code will not work with Strings but I do not want
to change the numbers in any other way.
That may be impossible. Float type is not exact and the conversion
will be the closest binary representation of your decimal number.
It will be very close but it may be slightly different when you
print it, for example. (You can usually deal with that by using
string formatting features.)
Another option is to use the decimal numeric type. That has other
compromises associated with it but, if retaining absolute decimal
accuracy is your primary goal, it might suit you better.
--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at: http://www.flickr.com/photos/alangauldphotos
Thanks to all!this:
It was the rounding rounding error that I needed to avoid (as Peter J. Holzer suggested). The use of decimal solved it and just in time. I was about to truncate the number, get each of the characters from the string mantissa, and then do something like
64550.727
64550 + (7 * 0.1) + (2 * 0.01) + (7 * 0.001)
Now I do not need to!
It was the rounding rounding error that I needed to avoid (as Peter J.
Holzer suggested). The use of decimal solved it and just in time. I
was about to truncate the number, get each of the characters from the
string mantissa, and then do something like this:
64550.727
64550 + (7 * 0.1) + (2 * 0.01) + (7 * 0.001)
It was the rounding rounding error that I needed to avoid (as Peter
J. Holzer suggested). The use of decimal solved it and just in
time. I was about to truncate the number, get each of the
characters from the string mantissa, and then do something like
this:
64550.727
64550 + (7 * 0.1) + (2 * 0.01) + (7 * 0.001)
Now I do not need to!
It sounds like fixed-point arithmetic might be a better fit for what
you're doing.
On 2022-12-17 12:51:17 +0100, Paul St George wrote:
I have a large/long array of numbers in an external file. The numbers[...]
look like this:
-64550.727
-64511.489
-64393.637
When I bring the numbers into my code, they are Strings. To use the
numbers in my code, I want to change the Strings to Float type because
the code will not work with Strings but I do not want to change the
numbers in any other way.
-64550.727s = "-64550.727"
f = float(s)
f
<class 'float'>type(f)
(Contrary to the other people posting in this thread I don't think float
is the wrong type for the job. It might be, but you haven't given enough details to tell whether the inevitable rounding error matters or not. In
my experience in almost all cases where people think it matters it
really doesn't.)
Yes, fixed point (or decimal) is a better fit for what he's doing. but
I suspect that floating point would be a better fit for the problem
he's trying to solve.
|5.551115123125783e-170.1 + 0.2 - 0.3
Thanks to all!this:
It was the rounding rounding error that I needed to avoid (as Peter J. Holzer suggested). The use of decimal solved it and just in time. I was about to truncate the number, get each of the characters from the string mantissa, and then do something like
64550.727
64550 + (7 * 0.1) + (2 * 0.01) + (7 * 0.001)
Now I do not need to!
On 17 Dec 2022, at 13:11, Alan Gauld <learn2program@gmail.com> wrote:
On 17/12/2022 11:51, Paul St George wrote:
I have a large/long array of numbers in an external file. The numbers look like this:
-64550.727
-64511.489
-64393.637
-64196.763
-63920.2
When I bring the numbers into my code, they are Strings. To use the
numbers in my code, I want to change the Strings to Float type
because the code will not work with Strings but I do not want
to change the numbers in any other way.
That may be impossible. Float type is not exact and the conversion
will be the closest binary representation of your decimal number.
It will be very close but it may be slightly different when you
print it, for example. (You can usually deal with that by using
string formatting features.)
Another option is to use the decimal numeric type. That has other
compromises associated with it but, if retaining absolute decimal
accuracy is your primary goal, it might suit you better.
--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos
On 2022-12-17, Chris Angelico <rosuav@gmail.com> wrote:
It was the rounding rounding error that I needed to avoid (as Peter
J. Holzer suggested). The use of decimal solved it and just in
time. I was about to truncate the number, get each of the
characters from the string mantissa, and then do something like
this:
64550.727
64550 + (7 * 0.1) + (2 * 0.01) + (7 * 0.001)
Now I do not need to!
It sounds like fixed-point arithmetic might be a better fit for what
you're doing.
Yes, fixed point (or decimal) is a better fit for what he's doing. but
I suspect that floating point would be a better fit for the problem
he's trying to solve.
Grant Edwards <grant.b.edwards@gmail.com> writes:
Yes, fixed point (or decimal) is a better fit for what he's doing. but
I suspect that floating point would be a better fit for the problem
he's trying to solve.
I'd like to predict that within the next ten posts in this
thread someone will mention "What Every Computer Scientist
Should Know About Floating-Point Arithmetic".
|5.551115123125783e-170.1 + 0.2 - 0.3
You have strings, and you want to end up with numbers. The numbers
are not integers. Other responders have gone directly to whether you
should use float or decimal as the conversion, but that is a secondary matter.
If you have integers, convert with
integer = int(number_string)
-64550.727
---64511.489
-64393.637
-64196.763
-63920.2
-63563.037
-63124.156
-62602.254
-61995.895
-61303.548
-60523.651
-59654.66
Grant Edwards <grant.b.edwards@gmail.com> writes:
Yes, fixed point (or decimal) is a better fit for what he's doing. but
I suspect that floating point would be a better fit for the problem
he's trying to solve.
I'd like to predict that within the next ten posts in this
thread someone will mention "What Every Computer Scientist
Should Know About Floating-Point Arithmetic".
I'd like to predict that within the next ten posts in this
thread someone will mention "What Every Computer Scientist
Should Know About Floating-Point Arithmetic".
Arguably more thought was given to what those three digits meant in the
real world. For example, is calculating a latitude to 6 decimal places >meaningful when the data was gathered by a GPS receiver with 5m accuracy?
.. And maybe lament the days when a 3-digit result was acceptable in
math class -- being the typical capability in reading a standard (10"
scale) slide rule.
On 12/17/2022 3:45 PM, Paul St George wrote:On 17 Dec 2022, at 16:54:05 EST 2022, Thomas Passin wrote:
Thanks to all!this:
It was the rounding rounding error that I needed to avoid (as Peter J. Holzer suggested). The use of decimal solved it and just in time. I was about to truncate the number, get each of the characters from the string mantissa, and then do something like
64550.727
64550 + (7 * 0.1) + (2 * 0.01) + (7 * 0.001)
Now I do not need to!
On 17 Dec 2022, at 13:11, Alan Gauld <learn2program at gmail.com <https://mail.python.org/mailman/listinfo/python-list>> wrote:
On 17/12/2022 11:51, Paul St George wrote:
I have a large/long array of numbers in an external file. The numbers look like this:
-64550.727
-64511.489
-64393.637
-64196.763
-63920.2
When I bring the numbers into my code, they are Strings. To use the
numbers in my code, I want to change the Strings to Float type
because the code will not work with Strings but I do not want
to change the numbers in any other way.
That may be impossible. Float type is not exact and the conversion
will be the closest binary representation of your decimal number.
It will be very close but it may be slightly different when you
print it, for example. (You can usually deal with that by using
string formatting features.)
Another option is to use the decimal numeric type. That has other
compromises associated with it but, if retaining absolute decimal
accuracy is your primary goal, it might suit you better.
--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos
So I am working on a physics paper with a colleague. We have a theory about Newtons Cradle. We answer the question why when you lift and drop balls 1 and 2, balls 4 and 5 rise up. I could say more, but ... (if you are interested please write to me).animations: the balls are not moving smoothly. I do not know (yet) where the problem lies so it is difficult to provide a clear narrative.
We want to illustrate the paper with animations. The theory includes distortion of the balls and this distortion is very very small. So, I am sent data with locations and dimensions to 13 decimal places. Something strange is happening with the
Because there is a problem, I am investigating in all areas. This brings me to the question I asked here. I am not expecting six decimal places or three decimal places to be as accurate as thirteen decimal places, but I would like to be in control ofor fully aware of what goes on under the bonnet.
Here is a picture:
https://paulstgeorge.com/newton/cyclography.html
Thanks,
Paul
like this:On 12/17/2022 3:45 PM, Paul St George wrote:On 17 Dec 2022, at 16:54:05 EST 2022, Thomas Passin wrote:
Thanks to all!
It was the rounding rounding error that I needed to avoid (as Peter J. Holzer suggested). The use of decimal solved it and just in time. I was about to truncate the number, get each of the characters from the string mantissa, and then do something
64550.727
64550 + (7 * 0.1) + (2 * 0.01) + (7 * 0.001)
Now I do not need to!
And that approach would not have helped you, because each of those calculations would be done as floating point, and you wouldn't have
gotten any more precision (and maybe less) than simply doing float('64550.727').
Here is a small but interesting discussion thread about float vs Decimal:
https://stackoverflow.com/questions/32053647/comparing-python-decimals-created-from-float-and-string
Would you mind telling us why that degree of precision (that is, decimal
vs float) matters for your problem?
On 17 Dec 2022, at 13:11, Alan Gauld <learn2program at gmail.com <https://mail.python.org/mailman/listinfo/python-list>> wrote:
On 17/12/2022 11:51, Paul St George wrote:
I have a large/long array of numbers in an external file. The numbers look like this:
-64550.727
-64511.489
-64393.637
-64196.763
-63920.2
When I bring the numbers into my code, they are Strings. To use the
numbers in my code, I want to change the Strings to Float type
because the code will not work with Strings but I do not want
to change the numbers in any other way.
That may be impossible. Float type is not exact and the conversion
will be the closest binary representation of your decimal number.
It will be very close but it may be slightly different when you
print it, for example. (You can usually deal with that by using
string formatting features.)
Another option is to use the decimal numeric type. That has other
compromises associated with it but, if retaining absolute decimal
accuracy is your primary goal, it might suit you better.
--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos
Thanks for filling us in! I wouldn't think the animations themselves
would need such precision, though perhaps the calculations of the forces
and motions do.
One way to check might be to perturb the initial
conditions a bit and see if the changes in the motions seem to be >correspondingly small.
On 12/17/2022 3:45 PM, Paul St George wrote:On 17 Dec 2022, at 16:54:05 EST 2022, Thomas Passin wrote:
Thanks to all!this:
It was the rounding rounding error that I needed to avoid (as Peter J. Holzer suggested). The use of decimal solved it and just in time. I was about to truncate the number, get each of the characters from the string mantissa, and then do something like
64550.727
64550 + (7 * 0.1) + (2 * 0.01) + (7 * 0.001)
Now I do not need to!
On 17 Dec 2022, at 13:11, Alan Gauld <learn2program at gmail.com <https://mail.python.org/mailman/listinfo/python-list>> wrote:
On 17/12/2022 11:51, Paul St George wrote:
I have a large/long array of numbers in an external file. The numbers look like this:
-64550.727
-64511.489
-64393.637
-64196.763
-63920.2
When I bring the numbers into my code, they are Strings. To use the
numbers in my code, I want to change the Strings to Float type
because the code will not work with Strings but I do not want
to change the numbers in any other way.
That may be impossible. Float type is not exact and the conversion
will be the closest binary representation of your decimal number.
It will be very close but it may be slightly different when you
print it, for example. (You can usually deal with that by using
string formatting features.)
Another option is to use the decimal numeric type. That has other
compromises associated with it but, if retaining absolute decimal
accuracy is your primary goal, it might suit you better.
--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos
So I am working on a physics paper with a colleague. We have a theory about Newtons Cradle.
We want to illustrate the paper with animations.
Because there is a problem, I am investigating in all areas. ... I would like to be in control of or fully aware of what goes on under the bonnet.
So I am working on a physics paper with a colleague. We have a theory about Newtons Cradle.
We want to illustrate the paper with animations.
Because there is a problem, I am investigating in all areas. ... I would like to be in control of or fully aware of what goes on under the bonnet.
Grant Edwards <grant.b.edwards@gmail.com> writes:
Yes, fixed point (or decimal) is a better fit for what he's doing. but
I suspect that floating point would be a better fit for the problem
he's trying to solve.
I'd like to predict that within the next ten posts in this
thread someone will mention "What Every Computer Scientist
Should Know About Floating-Point Arithmetic".
So I am working on a physics paper with a colleague. We have a theory about Newtons Cradle. We answer the question why when you lift and drop balls 1 and 2, balls 4 and 5 rise up. I could say more, but ... (if you are interested please write to me).animations: the balls are not moving smoothly. I do not know (yet) where the problem lies so it is difficult to provide a clear narrative.
We want to illustrate the paper with animations. The theory includes distortion of the balls and this distortion is very very small. So, I am sent data with locations and dimensions to 13 decimal places. Something strange is happening with the
Because there is a problem, I am investigating in all areas. This brings me to the question I asked here. I am not expecting six decimal places or three decimal places to be as accurate as thirteen decimal places, but I would like to be in control of orfully aware of what goes on under the bonnet.
like this:On 12/17/2022 3:45 PM, Paul St George wrote:On 17 Dec 2022, at 16:54:05 EST 2022, Thomas Passin wrote:
Thanks to all!
It was the rounding rounding error that I needed to avoid (as Peter J. Holzer suggested). The use of decimal solved it and just in time. I was about to truncate the number, get each of the characters from the string mantissa, and then do something
64550.727
64550 + (7 * 0.1) + (2 * 0.01) + (7 * 0.001)
Now I do not need to!
G = Decimal( 6.6743015E-11 )
r = Decimal( 6.371E6 )
M = Decimal( 5.9722E24 )
So what's the time until a mass of one gram
arrives at the ground versus a mass of ten grams? I think
one needs "Decimal" to calculate this!
3.4004053539917275e-28G = 6.6743015E-11
r = 6.371E6
M = 5.9722E24
dtdm = -0.5 * sqrt(2*s*(r**2) / (G * M**3))
dtdm * (1/1000 - 10/1000)
I'm no expert on floating point coding for precision, but I believe
that trying to work with values "close together" in magnitude is
important because values of different scales inherently convert one of
them to the other scale (i.e. similar sized exponent part) with
corresponding loss of precision in the mantissa part. That may require
you to form your calcutations carefully.
This is a good example of why it's important to choose
an appropriate numerical algorithm!
On Mon, 19 Dec 2022 at 07:57, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
G = Decimal( 6.6743015E-11 )
r = Decimal( 6.371E6 )
M = Decimal( 5.9722E24 )
What's the point of using Decimal if you start with nothing more than
float accuracy?
On 2022-12-19 09:25:17 +1100, Chris Angelico wrote:
On Mon, 19 Dec 2022 at 07:57, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
G = Decimal( 6.6743015E-11 )
r = Decimal( 6.371E6 )
M = Decimal( 5.9722E24 )
What's the point of using Decimal if you start with nothing more than
float accuracy?
Right. He also interpreted the notation "6.67430(15)E-11" wrong. The
digits in parentheses represent the uncertainty in the same number of
last digits. So "6.67430(15)E-11" means "something between 6.67430E-11 - 0.00015E-11 and 6.67430E-11 + 0.00015E-11". The r value has only a
precision of 1 km and I'm not sure how accurate the mass is. Let's just assume (for the sake of the argument) that these are actually accurate in
all given digits.
So G is between 6.67415E-11 and 6.67445E-11, r is between 6.3705E6 and 6.3715E6 and M is between 5.97215E24 and 5.97225E24. If we compute the
time for those deviations you will find that the differences are many
orders of magnitude greater than the effect you wanted to show. And that still ignores the fact that a vacuum won't be perfect (and collisions
with a few stray atoms might have a similarly tiny effect), that gravity isn't constant while the weight falls (it's getting closer to the center
of the earth and it's moving past other masses on its way) that Newton's
law is only an approximation, etc. So while the effect is (almost
certainly) real, the numbers are garbage.
I think there's a basic numeracy problem here. This is unfortunately all
too common, even among scientists. The OP apparently rounded their
numbers to 8 significant digits (thereby introducing an error of about
1E-8) and then insisted that the additional error of 1E-15 introduced by
the decimal to float conversion was unacceptable, showing IMHO a
fundamental misunderstanding of the numbers they are working with.
hp
On 2022-12-19 09:25:17 +1100, Chris Angelico wrote:
On Mon, 19 Dec 2022 at 07:57, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
G = Decimal( 6.6743015E-11 )
r = Decimal( 6.371E6 )
M = Decimal( 5.9722E24 )
What's the point of using Decimal if you start with nothing more than
float accuracy?
Right. He also interpreted the notation "6.67430(15)E-11" wrong. The
digits in parentheses represent the uncertainty in the same number of
last digits. So "6.67430(15)E-11" means "something between 6.67430E-11 - 0.00015E-11 and 6.67430E-11 + 0.00015E-11". The r value has only a
precision of 1 km and I'm not sure how accurate the mass is. Let's just assume (for the sake of the argument) that these are actually accurate in
all given digits.
So G is between 6.67415E-11 and 6.67445E-11, r is between 6.3705E6 and 6.3715E6 and M is between 5.97215E24 and 5.97225E24. If we compute the
time for those deviations you will find that the differences are many
orders of magnitude greater than the effect you wanted to show. And that still ignores the fact that a vacuum won't be perfect (and collisions
with a few stray atoms might have a similarly tiny effect), that gravity isn't constant while the weight falls (it's getting closer to the center
of the earth and it's moving past other masses on its way) that Newton's
law is only an approximation, etc. So while the effect is (almost
certainly) real, the numbers are garbage.
I think there's a basic numeracy problem here. This is unfortunately all
too common, even among scientists. The OP apparently rounded their
numbers to 8 significant digits (thereby introducing an error of about
1E-8) and then insisted that the additional error of 1E-15 introduced by
the decimal to float conversion was unacceptable, showing IMHO a
fundamental misunderstanding of the numbers they are working with.
On 2022-12-19 14:10, Peter J. Holzer wrote:[...]
He also interpreted the notation "6.67430(15)E-11" wrong. The
digits in parentheses represent the uncertainty in the same number of
last digits. So "6.67430(15)E-11" means "something between 6.67430E-11 - 0.00015E-11 and 6.67430E-11 + 0.00015E-11".
To be fair, I don't think I've never seen that notation either!
I've only ever seen the form 6.67430E-11 0.00015E-11, which is much clearer.
On 2022-12-19 14:10, Peter J. Holzer wrote:
On 2022-12-19 09:25:17 +1100, Chris Angelico wrote:
On Mon, 19 Dec 2022 at 07:57, Stefan Ram <ram@zedat.fu-berlin.de> wrote: >>> > G = Decimal( 6.6743015E-11 )
r = Decimal( 6.371E6 )
M = Decimal( 5.9722E24 )
What's the point of using Decimal if you start with nothing more than
float accuracy?
Right. He also interpreted the notation "6.67430(15)E-11" wrong. The
digits in parentheses represent the uncertainty in the same number of
last digits. So "6.67430(15)E-11" means "something between 6.67430E-11 -
0.00015E-11 and 6.67430E-11 + 0.00015E-11". The r value has only a
precision of 1 km and I'm not sure how accurate the mass is. Let's just
assume (for the sake of the argument) that these are actually accurate in
all given digits.
To be fair, I don't think I've never seen that notation either! I've only ever seen the form 6.67430E-11 ± 0.00015E-11, which is much clearer.
To be fair, I don't think I've never seen that notation either! I've
only ever seen the form 6.67430E-11 ± 0.00015E-11, which is much clearer.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 300 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 78:10:30 |
| Calls: | 6,716 |
| Files: | 12,247 |
| Messages: | 5,357,827 |