- Deleted copy assignment operator vs. trivial copy assignment operator - 1 Update
- n-ary roots from complex numbers... - 3 Updates
- Unicode test - 1 Update
| bitrex <bitrex@de.lete.earthlink.net>: Apr 12 11:42AM -0400 On 04/11/2017 02:27 PM, Alf P. Steinbach wrote: > Lols. :) > Cheers & hth., > - Alf This seems to work fine (at least on my architecture and compiler.) Though is probably undefined behavior. At least from a "C++ outsider's" perspective, why you couldn't at least from a theoretical implementation standpoint memmove a class whose fields consisted solely of immutable pointers or aliases for such and otherwise met the requirements for being trivially copyable escapes me. #include <stack> #include <cstring> #include <iostream> struct Foo { Foo(std::stack<int>& thing1, int *const thing2) : _thing1(thing1), _thing2(thing2) {} std::stack<int>& _thing1; int *const _thing2; }; int main() { std::stack<int> a; std::stack<int> b; int c = 5; int *const d = &c; int e = 6; int *const f = &e; a.push(c); b.push(e); auto bar = Foo(a, d); auto baz = Foo(b, f); std::cout << *bar._thing2 << std::endl; std::cout << *baz._thing2 << std::endl; std::cout << bar._thing1.top() << std::endl; std::cout << baz._thing1.top() << std::endl; std::memmove(&bar, &baz, sizeof(Foo)); std::cout << *bar._thing2 << std::endl; std::cout << *baz._thing2 << std::endl; std::cout << bar._thing1.top() << std::endl; std::cout << baz._thing1.top() << std::endl; } |
| Marcel Mueller <news.5.maazl@spamgourmet.org>: Apr 12 08:42AM +0200 On 11.04.17 07.41, Christian Gollwitzer wrote: > root *= phasor; > myroots.push_back(root); > } I did not ckeck whether your code gives correct results, but this kind of calculation results in amazingly large floating point errors. A similar method is used in the GPU FFT algorithm for the Raspberry Pi and has errors in the order of 10^-3 for n of a few hundred. This even bad for single precision floats. The iterative multiplication tends to create cumulative errors for small angles. Chris's method is by far more accurate. There is a workaround possible by dealing with residuals of the complex multiplication, more precisely the additions and subtractions in the complex multiplication are the root of the errors. This workaround increases accuracy but not to the level of the transcendental functions. Marcel |
| Marcel Mueller <news.5.maazl@spamgourmet.org>: Apr 12 09:09AM +0200 On 11.04.17 01.09, Chris M. Thomasson wrote: > std::cos(angle_base + angle) * radius, > std::sin(angle_base + angle) * radius > }; Depending on your portability and speed requirements you might want to calculate sin and cos at once. Unfortunately sincos() never made it in the standard. However, ct_complex c = std::polar(radius, angle_base + angle); might do the job for you if it is appropriately optimized at your target platform. At least it is more readable. > } > // gain the average error sum... ;^o > return avg_err / n; Is there a reason why you calculated the /absolute/ floating point error rather than the RMS value as usual? > Can you run this? BTW, what about possibly reducing the average error > ratio? Any ideas? Hmm, there is probably no much you can do to reduce floating point errors except if you do your own calculations at higher precision. E.g. the complex angle calculations could be done with integer arithmetic. This gives you about 63 significant bits rather than 52 bits of IEEE 754 double. Since you are operating at the unit circle fixed point is no big deal. But reasonably implementing the transcendental functions is no fun either. Marcel |
| Manfred <noname@invalid.add>: Apr 12 02:57PM +0200 On 4/11/2017 1:09 AM, Chris M. Thomasson wrote: > std::cos(angle_base + angle) * radius, > std::sin(angle_base + angle) * radius > }; The pair of cos+sin calculations can be efficiently combined in a single call on platforms that allow that. This makes use of the power of numerical algorithms to calculate both values simultaneously in significantly less time than the two separate calls. I think it is a pity that sincos() was not included (was it considered?) in the standard, anyway these are the options I know of: - GNU glibc exports a sincos() function - on x87 a FSINCOS instruction is built in the FPU which can easily be used on 32-bit x86 - on x86_64 it requires more work, but still the core numerical algorithm (e.g. a Newton expansion) can be easily adapted to this. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Apr 12 06:03AM On Fri, 2017-04-07, David Brown wrote: > On 07/04/17 14:19, Alf P. Steinbach wrote: ... >> since 1981 old Unix unification of files, pipes and interactive i/o as >> streams of single bytes. Even with UTF-8 and no support for interactive >> features it's ungood, because UTF-8 error states are usually persistent. That surprises me, because UTF-8 was designed so that recovering would be easy. E.g. when you encounter an octet with MSB unset, you know you've found an undamaged ASCII character. > Linux terminals can certainly be screwed up if you try and cat a binary > file. I don't know if it is only UTF-8 errors, or other problems. It's very easy to screw up a terminal without involving UTF-8. I doubt if UTF-8 makes that worse. > No system is perfect, it seems. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| 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. |
No comments:
Post a Comment