Monday, August 3, 2020

Digest for comp.lang.c++@googlegroups.com - 20 updates in 4 topics

Mike Terry <news.dead.person.stones@darjeeling.plus.com>: Aug 03 01:57AM +0100

> uint64_t sqrt(uint64_t n) {
> return ::sqrt(static_cast<long double>(n));
> };
 
I have done this (or equivalent) in my own code, because it was the most
efficient algorithm I could find to achieve calculation of integral
square roots.
 
The reason is that floating point square roots have hardware support and
execute (at least in my environment) considerably quicker than anything
else I found.
 
The downside is that due to resolution issues, the floating point square
root is NOT always equal to the required integral square root, so
FURTHER PROCESSING IS REQUIRED TO TEST FOR THIS AND CORRECT IF REQUIRED.
[The floating result was sometimes out by one from the correct
result.] Even so, in timed tests this (with the follow-up corrections)
was clearly quicker than any other approach I looked at.
 
(So, it /might/ be good, but probably only as part of some larger
routine that handles any required corrections. Maybe on other
architectures or with other argument sizes the correction would not be
required. My environment was Windows 10 on a DELL laptop with Intel i7,
calculating square roots for 64-bit arguments. No, I don't think I have
the timing results any more...)
 
Mike.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Aug 03 07:29AM

> uint64_t sqrt(uint64_t n) {
> return ::sqrt(static_cast<long double>(n));
> };
 
Since the subject mentions sorting, you might as well sort on
sqrt(n)*sqrt(n), i.e. n.
 
Unless you need the loss of precision that makes e.g. integer sqrt(4)
and sqrt(5) compare equal.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Christian Gollwitzer <auriocus@gmx.de>: Aug 03 09:31AM +0200

Am 03.08.20 um 09:29 schrieb Jorgen Grahn:
> Since the subject mentions sorting, you might as well sort on
> sqrt(n)*sqrt(n), i.e. n.
 
Where do you see "sorting"? I see "store" and "sqrt" only.
 
Christian
"Öö Tiib" <ootiib@hot.ee>: Aug 03 02:02AM -0700

> uint64_t sqrt(uint64_t n) {
> return ::sqrt(static_cast<long double>(n));
> };
 
Result can be one less. Those would be more round:
 
uint16_t sqrt(uint16_t n) {
return ::sqrt(static_cast<double>(n)) + 0.5;
};
uint32_t sqrt(uint32_t n) {
return ::sqrt(static_cast<double>(n)) + 0.5;
};
uint64_t sqrt(uint64_t n) {
return ::sqrt(static_cast<long double>(n)) + 0.5;
};
Jorgen Grahn <grahn+nntp@snipabacken.se>: Aug 03 09:16AM

On Mon, 2020-08-03, Christian Gollwitzer wrote:
>> Since the subject mentions sorting, you might as well sort on
>> sqrt(n)*sqrt(n), i.e. n.
 
> Where do you see "sorting"? I see "store" and "sqrt" only.
 
Oh, I misread. Thanks. I read "integral sort" when I browed past it
quickly yesterday, and for some reason that "sort" stuck in my head.
 
Maybe I need new glasses after all.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
wyniijj@gmail.com: Aug 03 06:03AM -0700

Mike Terry於 2020年8月3日星期一 UTC+8上午8時58分09秒寫道：
> calculating square roots for 64-bit arguments. No, I don't think I have
> the timing results any more...)
 
> Mike.
 
Uh, it took me a while to understand what you were talking about was
representation issues!
Bonita Montero <Bonita.Montero@gmail.com>: Aug 03 03:33PM +0200

> uint64_t sqrt(uint64_t n) {
> return ::sqrt(static_cast<long double>(n));
> };
 
Which compiler today has long double support > 64 bit ?
I think they're rather rare.
jacobnavia <jacob@jacob.remcomp.fr>: Aug 03 04:15PM +0200

Le 03/08/2020 à 15:33, Bonita Montero a écrit :
>> };
 
> Which compiler today has long double support > 64 bit ?
> I think they're rather rare.
 
Under the ARM64 bits, gcc has long double of 128 bits implemented in
software. I have tried to implement that also in my compiler but it
isn't ready yet.
 
My compiler lcc-win has 80 bit long double support under x86 (32 and 64
bits)
Juha Nieminen <nospam@thanks.invalid>: Aug 03 02:55PM

> Which compiler today has long double support > 64 bit ?
> I think they're rather rare.
 
For Intel targets gcc and clang (and probably icc) have generated 80-bit
floating point for long doubles since the dawn of time. (This is
probably configurable with a compiler option, though.)
 
I think ARM64 specifies support for 128-bit floating point, but
whether this is supported by the actual CPU hardware is up to the
CPU manufacturer (and, AFAIK, the vast majority don't). In that
case it's usually simulated in software.
Manfred <noname@add.invalid>: Aug 03 05:31PM +0200

On 8/3/2020 4:15 PM, jacobnavia wrote:
> isn't ready yet.
 
> My compiler lcc-win has 80 bit long double support under x86 (32 and 64
> bits)
 
The documentation for MSVC still lists FP10.obj [*] as a link option to
change "the default precision control to 64 bits" which means 80-bit
intermediate values, however the linked to page "Floating-Point Support"
[**] has removed the FP10.obj option from recent versions of VS.
 
[*] https://docs.microsoft.com/en-us/cpp/c-runtime-library/link-options
[**]
https://docs.microsoft.com/en-us/cpp/c-runtime-library/floating-point-support
Bonita Montero <Bonita.Montero@gmail.com>: Aug 03 06:02PM +0200

> I think ARM64 specifies support for 128-bit floating point, but
> whether this is supported by the actual CPU hardware is up to the
> CPU manufacturer (and, AFAIK, the vast majority don't). ...
According to the Wikipedia the POWER9-CPU is the only one with 128 bit
fp hardware-support. I think there's rare need for 128 bit fp, but no
need for 128 bit fp with hw-speed.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Aug 03 11:51AM -0700

On 8/3/2020 9:02 AM, Bonita Montero wrote:
> According to the Wikipedia the POWER9-CPU is the only one with 128 bit
> fp hardware-support. I think there's rare need for 128 bit fp, but no
> need for 128 bit fp with hw-speed.
 
Deep fractal zooms would benefit from fast 128-bit floats in the GPU.
Bonita Montero <Bonita.Montero@gmail.com>: Aug 03 09:09PM +0200

>> fp hardware-support. I think there's rare need for 128 bit fp, but no
>> need for 128 bit fp with hw-speed.
 
> Deep fractal zooms would benefit from fast 128-bit floats in the GPU.
 
There are even climate-predictions made with endless chain-calculations.
And no GPU would ever have 128 bit fp.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Aug 03 02:26PM -0700

On 8/3/2020 12:09 PM, Bonita Montero wrote:
 
>> Deep fractal zooms would benefit from fast 128-bit floats in the GPU.
 
> There are even climate-predictions made with endless chain-calculations.
> And no GPU would ever have 128 bit fp.
 
Why? They have 64 bit...
 
https://docs.nvidia.com/cuda/floating-point/index.html
 
To get really deep fractal zooms, people create arbitrary precision in
the shader.
Lynn McGuire <lynnmcguire5@gmail.com>: Aug 03 01:37PM -0500

"C++ Creator Bjarne Stroustrup Weighs in on Distributed Systems, Type
Safety and Rust" by David Cassel

https://thenewstack.io/c-creator-bjarne-stroustrup-weighs-in-on-distributed-systems-type-safety-and-rust/
 
"In June the creator of the C++ programming language, 69-year-old Bjarne
Stroustrup, appeared on YouTube's channel on behalf of the Association
for Computing Machinery's Special Interest Group on Programming Languages."
 
"Some 35 years after bringing his language into the world, Stroustrup
compared his earliest goals to how the language has ultimately evolved,
shared some thoughts on the world's other programming languages, and
revealed what he does when he's not shepherding the language's massive
user community. And he also took a few moments to explain why C++ "is
far, far better than it was a couple of decades ago.""
 
Dadgum, we are all getting old.
 
Lynn
Daniel P <danielaparker@gmail.com>: Aug 03 02:01PM -0700

On Monday, August 3, 2020 at 2:38:10 PM UTC-4, Lynn McGuire wrote:
> "C++ Creator Bjarne Stroustrup Weighs in on Distributed Systems, Type
> Safety and Rust" by David Cassel
 
> https://thenewstack.io/c-creator-bjarne-stroustrup-weighs-in-on-distributed-systems-type-safety-and-rust/
 
"He's a walkin' contradiction, partly truth and partly fiction"
 
basic type safety? Nobody who was concerned with type safety would ever
have introduced a bool type silently convertible to/from int.
 
generics? Then why all those distinctly non-generic functions to_string()
to_wstring(), stoul, stoull, etc.?
 
"Takin' every wrong direction on his lonely way back home"
 
Daniel
RM <robert_magdziarz@wp.pl>: Aug 03 05:32PM +0200

I need to remove from identifiers[i_properties] (which is
vector<string>) all items (strings) that can be found in
identifiers[i_variables] (which is vector<string>, too).
 
for (string v : identifiers[i_variables]) {
auto it = find(identifiers[i_properties].begin(),
identifiers[i_properties].end(), v);
if (it != identifiers[i_properties].end()) {
identifiers[i_properties].erase(it);
}
}
 
It doesn't work. Strings are found but not erased.
Real Troll <real.troll@trolls.com>: Aug 03 06:15AM -1000

On 03/08/2020 16:32, RM wrote:
>         }
>     }
 
> It doesn't work. Strings are found but not erased.
 
I believe you need to assign an  index of the found item and then erase
it.  Try or change this code:
 
>             identifiers.erase (identifiers.begin()+index);
>         }
>     }
 
I have assumed that identifiers is your vector and this may or may not
be correct as your snippet is a bit cryptic for me!!.
"Öö Tiib" <ootiib@hot.ee>: Aug 03 09:50AM -0700

On Monday, 3 August 2020 18:32:59 UTC+3, RM wrote:
> }
> }
 
> It doesn't work. Strings are found but not erased.
 
Since it is random whiny garbage not program. Program looks like that ...:
 
#include <algorithm>
#include <iostream>
#include <string>
#include <vector>
 
size_t i_variables = 0;
size_t i_properties = 1;
std::vector<std::string> identifiers[2] = {
{"removing", "items", "from", "what"},
{"from", "noob", "what"}
};
 
int main() {

// your posted garbage begins
for (std::string v : identifiers[i_variables]) {
auto it = find(identifiers[i_properties].begin()
, identifiers[i_properties].end(), v);
if (it != identifiers[i_properties].end()) {
identifiers[i_properties].erase(it);
}
}
// your posted garbage ends

for (auto const& v : identifiers[i_properties]) {
std::cout << v << '\n';
}
}
 
... and it seems to work.
Demo: <http://coliru.stacked-crooked.com/a/3bc5c9364eb72e31>
Bart <bc@freeuk.com>: Aug 02 07:30PM +0100

On 02/08/2020 16:10, Scott Newman wrote:
> The bitfield-handling is the same for all little-endian and all big-en-
> dian compilers.
> So there are ways to have reliable IPC with bitfields.
 
Try this version:
 
#include <iostream>
 
struct S
{
unsigned short t : 9;
unsigned char c;
unsigned short r : 7;
};
 
int main()
{
std::cout << sizeof(S) << std::endl;
}
 
 
I get a size of 4 with gcc/clang, and 6 with msvc (all tested at
rextester.com). (I get 8 with one C compiler, for that same struct.)
 
You can try it with t:8, the results vary a little I think. Here it
depends on whether the non-bitfield 'c' field is subsumed into the
storage units used for the bit-fields.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)