I'm not familiar with C and I'm trying to translate a piece of code I found to another language. For the most part, it's been rather intuitive but now i encountered a bit of code in which a subtraction operator is preceeded by a fullstop, like this:
double C;
C = 1.-exp(A/B)
I searched for it but all I can find about the dot operator is the standard property access of an object. I've encountered the '.-' operator in other langauges where it denoted element-wise operation on an array, but in my code none of the elements are arrays; all of A, B and C are doubles.
It instructs the compiler to treat that literal number as a floating-point number.
1. = 1.0
In your case C = 1.-exp(A/B) is equivalent to C = 1.0 -exp(A/B)
Related
K&R's C language has the following sentence:
A compiler's license to treat mathematically associative operators as computationally associative is revoked.
This is in the Appendix C, which tells what's different from before ANSI C. But I don't know how computationally associated is different from mathematically associated. Maybe I guess the mathematically associative is a * b * c = (a * b) * c (left), or a * (b * c) (right).
Consider this code:
#include <stdio.h>
int main(void)
{
double a = 0x1p64; // Two the power of 64, 18,446,744,073,709,551,616.
double b = 1;
double c = -a;
printf("%g\n", a+b+c);
}
In the C grammar, a+b+c is equivalent to (a+b)+c, so a and b are added first, and then c is added. In the format commonly used for double, a+b yields 264, not 264+1, because the double format does not have enough precision to represent 264+1, so the result of the addition is the ideal mathematical result rounded to the nearest representable value, which is 264. Then adding c yields zero, so “0” is printed.
If instead we calculated a+c+b, adding a and c would give zero, and then adding b would give one, and “1” would be printed.
Thus, floating-point operations are not generally associative; a+b+c is not the same as a+c+b.
In ordinary mathematics with real numbers, a+b+c is the same as a+c+b; addition of real numbers is associative.
Prior to standardization, some C compilers would treat floating-point expressions as if operators were associative (for those operators whose counterparts in real-number-arithmetic were associative). The C standard does not permit that in implementations that conform to the standard. Conforming compilers must produce results as if the operations were performed in the order specified by the C grammar.
Some compilers may still treat floating-point operators as associative when operating in non-standard modes, which may be selected by flags or switches passed to the compiler. Also, because the C standard allows implementations to perform floating-point arithmetic with more precision than the nominal type (e.g., when computing a+b+c, it can calculate it as if the types were long double instead of double), that can produce results that are the same as if operations were rearranged, so you can still get results that look like operators have been reordered associatively, depending on the C implementation and the flags used.
I'm attempting to integrate
> ans1 := ([int(e^inx/(2*pi), x = -Pi .. Pi, AllSolutions)], assuming [n::integer]);
I was able to get several other similar integrals to evaluate properly. However, for some reason when I evaluate this integral I simply get back e^{inx}. Moreover, if I add '*' between i,n and x I get a different answer.
Is there any reason for this? Am I missing something?
As stated, 'inx' is a single variable in your expression and thus, the answer that you're getting is expected since you do not have an 'x' term in your function. In order to have three separate terms, i, n, and x, you will need to add in the * between each term, 'inx'. If you are entering this in Maple's 2-D math notation, then spaces are interpreted as implicit multiplications and you can leave out the *s.
In addition, you might need to consider changing a few other parts of your syntax to conform to the Maple language (unless of course these are intentional):
The exponential function 'e' is entered as 'exp'
'pi' is the symbolic lowercase Greek letter; 'Pi' is the mathematical constant.
By default, Maple uses 'I' for imaginary numbers. You can change your default to use 'i', but otherwise this is just a symbol 'i'.
Applying these changes to your code, try something like:
int( exp(I*n*x)/(2*Pi), x = -Pi .. Pi, ...)
I come from a Python background and I know that in Python you can do something like this:
'g'*8
gggggggg
Now, I know you can perform a for loop to get the same result in C, but is there actually a way to multiply strings and characters in C?
None. It's not in the C language.
But you can get them from library which is pretty useful. For your question, you can define an char array and use memset(doc).
char str[9];
memset(str, 'g', 8);
str[8] = '\0';
Then the str is "gggggggg". str[8] should be a terminal \0 when represents string.
You don't. You cannot multiply strings in c. You have to use other methods.
Since implementing the functionality is simple, i'd like to elaborate what happens when you try to use the same semantics.
There are two things that might happen. In python there is no difference between "c" and 'c', both are strings of length one. In c language, those would semantically be very different.
'c'*8 is valid c code, because it coverts character into its integer value and performs standard integer multiplication.
c does not have a native string type, and "c" would have type of char*, and at least my compiler says there is no operator * for char* and int, although I believe some older compilers might allow to convert pointer to an integer and perform operation, however it rarely makes any sense (note that +/- operators are used and useful).
Moreover, since you cannot define ( or overload ) operators in c, there is no standard-compatible way to achieve it. It would be possible to implement such semantics valid in c++ but not c.
My homework is to write a regular expression representing the language of numerical literals from C programming language. I can use l for letter, d for digit, a for +, m for -, and p for point. Assume that there are no limits on the number of consecutive digits in any part of the expression.
Some of the examples of valid numerical literals were 13. , .328, 41.16, +45.80, -2.e+7, -.4E-7, 01E-06, +0
I came up with: (d+p+a+m)(d+p+E+e+a+m)*
update2: (l+d+p+a+m)(d+p+((E+e)(a+m+d)d*) )* im not sure how to prevent something like 1.0.0.0eee-e1.
Your regular expression does not support the various suffixes (l, u, f, etc.), nor does it support hexadecimal or octal constants.
The leading signs (+ or - in front of the number) are not lexically part of the constant; they are the unary + and - operators. Effectively, all integer and floating constants are positive.
If you need to fully support C99 floating constants, you need to support hexadecimal exponents (p instead of e).
Your regular expression also accepts many invalid sequences of characters, like 1.0.0.0eee-e1.
A single regular expression to match all C integer and floating literals would be quite long.
Untested, but this should be along the right lines for decimal at least. (Also, it accepts the string ".", or I think it does anyway; to fix that would eliminate the last of the common code between integer and FP, the leading [0-9]*.)
[0-9]*([0-9]([uU](ll?+LL?)+(ll?+LL?)?[uU]?)+(\.[0-9]*)?([eE][+-]?[0-9]+)[fFlL])
This Regex will match all your need:
[+-]?(?P<Dot1>\.)?\d+(?(Dot1)(?#if_dot_exist_in_the_beginning__do_nothing)|(?#if_dot_not_exist_yet__we_accept_optional_dot_now)(?P<Dot2>\.)?)\d*(?P<Exp>[Ee]?)(?(Exp)[+-]?\d*)
I remember reading a book talking about standard the C programming language. It said in some kinda C you can write i=+1 which equals i+=1. So i(operator)=(expression) equals i=(operator)(expression). I never see this kind of C, is there someone who can explain this?
Best regards and thanks,
Fan
That was the very very inital syntax for the += operator in C. I think it was deprecated even before the first edition of K&R book.
EDIT: A PDF with the C Reference manaual can be found here:
http://www.math.utah.edu/computing/compilers/c/Ritchie-CReferenceManual.pdf
look at 7.14.1
(Alas, the one posted by AnT is no longer valid)
This is true. That version of C is called CRM C (CRM stands for "C Reference Manual" - a document written by Dennis Ritchie). There are many weird things in that version of C.
You can download the document here http://cm.bell-labs.com/cm/cs/who/dmr/cman.pdf
Kernighan and Ritchie's The C Programming Language, first edition explains this. I found a quote in this post on comp.lang.c. Relevent part of the quote:
Since C is an evolving language, certain obsolete constructions may be
found in older programs. Although most versions of the compiler support
such anachronisms [--as of 1978--], ultimately they will disappear,
leaving only a portability problem behind.
Earlier versions of C used the form =op instead of op= for assignment
operators. This leads to ambiguities, typified by
x=-1
which actually decrements x since the = and the - are adjacent, but
which might easily be intended to assign -1 to x.
Wikipedia also has a similar description. From their entry for C, talking about K&R C and "Old C" differences:
compound assignment operators of the form =op (such as =-) were changed to the form op= to remove the semantic ambiguity created by such constructs as i=-10, which had been interpreted as i =- 10 instead of the possibly intended i = -10.
It would most definitely give issues when you want to assign a negative number to a variable. What decides what you mean then? Spacings? (ew!) Or parenthetis (double ew!). Here are some examples showing the issues
i = -1; //Is this any different from the line below? Since when have spaces in these kind of cases mattered?
i =- 1; //If the suggested syntax existed, what would these two lines mean?
//The only thing left now (if we rule out making spaces matter) is to use parenthetis in my eyes, but...
i =(-1); //This is just ugly
As pointed out in the comments, the * symbol which is used to dereference pointers presents the exact same issue as the minus sign.
This is not C. In standard C that is equivalent to i=1. Might it be that you are looking for i++?
A little bit of whitespace might help clarify this for you.
When you write i=+1, what is actually happening is i = +1. This is because there is no =+ operator in C. The = is treated as its own operator, and the + is a unary operator acting on the constant 1. So the evaluation of this statement starts on the right hand side of the = operator. +1 will evaluate to 1 and the = operator will then assign that value to the variable i.
+= is it's own operator in C, which means "add the value of the expression on the right side of this operator to the variable on the left side, and assign it to that variable, so something like the following:
i = 3;
i += 2;
would evaluate to 5 because the += operator will evaluate the right side of the operator (in this case 2, and will add it to the left side (in this case, i has a value of 3) and will assign it to the variable on the left. In essence, this becomes i = (2 + 3). Therefore, the variable i will have a final value of 5.
If you're just adding the value 1 to an integer variable, you can use the ++ operator instead. Adding this operator after a variable (i.e. i++) will cause the current line of code to execute before incrementing the variable by one. Prefixing the operator in front of the variable will cause the statement to be executed after the variable is incremented.
e.g.:
i = 5;
j = i++;
will result in i = 6 and `j = 5', whereas
i = 5;
j = ++i;
will result in i = 6 and j = 6.
Similarly, the -- operator can be used to decrement (decrease) the variable by one, similar to how ++ will increment (increase) the variable by one. The same rules regarding positioning the operator before or after the variable apply to both operators.
Hope this clears things up a bit.