4 ms·

#define M_PI 3.14159265358979323846264338327950288

by CalChris 10y ago

tedmielczarek 10y ago
const M_PI: f64 = 3.14159265358979323846264338327950288; You wouldn't use a macro for something like that in Rust.
steveklabnik 10y ago
I don't understand what this means. You'd use const in Rust for this, not a macro.
- CalChris 10y ago
  That was just a trivial example. Yes, you could use a const which would be difficult to share across files. Moreover, if you wanted to do something equally textual #define PASS_VERBOSE if (flag_verbose && first_pass) printf you just might be able to but only with a completely different tool. A macro processor is not of the language; it is above the language.
  - kibwen 10y ago
    > A macro processor is not of the language; it is above the language. Then feel free to use the C preprocessor with Rust, it works just as well. :P Just like it does with Python, and Java, and...
    - int_19h 10y ago
      Better yet, use m4.
    - kazinator 10y ago
      The C preprocessor can only be used with Python as long as you don't do anything multi-line: #define whatever(param) \ foo: \ bar \ baz I made a preprocessor some 18 years ago that could be used with Python. Wayback Machine: https://web.archive.org/web/20000815202258/http://users.footprints.net/~kaz/mpp.html https://web.archive.org/web/20000815202258/http://users.foot...
  - steveklabnik 10y ago
    > which would be difficult to share across files. It's path::to::wherever::PI. That's it. Just like any other item. If you want to use only PI in your code, you'd use 'use', like any other name. Your second example is something better suited to a macro, it's true. I _think_ what you're getting at here is that you only want text substitution? I think we will have to agree to disagree if that's true :)
    - CalChris 10y ago
      Well, given that you have only written two macros in your years of Rust, I would strongly encourage you or the language ergonomics initiative to openly question why this is so. Clearly, Rust has a clever approach but I'm questioning whether it is in fact a usable approach. Too much solution for not enough problem. Yes, I do like textual substitution. Guilty. This is a common old school low level paradigm. Still, the underlying language and its compiler exist below to enforce the rules on any atrocities I commit with my macros.
      - steveklabnik 10y ago
        What I'm saying is, I personally find Rust expressive enough to never need macros, and so their ease of use, to me personally, is not an issue either way. (Well, other than the import bit, I do care about that.) Those who do use and write them heavily are the ones actually involved in the macros 2.0 effort. There are certainly flaws.
      - int_19h 10y ago
        If you want textual substitution, you are not limited by anything that Rust offers. You can incorporate any existing text preprocessor - of which there's a multitude, and at least cpp and m4 are in pretty much any Unix system - into your compile pilelines. By the very definition of textual substitution, it is completely orthogonal to the meaning of the output (in this case, Rust code). The kind of macros Rust implements, on the other hand, are the kind that have to be language-specific, because they deal with the syntax tree of that particular language. They also enable many things that are outright impossible with text substitution, such as hygienic macros.
  - lobster_johnson 10y ago
    A "macro" in C is not the same thing as a "macro" in Rust. By your logic, Erlang processes aren't processes because they aren't kernel processes, or Go packages aren't packages because they don't use the Java package naming convention. Nobody owns the exclusive right to define the words we use.
  - tatterdemalion 10y ago
    You want textual macros. Rust doesn't have this feature, it has a syntactic macro feature inspired by the Lisp family. Sorry.
kinghajj 10y ago
I thought that style was considered bad form in modern C/C++ (esp. the later, with `constexpr`). What's wrong with const PI: f64 = 3.14159265358979323846264338327950288; ?
- cardiffspaceman 10y ago
  What machine can represent all those decimal digits so precisely that the ending decimal digits ...0288 are exactly right and not ...0287 ? I'll accept without looking it up that the statement is correct syntax in some language (it doesn't look like C++ to me).
  - pklausler 10y ago
    See above. The constant is (a) not pi, and (b) not an exact decimal representation of any binary floating-point number.
pklausler 10y ago
3.141592653589793115997963468544185161590576171875 is the exact decimal representation for the 64-bit IEEE-754 number that's closest to pi (viz. 0x400921FB54442D18). Any time you see a decimal floating-point constant with a nonzero fractional part that doesn't end in '5', you're looking at a bug. EDIT: As long as this grizzled old Fortran programmer is giving out free advice, I'll add two more items every programmer should know about binary floating-point: a) Every binary floating-point number can be represented exactly in decimal notation if you use enough digits. b) Those decimal values are the only ones that can be exactly converted to binary; all of the rest require rounding.
- f2f 10y ago
  Any time you see a decimal floating-point constant with a nonzero fractional part that doesn't end in '5', you're looking at a bug. depends on the language. for example here it is in go: Pi = 3.14159265358979323846264338327950288419716939937510582097494459 // http://oeis.org/A000796
  - deathanatos 10y ago
    What the person above you is saying, I think, is to remember that computers usually work in base 2. This applies to IEEE floating points, where the mantissa is in base 2; when you represent fractions in base two, they're powers of two: 1/2 (.5), 1/4 (.25), 1/8 (.125), etc. What he's asserting, I think, is that any power-of-two fraction, or any combination of those (in binary), result in a number ending in 5 when represented in decimal. Anything else is going to be rounded to the nearest representable number (that ends in 5). So, go might have that value in its source, but it's getting rounded to something that would, if represented in decimal, end in 5.
    - f2f 10y ago
      In Go, floating-point constants may have very high precision, so that arithmetic involving them is more accurate. The constants defined in the math package are given with many more digits than are available in a float64. Having so many digits available means that calculations like Pi/2 or other more intricate evaluations can carry more precision until the result is assigned, making calculations involving constants easier to write without losing precision. It also means that there is no occasion in which the floating-point corner cases like infinities, soft underflows, and NaNs arise in constant expressions.

#define M_PI 3.14159265358979323846264338327950288

tedmielczarek 10y ago

const M_PI: f64 = 3.14159265358979323846264338327950288; You wouldn't use a macro for something like that in Rust.

steveklabnik 10y ago

I don't understand what this means. You'd use const in Rust for this, not a macro.

CalChris 10y ago
That was just a trivial example. Yes, you could use a const which would be difficult to share across files. Moreover, if you wanted to do something equally textual #define PASS_VERBOSE if (flag_verbose && first_pass) printf you just might be able to but only with a completely different tool. A macro processor is not of the language; it is above the language.
- kibwen 10y ago
  > A macro processor is not of the language; it is above the language. Then feel free to use the C preprocessor with Rust, it works just as well. :P Just like it does with Python, and Java, and...
  - int_19h 10y ago
    Better yet, use m4.
  - kazinator 10y ago
    The C preprocessor can only be used with Python as long as you don't do anything multi-line: #define whatever(param) \ foo: \ bar \ baz I made a preprocessor some 18 years ago that could be used with Python. Wayback Machine: https://web.archive.org/web/20000815202258/http://users.footprints.net/~kaz/mpp.html https://web.archive.org/web/20000815202258/http://users.foot...
- steveklabnik 10y ago
  > which would be difficult to share across files. It's path::to::wherever::PI. That's it. Just like any other item. If you want to use only PI in your code, you'd use 'use', like any other name. Your second example is something better suited to a macro, it's true. I _think_ what you're getting at here is that you only want text substitution? I think we will have to agree to disagree if that's true :)
  - CalChris 10y ago
    Well, given that you have only written two macros in your years of Rust, I would strongly encourage you or the language ergonomics initiative to openly question why this is so. Clearly, Rust has a clever approach but I'm questioning whether it is in fact a usable approach. Too much solution for not enough problem. Yes, I do like textual substitution. Guilty. This is a common old school low level paradigm. Still, the underlying language and its compiler exist below to enforce the rules on any atrocities I commit with my macros.
    - steveklabnik 10y ago
      What I'm saying is, I personally find Rust expressive enough to never need macros, and so their ease of use, to me personally, is not an issue either way. (Well, other than the import bit, I do care about that.) Those who do use and write them heavily are the ones actually involved in the macros 2.0 effort. There are certainly flaws.
    - int_19h 10y ago
      If you want textual substitution, you are not limited by anything that Rust offers. You can incorporate any existing text preprocessor - of which there's a multitude, and at least cpp and m4 are in pretty much any Unix system - into your compile pilelines. By the very definition of textual substitution, it is completely orthogonal to the meaning of the output (in this case, Rust code). The kind of macros Rust implements, on the other hand, are the kind that have to be language-specific, because they deal with the syntax tree of that particular language. They also enable many things that are outright impossible with text substitution, such as hygienic macros.
- lobster_johnson 10y ago
  A "macro" in C is not the same thing as a "macro" in Rust. By your logic, Erlang processes aren't processes because they aren't kernel processes, or Go packages aren't packages because they don't use the Java package naming convention. Nobody owns the exclusive right to define the words we use.
- tatterdemalion 10y ago
  You want textual macros. Rust doesn't have this feature, it has a syntactic macro feature inspired by the Lisp family. Sorry.

kinghajj 10y ago

I thought that style was considered bad form in modern C/C++ (esp. the later, with `constexpr`). What's wrong with const PI: f64 = 3.14159265358979323846264338327950288; ?

cardiffspaceman 10y ago
What machine can represent all those decimal digits so precisely that the ending decimal digits ...0288 are exactly right and not ...0287 ? I'll accept without looking it up that the statement is correct syntax in some language (it doesn't look like C++ to me).
- pklausler 10y ago
  See above. The constant is (a) not pi, and (b) not an exact decimal representation of any binary floating-point number.

pklausler 10y ago

3.141592653589793115997963468544185161590576171875 is the exact decimal representation for the 64-bit IEEE-754 number that's closest to pi (viz. 0x400921FB54442D18). Any time you see a decimal floating-point constant with a nonzero fractional part that doesn't end in '5', you're looking at a bug. EDIT: As long as this grizzled old Fortran programmer is giving out free advice, I'll add two more items every programmer should know about binary floating-point: a) Every binary floating-point number can be represented exactly in decimal notation if you use enough digits. b) Those decimal values are the only ones that can be exactly converted to binary; all of the rest require rounding.

f2f 10y ago
Any time you see a decimal floating-point constant with a nonzero fractional part that doesn't end in '5', you're looking at a bug. depends on the language. for example here it is in go: Pi = 3.14159265358979323846264338327950288419716939937510582097494459 // http://oeis.org/A000796
- deathanatos 10y ago
  What the person above you is saying, I think, is to remember that computers usually work in base 2. This applies to IEEE floating points, where the mantissa is in base 2; when you represent fractions in base two, they're powers of two: 1/2 (.5), 1/4 (.25), 1/8 (.125), etc. What he's asserting, I think, is that any power-of-two fraction, or any combination of those (in binary), result in a number ending in 5 when represented in decimal. Anything else is going to be rounded to the nearest representable number (that ends in 5). So, go might have that value in its source, but it's getting rounded to something that would, if represented in decimal, end in 5.
  - f2f 10y ago
    In Go, floating-point constants may have very high precision, so that arithmetic involving them is more accurate. The constants defined in the math package are given with many more digits than are available in a float64. Having so many digits available means that calculations like Pi/2 or other more intricate evaluations can carry more precision until the result is assigned, making calculations involving constants easier to write without losing precision. It also means that there is no occasion in which the floating-point corner cases like infinities, soft underflows, and NaNs arise in constant expressions.