Bien, pero Ucrania no tiene misiles d elargo alcance, y aúnque los tuviera, todavía podrían ser destruídos por las defensas antiaéreas, peor el mayor problemas, por ejemplo en las fábricas de armamento, es que suelen estar ubicadas en Siberia máso menos ocultas...

En resumen, Ucrania no tiene esa capacidad ofensiva, si no, desde un principio ya hubieran devuelto el fuego sobre Moscú y la guerra hubiera sido otra.
Tienen que luchar con lo que tienen, no con ideales...

Chorradas...

"Tu me puedes hacer lo que te dé la gana y yo solo puedo soplar cuando me pegues..."
Si das, prepárate a recibir, es la premisa elemental de la guerra.

El artículo menciona el término "interestelar", que es el adecuado y suficiente para diferenciar un meteroito que procede de otra parte del espacio... pero que al final ha sido captado por la gravedad del Sol.

Si como ha puesto el-Brujo, estos son sus datos de memoria, 2 slots y máximo 8Gb. en efecto, 2 memorias de 4Gb, es lo que necesitas, y lo reconocerá cuando instales el S.O. de 64 bits...

No se hacen tareas.
Muestra tus avances y señalas tus dudas o errores y desde ahí se te podrá orientar.

Tu problema está en el bucle while dentro de la condición de coincidencia...

Pasando 144, se localiza en el penúltimo índice, le pides que localiza los que sean iguales para tratar de devolver el último de ellos con el mismo valor, hay uno más... pero en tu bucle sigues aumentando el índice sin comprobar si se alcanzó el final del array.

Una mejor manera es hacer justo lo contrario (en cierto modo), devolver el índice donde debiera ubicarse si no existe, o el primer lugar donde exista. Dado que el índice 0, siempre existe, si resulta ser menor que todo el array o igual al primer elemento, devuelve 0, con lo cual siempre estará bien ubicado, y no incurres en error.

Mejor aún es simplemente devolver ese índice, sin tratar de buscar los que le preceden o siguen de igual valor... ya si por ejemplo se tratara de insertar un elemento, que más da, que se inserte el primero, el 5 de 10 o el 10 (si antes eran 9). tu al final tras la inserción tendrías (por ejemplo):
...x, x, x, x 144, 144, 144, 144, 144, 144, 144, 144, 144, 144, y, y, y, y...
Cuál de esos 144 es el que tu has añadido?. No suele importar si no tiene más datos asociados.


Si a pesar de todo deseas mantener tu código, lo comento en detalle...
Observa el problema paso a paso... el array tiene 15 elementos que van del indice 0 al 14.
Hay dos casos, que accedas primero al indice 13 o primero al indice 14...

A - En el indice 13 localiza, el valor 144: luego entra en el bucle, ya que el índice 13 es menor que el size-1 del array. Ahora evalúa si el valor es menor que el recién enconttrado (en el índice 13), no es verdad luego incrementa centro y regresa a la condición del bucle... ahora se alcanzó el límite del bucle, lo que impide seguir ejecutándolo, sale del bucle y luego del externo y por tanto devuelve -1

B - En el indice 14 localiza el valor 144: El bucle while impide entrar al mismo, pues es el último en el array, sale del bucle interno y luego del externo y devuelve -1

Tú codigo funcionaría, si tras dichos valores hubiera un elemento más (mayor lógicamente que los previos). Pero entonces tendría el mismo problema con ése... es decir siempre con el último (o últimos, si son iguales).

Tu código debe quedar así:

while(bajo <= alto){
    centro = (bajo + alto) / 2;
    if(clave == array[centro]){
        centro++;
	while(centro <= (size - 1)){
	    if(clave < array[centro])
	        return centro;
	    centro++;
	}  
        return centro;
    }else if(clave < array[centro])
	alto = centro - 1;
    else
	bajo = centro + 1;    
}
return -1;
 

Nota las dos líneas (4 y 10) que he añadido y la 5 modificado.

Este tipo de error "the memory could not be written", me lo daba el programa "Paint Shop Pro", cuando tenía abiertas 2 o más instancias del editor de Visual Studio y estaba abirnedo el programa, con o sin una imagen.

Asumo que el programa consideraba que se trataba o existía una posibilidad de ¿hackear? el programa y ante ello, cambiaba el comportamiento esperado sacando errores (a propósito) para forzar a cerrarlo (cuando no se cerraba sólo). Una sobreprotección bastante inútil y molesta.

La solución era cerrar las instancias de Visual Studio... a veces colapsaba algunas funciones de la Shell de win2, lo que forzaba a tener que reiniciar, para evitar cuelgues inesperados y perder datos estúpidamente.

Te animo a que reinicies el equipo y sin abrir ningún otro programa, lo intentes de nuevo. Si puedes hacerlo funcionar así, es probable que tenga algún tipo de 'protección' similar...

Es adecuado incluir paréntesis, ofrece m´s precisión para mantener la prioridad de operadores, aunque tengan la misma prioridad, solventa especialmente cuando están anidados (solo el último caso lo requiere extricamente si no usamos el operador O-exclusivo)... además añade claridad (salvo que haya muchos paréntesis anidados, que fuerza a contarlos).

a: A es positivo y B es negativo.
a: (A > 0) Y (B < 0)

Este admite múltiples soluciones a la hora de poner variables... te pongo solo 2.
b: A, B y C son diferentes.
b: (A <> B) Y (A <> C) Y (B <> C)  
b: (A <> B) Y (B <> C) Y (C <> A)

c: E es no nulo y F no es mayor que G.
c: (E <> 0) Y (F <= G)

d: B está estrictamente entre A y C.
d: (B > A) Y (B < C)
d: (A < B) Y (C > B)
Al decir 'estrictamente', se debe entender que no admite la siguiente:
d: (B => A) Y (B <= C)
Nota que al dar dos variables (A,C), deben entenderse como el menor y mayor del rango respectivamente.

e: F es negativo o E es no negativo pero no ambos a la vez
e: ((F < 0) Y (E => 0)) O ((F => 0) Y (E < 0))
e:  (F < 0) XOR (E => 0)       # XOR es un operador O-exclusivo: Solo-A o Solo-B

Sobre los operadores, considera que una cosa son los operadores matemáticos... a la hora de programar hay que poner el operador que admite el lenguaje.
Tirando de pseudocódigo es preferible también poner operadores matemáticos (siempre será entendible por todos).

Pareciera que crees que los juegos son el fundamento de la teconología digital.
La impulsan por un beneficio económico, pero no te engañes, se creó para satisfacer las necesidades científicas, y ese camino nunca estará satisfecho, siempre tendrá 'hambre' de más.

Quien sabe si dentro de 100 años, el tamaño de palabra lo que hasta ahora han sido 8bits, 16, 32, 64.., acabe siendo 1Gb. x8 bits. Y aún entonces, se considerará suficiente?. Pues no, salvo que la tecnología encuentre límites insuperables, no parará.

Al margern del tamaño de palabra, todavía es de interés la velocidad de procesamiento (que es distinto d ela velocidad de cálculo, pués esta incluye en su consideración el paralaje), tanto como la memroia de almacenamiento.

Es como el perro que se muerde la cola: Aumenta el tamaño de palabra, exige más memoria, que a su vez exige más velocidad, se completa así un ciclo, donde tarda básicamente lo mismo pero han aumentado las capacidades, calidad y prtrecisión de detalles... Al final del ciclo está igual que antes, porque aunque ha aumentado todo, ahora la cantidad de cálculos que puede hacerse es mayor, lo que implica que tarde en calcular lo mismo que antes, pero ahora con más de todo... y vuelve así a empezar un nuevo ciclo. Aunque en algún momento, se mejore sensiblemente la velocidad de cálculo, siempre se prodrán añadir más detalles que harán más pesado todo y vuelva a ser 'lento' (cuestión de tiempo). Lo qwue exigirá de nuevo otro ciclo.

Lo que si es cansino, es que los saltos sean de miniatura y cada poco tiempo, lo que fuerza a gastarse constantemente dinero en nuevos equipos, ligeramente más capaces que los anteriores. Sería preferible (de cara al usuario) saltos cuantitativos, más espaciados en el tiempo, cada 12-25 años dar ese salto de un sola vez.

Al margen el fotorrealismo de las escenas, no implican necesariamente más entretenimiento... un juego tan simple como el Tetris, garantiza horas y horas de entretenimiento, y no exige grandes requisitos de realismo, bastan fichas de pocos colores planos. Muchas veces es preferible la maniobrabilidad del juego que el realismo, por ejemplo jugando con un simulador de vuelo, la precisión de los mandos respecto del movimiento real del aparato, es preferible a la calidad de las escenas.

Es decir la jugabilidad prima en primer lugar junto al entretenimiento (que sea divertido, entretenido, que quedes satisfecho), el realismo, no es un requisito imprescindible... Que se muevan en ese terreno los juegos actuales, implica solo una lucha en un terreno para intentar aparentar ser mejor los de la competencia, pero solo porque carecen de ideas brillantes que bien aplicadas no admiten una comparación con la competencia, destacan sin importar el realismo.

El hasrdware seguirá evolucionado, cuando se encuentre un límite, también irá mejorando, pero en otra dirección. Nos acercamos al límite físico de miniaturización de las puertas lógicas... eso implica que no pudiendo avanzar por ahí, habrá que avanzar por otras direcciones, velocidad de ejecucióin, paralaje, etc...

...durante la visita, el presidente británico, también le dijo que les entregaría misiles antibuque, que falta les hacen. Conviene que no sea tardando mucho.