On Wednesday, 27 January 2021 at 01:16:40 UTC, Bruce Carneal wrote:
> I'd vote for "overweight and almost-certainly-correct" over "trim but iffy" if the extra poundage is reasonable which, in the non-embedded environments, it appears to be.
>
> On another note, it looks like ryu was submitted by MS in late 2019 for inclusion in libc++.  Despite a massive 3 minutes of google-fuing, I'm still not sure how far that has gotten but the direction seems pretty clear.  A large body of others believe that ryu is a good way to go and are moving to standardize on it.
>
> It's not a live-or-die issue for me but ryu looks pretty good.

Yup, I'm in complete agreement with you on this.  I am curious if the MS implementation and usage carries the extra weight described (ryu alone is more lightweight, it's ryu printf that has the larger tables).

On Wednesday, 27 January 2021 at 01:38:38 UTC, Joseph Rushton Wakeling wrote:
>
> Yup, I'm in complete agreement with you on this.  I am curious if the MS implementation and usage carries the extra weight described (ryu alone is more lightweight, it's ryu printf that has the larger tables).

Judging by this presentation, it's just regular Ryu:

https://www.youtube.com/watch?v=4P_kbF0EbZM

On Wed, Jan 27, 2021 at 12:15:41AM +0000, Joseph Rushton Wakeling via Digitalmars-d wrote:
> On Tuesday, 26 January 2021 at 16:25:54 UTC, Berni44 wrote:
> > The paper states 104KB for doubles (can be compressed on the expense
> > of slowing  everthing down).
> 
> It also notes that "the size could be halved to 52 kB with no performance impact".
> 
> For comparison, a simple "Hello, World!", built with optimizations and stripped, comes to about 700 kB.  Even allowing that the 128-bit table (which will support 80-bit reals) is going to be larger, is this really an issue on modern machines?
> 
> The only circumstances I can see it mattering is in very low-resource embedded use-cases where D stdlib is unlikely to be viable anyway.

If there was a way to make these tables pay-as-you-go, I'd vote for it. Adding 104KB or 52KB even if the code never once formats a float, is not ideal, though granted, in this day and age of cheap, high-capacity RAM not really a big issue.


T

-- 
May you live all the days of your life. -- Jonathan Swift

On Wednesday, 27 January 2021 at 02:17:52 UTC, H. S. Teoh wrote:
> If there was a way to make these tables pay-as-you-go, I'd vote for it. Adding 104KB or 52KB even if the code never once formats a float, is not ideal, though granted, in this day and age of cheap, high-capacity RAM not really a big issue.

Agree completely -- pay-as-you-go should be important for something like this.  (But then, it should be important for the whole stdlib...)

On Wednesday, 27 January 2021 at 01:56:55 UTC, Paul Backus wrote:
> On Wednesday, 27 January 2021 at 01:38:38 UTC, Joseph Rushton Wakeling wrote:
>>
>> Yup, I'm in complete agreement with you on this.  I am curious if the MS implementation and usage carries the extra weight described (ryu alone is more lightweight, it's ryu printf that has the larger tables).
>
> Judging by this presentation, it's just regular Ryu:
>
> https://www.youtube.com/watch?v=4P_kbF0EbZM

This link: https://github.com/microsoft/STL/issues/172
suggests that they're adding 121KB of constant data and that they're compiling 385KB of source code. Wow.  Hope that's mostly the tables.

Also, per the youtube presentation that Paul pointed at, that does not include 80/128 bit FPs as their "long double" is defined to be "double".

On Wednesday, 27 January 2021 at 00:53:11 UTC, Bruce Carneal wrote:
> You made an assertion, in a proof discussion, that the tractable extension of the exhaustive proof to cover larger FP types, was "no problem".

Eh. I argued that you can fully cover an implementation without doing exhaustive testing. Don't confuse what I will waste my time on with what is possible.

For algorithms with limited loops and limited input you can also fully unroll them and prove them correct by bit-blasting. Algorithms that are written to execute few instructions are not unlikely candidates for that.

On Wednesday, 27 January 2021 at 02:17:52 UTC, H. S. Teoh wrote:
> If there was a way to make these tables pay-as-you-go, I'd vote for it. Adding 104KB or 52KB even if the code never once formats a float, is not ideal, though granted, in this day and age of cheap, high-capacity RAM not really a big issue.

Network transfer costs responsiveness,  Web/WASM. 100Kb to do float to string conversion in a web app would be crazy. Same with embedded.

Anyway, in most system programming scenarios where you control the format it would be better to use hex for accuracy anyway.

On 1/26/2021 6:20 PM, Joseph Rushton Wakeling wrote:
> On Wednesday, 27 January 2021 at 02:17:52 UTC, H. S. Teoh wrote:
>> If there was a way to make these tables pay-as-you-go, I'd vote for it. Adding 104KB or 52KB even if the code never once formats a float, is not ideal, though granted, in this day and age of cheap, high-capacity RAM not really a big issue.
> 
> Agree completely -- pay-as-you-go should be important for something like this.  (But then, it should be important for the whole stdlib...)

I've always thought things like this should be in the operating system. Get it right once, then everyone uses it.

Date/time/DST should be in the OS, so should the ridiculously large amount of code to deal with the level 3 Unicode madness.

On 1/26/2021 6:17 PM, H. S. Teoh wrote:
> If there was a way to make these tables pay-as-you-go, I'd vote for it.
> Adding 104KB or 52KB even if the code never once formats a float, is not
> ideal, though granted, in this day and age of cheap, high-capacity RAM
> not really a big issue.

We only really need it when the C stdlib printf is inadequate.

On Wednesday, 27 January 2021 at 01:16:40 UTC, Bruce Carneal wrote:
> I'd vote for "overweight and almost-certainly-correct" over "trim but iffy" if the extra poundage is reasonable which, in the non-embedded environments, it appears to be.

I'd like to compare the task to write floating point numbers to building a car: You need a chassis, wheels, seats and other stuff. And you need an engine. The engine in the PR is a simple division by 10 (as explained above). Ryu Printf would be an other engine, a better one when concerned of speed only (but much worse in memory usage). But all else of the car would remain the same (and is not touched by the proof of Ryu Printf, as far as I know). (My plan is to start with a simple engine and replace that one by better ones step by step.)

Coming back to your vote, I'd say it's a vote between "overweight and almost-certainly-correct" vs. "trim and correct". I don't say that, because I'm overly self confident, but because the "engine" I used is quite simple. And furthermore, that simple engine is already part of phobos (in the %e-car) sind almost one year, I just reuse it for the %f-car.

> A large body of others believe that ryu is a good way to go and are moving to standardize on it.
>
> It's not a live-or-die issue for me but ryu looks pretty good.

We are in complete agreement here. My point is: Adding ryu printf would be the second step before the first step: First build the car with a simple engine (that's what the PR does) and then replace this engine by a better one. I will (probably) do this job, but only in this order.

Adding ryu is jet another unrelated step. I've got plans to add ryu, or at least to prepare everything for adding it. But to do this std.format needs some other improvements (including refactoring) first, in order to add some space, where ryu nicely fits in. PR #7765 (splitting std.format into submodules) is the first step here, not absolutely needed, but with all these additions IMHO std.format is getting too large. It also simplifies working in parallel on replacing snprintf and improving the rest of std.format.