MPFR: get sin of mpf_class - gmp

I installed gmp and mpfr on my environment. Now I can successfully
#include <gmpxx.h>
#include <mpfr.h>
#include <mpf2mpfr.h>
Now, say that I initialize an mpf_class with some value:
mpf_class x = 0.73;
How can I use mpfr to get the sin of this number? I just need an mpf_class in, an mpf_class out. Something like:
mpf_class y = sin(x)
Which obviously doesn't work. I noticed that there is a mpfr_sin function, which I called like this:
mpfr_sin(x, y, MPFR_RNDN);
But that didn't work as well. So what am I supposed to do? Am I doing something wrong?
Thank you

mpf2mpfr.h is probably not what you want. It contains plenty of #define to replace mpf names with mpfr names in everything that follows. If you wanted a chance of having it work in your case, you would have to include mpf2mpfr.h before gmpxx.h. However, the file does not translate everything. The following lets it compile in C++03 (as long as you don't convert to mpq_class):
#include <mpfr.h>
#include <mpf2mpfr.h>
void mpfr_get_q (mpq_ptr, mpfr_srcptr);
#undef mpq_set_f
#define mpq_set_f(x,y) mpfr_get_q(x,y)
#include <gmpxx.h>
int main(){
mpf_class x=.73;
mpf_class y;
mpfr_sin(y.get_mpf_t(),x.get_mpf_t(),MPFR_RNDN);
}
but trying to print with operator<< will print a pointer instead of the number, for instance. Extra functions provided in C++11 would require more tweaking, it is easier to disable them: #define __GMPXX_USE_CXX11 0 before including gmpxx.h.
There are mostly two ways to solve this and both start with removing mpf2mpfr.h. The first one is to create a temporary mpfr_t:
mpf_class x=.73;
mpf_class y;
mpfr_t xx;
mpfr_t yy;
mpfr_init_set_f(xx, x.get_mpf_t(), MPFR_RNDN);
mpfr_init(yy);
mpfr_sin(yy, xx, MPFR_RNDN);
mpfr_get_f(y.get_mpf_t(), yy, MPFR_RNDN);
The second one is to drop mpf completely and use only mpfr. Its webpage lists 6 C++ wrappers for it, several of which are still maintained.

Related

OBJC_EXTERN: what's the purpose?

Hi was reviewing some Objective-C code and found out the following statement:
OBJC_EXTERN void CLSLog(NSString *format, ...) NS_FORMAT_FUNCTION(1,2);
What does this mean?
Also, what is supposed to be the syntax of this statement?
Thanks in advance.
OBJC_EXTERN is defined in <objc/objc-api.h> as
#if !defined(OBJC_EXTERN)
# if defined(__cplusplus)
# define OBJC_EXTERN extern "C"
# else
# define OBJC_EXTERN extern
# endif
#endif
and therefore prevents "C++ name mangling" even if the above declaration is
included from a C++ source file, as for example explained here:
In C++ source, what is the effect of extern "C"?
For pure C code, you can just remove the OBJC_EXTERN, because the extern
keyword is not needed in a function declaration.
NS_FORMAT_FUNCTION is defined as
#define NS_FORMAT_FUNCTION(F,A) __attribute__((format(__NSString__, F, A)))
and __attribute__((format(...))) is a GCC specific extension, also understood
by Clang:
http://clang.llvm.org/docs/LanguageExtensions.html#format-string-checking
http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html
It allows the compiler to check the number and types of the variable argument list
against the format string. For example
CLSLog(#"%s", 123);
would cause a compiler warning, because %s is the placeholder for a string,
but 123 is an integer.

clang optimization bug?

I've been trying to track down what seems like a bug in clang, and I think I've got a reasonably minimal reproduction of it. Here's my program:
#include <stdio.h>
#include <string.h>
#include <ctype.h>
#define x_Is_Digit(x) isdigit((unsigned char) (x))
void Odd_Behavior(char * version)
{
char * ptr, *tmp;
for (ptr = version; x_Is_Digit(*ptr); ptr++);
ptr++;
for (tmp = ptr; x_Is_Digit(*ptr); ptr++);
if (ptr == tmp)
printf("%08x == %08x! Really?\n", ptr, tmp);
}
int main()
{
char buffer[100];
strcpy(buffer, "3.8a");
Odd_Behavior(buffer);
return(0);
}
When I compile it with optimization, in the clang included with the Xcode download ("Apple clang 2.1"):
clang++ -Os optimizebug.cpp
And run it, it reports:
6b6f2be3 == 6b6f2be2! Really?
This strikes me as a tad odd, to say the least. If I remove the (unsigned char) cast in x_Is_Digit, it works properly.
Have I run into a bug in clang? Or am I doing something here that's causing some sort of undefined behavior? If I compile it with -O0, I don't get the problem.
Certainly looks like a bug to me. Clang mainline doesn't display this (at least on darwin/x86-64). Please file a bug at llvm.org/bugs with full details on how to reproduce this. Stack overflow isn't a great place to report compiler bugs :)
Definitively a bug. If the two pointers are equal at the if statement, they must also be equal in the printf statement.

Is it possible to use #ifdef like checks in assembler?

I have tested a bit of assembler on Linux using the AT&T syntax. One thing that struck me was that the book I was reading was written from a 32-bit standpoint. Thus, all sizes would have to be changed to the correct 64-bit versions for me. Or I could (which I did) assemble the code using the --32 flag for as and the -melf_i386 flag for ld when linking. I have also adapted some of the code and to run on Windows under Cygwin.
But that got me thinking. Is there a way to do ifdef like checks in assembler to do one thing if I'm on Windows and another under Linux and also handle 32 vs 64 bit that way? For example to have a .globl _start under Linux and a .globl _main under Windows.
Or is this handled by checking before assembling and having different source files to assemble based on the result of the checks?
I.e. foo_linux.s and foo_windows.s
If so, how do you overcome that fact that you will not know which .s files you will use, and thus have to include, when you are creating your program?
For example, say that we have a socket_linux.s and a socket_windows.s. They both present an identical interface but do the OS specific work associated to sockets. But when I work with the sockets in my program I will not know if I need the Windows or Linux version included. So I would be kinda screwed :)
So how is this handled in Assembler? In C++ for example I could include my socket.h and socket.cpp and wrap all the Linux and Windows specific code in #ifdef statements.
If you use GCC to compile your files and name them .S (with uppercase S) or .sx, it will pass them through the preprocessor before invoking the assembler.
From the docs:
file.s
Assembler code.
file.S
file.sx
Assembler code which must be preprocessed.
You can add -v to the command line to see how the various sub-processes are invoked.
in MASM (.asm), you can use ifdef, ifndef and the likes, as:
ifdef X64
endif
When writing for different platforms you can define some macro for loading target specific files:
FILE target.h
#if defined(__arm__)
#define target "arm"
#elif defined(__x86_64__)
#if defined(_WIN64)
#define target "win64"
#else
#define target "linux64" // all non-Win share the same calling convention
#endif
#else
// 32bit defs
#endif
Then you can include target specific files with the macro, two string literals successively get one single literal:
#include "target.h"
#include "target_specific_code_" target ".h"
It includes one of these files:
target_specific_code_arm.h
target_specific_code_win64.h
target_specific_code_linux64.h
...
EDIT:
Like this, you can also define target specific assembler instructions for later use in inline assembly:
#ifdef ...
#define ASM_PP_LOAD_WORD "movi "
#else
#define ASM_PP_LOAD_WORD "mov "
#endif
or as macro
#ifdef ...
// when using intel assembler there is a different
// order of parameters
#define ASM_PP_LOAD_WORD(a, b) "movi " #b ", " #a
#else
#define ASM_PP_LOAD_WORD(a, b) "mov " #a ", " #b
#endif

MinGW and "declaration does not declare anything"

I'm working on converting a Linux project of mine to compile on Windows using MinGW. It compiles and runs just fine on Linux, but when I attempt to compile it with MinGW it bombs out with the following error message:
camera.h:11: error: declaration does not declare anything
camera.h:12: error: declaration does not declare anything
I'm kind of baffled why this is happening, because
I'm using the same version of g++ (4.4) on both Linux and Windows (via MinGW).
The contents of camera.h is absurdly simple.
Here's the code. It's choking on lines 11 and 12 where float near; and float far; are defined.
#include "Vector.h"
#ifndef _CAMERA_H_
#define _CAMERA_H_
class Camera{
public:
Vector eye;
Vector lookAt;
float fov;
float near;
float far;
};
#endif
Thanks for your help.
EDIT: Thanks both Dirk and mingos, that was exactly the problem!
Edit If you happen to include windef.h (either directly or indirectly), you will find
#define FAR
#define far
#define NEAR
#define near
there. I think, that this is the culprit.
Try
#undef near
#undef far
before your class definition.
Try giving them different names, like
float my_near;
float my_far;
I recall Borland using "near" and "far" as keywords (my 1992 Turbo C had these, back in MS-DOS era). Dunno if this is the case with gcc, but you can always try that.
In <windef.h>, you'll find on the following lines:
#define NEAR
#define near
Simple answer: you can't #undef them because they're a part of the Windows headers (_WINDEF_H will still be defined even if you #undef those definitions, so it won't be re-included if you try to #include <windef.h> again, not to mention the fact that if you #undef _WINDEF_H before using #include <windef.h> after your class definition, you'll end up with duplicate definitions for things like RECT, LONG, PROC and more), so the only other solution is to change your variable names.

Is there a length limit on g++ variable names?

See title​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​
Short Answer:
No
Long Answer:
Yes, it has to be small enough that it will fit in memory, but otherwise no, not really. If there is a builtin limit (I don't believe there is) it is so huge you'd be really hard-pressed to reach it.
Actually, you got me really curious, so I created the following Python program to generate code:
#! /usr/bin/env python2.6
import sys;
cppcode="""
#include <iostream>
#include <cstdlib>
int main(int argc, char* argv[])
{
int %s = 0;
return 0;
}
"""
def longvarname(n):
str="x";
for i in xrange(n):
str = str+"0";
return str;
def printcpp(n):
print cppcode % longvarname(n);
if __name__=="__main__":
if len(sys.argv)==2:
printcpp(int(sys.argv[1]));
This generates C++ code using the desired length variable name. Using the following:
./gencpp.py 1048576 > main.cpp
g++ main.cpp -o main
The above gives me no problems (the variable name is roughly 1MB in length). I tried for a gigabyte, but I'm not being so smart with the string construction, and so I decided to abort when gencpp.py took too long.
Anyway, I very much doubt that gcc pre-allocates 1MB for variable names. It is purely bounded by memory.
an additional gotcha, some linkers have a limit on the length of the mangled name. this tends to be an issue with template and nested classes more than identifier length but either could trigger a problem afaik
I don't know what the limit is (or if there is one), but I think it is good practice that there should be one, in order to catch pathological code, for example that created by a runaway code generator. For what it's worth, the C++ Standard suggests a minimum of 1K for identifier length.