The result in Python cell, in line 4
f = float(1 / 2) # 0.0
seems wrong in Python 3.11, numpy 1.26.4. It should be 0.5.
And I also tried float32(1/2), it returns the same result.
2 Likes
The page link is
Go ahead, read about the rules how to contribute (link), fork the website’s GitHub repository. After edit of line 1043 of the markdown file in question (i.e. webpage/source/learn/rosetta_stone.md), file a PR. After passing the review, the credit will be yours.
2 Likes
Thank you very much, I will try! Have a nice day.
2 Likes
Indeed, in Fortran (and C) the compiler chooses implicitly either to use the FPU or the integer circuit depending on the types of the numerator and denominator.
In Python, the user is explicitly choosing real / or euclidean division // :
>>> 1/2
0.5
>>> 1//2
0
Yes, thank you for your emphasis. Do you think it should be change to
f = float(1 // 2) # 0.0
or
f = float(1 / 2) # 0.5
1 Like
Good question…
f = 1 / 2 ! 0.0 is demonstrating what I said about Fortran.
So I would indeed write f = float(1 // 2) # 0.0 in Python and would add a paragraph explaining how the Fortran compiler chooses real or euclidean division (two integers => euclidean division, at least one real => real division). Because for people knowing only one language and switching to the other, the different behaviour can be surprising. And it could create a severe bug (a program running but giving a bad result) in a scientific computation if you ignore the rules.
1 Like
Thank you for your detailed explanation. Looking forward to seeing these on the webpage.
1 Like
Yes, I wrote it when Python 2 was the most used Python and Python 3 wasn’t widely used. @yydx, if you could fix it, that would be highly appreciated!
1 Like
Ah yes, I did not remember that intrepid change between Python 2 and 3.
Should we hope that there won’t be Python 4? 
1 Like
The second time Lex Fridman invited Guido van Rossum for a talk (episode 341 Python and the Future of Programming, recorded November 26, 2022, link to youtube), the pros and cons of such a transition and what would be organized differently (intent to be «better this time™») were addressed (about 2h22mn into the video).
If there were a Python 4.0, then with less/or better no breaks at all about how to access the modules of the standard library (I presume van Rossum refers to instances like print statement vs print() function). If so, for instance because usage of no-GIL Python already became so much more prominent than the of GIL Python, with an announce multiple years ahead to provide the many third party applications to identify and test a better working – for the reason many of them (as compiled in directories like PyPI) struggle to stay afloat/maintained already today.
And now, the assisting 2-to-3 for a rule-based automatic (and eventually faster) transition* already is scheduled to disappear from the standard library with Python 3.13 (after a release candidate in August, the official shipment is anticipated for October 2024).
* Though it helps with core syntax, subsequent changes e.g., in numpy’s array definitions are beyond its scope (by recollection, pylint and likely ruff spotted then).
2 Likes
The key lesson is that if you are going to do breaking changes, to allow the same code base to be some subset of both Python 2 and 3, so that it can run in both (unmodified, no 2to3 tool needed), thus providing a smooth, gradual transition. At the beginning the 2to3 tool was needed, which didn’t allow to develop using Python 3 directly (one had to modify the codebase using Python 2 and run the tool).