It seems that most research effort goes into better dtoa, and not enough in a better atod. There are probably a dozen dtoa algorithms now, and (I think?) two for atod. Anyone know why?
Good question. I am not familiar with string-to-double algorithms but maybe it's an easier problem? double-to-string is relatively complex, people even doing PhD in this area. There is also some inherent asymmetry: formatting is more common than parsing.
In implementing Rust's serde_json library, I have dealt with both string-to-double and double-to-string. Of the two, I found string-to-double was more complex.
Unlike formatting, correct parsing involves high precision arithmetic.
Example: the IEEE 754 double closest to the exact value "0.1" is 7205759403792794*2^-56, which has an exact value of A (see below). The next higher IEEE 754 double has an exact value of C (see below). Exactly halfway between these values is B=(A+C)/2.
So for correctness the algorithm needs the ability to distinguish the following extremely close values, because the first is closer to A (must parse to A) whereas the second is closer to C:
The problem of "string-to-double for the special case of strings produced by a good double-to-string algorithm" might be relatively easy compared to double-to-string, but correct string-to-double for arbitrarily big inputs is harder.
I guess one aspect of it is that in really high performance fields where you're taking in lots of stringy real inputs (FIX messages coming from trading venues for example, containing prices and quantities) you would simply parse directly to a fixed point decimal format, and only accept fixed (not scientific) notation inputs. Except for trailing or leading zeros there is no normalisation to be done.
Parsing a decimal ASCII string to a decimal value already optimizes well, because you can scale each digit by it's power of 10 in parallel and just add up the result.
For those wishing to read up on this subject, an excellent starting point is this comprehensive post by one of the main contributors of the fast algorithm currently used in core:
> Unlike formatting, correct parsing involves high precision arithmetic.
Formatting also requires high precision arithmetic unless you disallow user-specified precision. That's why {fmt} still has an implementation of Dragon4 as a fallback for such silly cases.
Is it, though? It's genuinely hard for me to tell.
There's both serialization and deserialization of data sets with, e.g., JSON including floating point numbers, implying formatting and parsing, respectively.
Source code (including unit tests etc.) with hard-coded floating point values is compiled, linted, automatically formatted again and again, implying lots of parsing.
Code I usually work with ingests a lot of floating point numbers, but whatever is calculated is seldom displayed as formatted strings and more often gets plotted on graphs.
For serialization and deserialization, when the goal is to produce strings that will be read again by a computer, I consider the use of decimal numbers as a serious mistake.
The conversion to string should produce a hexadecimal floating-point number (e.g. with the "a" or "A" printf conversion specifier of recent C library implementations), not a decimal number, so that both serialization and deserialization are trivial and they cannot introduce any errors.
Even if a human inspects the strings produced in this way, comparing numbers to see which is greater or less and examining the order of magnitude can be done as easy as with decimal numbers. Nobody will want to do exact arithmetic computations mentally with such numbers.
Think about things like logging and all the uses of printf which are not parsed back. But I agree that parsing is extremely common, just not the same level.
Can the metadata feature be used to ergonomically emulate HTML attributes? It's not clear from the docs, and the spec doesn't seem to document the feature at all.
i feel hiccup indexed based magic is a common design pattern you see in early Clojure and its less common now (id say hiccup is the exception that lives on)
SDL GPU is extremely disappointing in that it follows the Vulkan 1.0 model of static pipelines and rigid workflows. Using Vulkan 1.3 with a few extensions is actually far more ergonomic beyond a basic "Hello, World" than using SDL GPU.
That might exclude a lot of your user base. For example a big chunk of Android users, or Linux workstation users in enterprise settings who are on older LTS distributions.
Given how C was seen in the past, before there was a change of heart to add C11/C17, minus atomics and aligned memory allocators (still between experimental or not going to happen),
1. No current plans for native mobile app. We plan to make the web app somewhat usable on mobile, soon. Eventually, yes we would like to have a native app also.
2. We have few banks supported (HDFC, ICICI). We have custom importer also, where you can define how to map a file to the fields we use. Note that import is manual. E.g. we don't scrape your bank etc. You export statement (like hdfc pdf statement, or zerodha transactions csv) and import it into the software.
Hard to parse the networking jargon, but does this enable offline connections?
If I have two devices on my local LAN (both connected to a Tailnet) and my home internet goes, currently the devices disconnect from each other. I have been looking for a way to prevent that, so that the all devices connected to the same WiFi network on a tailnet can find each other even if the internet connection to the wider world is broken.
> my home internet goes, currently the devices disconnect from each other.
You might be able to solve this by hosting your own control plane such as Headscale. Instead of having Tailscale manage/coordinate all the nodes on tailnet.
That'd be easy if only wireguard supported multiple endpoints per peer, then one could add the ULA address of the local devices in addition to the external one.
reply