- sin/cos with constexpr - 1 Update
- Iterator and [] operator - 4 Updates
| Nobody <nobody@nowhere.invalid>: Sep 17 02:08PM +0100 On Sun, 13 Sep 2015 22:13:21 +0200, mark wrote: > I don't think there is a 'sane' possibility. But, you if you don't care > about sanity, you can evaluate a taylor series as constexpr: > http://prosepoetrycode.potterpcs.net/2015/07/more-fun-with-constexpr/ FWIW, here's a complete implementation of such: #include <cmath> namespace { static const int terms = 20; constexpr double alternate(double x2, int i, int k, double xn, long long nf) { return (i > terms) ? 0.0 : (k*xn/nf + alternate(x2, i+2, -k, xn*x2, nf*(i+1)*(i+2))); } } namespace taylor { constexpr double sin(double x) { return alternate(x*x, 1, 1, x, 1); } constexpr double cos(double x) { return 1.0 + alternate(x*x, 2, -1, x*x, 2); } } It doesn't always agree with libc's sin/cos, but any difference appears to be limited to the last bit. sin() differs in ~15% of cases, cos() in ~30%. |
| mark <mark@invalid.invalid>: Sep 17 02:10AM +0200 On 2015-09-16 23:33, Jens Thoms Toerring wrote: > I found that an overloaded '[]' operator in the iterator > neither seemed to be necessary nor was it called if defined. It normally is called. You should post complete code. > Since 'x[n]' is just syntactic sugar for '*(x+n)' I'm tempted > to assume that having the required '+' and the dereferencing > operator is all that's actually needed. 'operator*()' doesn't work for this. You probably have a conversion operator defined - e.g. an 'operator int*()'. This guy could be used for both 'x[n]' and '*(x+n)' and is probably invoked. You should really post complete code. |
| "Öö Tiib" <ootiib@hot.ee>: Sep 17 03:15AM -0700 On Thursday, 17 September 2015 01:38:55 UTC+3, Jens Thoms Toerring wrote: > and that it's a 'courtesy thing' to do it anyway? I'd not mind > defining one at all, but I'm puzzled if it is required and, if > yes, why;-) It is operator that has been required from random access iterator since C++98. Iterators were in C++ since standardization and were considered as replacement to raw pointers. Implementations may still use raw pointers as iterators of 'std::string', 'std::valarray', 'std::array' or 'std::vector' (but no implementation I know of does). Code that uses raw pointers as random access iterators of some raw buffer sometimes uses also operator []. Operator [] was required to simplify migration of such code to (potentially safer) containers and iterators. Does that answer your "why"? |
| jt@toerring.de (Jens Thoms Toerring): Sep 17 11:53AM > > I found that an overloaded '[]' operator in the iterator > > neither seemed to be necessary nor was it called if defined. > It normally is called. You should post complete code. Sorry, I should have - I just hoped I could do without it since it's over 250 lines. But if I had you (and some others) probably would have spotted my mistake immedi- ately. For completeness sake you can see it at: http://users.physik.fu-berlin.de/~jtt/iter_test.cpp The solution to the puzzle is simple: I made the mistake of using '[]' with a std::reverse_iterator<My_Iter> instead of with an instance of My_Iter itself. And reverse_iterator, of course, comes with a '[]' operator of its own. If I try to use '[]' on an instance of my iterator instead and don't have '[]' defined in that class, compilation fails as it should. Sorry for the confusion! > > to assume that having the required '+' and the dereferencing > > operator is all that's actually needed. > 'operator*()' doesn't work for this. Ok. That was born out of my confusion why it seemed to work without a '[]' operator... Thanks and best regards, Jens -- \ Jens Thoms Toerring ___ jt@toerring.de \__________________________ http://toerring.de |
| jt@toerring.de (Jens Thoms Toerring): Sep 17 11:58AM > raw buffer sometimes uses also operator []. Operator [] was > required to simplify migration of such code to (potentially safer) > containers and iterators. Does that answer your "why"? Yes, thank you! After I finally spotted the mistake I made in my program (see my reply to 'mark') it's now all clear - what threw me off (and made me jump to wrong conclusions) was that, due to an error of mine, it seemed to work with- out '[]'. But, of course, it doesn't. Thanks and best regards, Jens -- \ Jens Thoms Toerring ___ jt@toerring.de \__________________________ http://toerring.de |
| 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