Autor Tema: Proyecto de Curso (Comentarios): Programación en C (2013, por Argentinator)

0 Usuarios y 1 Visitante están viendo este tema.

08 Enero, 2013, 04:53 am
Respuesta #80

pierrot

  • pabloN
  • Moderador Global
  • Mensajes: 3,395
  • País: uy
  • Karma: +0/-0
  • Sexo: Masculino
Todo el manejo de los tipos de datos enteros es muy engorroso, complicado, lleno de excepciones, consideraciones, vueltas y contratuercas.

Humm ya veo. Mañana leeré más despacio los dos posts que has escrito (me refiero a los de las notas teóricas).

Me costó porque no quería dejar la tarea incompleta.

Lo que estás haciendo es admirable. Es como la madre que pela el fruto a su hijo y lo corta en trozos pequeños para facilitarle el trabajo. Aquí no hay que hacer nada; presentas el material de forma clara, sin ambigüedades. Está todo subrayadito e incluso resaltas en negrita y con colores las cosas importantes. Sólo resta sentarse a leer el resumen que has hecho e intentar digerirlo. 

También les estoy dejando una muy buena bibliografía.

La verdad es que con el excelente trabajo que estás haciendo, no pienso lidiar con esos libros. ¿Para qué molestarme en leerlos para luego llegar a las mismas conclusiones que tú has llegado? Yo confío en que no me estás mintiendo...  :laugh:
$_="loe  hnachaPkr erttes,urJ";$j=0;for($i=0;s/(.)(.{$j})$//;$i++){$_=$2.$_,$j+=1-$i%2,print$1}print

08 Enero, 2013, 11:28 am
Respuesta #81

argentinator

  • Consultar la FIRMAPEDIA
  • Administrador
  • Mensajes: 7,274
  • País: ar
  • Karma: +0/-0
  • Sexo: Masculino
  • Vean mis posts activos en mi página personal
    • Mis posts activos (click aquí)
Citar
Yo confío en que no me estás mintiendo...

Mmmm...

Bueno, casi en todo lo que escribí me siento seguro.

Pero hay algún detalle que se me escapa.

Dije por ahí que entre las reglas del estándar está que tanto la versión signed como unsigned de un tipo de datos dado tienen la misma longitud en bits.
Pero luego enuncia las demás reglas como si esto no fuera necesariamente cierto.
O sea que ya no sé si es cierta esa regla  :-[ (que encima es la primera que anoté de la representación en bits).
Y ya no me acuerdo de dónde lo saqué.  :-\

Pero la confusión viene de que la versión original tiene en cuenta detalles que yo he omitido a propósito, y ahí quizás me haya quedado algún cabo suelto.
Me refiero a que hay cosas como los "padding bits", que son puro humo, porque son una característica que no es obligatoria en el lenguaje, y yo me estoy ajustando siempre a lo que el estándar pone como estrictamente obligatorio.

Lo opcional lo dejo correr, por la sencilla razón de que no es portable entre compiladores o sistemas distintos.

Pero bueno. Creo que esos posts son un 99% creíbles.

08 Enero, 2013, 12:39 pm
Respuesta #82

argentinator

  • Consultar la FIRMAPEDIA
  • Administrador
  • Mensajes: 7,274
  • País: ar
  • Karma: +0/-0
  • Sexo: Masculino
  • Vean mis posts activos en mi página personal
    • Mis posts activos (click aquí)
Bueno PabloN, parece que sí te he mentido.

Como tenía esa duda con los tamaños de signed y unsigned, lo volví a revisar con más cuidado.

Al parecer yo estaba equivocado al decir que ocupan la misma cantidad de bits.

En realidad, esto ocurre en casi todos los sistemas.
Pero hay sistemas en que no pasa.
Y además el estándar no obliga.

Así que en un par de párrafos donde yo insistía en que los tamaños de signed y unsigned de un mismo tipo tenían el mismo tamaño en bits, los he "maquillado" poniendo que en realidad eso es costumbre, pero no regla del estándar.

Y por último puse al final del spoiler que analiza los bits, este texto que explica la situación:

Citar

Nos queda pendiente analizar un detalle técnico importante:

¿Son iguales el número de bits de las versiones signed y unsigned de un tipo entero dado?

En general, se acostumbra   ;) ;) que la versión signed de un tipo entero tenga la misma longitud que su compañera unsigned, y así la precisión será exactamente 1 menos que de la compañera unsigned.

Pero el estándar no obliga a esto, y puede ocurrir que los tipos signed podrían ser más pequeños.
Lo que el estándar sí obliga es que el rango de valores positivos y los bits que representan valores de la versión signed encajen a nivel de bits la versión unsigned, de manera que representen el mismo valor matemático.

Así, podría ocurrir que un signed int tenga 1 bit más que su compañero unsigned int, si ambos comparten los mismos valores positivos, ya que el signed int además debe contener el bit de signo.
(Incluso hay ejemplo de un sistema de la vida real que trabaja así).

Pero en todo otro caso, el número de bits de un signed será menor o igual  :) que la de su compañero unsigned.
Inclusive podría ocurrir que la versión unsigned tenga varios bits más.
 
Precaución: A nivel de bits, se puede dar el caso que los bits de valor sean de cierta forma, pero que su representación como objeto en memoria sea algo diferente, por más que en ambos casos se hable de bits bien ordenaditos y todo.
Nosotros estamos suponiendo que ambas cosas son lo mismo, para no marearnos.
Pero en algún momento tendríamos que estudiar la diferencia entre estos dos aspectos.





¡Ahora sí creo que hay no hay más mentiras!  >:D


08 Enero, 2013, 12:39 pm
Respuesta #83

feriva

  • $$\Large \color{red}\pi\,\pi\,\pi\,\pi\,\pi\,\pi\,\pi$$
  • Mensajes: 9,171
  • País: es
  • Karma: +1/-0
  • Sexo: Masculino
También les estoy dejando una muy buena bibliografía.

La mayoría de los textos son gratuitos por internet:

Bibliografía para C

 :-* :-*


Ya ha leído despacio las notas, pero tengo que seguir mirando algunas cosas.

 Sobre lo que pasa "por dentro" para hacer todas esas operaciones, yo, la idea me la hago a partir del primer libro que leí sobre estas cuestiones; lo enlazo aquí (es auténtica arqueología de la informática, creo que puede interesar a los estudiantes de ingeniería informática de hoy como curiosidad). Ya lo enlacé una vez en un post sobre un debate relativo a las máquinas de Turing, pero lo vuelvo a enlazar (se trata de un PDF que no llega al mega y se descarga enseguida)

http://trastero.speccy.org/cosas/Libros/El_libro.htm

 El interés está en que es muy de primera mano, en cuanto a que esto es lo que empezaba a llegar al gran público sobre el lenguaje máquina y, en general, sobre cómo almacena la información un ordenador. Antes de este tipo de libros existían, lógicamente, lo que fueron los primeros libros de una muy incipiente carrera de informática que, hacía sólo unos pocos años, no existía en la mayoría de las universidades de España y otros países. Los ordenadores que existían antes de esos años funcionaban con válvulas de vacío, no con microchips, que no existían aún (por aquella época creo que se hacía el servicio militar con lanza :D ).

 Lógicamente, habla de ordenadores que metían la información de 8 en 8 bits, no más ( un byte para la dirección de memoria y un byte asociado de órdenes; órdenes que dependían según el estado de los bits de éste). Aquí no había long ni short ni mucho menos long long (todo eso es muy nuevo para mí, por eso tengo que mirarlo e ir despacio)  por lo que imagino que, cuando un número sobrepasaba el 256d en bits, habría que formarlo a partir de la dirección de memoria inmediatamente siguiente, adosando otro byte de datos en esa dirección (aunque no lo sé a ciencia cierta, no recuerdo ahora si el libro detalla esto de los números grandes).

 Recuerdo que, cuando lo leí, aunque lo entendía, no terminaba de formarme bien del todo la idea de cómo iba aquello, pues por una parte si ciertos bits, según su posición y normalmente tomados de 2 en 2 consecutivamente, estaban cargados con un 1, quería poder decir, por ejemplo, que estaban activadas las mayúsculas del telcado, etc., pero, luego, otros bytes almacenaban datos en la pila de máquina que a la vez se obtenían de otros bytes que estaban cargados en sólo uno o dos registros acumuladores... No era en sí difícil de entender, era difícil de visualizar; por lo menos para mí, que no tenía ni tengo idea de electrónica ni de cómo se organiza el microprocesador para hablar con la RAN, la ROM, periféricos y demás.

 Sí quedaba claro, básicamente, cómo se almacenaban los datos; en un byte había ocho celdillas y las combinaciones que se podían formar con éstas; si en una celdilla había con una carga eléctrica positiva, ese bit era un 1, si estaba descargada era un cero. Y creo que hoy en día, supongo, no puede ser muy distinto, lo que existirá será la posibilidad de utilizar muchísimas más combinaciones y con ello almacenar números más grandes y mayor número de datos; y eso es lo que dará lugar a tanta complejidad, pero en esencia no creo que sea más que un sistema numérico distinto al que estamos acostumbrados a usar, más bien una forma distinta de entender los números; tengo claro que el ordenador no ve, no reconoce dibujitos, símbolos, todo la información la tiene que guardar o transmitir simplemente sintiendo "frío" o "calor" en  las mil y una partes de su cuerpo; cosa que quizá también hacemos nosotros inconscientemente con muchas informaciones; pero si tuviéramos que hacerlo conscientemente nos resultaría más difícil que entender el funcionamiento de un ordenador, seguramente; o al menos igual de difícil.

 Porque si "sacanf" es "preguntar" o "printf" es "imprimir en pantalla", o que un número tenga un cero delante, respecto de ciertos bytes signifique que está en base ocho, está claro también que eso es una "cortesía" del lenguaje hacia nosotros; el ordenador tiene que guardar la información útil con su "sí" y su "no" en binario y, además, también con sus mismos "sí" y "no", tiene que guardar el traductor de esas palabras humanas para poderse comunicar con nosotros; con lo que hace un gasto de más y bastante grande; y ahí, es de imaginar, entra la labor del compilador para, una vez usado ese "diccionario" que utiliza para hablar con nosotros, tirarlo a la basura y dejar más sitio.

 Luego daré otro repaso a tus notas y en especial al tema de abrir archivos que es lo que está lo último y he mirado menos. El Basic, me parece recordar, reservaba casi en exclusiva el símbolo # para el tema de abrir y cerrar archivos, pero el programa que has puesto funciona con un bucle y no sé si es equivalente; se parece más a lo que era utilizar una "array" de datas que se van leyendo mediante un "for-next"; allí los "datas" se acababan y necesitaba una orden llamada "restore" para volverlos a poder leer. Internamente esto sucedía así, según leí, porque los bits de cada byte almacenados en el stack de la maquina se sacan como de una caja; se toma el que está apilado más arriba, después el siguiente... y se invierte el orden al ser usados, con lo que hay que volver a ordenarlos si se quieren usar para que den el mismo resultado dentro de un programa; por eso, además de una orden gousub-return o lo que fuera del bucle, necesitaba el "restore".

 Saludos.

    

 

08 Enero, 2013, 12:58 pm
Respuesta #84

argentinator

  • Consultar la FIRMAPEDIA
  • Administrador
  • Mensajes: 7,274
  • País: ar
  • Karma: +0/-0
  • Sexo: Masculino
  • Vean mis posts activos en mi página personal
    • Mis posts activos (click aquí)
Feriva:

Citar
Sí quedaba claro, básicamente, cómo se almacenaban los datos; en un byte había ocho celdillas y las combinaciones que se podían formar con éstas; si en una celdilla había con una carga eléctrica positiva, ese bit era un 1, si estaba descargada era un cero.

A ver si no te mareo tanto.

Hay algo que debería quedar claro: Si algo no lo estoy explicando... es porque no importa, jeje.
Siempre en la vida trato de mantener un estilo "autocontenido".

Por ejemplo, no he explicado mucho cómo funciona el printf.
Eso es porque lo uso de forma casera para mostrar información sencilla y rápida, sin analizar mucho cómo funciona.

En el momento oportuno lo voy a explicar con detalle.
Lo mismo pasa con cosas como el getchar, el system("PAUSE") y demás truquillos.
Son temas que deben explicarse en otro contexto, y que nosotros sólo usamos para "hacer trampa", y que queremos que nuestros incipientes programitas hagan "por lo menos algo"  :-[



En cuanto a la representación interna de los datos, quisiera que quede claro qué estamos haciendo:

  • En efecto, existe una manera en que la máquina representa los datos internamente, en forma pura y dura. Son los bits y bytes de máquinas reales, en carne viva.
  • Los lenguajes de alto nivel "se abstraen" de esto, y no le dan importancia alguna a cómo el compilador va a interactuar con los datos a nivel de máquina.
  • Pero el estándar C es una excepción a esta regla, y se pone a hablar de bits y de reglas de representación internas.

  • Las reglas del estándar C no son una descripción de lo que ocurre a nivel de bits internos en la máquina.

    Sino todo lo contrario, el estándar C son reglas escritas por un comité en un libro archivado por ahí, que nunca tuvo algo que ver con una máquina real.

    Y dicho estándar lo que hace es obligar a los futuros compiladores de C que representen los números siguiendo determinadas reglas con los bits.

    Esas reglas son "muy parecidas" a las que emplea una máquina real internamente.
    Pero no son lo mismo.

En otras palabras:

No te estoy enseñando cómo se representa un entero mediante bits internamente.
Y de hecho, esto a mí ni siquiera me importa.  ;D

Pero lo hago porque el comité ISO de estandarización de C de 1999 me obliga a tener en cuenta esos dichosos bits, a fin de poder terminar de entender qué son los tipos de datos enteros en el lenguaje C.

O sea, no perdamos el foco del tema, que está en el título de esos posts: Enteros en C.

Lo que estamos haciendo es tratar de entender qué son y cómo funcionan los tipos enteros,
qué rangos de valores tienen, hasta qué grado de precisión se parecen, cómo se intercambian o combinan, etc.

El hecho de que hayamos tenido que irnos hasta los bits, es porque el estándar se ocupa de eso.

____________

Por ejemplo, un libro que tenga las reglas de estándar de, digamos el lenguaje Delphi, estoy seguro que en ningún momento se va a ocupar de cómo se representan los datos a nivel de bits.
Y entonces, si estudiáramos los tipos de datos enteros en Delphi, no tendríamos que hacer jamás todo este análisis de los bits, ni sufrir con eso.

¿Se entiende más o menos?




Feriva again: ¿Estás pudiendo leer con comodidad las notas? Mario una vez me advirtió de que el exceso de colores puede dificultad la lectura a determinados tipos de ojos . :-\

Se puede hacer un programita que saque todos los colores y deje el resto del texto intacto...
Queda pendiente para más adelante.

08 Enero, 2013, 01:12 pm
Respuesta #85

feriva

  • $$\Large \color{red}\pi\,\pi\,\pi\,\pi\,\pi\,\pi\,\pi$$
  • Mensajes: 9,171
  • País: es
  • Karma: +1/-0
  • Sexo: Masculino
Feriva again: ¿Estás pudiendo leer con comodidad las notas? Mario una vez me advirtió de que el exceso de colores puede dificultad la lectura a determinados tipos de ojos . :-\

Se puede hacer un programita que saque todos los colores y deje el resto del texto intacto...
Queda pendiente para más adelante.

No te preocupes, tengo una pantalla que me dio un amigo y un sintetizador de voz para cuando me canso; y se ven bien los colores.

 En cuanto a lo otro, te entiendo, el lenguaje C imita en ciertas cosas el lenguaje de la máquina para hablar, pero no es el lenguaje de la máquina, es un lenguaje de usuario, creo que es eso lo que me quieres decir.

 Saludos y muchas gracias.

Tengo que operarme de cataratas algún años de éstos, pero cuanto más tarde, mejor, me da un poco de miedo de los médicos, no son matemáticos :D

08 Enero, 2013, 06:52 pm
Respuesta #86

argentinator

  • Consultar la FIRMAPEDIA
  • Administrador
  • Mensajes: 7,274
  • País: ar
  • Karma: +0/-0
  • Sexo: Masculino
  • Vean mis posts activos en mi página personal
    • Mis posts activos (click aquí)
Buenas.

Otro cambio:

En el primer post, en donde se explica cómo instalar el IDE DevC++,
había una opción de configuración seleccionada.
La he quitado, y ahora dice que lo mejor es "no tocar las opciones de configuración".

En el próximo post se explicará cómo tocar opciones del Compilador, acorde a nuestras necesidades.

08 Enero, 2013, 06:55 pm
Respuesta #87

feriva

  • $$\Large \color{red}\pi\,\pi\,\pi\,\pi\,\pi\,\pi\,\pi$$
  • Mensajes: 9,171
  • País: es
  • Karma: +1/-0
  • Sexo: Masculino
Buenas.

Otro cambio:

En el primer post, en donde se explica cómo instalar el IDE DevC++,
había una opción de configuración seleccionada.
La he quitado, y ahora dice que lo mejor es "no tocar las opciones de configuración".

En el próximo post se explicará cómo tocar opciones del Compilador, acorde a nuestras necesidades.


Yo el otro día lo reinstalé por aquello que te dije de las ventanas que se abrían; al final me cargó no sé que extra que tenía que ver con la caché y que decía que se podía cargar después, pero no me di cuenta y lo cargué antes; el caso es que funciona bien y ya no se abren las ventanas.

 Gracias, saludos.

08 Enero, 2013, 06:58 pm
Respuesta #88

argentinator

  • Consultar la FIRMAPEDIA
  • Administrador
  • Mensajes: 7,274
  • País: ar
  • Karma: +0/-0
  • Sexo: Masculino
  • Vean mis posts activos en mi página personal
    • Mis posts activos (click aquí)

08 Enero, 2013, 07:51 pm
Respuesta #89

feriva

  • $$\Large \color{red}\pi\,\pi\,\pi\,\pi\,\pi\,\pi\,\pi$$
  • Mensajes: 9,171
  • País: es
  • Karma: +1/-0
  • Sexo: Masculino
No hace falta reinstalar todo.
Ya voy a postear sobre el tema.


Ya lo he configurado, a ver si pruebo ahora el programa ése que no me funcionaba con el void, que a lo mejor era por eso...

Ahora sí va con el void :)