Re: file to bits text and text containing bits to file
On Saturday, October 10, 2020 at 1:43:09 AM UTC+5:30, dn wrote: > On 09/10/2020 19:27, Harshit Sharma wrote: > > I want to read bits data of all file of any extention in 0s and 1s. And > > also want to do back means means construct file from bits text data how to > > do that tell with proof please. I am on a work of something like new sloot > > method but here I stuck.help everything else is done. > Which (Python) tool(s) are you currently using? > What (Python) research have you done? > -- > Regards =dn I have got solution to that using bitstring module. I will tell to the world when program will get ready my blueprint of program is fully ready but I don't know coding very much so it will take time. it may take 3 or 4 months to code because I have to search on net everything how to do this or that in code. Or take help in social media. I also have to manage my studies side by side. Is there anyone who will code the program for me and make me owner for free or whatever I can make that but slowly. -- https://mail.python.org/mailman/listinfo/python-list
Trying to Download PygameZero
I am in a 8 grade coding class at the moment and my teacher asked me to
download a script called pgzero. I can not seem to download pgzer or pygame
when i try it shoots me a error message: ERROR: Command errored out with exit
status 1: command: 'c:\program files\python39\python.exe' -c 'import sys,
setuptools, tokenize; sys.argv[0] =
'"'"'C:\\Users\\thedg\\AppData\\Local\\Temp\\pip-install-g9sb_mr0\\pygame\\setup.py'"'"';
__file__='"'"'C:\\Users\\thedg\\AppData\\Local\\Temp\\pip-install-g9sb_mr0\\pygame\\setup.py'"'"';f=getattr(tokenize,
'"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"',
'"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' egg_info
--egg-base 'C:\Users\thedg\AppData\Local\Temp\pip-pip-egg-info-rre7x6r3'
cwd: C:\Users\thedg\AppData\Local\Temp\pip-install-g9sb_mr0\pygame\
Complete output (17 lines):
WARNING, No "Setup" File Exists, Running "buildconfig/config.py" Using
WINDOWS configuration...
Download prebuilts to "prebuilt_downloads" and copy to "./prebuilt-x64"?
[Y/n]Traceback (most recent call last): File "", line 1, in
File
"C:\Users\thedg\AppData\Local\Temp\pip-install-g9sb_mr0\pygame\setup.py", line
194, in buildconfig.config.main(AUTO_CONFIG) File
"C:\Users\thedg\AppData\Local\Temp\pip-install-g9sb_mr0\pygame\buildconfig\config.py",
line 210, in main deps = CFG.main(**kwds) File
"C:\Users\thedg\AppData\Local\Temp\pip-install-g9sb_mr0\pygame\buildconfig\config_win.py",
line 576, in main and download_win_prebuilt.ask(**download_kwargs):
File
"C:\Users\thedg\AppData\Local\Temp\pip-install-g9sb_mr0\pygame\buildconfig\download_win_prebuilt.py",
line 302, in ask reply = raw_input( EOFError: EOF when reading a
line ERROR: Command errored out with
exit status 1: python setup.py egg_info Check the logs for full command output.
Please let me know ASAP how to fix this. Ive spent countless hours trying to
fix this, ive tried my changing my Path becasue thats what everyone told me. I
have also tried some other means to fix this and non have been sucsussful.
Please Help me,
--
https://mail.python.org/mailman/listinfo/python-list
python
import numpy as np import matplotlib.pylab as plt x = [1, -2 , 1]; h = [1 , 2 , -1 , 0 , 3 , 1]; nx = nx=[0,1,2]; nh =[0,1,2,3,4,5] y = np.convolve(x ,h) ny = np.arange(nx[0] + nh[0], nx[-1] + nx[-1]+1,nx[1]); print(ny,y) plt.subplot(1,1,1); plt.stem(y) plt.subplot(1,1,1); plt.stem( ny, y) ValueError: x and y must have same first dimension, but have shapes (5,) and (8,) -whan can i do?? please comment please ㅠㅠ -- https://mail.python.org/mailman/listinfo/python-list
Re: Trying to Download PygameZero
On 10/10/20 12:22 AM, Tom Hedge via Python-list wrote:
> I am in a 8 grade coding class at the moment and my teacher asked me to
> download a script called pgzero. I can not seem to download pgzer or pygame
> when i try it shoots me a error message: ERROR: Command errored out with
> exit status 1: command: 'c:\program files\python39\python.exe' -c 'import
> sys, setuptools, tokenize; sys.argv[0] =
> '"'"'C:\\Users\\thedg\\AppData\\Local\\Temp\\pip-install-g9sb_mr0\\pygame\\setup.py'"'"';
>
> __file__='"'"'C:\\Users\\thedg\\AppData\\Local\\Temp\\pip-install-g9sb_mr0\\pygame\\setup.py'"'"';f=getattr(tokenize,
> '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"',
> '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))'
> egg_info --egg-base
> 'C:\Users\thedg\AppData\Local\Temp\pip-pip-egg-info-rre7x6r3' cwd:
> C:\Users\thedg\AppData\Local\Temp\pip-install-g9sb_mr0\pygame\ Complete
> output (17 lines):
>
> WARNING, No "Setup" File Exists, Running "buildconfig/config.py" Using
> WINDOWS configuration...
>
> Download prebuilts to "prebuilt_downloads" and copy to "./prebuilt-x64"?
> [Y/n]Traceback (most recent call last): File "", line 1, in
> File
> "C:\Users\thedg\AppData\Local\Temp\pip-install-g9sb_mr0\pygame\setup.py",
> line 194, in buildconfig.config.main(AUTO_CONFIG) File
> "C:\Users\thedg\AppData\Local\Temp\pip-install-g9sb_mr0\pygame\buildconfig\config.py",
> line 210, in main deps = CFG.main(**kwds) File
> "C:\Users\thedg\AppData\Local\Temp\pip-install-g9sb_mr0\pygame\buildconfig\config_win.py",
> line 576, in main and download_win_prebuilt.ask(**download_kwargs):
> File
> "C:\Users\thedg\AppData\Local\Temp\pip-install-g9sb_mr0\pygame\buildconfig\download_win_prebuilt.py",
> line 302, in ask reply = raw_input( EOFError: EOF when reading a
> line ERROR: Command errored out
> with exit status 1: python setup.py egg_info Check the logs for full command
> output.
>
> Please let me know ASAP how to fix this. Ive spent countless hours trying to
> fix this, ive tried my changing my Path becasue thats what everyone told me.
> I have also tried some other means to fix this and non have been sucsussful.
> Please Help me,
>
The problem is the pygame developers have not released a pygame for
Python 3.9 and you're using Python 3.9.
You can check the availability here:
https://pypi.org/project/pygame/#files
Easiest answer is to stick with Python 3.8.6 for now.
Slightly longer: all those daunting error messages are because pip
didn't find a wheel file matching your python version / operating system
/ architecture, and thus wants to instead download the source
distribution and build it (that's the pygame\\setup.py). And that fails,
as it normally does for Windows users.
--
https://mail.python.org/mailman/listinfo/python-list
Python's carbon guilt
Python advocates might want to organize their thoughts on this subject before their bosses spring the suggestion: >From >https://www.sciencemag.org/news/2020/10/we-re-part-problem-astronomers-confront-their-role-and-vulnerability-climate-change > : . . . Astronomers should also abandon popular programming languages such as Python in favor of efficient compiled languages. Languages such as Fortran and C++, Zwart calculates, are more than 100 times more carbon efficient than Python because they require fewer operations. -- To email me, substitute nowhere->runbox, invalid->com. -- https://mail.python.org/mailman/listinfo/python-list
Re: Truncation error
On 2020-10-07 07:53:55 +0200, Marco Sulla wrote:
> If you want to avoid float problems, you can use Decimal:
Decimal doesn't avoid floating point problems, because it is a floating
point format. For example:
Python 3.8.5 (default, Jul 28 2020, 12:59:40)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from decimal import *
>>> a = Decimal(3)
>>> a
Decimal('3')
>>> b = Decimal(1E50)
>>> b
Decimal('17629769841091887003294964970946560')
>>> c = Decimal(2)
>>> a + b - c - b
Decimal('8112996705035029053440')
>>> b - b + a - c
Decimal('1')
>>> a + (b - b) - c
Decimal('1')
>>> a + b - b - c
Decimal('8112996705035029053438')
>>>
Mathematically, all four expressions should have the result 1, but with
floating point numbers they don't because intermediate results are
rounded.
For comparison, here are the results with float:
>>> a + b - c - b
0.0
>>> b - b + a - c
1.0
>>> a + (b - b) - c
1.0
>>> a + b - b - c
-2.0
>>>
One could argue that these are at least closer to the truth, although I
think that's just luck,
Decimal does have two advantages over float:
a) It's precision is configurable and even by default higher. So on
average, the error is smaller (but still not zero).
b) It uses decimal numbers like we learned in school. So it will make
the same errors as we make when we use pencil and paper, which is
less confusing to laypersons than the seemingly arbitrary errors from
converting from decimal to binary and back.
The disadvantages are of course higher memory consumption and lower
speed. Also, I'm very confident that the engineers at Intel and AMD knew
what they were doing when they designed the FP units of their
processors. I'm slightly less confident about the authors of the Decimal
module. And I'm much less confident that the average Python programmer
can implement a matrix multiplication with Decimal which is as
numerically stable as what Matlab or Pandas provide using IEEE-754
arithmetic.
hp
PS: I recently read an interesting article on the Android calculator.
That goes to extreme lengths to avoid unexpected rounding errors.
It is also very slow, but still faster than a human can look, so it
doesn't matter.
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| | | h...@hjp.at |-- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
signature.asc
Description: PGP signature
--
https://mail.python.org/mailman/listinfo/python-list
Re: Truncation error
Thanks, the problem was I solved a covariance matrix manually, but my
fellow mate using the covariance syntax. That's why there was difference in
Matlab and python results. But now when I use the covariance syntax in
python, matlab and python gives the same results.
On Sat, Oct 10, 2020, 21:37 Peter J. Holzer wrote:
> On 2020-10-07 07:53:55 +0200, Marco Sulla wrote:
> > If you want to avoid float problems, you can use Decimal:
>
> Decimal doesn't avoid floating point problems, because it is a floating
> point format. For example:
>
> Python 3.8.5 (default, Jul 28 2020, 12:59:40)
> [GCC 9.3.0] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from decimal import *
> >>> a = Decimal(3)
> >>> a
> Decimal('3')
> >>> b = Decimal(1E50)
> >>> b
> Decimal('17629769841091887003294964970946560')
> >>> c = Decimal(2)
> >>> a + b - c - b
> Decimal('8112996705035029053440')
> >>> b - b + a - c
> Decimal('1')
> >>> a + (b - b) - c
> Decimal('1')
> >>> a + b - b - c
> Decimal('8112996705035029053438')
> >>>
>
> Mathematically, all four expressions should have the result 1, but with
> floating point numbers they don't because intermediate results are
> rounded.
>
> For comparison, here are the results with float:
>
> >>> a + b - c - b
> 0.0
> >>> b - b + a - c
> 1.0
> >>> a + (b - b) - c
> 1.0
> >>> a + b - b - c
> -2.0
> >>>
>
> One could argue that these are at least closer to the truth, although I
> think that's just luck,
>
> Decimal does have two advantages over float:
>
> a) It's precision is configurable and even by default higher. So on
>average, the error is smaller (but still not zero).
>
> b) It uses decimal numbers like we learned in school. So it will make
>the same errors as we make when we use pencil and paper, which is
>less confusing to laypersons than the seemingly arbitrary errors from
>converting from decimal to binary and back.
>
>
> The disadvantages are of course higher memory consumption and lower
> speed. Also, I'm very confident that the engineers at Intel and AMD knew
> what they were doing when they designed the FP units of their
> processors. I'm slightly less confident about the authors of the Decimal
> module. And I'm much less confident that the average Python programmer
> can implement a matrix multiplication with Decimal which is as
> numerically stable as what Matlab or Pandas provide using IEEE-754
> arithmetic.
>
> hp
>
> PS: I recently read an interesting article on the Android calculator.
> That goes to extreme lengths to avoid unexpected rounding errors.
> It is also very slow, but still faster than a human can look, so it
> doesn't matter.
>
> --
>_ | Peter J. Holzer| Story must make more sense than reality.
> |_|_) ||
> | | | h...@hjp.at |-- Charles Stross, "Creative writing
> __/ | http://www.hjp.at/ | challenge!"
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python's carbon guilt
On 2020-10-10 15:58:18 +, Peter Pearson wrote: > Python advocates might want to organize their thoughts on > this subject before their bosses spring the suggestion: > > From > https://www.sciencemag.org/news/2020/10/we-re-part-problem-astronomers-confront-their-role-and-vulnerability-climate-change > : > > . . . Astronomers should also abandon popular programming languages > such as Python in favor of efficient compiled languages. Languages > such as Fortran and C++, Zwart calculates, are more than 100 times > more carbon efficient than Python because they require fewer > operations. > It would be interesting on which data he based these calculations. For simple benchmarks of numerical code that's almost certainly true, but I doubt anyone writes code intended to run on a supercomputer in plain Python. Surely such programs would use numpy or other specialized libraries which are already written in C or Fortran and may even use a GPU if present? There is of course still some overhead, but it's much smaller. hp -- _ | Peter J. Holzer| Story must make more sense than reality. |_|_) || | | | h...@hjp.at |-- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" signature.asc Description: PGP signature -- https://mail.python.org/mailman/listinfo/python-list
Re: Python's carbon guilt
On Sun, Oct 11, 2020 at 3:01 AM Peter Pearson wrote: > > Python advocates might want to organize their thoughts on > this subject before their bosses spring the suggestion: > > From > https://www.sciencemag.org/news/2020/10/we-re-part-problem-astronomers-confront-their-role-and-vulnerability-climate-change > : > > . . . Astronomers should also abandon popular programming languages > such as Python in favor of efficient compiled languages. Languages > such as Fortran and C++, Zwart calculates, are more than 100 times > more carbon efficient than Python because they require fewer > operations. > > Ahh, yes, a new way for people to worship the little tin god. How cute. :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python's carbon guilt
He should also calculate the carbon dioxide emitted by brains that works in C++ only. I omit other sources. -- https://mail.python.org/mailman/listinfo/python-list
RE: Python's carbon guilt
People have a tendency to go too far in their religious zeal, Peter. We could go back to writing on chalkboards to do calculations then re-use the chalk dust when erasing to write again. Many computers do almost nothing 90+ percent of the time. Want to outlaw those or force them to accept random jobs from the internet when relatively idle? But all kidding aside, anything used frequently and not changed often might be a good candidate for an efficient solution that uses fewer resources. Yet our computers, so far, have been in many ways getting cheaper and in many cases use less electricity to do the same number of calculations. But there are tradeoffs such as optimizing speed over memory use or other resources that are external and thus slower. The ultimate carbon cost can sometimes be for carbon-based organisms, most of them suitable to be called human. When you measure how long it takes them to develop applications and verify they have minimal bugs, you may notice that some development environments seem to take lots more time than others for common tasks. Interactive has huge advantages in many cases. Slowest would be asking people to go back to writing in machine code, not very portably. The reality is that speed and other resource use do matter for anything run often or that would take a very long time. Languages like python and R acknowledge that and quite a few parts are now replaced by calls to libraries in other language or C/C++ code. But often that is done only later when the code is not going to be changed regularly. I think there is a reality here. The costs of computing end sometimes of power usage, often are dropping. The users like getting extra features and underneath the covers, that often means lots of extra IF statements or other checks, or loops that keep checking regularly to see if they need to do anything. If you program a GUI that allows the user to click or type in many places at random, there can be lots of overhead even when done in a compiled language. True speed and efficiency might require removing lots of features entirely as too expensive. It may well be cheaper to do some operations on matrices where every row/column is of the same object type but there are very serious advantages to allowing a mixed type operation such as a data.frame where each column is a hidden vector of some type or even at times to allowing every cell/item to be of any object type. The overhead rises in terms of storage and CPU time used but it allows higher levels of abstraction and often the ability to write code with fewer lines that handles many more conditions, sometimes invisibly. Consider how computing is being used and ask if a little more carbon footprint there may reduce the carbon footprint elsewhere. Would you rather have people spend years or months developing some app that can be used in a way that reduces overall carbon dioxide production? If your answer is that you can have it both ways, fine. But you may have trouble hiring enough people willing to work under those constraints and you may be told of lots of things they won't feel comfortable doing and it may take longer and ... A question. Are recent compiled languages that add features as small and fast as earlier ones? For example, many older languages required a function to take a fixed number of arguments in a fixed order and of exactly the types mentioned when created. Some interpreted languages allow lots of additional functionality, some of which could easily be provided such as allowing named arguments in any order, or allowing additional optional arguments or default values and so on. Much of this could be done in a compiled way, but with additional compile time and even run-time cost. But some features, by definition, must be at run time and especially for code that modifies itself or creates new objects dynamically. IF you want some of these new features, how would you supply them in a compiled way without adding lots of the overhead you want to reduce? Carbon guilt should not be taken seriously as an immediate goal as compared to an overall goal. If we make more people able to work from home or nearby offices and avoid long commutes, does it matter if your remote work is much more carbon friendly than the costs to travel and then still use other energy there for lighting and more computers and ... -Original Message- From: Python-list On Behalf Of Peter Pearson Sent: Saturday, October 10, 2020 11:58 AM To: python-list@python.org Subject: Python's carbon guilt Python advocates might want to organize their thoughts on this subject before their bosses spring the suggestion: From https://www.sciencemag.org/news/2020/10/we-re-part-problem-astronomers-confr ont-their-role-and-vulnerability-climate-change : . . . Astronomers should also abandon popular programming languages such as Python in favor of efficient compiled languages. Languages such as Fortran and C++, Zwart calculates, are mor
Problem saving datetime to file and reading it back for a calculation
I would like to use the line: HoursDiff = int((d2-d1).total_seconds()/3600) to determine the difference in hours between two timedate entries. The variable d2 is from datetime.now() and d1 is read from a text file. I can save d2 to the file only if I convert it to string and, at a later date, it gets read back in as d1 as string. The variable d1 as string will not work in the HoursDiff statement. To me, it looks like a problem in formatting. How do I fix this? Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: Problem saving datetime to file and reading it back for a calculation
On Sat, 10 Oct 2020 18:17:26 -0400, Steve wrote:
> I would like to use the line:
> HoursDiff = int((d2-d1).total_seconds()/3600)
> to determine the difference in hours between two timedate entries.
>
> The variable d2 is from datetime.now()
> and d1 is read from a text file.
>
> I can save d2 to the file only if I convert it to string and, at a later
> date, it gets read back in as d1 as string. The variable d1 as string will
> not work in the HoursDiff statement.
>
> To me, it looks like a problem in formatting.
> How do I fix this?
datetime.datetime.strftime and datetime.datetime.strptime ?
>>> t = datetime.datetime.now()
>>> t.strftime("%Y-%m-%d %H:%M:%S")
'2020-10-10 18:02:33'
>>> b = datetime.datetime.strptime("2020-09-09 12:34:56", "%Y-%m-%d %H:%M:%S")
>>> b.strftime("%Y-%m-%d %H:%M:%S")
'2020-09-09 12:34:56'
>>>
--
To email me, substitute nowhere->runbox, invalid->com.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Problem saving datetime to file and reading it back for a calculation
On 10Oct2020 18:17, Steve wrote: >I would like to use the line: >HoursDiff = int((d2-d1).total_seconds()/3600) >to determine the difference in hours between two timedate entries. > >The variable d2 is from datetime.now() >and d1 is read from a text file. > >I can save d2 to the file only if I convert it to string and, at a later >date, it gets read back in as d1 as string. That is the nature of text files. >The variable d1 as string will >not work in the HoursDiff statement. Because it is a string. Peter has described a way to transcribe a datetime in an arbitrary string format and back. Note that his example formats are "naive" - they don't know what you timezone is, and you want that if that ever varies (not just datetimes in contexts from different places, but also at different times of the year if you run different summer and winter times, particularly troublesome around the transition from one to the other). >To me, it looks like a problem in formatting. >How do I fix this? Personally I strongly dislike using datetimes for computation or as the basis for time record keeping, essentially because of the timezone issue but also because the human calendar is a complex disaster of illfitting units (days in a year? variable; days in a month? variable; that table of days per unit? variable depending on your time in history). Instead, I always try to work in POSIX timestamps, an absolute number of seconds since midnight, 1 January 1970 GMT. You can always do arithmetic directly between these in seconds, then convert for presentation purposes whenever. Because you're now working in seconds directly, you go: HoursDiff = int((t2-t1)/3600) or: HoursDiff = (t2-t1) // 3600 When you first collect your datetime, convert it to a POSIX timestamp immediately. If you're _starting_ from datetime.now(), do not do that! Just start with time.time() and no conversion is needed at all. Just _present_ in datetime formats if you need to. DO NOT try to work with them as your basic type - they are a source of pitfalls. As far as storing timestamps in a file, they're ints or floats; just write them out. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: Problem saving datetime to file and reading it back for a calculation
On Sun, Oct 11, 2020 at 12:57 PM Cameron Simpson wrote: > Personally I strongly dislike using datetimes for computation or as the > basis for time record keeping, essentially because of the timezone issue > but also because the human calendar is a complex disaster of illfitting > units (days in a year? variable; days in a month? variable; that table > of days per unit? variable depending on your time in history). > > Instead, I always try to work in POSIX timestamps, an absolute number of > seconds since midnight, 1 January 1970 GMT. You can always do arithmetic > directly between these in seconds, then convert for presentation > purposes whenever. > Absolutely agree, with the annoying exception of recurring events. If a human says "this happens every Monday at 2pm", then the human expects it to recur every Monday at 2pm, not every 604800 seconds. The difference shows up when the conversion between UTC and local time changes - most commonly when Daylight Saving Time starts or ends... (And I guess if you care about leap seconds, then Unix time would be inappropriate there too. But I rather doubt that most of us are bothered by that.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Trying to Download PygameZero
On 10/10/2020 11:11 AM, Mats Wichmann wrote:
On 10/10/20 12:22 AM, Tom Hedge via Python-list wrote:
I am in a 8 grade coding class at the moment and my teacher asked me to download a script
... [on Windows according to file paths]... .
The problem is the pygame developers have not released a pygame for
Python 3.9 and you're using Python 3.9.
https://www.lfd.uci.edu/~gohlke/pythonlibs/ has wheels for pygame.
('wheel' is the distribution format use by pypi.) Download to you
system and install with pip from that.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Re: Truncation error
On 2020-10-10, Peter J. Holzer wrote:
> On 2020-10-07 07:53:55 +0200, Marco Sulla wrote:
>> If you want to avoid float problems, you can use Decimal:
>
> Decimal doesn't avoid floating point problems, because it is a floating
> point format. For example:
> [...]
> >>> from decimal import *
> >>> a = Decimal(3)
> >>> a
> Decimal('3')
> >>> b = Decimal(1E50)
> >>> b
> Decimal('17629769841091887003294964970946560')
> [...]
There are two problems with your code:
1. You meant Decimal('1e50'). What you typed creates a Decimal value
from the IEEE 64-bit floating point value closest to 1e50.
2. You need to increase the context precision. It defaults to 28,
and you're example needs it to be at least 51:
>>> getcontext().prec = 100
>>> a = Decimal(3)
>>> b = Decimal('1e50')
>>> c = Decimal(2)
>>> a + b - c - b
Decimal('1')
>>> b - b + a - c
Decimal('1')
>>> a + (b - b) - c
Decimal('1')
>>> a + b - b - c
Decimal('1')
Like other floating point systems, you still need to know what you're
doing if you want to get the "right" results.
--
Grant
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python's carbon guilt
On 10/10/20 2:35 PM, Marco Sulla wrote: > He should also calculate the carbon dioxide emitted by brains that > works in C++ only. I omit other sources. > yes, methane is an alleged greenhouse gas as well -- https://mail.python.org/mailman/listinfo/python-list
Re: Python's carbon guilt
On 10/10/2020 11:58 AM, Peter Pearson wrote: Python advocates might want to organize their thoughts on this subject before their bosses spring the suggestion: From https://www.sciencemag.org/news/2020/10/we-re-part-problem-astronomers-confront-their-role-and-vulnerability-climate-change : . . . Astronomers should also abandon popular programming languages such as Python in favor of efficient compiled languages. Languages such as Fortran and C++, Zwart calculates, are more than 100 times more carbon efficient than Python because they require fewer operations. Here is my reply to the "senior correspondent for astronomy..." who wrote the columm. --- Dear Mr. Clery: You report that Zwart of Leiden U says ... "Astronomers should also abandon popular programming languages such as Python in favor of efficient compiled languages. Languages such as Fortran and C++, Zwart calculates, are more than 100 times more carbon efficient than Python because they require fewer operations." Summary counter claim: the claim is phony. As actually used by astronomers for computationally intensive tasks, Python is nearly if not as 'carbon efficient' -- because nearly all the computation is done with machine code compiled from C, Fortran, C++, or whatever. (I am not an expert here, but am reporting to you a summary of what is generally known among experienced Python users. I am leaving out numerous details. Feel free to contact scientific Python experts for more.) Here is how anti-Python, pro-OtherLanguage people come up with such misleading numbers as '100x slower'. Confuse the issue by ascribing efficiency to languages rather than implementations. Then compare a relatively efficient 'production' implementation of some algorithm in OtherLanguage to an computer inefficient (but human efficient) 'development' implementation in Python that ignores how Python is being used in practice by scientific communities, such as the astronomy community. Step 1: Create a file with couple of numerically intensive functions such as matrix_init and matrix_invert written in directly compiled OtherLanguage. Add calls to matrix_init and matrix_invert. Time one or more runs. Step 2: Naively translate OtherLanguage directly into Python. Don't allow imports. Time one or more runs with the CPython interpreter. Compare the OtherLanguage time to this worst case Python time. Imply that users of Python are stupid enough to stop here for production usage. I consider this a bit slanderous. In practice, Python users inverting matrices, for instance, import the compiled numpy module, which among other things, wraps the standard Linpack package, which uses machine-specific, assemble-coded, Basic Linear Algebra Subroutines (BLAS) when available. In practice, I have read, the overhead of calling C libraries from Python instead of C is only a few percent. The original and still main Python implementation, CPython, is written in C. It interprets Python code, which is 'slow', but the Python code can include calls to fast, compiled, pre-written C functions. CPython was designed from the beginning to be extended with other other modules and functions written in C. (Fortran extensions were included either immediately or soon after, but I don't know which.) Some of these are included in the standard library, others from third-parties. Since the release of Python 1.0 in 1992, real-world Python users, have been extending CPython when appropriate for production usage. Indeed, numerical scientific computation was Python's first 'killer application'. Now, most every open-source C library with significant usage has been wrapped. There are at least hundreds. The current standard numerical package, numpy, is the third, and the needs of astronomers were among those that contributed to the design. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
For Creatives and Developers Only
We are recruiting Developers, and Creatives to join our community into building personal portfolios, personal development skills, work on Open Source Projects, Devops, Collaboration, User Testing and Supports. Community members include experts in product designs, python programming, data science, creative writers, graphics and designs, artificial intelligence and a lot more. Link to join: https://chat.whatsapp.com/Geld8FNt4QCLGhYpA8DxkG -- https://mail.python.org/mailman/listinfo/python-list
