Just reminded that #Python's considerations to anything packaging-related is a trashfire: deprecating distutils, including distutils.version, pointing to an external module that provides “Reusable core utilities for various Python Packaging interoperability specifications.”
I still think it's nuts that #Python's best solutions for rendering #SVG are a bunch of wrappers around CairoSVG with the two next best solutions being use Inkscape from the command line and wand, a wrapper around ImageMagick.
(2/5) 𝐒𝐥𝐢𝐦 𝐢𝐦𝐚𝐠𝐞
Typically, I use the Python official image as the baseline for setting up a dockerized Python environment. The official Python image offers multiple images for different Linux flavors and CPU architectures. The default image (e.g., 𝘱𝘺𝘵𝘩𝘰𝘯:𝘭𝘢𝘵𝘦𝘴𝘵) has comprehensive supporting tools that impact the image size - 1 GB.
A simple way to reduce the image size is to replace the default image with a slim version that is 150 MB (compared to 1GB) 🚀.
Announcing Flask-SQLAlchemy-Lite, a new lightweight replacement for Flask-SQLAlchemy that provides engine configuration and session lifetime, but none of the other custom stuff in the prior extension. It works with Flask and Quart, sync and async. I figured out the core idea on the flight to PyCon US, teased it during FlaskCon, and now it's available! Check out the docs to get started! https://flask-sqlalchemy-lite.readthedocs.io#Python#Flask#SQLAlchemy
There are still a few days left to take advantage of the latest #HumbleBundle package from @nostarch: Dive into DevOps!
You can pick up 5 great titles for just $1, or go up to $35 for all 22 items in this "indispensable IT library".
Either way, be sure to use "Adjust Donation" to choose how much of your purchase goes to the PSF🐍❤️
Notably, I made the precision variable so that I could see how precise a value I could get. I tried it at lower precision at first and it worked, so I bumped it up. Seemed to work fine, until I got past 16 significant digits... (1/3)
At that point, I noticed that the values started to diverge at around the 16th decimal place, and it didn't get better as precision increased. In fact, I checked the answer against a calculator app and got a different answer, with completely different digits after the 16th place. So I thought, OK, it's a hardware precision issue.
BUT THEN I tried to estimate the square roots of other numbers (ex.: 1.7, 13, 33) and the difference was ZERO. That is, ONLY the square root of 2 diverged. (2/3)
@dragfyre There is nothing wrong with your algorithm. It gives the correct result within the precision of the number representation you're using.
In your case, you're hitting the limits of 64-bit floating point, and the reason you are getting different results is because the implementation of sqrt that Python uses (which appears to be the default libc implementation) is more accurate than yours for some specific inputs.
I took the libery to do an almost 1-to-1 port of your code to Kap, which allows you to try the same thing using rational arithmetic. When you do so, you get a value that is as precise as you tolerance value:
I also took your code and tested it on a 100 different values (0 to 5 with a step length of 0.05, and it gives you several other values for which your algorithm gives an imprecise value with floating point arithmetic:
Mostly you shouldn't subclass #Python built-in types. But if you do, dict subclasses can define missing: it's called when a key is missing. Instead of hiding a dict in a function as a cache, how about hiding a function in a dict!? A Fibonacci dictionary:
i wrote another blog post on my personal experiences with packaging as a teacher, a user and a maintainer. And how giving a tech talk on a big stage felt! (hint: scary!)
i'm curious if others have experienced imposter syndrome and/or challenges navigating our #python packaging ecosystem / data science ecosystem! let me know what you think. 💗