objective c - taller - ¿Por qué escribir 1,000,000,000 como 1000*1000*1000 en C?
taller notacion cientifica pdf (8)
En el código creado por Apple, existe esta línea:
CMTimeMakeWithSeconds( newDurationSeconds, 1000*1000*1000 )
¿Hay alguna razón para expresar
1,000,000,000
como
1000*1000*1000
?
¿Por qué no
1000^3
para el caso?
¿Por qué no
1000^3?
El resultado de
1000^3
es 1003.
^
es el operador bit-XOR.
Incluso si no trata con la Q en sí, agrego una aclaración.
x^y
no
siempre evalúa a
x+y
como lo hace en el ejemplo del interrogador.
Tienes que xor cada bit.
En el caso del ejemplo:
1111101000₂ (1000₁₀)
0000000011₂ (3₁₀)
1111101011₂ (1003₁₀)
Pero
1111101001₂ (1001₁₀)
0000000011₂ (3₁₀)
1111101010₂ (1002₁₀)
Hay razones para
no
usar
1000 * 1000 * 1000
.
Con 16 bits
int
,
1000 * 1000
desbordamientos.
Por lo tanto, el uso de
1000 * 1000 * 1000
reduce la portabilidad.
Con 32 bits
int
, los siguientes desbordamientos.
long long Duration = 1000 * 1000 * 1000 * 1000; // overflow
long long Duration = 1000000000000; // no overflow, hard to read
Sugiera que el valor de plomo coincida con el tipo de destino para facilitar la lectura, la portabilidad y la corrección.
double Duration = 1000.0 * 1000 * 1000;
long long Duration = 1000LL * 1000 * 1000 * 1000;
También podría usar la notación
e
para valores que son exactamente representables como un
double
.
Por supuesto, esto lleva a saber si
double
puede representar exactamente el valor del número entero, algo que preocupa con valores superiores a 1e9.
(Ver
DBL_EPSILON
y
DBL_DIG
).
long Duration = 1000000000;
// vs.
long Duration = 1e9;
Otra forma de lograr un efecto similar en C para los números decimales es usar la notación de coma flotante literal, siempre que un doble pueda representar el número que desee sin pérdida de precisión.
IEEE 754 doble de 64 bits puede representar cualquier número entero no negativo <= 2 ^ 53 sin problema. Por lo general, el doble largo (80 o 128 bits) puede ir aún más lejos que eso. Las conversiones se realizarán en tiempo de compilación, por lo que no hay sobrecarga de tiempo de ejecución y es probable que reciba advertencias si hay una pérdida inesperada de precisión y tiene un buen compilador.
long lots_of_secs = 1e9;
Para ilustrar las razones, considere el siguiente programa de prueba:
$ cat comma-expr.c && gcc -o comma-expr comma-expr.c && ./comma-expr
#include <stdio.h>
#define BILLION1 (1,000,000,000)
#define BILLION2 (1000^3)
int main()
{
printf("%d, %d/n", BILLION1, BILLION2);
}
0, 1003
$
Podría ser más simple de leer y obtener algunas asociaciones con el formulario
1,000,000,000
.
Desde el aspecto técnico, supongo que no hay diferencia entre el número directo o la multiplicación. El compilador lo generará como un número constante de mil millones de todos modos.
Si habla del objetivo-c, entonces
1000^3
no funcionará porque no existe tal sintaxis para pow (es xor).
En cambio, se puede usar la función
pow()
.
Pero en ese caso, no será óptimo, será una llamada de función de tiempo de ejecución, no una constante generada por el compilador.
Por legibilidad.
A modo de comparación, Java admite
_
en números para mejorar la legibilidad (propuesta por primera vez por Stephen Colebourne como
respuesta a la PROPUESTA de Derek Foster: Literales binarios
para Project Coin / JSR 334).
Uno escribiría
1_000_000_000
aquí.
En un orden aproximadamente cronológico, desde el soporte más antiguo hasta el más nuevo:
-
XPL:
"(1)1111 1111"( aparentemente no para valores decimales, solo para cadenas de bits que representan valores binarios, cuartos, octales o hexadecimales ) -
PL / M:
1$000$000 -
Ada:
1_000_000_000 - Perl: igualmente
- Ruby: igualmente
- Fantom (anteriormente Fan): del mismo modo
- Java 7: igualmente
- Swift: (¿lo mismo?)
- Python 3.6
-
C ++ 14:
1''000''000''000
Es una característica relativamente nueva para los idiomas darse cuenta de que deberían ser compatibles (y luego está Perl).
Como en la excelente respuesta de chux @,
1000*1000...
es una solución parcial, pero abre el programador a errores que desbordan la multiplicación, incluso si el resultado final es de tipo grande.
Por legibilidad.
Colocar comas y espacios entre los ceros (
1 000 000 000
o
1,000,000,000
) produciría un error de sintaxis, y tener
1000000000
en el código hace que sea difícil ver exactamente cuántos ceros hay.
1000*1000*1000
hace evidente que son 10 ^ 9, porque nuestros ojos pueden procesar los trozos más fácilmente.
Además, no hay costo de tiempo de ejecución, porque el compilador lo reemplazará con la constante
1000000000
.
Una razón para declarar constantes de forma multiplicativa es mejorar la legibilidad, mientras que el rendimiento en tiempo de ejecución no se ve afectado. Además, para indicar que el escritor estaba pensando de manera multiplicativa sobre el número.
Considera esto:
double memoryBytes = 1024 * 1024 * 1024;
Es claramente mejor que:
double memoryBytes = 1073741824;
como este último no parece, a primera vista, la tercera potencia de 1024.
Como mencionó Amin Negm-Awad, el operador
^
es el
XOR
binario.
Muchos idiomas carecen del operador incorporado de exponenciación en tiempo de compilación, de ahí la multiplicación.