-
Notifications
You must be signed in to change notification settings - Fork 78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prime numbers (unit magnitude) unfit for standardization #509
Comments
I can't tell: are you saying that |
A definite yes for the former (again, my own opinion). For the latter one, I do find it unfortunate to close the door to improvements. |
I think the unfitness of The plan for the prime number paper is to outline the problem that motivated
These aren't mutually exclusive, but either is sufficient to obviate As for vector space magnitudes; well, it's the only known solution that satisfies our most basic requirements. Namely:
(These are off the top of my head; there may be one or two more.) If there's a viable alternative to vector space magnitudes (using prime numbers as a basis for that vector space), then I think we'd need to see an implementation and get real-world experience with it. |
This is good.
I was under the impression that some WG21 papers treated primers. Ah, but https://cpplang.slack.com/archives/C2PQKRWJU/p1518448215000036 does mention "the prime testing paper". You might want to get in contact with those folks,
This might not be a good strategy. |
Hi everyone. Thank you, @JohelEGP, for raising your concerns. It is always good to get feedback if something doesn't look right or seems wrong. It is also important for all of us to stay on the same page. Missing one or two online meetings may be enough to fall behind the discussions and then be confused about the general direction. I would like to encourage everyone to raise their concerns (if there are any), as @JohelEGP just did. Thanks to that, we can improve or clarify the issues. Said that, I think that this time, we are dealing with the miscommunication issue, and it seems we have a coherent view of how to proceed with magnitudes. Regarding P2980, it says:
but it also says in External dependencies:
As @chiphogg mentioned above, this is not about standardizing our algorithm as a part of the units library. It is about getting tools to implement this not only by us but by any other vendor in a portable way.
Yes, this is really unfortunate, and that is why we want to provide the above paper to SG6 to get compile-time-friendly utilities in the language that would allow a better implementation of vector space magnitudes without the need for such customization points.
Totally agree.
That is what #505 is about. The user-facing interface should use expression templates, which will improve the readability of generated types and will hide the actual algorithm below. Please share feedback there if you have some ideas on how to improve this feature. As we can't be sure that someone will not find a better algorithm for expressing magnitudes in the future and clearly we are not fully satisfied with the exciting solution (even though it works), we always planned to make it implementation-defined.
We should prevent that. We already made many errors in the C++ standard library by standardizing the implementation details (e.g. Moreover, we also ask SG6 for guidance on this subject with "Unit magnitudes" chapter in P2982. Maybe the Committee members or some readers of this paper will be able to come up with some improvements. |
Not really. For example, at some point in the future, |
I am not sure if I agree with that. We have to standardize the user-facing part somehow. Expression templates could be the official interface. Breaking it to powers of prime numbers done under the hood should be implementation-defined and not standardized. I think that is consistent with what you propose? |
In that case, yes, I agree it's the right direction. |
Sorry, I can't view this link.
That's fascinating! I have a hard time understanding how raising the iteration limit for a linear algorithm could lead to exponentially worse performance. Maybe your algorithm was different? |
I suppose the it's because I tested the compilers' behavior with this quadratic algorithm. constexpr unsigned f() {
unsigned res = 0;
for (unsigned i = 0; i != MAX; ++i)
for (unsigned j = 0; j != MAX; ++j)
res = i * j;
return res;
}
#if defined(__GNUC__) && !defined(__clang__)
constexpr unsigned i = f();
int main() { return i; }
#endif These are the times:
Once you need to raise the limit, times just get much worse. In my example here, |
Is that a valid test? With the iteration limit for compilers, the failure mode isn't "gracefully exit the loop". The failure mode is "produce a hard compiler error". Maybe this would be a better test? constexpr unsigned f() {
unsigned res = 0;
for (unsigned i = 0; i != MAX; ++i)
for (unsigned j = 0; j != i; ++j)
res = i * j;
return res;
}
#if defined(__GNUC__) && !defined(__clang__)
constexpr unsigned i = f();
int main() { return i; }
#endif It would be interesting to see how long it takes to find the largest "first prime factor" in
This would be a good data point on the feasibility of this approach. I think I'll need to get around to doing this for the prime paper. |
Prime numbers (unit magnitude) unfit for standardization
The current mp-units library (v2.0), since #300,
implements the amount of an unit, its magnitude, as a sum of prime numbers.
[ Note:
10 km = 10⋅10³ m = 10 000 m.
In code, 10 km is 10⋅10³ m, a quantity with runtime value 10 and compile-time values 10³ m.
10³ is the magnitude of the unit m.
-- end note ]
P2980 R0 and R1 mention, in "Plan for standardization" (§8 and §9, respectively),
What follows are my opinions, previously voiced and still unchanged.
What's changed since then is the appearance of P2980 with the quote above.
The exchanges sparked by my opinions gained me some insights.
This issue themes my insights around the expectation of
std::quantity
.The implementation uses
known_first_factor
.It is to be specialized for prime numbers it can't compute due to limits.
Before v2.0, it was exercised at
mp-units/test/unit_test/static/magnitude_test.cpp
Lines 30 to 31 in 5cc7fb1
mp-units/test/unit_test/static/magnitude_test.cpp
Lines 181 to 193 in 5cc7fb1
I have argued that such an interface is unfit for standardization.
I suggested that the unit magnitude should be implementation-defined
(with minimal requirements, e.g., at least as much support as
std::chrono::duration
withstd::ratio
;possibly with implementation-defined limits https://wg21.link/implimits).
My intent was to allow for better implementations to emerge.
@mpusz rightly argued that it would make for less portable code as the limits of implementations diverge.
Considering this, for standardization, I think we're left with a single option.
Standardize the current implementation as-is.
Code will be portable, with the limits of the unit magnitude fixed
(and with
known_first_factor
for working around those limits).The intent of the "Paper on prime numbers to SG6" is to make
the would-be implementation-defined interfaces
std::quantity
uses for unit magnitudesjust another library part of the C++ standard library.
But I think those prime number interfaces are unfit for standardization.
And so, I have thought, can't we use expression templates instead of prime numbers?
There remains the need to simplify (which #300 achieved by definition).
There remains the need to tell whether two magnitudes are equal.
Or maybe we could fall back to using expression templates when specializing
known_first_factor
would be needed.I'm not sure what we would lose by foregoing #300 for expression templates on the unit magnitudes.
Would we have to use more explicit casts?
How would it affect what can be done by the library?
I'd like to know that in terms of possibility, simplicity, and safety.
Would it make existing use cases impossible to express, or
would it actually permit more without going through
known_first_factor
?For certain, if we had to use more explicit casts, it wouldn't be simpler.
And if we had to use more casts, we'd shadow the casts with actual safety concerns.
The text was updated successfully, but these errors were encountered: