Charla en Wikipedia: Manual de estilo / Fechas y números
De Wikipedia, la enciclopedia libre
Saltar a navegación Saltar a búsqueda
Manual de estilo de WikiProject  
Icono de WikiProjectEsta página cae dentro del alcance del Manual de estilo de WikiProject , un impulso para identificar y abordar contradicciones y redundancias, mejorar el lenguaje y coordinar las páginas que forman las pautas de MoS .
 
Icono de nota
El Comité de Arbitraje ha autorizado el uso de sanciones discrecionales para las páginas relacionadas con la política de títulos de artículos de Wikipedia en inglés y el Manual de estilo , incluida esta página. Consulte los criterios de reconocimiento y edítelos detenidamente.
Icono de nota
Ver WP: PROPUESTA para la política de procedimiento de Wikipedia sobre la creación de nuevas pautas y políticas. Vea cómo contribuir a la guía de Wikipedia para obtener recomendaciones sobre la creación y actualización de páginas de políticas y guías .

Atajos
Imagen externa
icono de imagen Kliban: conversión de pies a metros
Anagrama no oficial del Manual de estilo (Primer finalista: Un flato alimonado ).

espaciado en el ejemplo de floruit

¿Hay alguna razón por la que el ejemplo utilizado para ilustrar el uso de floruit (fl.) no tiene un guión espaciado?

Jacobus Flori ( fl. 1571-1588)

el último punto en la sección mos: approxdate señala que se deben usar guiones espaciados cuando "fl". aparece en un rango, "ya sea en uno o ambos lados", y parece que no puedo encontrar una excepción aplicable para este ejemplo. si el punto hubiera dicho explícitamente "ya sea en la derecha o en ambos lados", habría entendido la falta de un guión espaciado, pero ese no es el caso actualmente. muriendo ( hablar ) 06:53, 16 de abril de 2021 (UTC)

Me parece que es un caso de práctica (inadvertidamente) que no está de acuerdo con la teoría, y nadie lo ha detectado antes. Dhtwiki ( charla ) 23:15, 16 de abril de 2021 (UTC)
Gracias por la respuesta. He agregado espacios al ejemplo. siéntase libre de revertir mi edición si se descubre una razón de la falta de espacios anterior. muriendo ( hablar ) 07:52, 17 de abril de 2021 (UTC)
No, esto está mal. Estoy seguro de que la guía hace un mal trabajo al explicar esto, y creo que incluso algunos de los ejemplos relacionados pueden no ser correctos, pero en este caso definitivamente no hay espacios alrededor del ndash, básicamente porque se 1571–1588unen primero entre sí, y el fl.se aplica a ellos como una unidad: fl. 1571-1588 .
Por el contrario, en c. 1588-1622 , el se c.aplica (presumiblemente) solo al 1588, por lo que alejamos un poco este último 1622para ponerlo en una asociación visual más cercana con el c.. E Eng 08:00, 17 de abril de 2021 (UTC)
interesante. Anteriormente había interpretado que las pautas indicaban básicamente que si el texto utilizado para describir el rango de fechas, incluidos todos los modificadores, podía escribirse sin un espacio si el guión no estaba espaciado, entonces el guión no estaba espaciado. de lo contrario, el guión está espaciado. [a] mi interpretación se basó más en el estilo que en la semántica, así que gracias por esa explicación.
¿Significa esto que fl. ¿No debería haber sido incluido previamente en la última pauta de la sección mos: approxdate? es cierto que actualmente no puedo pensar en cómo fl. podría haberse aplicado a solo un lado de un rango, especialmente desde fl. se utiliza "[c] uando se desconocen las fechas de nacimiento y defunción".
también, por lo que puedo decir, fl. se considera un modificador, tanto actualmente [b] como antes de las ediciones recientes de las directrices. [c] dado que la directriz justo antes de la sección mos: topresent recomienda actualmente que se utilice un guión espaciado cuando haya un modificador, en caso de que se haga una excepción explícitamente para fl. en esa directriz? alternativamente, debe señalarse explícitamente que fl. no se considera un modificador? muriendo ( hablar ) 13:35, 18 de abril de 2021 (UTC)
EEng , esperaba recibir más orientación sobre este tema, si tiene tiempo. tianwen-1 , actualmente un enlace en negrita en itn , menciona el rango de fechas " c.  340-278 a . C." para señalar la vida útil del poeta qu yuan . [D] en este rango, supongo que "BC" debe interpretarse como un modificador que "se aplica al rango como un todo", lo que implica que se debe utilizar un guion sin espaciado. sin embargo, esto también parece ser un caso "[d] donde las designaciones de era ... están presentes", lo que implica que se debe utilizar un guión espaciado. también, el modificador "c". está presente y se aplica solo a la primera fecha del rango, lo que implica que se debe usar un guión espaciado. tenga en cuenta que la versión sin espacio también se utiliza actualmente en el encabezado del artículo sobre qu yuan.
¿Es correcto el uso actual del guión sin espacio? Si es así, ¿hay algún problema con "c". ¿Se malinterpreta como aplicable a todo el rango debido al guión sin espacio? muriendo ( hablar ) 19:38, 16 de mayo de 2021 (UTC)
Vuelvo a plantear este problema porque la propaganda del artículo destacado programada para mañana tiene un intervalo de fechas que cae dentro de esta ambigüedad. el rango de fechas en cuestión, " c.  113 –88 AC", encuentra los mismos problemas que el rango de fechas en el artículo tianwen-1 que mencioné anteriormente. Debo señalar que esta no parece ser la única situación en la que las directrices actuales parecen contradictorias. el problema radica en el hecho de que un tipo de modificador requiere un guión sin espaciado mientras que el otro requiere un guión espaciado, y ambos tipos pueden aparecer en un rango de fechas. considere los siguientes ejemplos.
r . C. 1353-1336a.C.     o  r . C. 1353-1336 a.C.   
Florida.  12  BH – AH  10  o  Florida.  12  BH - AH  10
tradicionalmente 1585– c.  1590  o  tradicionalmente 1585 - c.  1590
en cada uno de estos ejemplos, hay al menos un modificador que "se aplica sólo a uno de los dos extremos del rango", y al menos un modificador que "se aplica al rango en su totalidad".
De repente, puedo pensar en dos soluciones razonables a este problema. en el primero, los cambios recientes en las pautas simplemente se revierten cuando solo había un tipo de modificador . esto termina significando que el guión en el ejemplo original de floruit terminará espaciado, pero considerando que este parece ser el comportamiento actual de la plantilla de floruit , asumo que esto no es necesariamente un comportamiento no deseado. [e] esta fue mi solución propuesta original, ya que parecía ser la más simple de implementar y no parecía perturbar muchas de las pautas ya establecidas.
en la segunda solución, las pautas actuales se modifican de modo que cuando "el modificador se aplica al rango como un todo", el modificador simplemente se ignora al determinar si se debe usar o no un guión espaciado. [f] esto daría como resultado que el ejemplo de floruit original no estuviera espaciado, pero también permitiría un guión espaciado en los usos de floruit como el segundo de los tres ejemplos anteriores. este también parece ser el comportamiento actual de la plantilla de reinado cuando se utiliza un rango de año-año simple. un posible problema es el hecho de que rangos como "antes de 1758-1804" y "antes de 1758-1804" tendrían técnicamente significados diferentes, mientras que no está claro si la mayoría de los lectores, o incluso la mayoría de los editores, estarían al tanto de esto. [gramo]
tenga en cuenta que en ambas soluciones, el guión con espaciado se usaría en cada uno de los tres rangos de fechas de ejemplo dados anteriormente.
por supuesto, no pretendo tener todas las soluciones, y agradezco cualquier otra sugerencia o crítica. Realmente no tengo una preferencia personal sobre qué solución usar. Solo deseaba resolver una aparente contradicción cuando planteé la cuestión por primera vez, y lamento que plantear esta cuestión parezca haber empeorado el problema. muriendo ( hablar ) 22:16, 16 de junio de 2021 (UTC)
Creo que hay una solución sencilla para esto. Considere que los dos lados están conectados por un guión corto. Si alguno de los lados tiene un espacio dentro de él (por ejemplo, una fecha regular como "16 de junio de 2021", o algo que incluya "c." O "fl." O cualquier otro modificador), entonces deberíamos usar un guión espaciado. De lo contrario, los rangos "simples" usan un guión sin espacio. Esta es la pauta que ya se dio en MOS: DATERANGE (¿que no creo que nadie haya mencionado todavía en esta discusión?). -  RAVEN PVFF  · charla  · 23:47, 16 de junio de 2021 (UTC)
Ravenpuff , su solución también es básicamente cómo había interpretado previamente las pautas de mos: daterange antes de que se cambiaran hace unos dos meses , por lo que supongo que prefiere la primera solución, que simplemente revierte los cambios recientes. ¿Estoy interpretando tu comentario correctamente? Además, creo que mos: daterange no se ha mencionado explícitamente porque todas las demás pautas a las que se hace referencia eran parte de mos: daterange o su siguiente sección mos: approxdate , y tenía más sentido ser más específico. muriendo ( hablar ) 02:31, 17 de junio de 2021 (UTC)
@ Dying : Al contrario, creo que los cambios son razonables y coherentes con las pautas anteriores. Por ejemplo, en "[ fl. ] 1571-1588", ni "1571" ni "1588" tienen un espacio, por lo que usamos un guión sin espacio para conectar los dos. La presencia del floruit no influye en si usamos un guión espaciado o sin espaciado aquí, ya que el término / abreviatura puede (por definición) solo aplicarse a un solo año que no forma parte de un rango, o bien a un rango de años (como en este caso). " fl.  1571" no puede tomarse para representar el nacimiento de Jacobus Flori, o "1588" su muerte - floruit simplemente indica el (los) año (s) en los que se sabía que estuvo activo.
El {{ fl. }} es un poco desconcertante: prescribe un guión espaciado, pero solo porque tiene el prefijo "c". hasta el año final. Si bien no estoy seguro de que este comportamiento sea siempre deseable, ciertamente es coherente con las pautas vigentes. -  RAVEN PVFF  · charla  · 08:40, 17 de junio de 2021 (UTC)

Ravenpuff , estoy de acuerdo en que los cambios recientes son razonables, pero no creo que sean consistentes con las pautas anteriores . No estoy seguro de si este es el caso, pero creo que actualmente no estamos de acuerdo sobre si las pautas anteriores habrían pedido un guión espaciado en el ejemplo original de floruit. Creo que las pautas anteriores habrían requerido un guión espaciado, mientras que su comentario me ha llevado a creer que cree que las pautas anteriores habrían requerido un guión sin espaciado. Si es así, me gustaría entender por qué no estamos de acuerdo, pero quería determinar si ese era realmente el caso.

por cierto, también comparto su confusión sobre el comportamiento de la plantilla floruit cuando se proporcionan dos argumentos, como mencioné en la nota al pie [e] . el comportamiento parece haber sido introducido cuando se copió el código de la plantilla circa en ese momento , [h] como se menciona en el resumen de la edición de la plantilla de floruit, y no sé si retener ese comportamiento fue intencional. [i] sin embargo, estoy de acuerdo en que es consistente tanto con las pautas anteriores como con las actuales.

En cualquier caso, el hecho de que las directrices actuales sean coherentes con las directrices anteriores no fue la razón por la que propuse dos soluciones a lo que creo que es un problema de ambigüedad. ¿Está de acuerdo en que las directrices, tal como están actualmente, son ambiguas? Si es así, ¿tiene alguna sugerencia sobre cómo resolver la ambigüedad? si no es así, ¿podría explicar cómo los guiones cortos en los tres ejemplos anteriores están espaciados (o no espaciados) de acuerdo con las pautas actuales, y por qué? muriendo ( hablar ) 23:00, 18 de junio de 2021 (UTC)

@ Dying : en sus ejemplos, los tres guiones deben estar espaciados :
  1. El lado izquierdo es "c. 1353" y el lado derecho "1336". Al menos un lado tiene un espacio interno (en este caso el izquierdo), por lo que debe usarse un guión espaciado . A esto se le agrega "BC", y luego "r."; obtenemos rc 1353-1336 aC . Vale la pena señalar que el circa no se puede aplicar al rango como un todo, siendo ambos extremos aproximados, como se estipula en la segunda viñeta de MOS: APPROXDATE (si esto estuviera permitido, el guión no estaría espaciado).
  2. El lado izquierdo es "12 BH" y el lado derecho "AH 10". Al menos un lado tiene un espacio interno (en este caso ambos), por lo que debe usarse un guión espaciado . A esto se le añade "fl."; obtenemos fl. 12 BH - AH 10 .
  3. El lado izquierdo es "[tradicionalmente] 1585" y el lado derecho "c. 1590". Al menos un lado tiene un espacio interno, por lo que debe usarse un guión espaciado . "Tradicionalmente" aquí podría aplicarse al año "1585" solo, o al rango "1585 - c. 1590"; en cualquier caso, el guión debe estar espaciado ya que el lado derecho tiene un espacio interno en ambos casos. Obtenemos tradicionalmente 1585 - c. 1590 .
Aparte de eso, creo que las antiguas pautas eran ligeramente contradictorias al prescribir un guión espaciado con "fl". (en el séptimo y último punto de la sección); Lo atribuiría a una mala interpretación del término en sí. Como se explicó anteriormente, floruit no se puede aplicar a un lado de un rango, sino que debe aplicarse a un solo año o un rango completo de años, expresando el período de tiempo durante el cual una persona en particular "floreció". En contraste, "c". o "después" solo puedeaplicarse a un lado de un rango, en cuyo caso el guión, por supuesto, estaría espaciado. (Admito que no me di cuenta explícitamente de esta viñeta anteriormente). Sin embargo, no veo cómo las nuevas pautas son ambiguas; en todo caso, son más claras que las antiguas desde "fl". ya no se considera incorrectamente una "forma similar". Si tenemos un rango, "c". o "after" solo se puede aplicar a un lado a la vez, mientras que "fl". solo se puede aplicar al conjunto. Espero que esto aclare un poco las cosas. -  RAVEN PVFF  · charla  · 23:37, 19 de junio de 2021 (UTC)
Ravenpuff, gracias por la explicación detallada de su razonamiento, ya que creo que ahora entiendo nuestras diferentes posiciones sobre las pautas anteriores. Me disculpo de antemano por la extensión de este comentario, pero dado que el asunto que nos ocupa se ocupa de la ambigüedad, creo que es mejor ser detallado y claro que seco y confuso. En general, había interpretado que las pautas tenían prioridad sobre los ejemplos, por lo que creía que las pautas anteriores abogaban por un guión espaciado y que el ejemplo de floruit era un error. usted había interpretado que las pautas tenían la intención de abogar por un en dash sin espacio en el ejemplo de floruit, pero no había notado previamente el último punto, y ahora considera que las pautas anteriores son contradictorias como resultado. por favor avíseme si he malinterpretado su posición. Yo no't considero mejor cualquiera de las interpretaciones; Las interpretaciones contradictorias son el resultado natural de pautas contradictorias. Estoy de acuerdo en que, si la intención hubiera sido crear un conjunto de pautas para las cuales el ejemplo original de floruit hubiera abogado por un guión sin espacios, las pautas actuales hacen un mejor trabajo al respecto.
Por lo que puedo decir, nuestro desacuerdo con las pautas actuales radica en nuestras diferentes interpretaciones de si las pautas establecen actualmente modificadores que se aplican al rango en su conjunto, como la "r". y "BC" en el primer ejemplo, "fl". en el segundo, y "tradicionalmente" en el tercero, "no influye en si usamos un guión espaciado o no". su explicación anterior me lleva a creer que cree que las pautas actuales establecen que no tienen relación. Creo que actualmente no lo afirman.
la razón por la que creo que esto es así es porque las pautas actualmente establecen que "[i] si el modificador se aplica al rango en su conjunto, use un guión sin espacio". no indica ignorar el modificador; por el contrario, establece explícitamente que se debe utilizar un en dash sin espacio. esta declaración no está calificada, por lo que no permite excepciones, como la presencia de un modificador circa en el rango. Si la viñeta indicara que el modificador debería ignorarse, entonces estoy de acuerdo con su análisis de los tres ejemplos anteriores. [j] mi segunda solución aborda este problema para ajustarse mejor a su análisis, proponiendo modificar las pautas "para que cuando 'el modificador se aplique al rango como un todo', el modificador simplemente se ignore".
Estoy de acuerdo en que mencionar "fl". en la séptima y última viñeta principal de las pautas anteriores puede haber sido un error si la intención era que el ejemplo original de floruit usara un guión sin espacio, como mencioné en el segundo párrafo de mi tercer comentario, con marca de tiempo 13:35 . Además, había elegido específicamente usar el modificador "tradicionalmente" porque se usó explícitamente en el último ejemplo de la última viñeta actual de la sección mos: approxdate, aunque estoy de acuerdo en que el uso de este modificador puede ser ambiguo. [k]
Por cierto, noté que estás usando el concepto de "espacio interno", que no parece estar bien definido en las pautas, aunque creo que entiendo tu definición del concepto. Por ejemplo, considera que los espacios en "12 BH" y "AH 10" son espacios internos, pero porque afirma que, en el ejemplo de rexit, "[a] t menos un lado tiene un espacio interno (en este caso, el left) ", supongo que no considera que el espacio en" 1336 aC ", en el lado derecho del tablero, sea un espacio interno.
No lo sé con certeza, pero supongo que también estaba usando el concepto de "espacio interno" en la solución sencilla que había propuesto, pero había usado la frase "espacio dentro de él" para referirse a esos espacios. si este es el caso, su explicación de que tales espacios incluyen aquellos que aparecen en "algo que involucra  ... 'fl. ' " parece enturbiar la definición de "espacio interno", quizás de la misma manera que la séptima y última viñeta principal punto hizo en las pautas anteriores. Creo que es posible resolver lo que creo que es una contradicción en las pautas actuales utilizando el concepto de espacio interno, pero actualmente siento que la segunda solución que propuse es una alternativa más limpia.
¿Está de acuerdo en que la segunda solución se ajusta mejor a su análisis? alternativamente, si no ve ninguna diferencia práctica entre las directrices actuales y un conjunto de directrices que implementa la segunda solución, ¿tendría algún problema con la implementación de la segunda solución? muriendo ( hablar ) 23:29, 29 de junio de 2021 (UTC)
Ravenpuff , esperaba redactar una revisión para proponer, de conformidad con la segunda solución, pero quería hacer un ping primero, ya que valoro sus comentarios y quería ver si tenía alguna información adicional, para poder evitar problemas potenciales. si tuviera que redactar la revisión. muriendo ( hablar ) 23:57, 29 de julio de 2021 (UTC)
  • He tenido la intención de volver a esto, de verdad. Y lo haré. E Eng 03:15, 17 de junio de 2021 (UTC)

Notas

  1. ^ sin embargo, existe la notable excepción de lo que se describe en las directrices como " rangos 'simples'", como " mayo-julio de 1940 ".
  2. ^ un uso de fl. se da como un ejemplo de cuando un "modificador se aplica al rango como un todo".
  3. ^ se dio como un ejemplo de los "modificadores muy cortos" después de los cuales se debe usar un espacio sin interrupciones.
  4. ^ el artículo había usado previamente "acerca de" en lugar de " c. ", pero lo cambié porque sentí que toda la oración había parafraseado su fuente bastante de cerca. la fuente parece ambigua con respecto a si "aproximadamente" se aplica a ambos puntos finales del rango, pero esta fuente deja más claro que la segunda fecha no parece estar en duda.
  5. ^ a b , sin embargo, es discutible si ese fue o no el comportamiento previsto de la plantilla floruit, ya que actualmente la plantilla también produce una " c " cuando se da un segundo argumento. No estoy seguro de por qué ese es el caso, pero actualmente supongo que automáticamente asume que el punto final de dicho rango de fechas es necesariamente aproximado, o es un error que se introdujo cuando se copió el código de la plantilla circa .
  6. ^ la redacción de la directriz justo antes de lasección mos: topresent también debería cambiarse para ajustarse, ya que actualmente recomienda que se utilice un guion espaciado siempre que esté presente un modificador, independientemente de lo que modifique el modificador.
  7. ^ en la primera solución, si se considera que "antes" es un modificador, el guión corto estaría espaciado en ambos casos, con el significado específico ambiguo, lo que probablemente no sea un problema importante ya que las ambigüedades no son infrecuentes en los lenguajes humanos.
  8. ^ esto es lo que se cambió cuando se adoptó el código para la plantilla floruit.
  9. ^ personalmente, no creo que la plantilla deba comportarse de esta manera, ya que supongo que floruit se usa con muchos rangos de fechas con segundos puntos finales que no son inciertos, incluidos aquellos similares al del ejemplo original de floruit anterior.
  10. ^ por supuesto, esto supone que todas las otras menciones conflictivas de modificadores se resuelven de manera similar.
  11. ^ No había ninguna razón por la que hubiera sabido esto, pero agregué comentarios invisibles a cada ejemplo que había creado para notar qué persona o evento histórico real estaba describiendo cada ejemplo, ya que no quería que mis ejemplos fueran meramente teóricos. para el tercer ejemplo, había hecho referencia a la colonia de roanoke , un intento temprano de fundar un asentamiento inglés permanente en las américas. desapareció en circunstancias poco claras, por lo que se desconocen las fechas exactas de su existencia, pero tradicionalmente se consideran 1585 - c.  1590. (obviamente me he tomado la libertad de usar el guión espaciado aquí, después de su análisis). Por lo tanto, mi intención en este caso había sido usar "tradicionalmente" para aplicar al rango como un todo.
    el uso de este ejemplo trae a colación un punto adicional, que es similar al problema que noté cuando propuse la segunda solución en mi comentario con marca de tiempo en 22:16. si se interpreta que las pautas actuales requieren el uso de un guión sin espacio, anulando la presencia de un espacio en el rango debido a otras razones, como un modificador circa, entonces "tradicionalmente 1585 - c.  1590" y "tradicionalmente 1585 - c.  1590 "significaría cosas diferentes, con el primero utilizado cuando" tradicionalmente "se aplica al rango como un todo, y el segundo utilizado cuando se aplica sólo al primer punto final.

WP: COMPUNITS

@ Dondervogel 2 : (quien anteriormente editó aquí como Thunderbird2  ( talk  · contribs )) no le gusta WP: COMPUNITS , específicamente los requisitos de no usar unidades IEC excepto bajo circunstancias muy específicas. Le gustaría cambiarlo. Como me opongo mucho al uso de unidades IEC, ya que rara vez se usan en algo con un uso generalizado (la mayoría de nuestras fuentes usan términos métricos clásicos como KB, MB, GB, no KiB, MiB y GiB), lo haré déjeles que completen el razonamiento para usar estos términos arcaicos que de alguna manera anulan WP: NOR y WP: VNT . - Locke Cole • t • c 16:54, 25 de abril de 2021 (UTC)

@ Denniss y Zac67 : ya que aparentemente está de acuerdo con las unidades IEC y también quiere que se cambie el MoS. - Locke Cole • t • c 16:56, 25 de abril de 2021 (UTC)

En pocas palabras, no. Este es un escrutinio inapropiado . No necesitamos fanáticos de IEC que dicten el MOS. Headbomb { t · c · p · b } 18:13, 25 de abril de 2021 (UTC)
¿ Dibi-hibiards IEC , tal vez? De todos modos, de acuerdo, no se necesita ni se desea ningún cambio. - David Eppstein ( charla ) 18:21, 25 de abril de 2021 (UTC)
@ Headbomb : debatí hacer ping en masa a los editores involucrados en la gran discusión anterior (que aparentemente fue hace más de 10 años) pero no quería que la gente se enojara demasiado. El problema es que Dondervogel 2 (y los otros dos editores a los que hice ping) están revirtiendo los cambios en los artículos para usar los términos métricos (KB, MB, GB) a favor de mantenerlos usando los términos IEC (KiB, MiB, GiB) . Entonces, o debemos discutir esto nuevamente, o esto debe ir a WP: AN / I porque un consenso local de editores no debería anular las pautas en el MoS. De lo contrario, ¿por qué tener estas pautas si solo pueden hacer pequeñas batallas durante años y forzar lentamente los artículos a los términos de la IEC? - Locke Cole • t • c 19:11, 25 de abril de 2021 (UTC)
AN / I es de hecho la forma de lidiar con la edición tendenciosa. Headbomb { t · c · p · b } 19:12, 25 de abril de 2021 (UTC)

Estoy un poco sorprendido del tono agresivo que se ve en los comentarios aquí. Revertimos los cambios no discutidos en los artículos relacionados con SDRAM donde se desea y requiere KiB, etc. Locke Cole ni siquiera intentó entrar en una discusión, sino que simplemente continuó revirtiendo. Comenzamos una discusión en Talk: Synchronous_dynamic_random-access_memory # Disputed_edits pero todo lo que hizo fue simplemente cerrarla. No tenemos la intención de cambiar Mosnum, solo tienes que aceptar que hay áreas donde KiB, etc.tiene más valor que KB, etc. - Denniss ( charla ) 19:36, 25 de abril de 2021 (UTC)

Se vuelve molesto revivir los momentos del Día de la Marmota aquí porque un editor se niega a discutir esto en el foro apropiado (en este caso, aquí) porque saben que el resultado aquí probablemente no será de su agrado. Consulte Discusión: ThinkStation # COMPUNITS para ver otra discusión que este editor trató de forzar en una página de artículo lejana que debatía esta guía. WP: COMPUNITSTambién es explícito sobre dónde y cuándo las unidades IEC son apropiadas, y los artículos sobre los que me han revertido no se enumeran como posibles excepciones. Además, con las unidades IEC, los artículos ahora se dedican a la investigación original, dando un peso indebido a una unidad de medida que casi nadie usa (ESPECIALMENTE para artículos relacionados con la memoria, ya que los estándares JEDEC utilizan casi exclusivamente KB, MB, GB). La conversación bifurcada actual (que también cerré y señalé aquí) es del día anterior, aquí .
(editado para agregar) Dondervogel 2 también ha intentado, repetidamente, tener esta discusión en otras páginas de discusión de artículos (además de los otros dos vinculados anteriormente):
  • Charla: X86-64 # COMPUNITS
  • Charla: IPad_Pro_ (3rd_generation) #COMPUNITS
  • Charla: IPad_Pro_ (4th_generation) #COMPUNITS
  • Charla: IPad_Pro # Aclaración_de_GB_vs_GiB
Esperaré y veré si sale algo de esta conversación, pero parece que AN / I es cada vez más probable .. - Locke Cole • t • c 19:58, 25 de abril de 2021 (UTC)

En mi trabajo diario, programo dispositivos integrados. Lo que significa que paso mucho tiempo en las hojas de datos del fabricante. No recuerdo la última vez que vi un MiB, KiB, etc. en una hoja de datos oficial. Tampoco los encuentro en Stack Overflow, blogs de programación o cualquier otro recurso en línea cuando busco respuestas para problemas particularmente difíciles. De hecho, las únicas veces que puedo recordar es aquí en WP en las discusiones de la página de discusión sobre si usarlas. Simplemente no se usa en la industria en gran medida.  Stepho   talk  22:55, 25 de abril de 2021 (UTC)

No veo la necesidad de discutir aquí porque no estoy sugiriendo un cambio a MOSNUM. Sin embargo, si hay consenso para mantener la discusión aquí, que así sea. Como ya ha señalado Denniss , la discusión así iniciada es innecesariamente hostil, así que comienzo recordando a los participantes el WP: CIVIL . Mi propósito es mejorar los artículos individuales implementando el MOS tal como está actualmente. Las mejoras en los artículos individuales se tratan mejor caso por caso, así que comencemos con SDRAM . En ese artículo se produjo una guerra de edición y traté de mover la discusión a su página de Discusión . El problema es cómo eliminar la ambigüedad introducida por esta edición (y las reversiones posteriores) porLocke Cole . Comencé una discusión en la página de discusión. Esa discusión fue cerrada por Locke Cole , así que he transferido ese hilo aquí (abajo). Dondervogel 2 ( charla ) 14:45, 26 de abril de 2021 (UTC)
@ Zac67 : @ Locke Cole : @ Denniss : Dondervogel 2 ( charla ) 14:48, 26 de abril de 2021 (UTC)
Su preocupación es la aplicación de WP: COMPUNITS . No está de acuerdo con la forma en que se ha aplicado y cree que mis ediciones son erróneas. La "hostilidad" que percibe es bien merecida porque ha comenzado repetidamente discusiones de whack-a-mole en varias páginas de discusión (para temas prácticamente idénticos) en lugar de venir aquí donde el nexo de sus preocupaciones se puede abordar de manera realista. En cuanto a Denniss  ( talk  · contribs ), esta edición en la que se refirió a lo que dije como "bla, bla", le quita el aire a cualquier víctima fingida que intente presentar aquí. WP: CIVIL es una calle de doble sentido. - Locke Cole • t •c 15:20, 26 de abril de 2021 (UTC)
Para una (con suerte) desambiguación del prefijo MOSNUM, he creado una nueva plantilla, {{binpre}} . La plantilla debe permitir notas a pie de página rápidas y uniformes cuando se usen (y deben usarse) prefijos binarios. Espero que ayude. - Zac67 ( conversación ) 11:55, 30 de abril de 2021 (UTC)
@ Zac67 : Hemos tenido {{ BDprefix }} durante algún tiempo, y he estado tratando de usarlo cuando sea apropiado. Cuando se combina con {{ efn }} y {{ notelist }}, proporciona una explicación clara que generalmente se integra bien con el contenido de otros artículos, como referencias y otras notas. - Locke Cole • t • c 14:35, 30 de abril de 2021 (UTC)
{{ binpre }} produce una referencia numerada, que no es apropiada. Si se va a utilizar, debe incluir una nota al pie con letras. NebY ( charla ) 09:17, 8 de mayo de 2021 (UTC)

@ Compvis , Jc3s5h , Cybercobra , Woodstone , Greg L , Art LaPella , Seraphimblade , MJCdetroit , Pyrotec , Theaveng y Cyde : editores de ping de las discusiones anteriores, ya que aparentemente se ha convertido en una discusión más amplia. Dondervogel 2 está intentando usar unidades IEC como desambiguación en artículos a pesar de que las recomendaciones de larga data están disponibles aquí en WP: COMPUNITS. Mi lectura es que hay muy pocas excepciones para usar IEC, y la mayoría se trata de si la mayoría de las fuentes las usan o no, y si es posible o no usar uno de los otros métodos para eliminar la ambigüedad de los términos. Se agradecería aportaciones adicionales. - Locke Cole • t • c 18:27, 3 de mayo de 2021 (UTC)

De hecho, WP: COMPUNITS permite absolutamente el uso de prefijos IEC "en artículos en los que ambos tipos de prefijos se utilizan sin que sean claramente primarios, o en los que convertir todas las cantidades a uno u otro tipo sería engañoso o perdería la precisión necesaria, o declarar la el significado real de una unidad en cada uso no sería práctico ". En SDRAM ], M y G se utilizan con un significado binario para las capacidades de memoria, y con su significado estándar del SI para las velocidades y frecuencias de datos. En mi opinión, las notas a pie de página que se utilizan actualmente no son prácticas, especialmente cuando ambos significados se utilizan muy de cerca. Locke Colerevertir repetidamente esas desambigaciones es una violación de esos términos. No solicito el uso de prefijos IEC en ningún otro caso (tamaños de almacenamiento y demás) que no sean los expresamente designados en WP: COMPUNITS. - Zac67 ( charla ) 05:18, 4 de mayo de 2021 (UTC)
Usted (y otros) se están tomando demasiada libertad con esa frase de COMPUNITS. Mi lectura de eso es que las fuentes aún deben usar esos términos para que sea aplicable, pero hasta donde he visto, ninguna fuente usa gibit . WP: V y WP: NOR son política por una razón. - Locke Cole • t • c 14:17, 4 de mayo de 2021 (UTC)

@ Dondervogel 2 : No estoy seguro de si fue obvio, pero esta discusión ha terminado en gran medida. COMPUNITS no está cambiando y no vamos a utilizar unidades IEC en los artículos. Si persiste en intentar agregarlos a los artículos, es posible que se bloquee por interrupción, ya que claramente no hay consenso para usar IEC en los artículos, y simplemente discutir largamente hasta que sus oponentes se cansen y se vayan no es un "consenso" como parece. pensar. Voy a revertir sus adiciones a los diversos artículos de Apple. Si vuelve a añadirlos, entonces el siguiente paso será una visita a WP: AN / I . Parar ahora. - Locke Cole • t • c 19:41, 14 de junio de 2021 (UTC)

Además, considere cuidadosamente la redacción en WP: IDHT . Describe tu comportamiento con un T. - Locke Cole • t • c 20:25, 14 de junio de 2021 (UTC)
Me alarma esta profusión de comentarios llenos de "tú esto", "tú aquello". Creo que todos sabemos de dónde tienden a provenir esos comentarios y adónde tienden a ir. Estos intercambios producen inevitablemente más calor que luz. Además, amenazar a las personas por valorar la desambiguación no es una buena apariencia, y revertir las ediciones de las personas también puede considerarse perjudicial. El hecho de que mucha gente vea el valor de los prefijos IEC es quizás una buena indicación de que la postura que ha adoptado aquí no es la única posición defendible. Además, como señalé a continuación, nada menos que una autoridad que el BIPM ( es decir,la autoridad global final sobre el uso de unidades de medida) ha respaldado explícitamente el uso de prefijos IEC. Por lo tanto, diría que, si algo es incompatible con NPOV, es tratar IEC como si fuera únicamente el dominio exclusivo de los chiflados (a menos que vayamos a argumentar que los metrólogos profesionales líderes en el mundo son unos chiflados que empujan los POV). Archon 2488 ( charla ) 11:04, 15 de junio de 2021 (UTC)
Usted y yo debemos estar leyendo conversaciones muy diferentes a continuación ... y mi buena fe expiró por completo después de este intercambio (lo notará después de ese intercambio y las respuestas que siguieron. Dejé de participar aquí cuando quedó claro que Dondervogel simplemente se niega a "entenderlo "). En cuanto a sus comentarios sobre IEC, dada la falta de fuentes académicas y de los medios de comunicación a continuación, yo diría que les da mala fama a los chiflados traerlos a esto ... no hacemos cosas solo porque una organización de estándares lo aprueba, hacemos las cosas por lo que dicen nuestras fuentes. Y nuestras fuentes no utilizan IEC (consulte Usuario: Locke Cole / las unidades IEC son malas , o el uso de #IEC en los medios impresos y las unidades #IEC en los escritos académicos a continuación (el material a continuación es principalmenteduplicado en mi espacio de usuario)). Vale la pena mencionar que este caballo muerto ha sido golpeado desde 2010 (y antes). Y parece que la reacción de Dondervogel al no defender con éxito las unidades de IEC en esas viejas discusiones es jugar una guerra de edición prolongada en el espacio de artículos, agregándolos lentamente a los artículos y esperando que nadie se dé cuenta. Esa es la definición de disrupción. Lamento que no lo veas. 🤷‍♂️ - Locke Cole • t • c 16:52, 15 de junio de 2021 (UTC)
@ Locke Cole :
  • No tengo tiempo para detenerme en su edición hostil y su acoso continuo. Sigues repitiendo que no ves ninguna razón para cambiar MOSNUM, pero en todo este hilo no he propuesto ni una vez un cambio a mosnum. En cambio, mi propósito es mejorar los artículos y me he centrado constantemente en los problemas. WP se basa en el consenso y el consenso no se logra cuando un editor declara unilateralmente que la discusión ha terminado. Y ciertamente no mientras haya muchos artículos para mejorar. Si está aquí para mejorar WP, deje de hacer tonterías y concéntrese en mejorar los artículos.
  • Ha tenido problemas con algunas de mis ediciones en artículos seleccionados de iPad y iPod, así que comencemos por ahí. El 30 de mayo hice una propuesta razonada para mejorar algunos artículos de iPad y iPod , aclarando cuánto espacio en disco hay disponible. Después de 10 días, nadie había respondido, así que implementé con valentía el cambio e informé en mosnum . Ahora ha revertido mis cambios sin discutirlo. Responderé a esas reversiones en el lugar donde hice la propuesta.
Dondervogel 2 ( charla ) 19:53, 19 de junio de 2021 (UTC)
@ Dondervogel 2 : de WP: NOTSILENCE : Retirarse de la comunicación con un editor tendencioso o pendenciero no le da su consentimiento al editor para hacer lo que le gusta .
Usted dijo: Ni una sola vez propuse un cambio a mosnum : sí, solo ha querido volver a litigar los prefijos IEC en todos y cada uno de los casos a pesar de que la directriz dice claramente que "no deben usarse". Pero claro, no está tratando de cambiar el MOS, solo está tratando de ignorarlo y pasar por alto el consenso existente.
Ya terminé aquí. Otros editores también parecen haber terminado aquí (bueno, hay un editor que se unió recientemente, pero esto ha estado sucediendo durante casi dos meses y durante el último mes ha sido principalmente usted respondiendo ocasionalmente lo que evita que el tema se archive automáticamente) . No hay consenso para cambiar MOSNUM para permitir los tipos de ediciones que parece obligado y decidido a realizar. Es poco probable que se produzca tal consenso solo porque sigues forzando el tema. No se tolerará la participación en la edición tendenciosa.
Para mí está claro que tienes la intención de intentar hacernos jugar al whack-a-mole contigo en todos y cada uno de los casos. Si continúa con este hilo, puede asumir automáticamente lo que esté proponiendo, si implica el uso de prefijos IEC en el espacio del artículo (directa o indirectamente), me opongo. Además, considere esto : cuando existe un consenso global para editar de cierta manera, debe respetarse y no puede ser anulado por un consenso local. COMPUNITS es el consenso global existente, deje de proponer ediciones que vayan en contra de él. - Locke Cole • t • c 20:13, 19 de junio de 2021 (UTC)
@ Locke Cole : De hecho, no es necesario ningún cambio en WP: MOSNUM # Cantidades de bytes y bits , ya que ya permite el uso de prefijos IEC en casos marginales, por ejemplo, cuando se mezclan prefijos decimales y binarios en un artículo. En caso de que no pueda molestarse en pasar la página (el énfasis es mío):

Los prefijos IEC kibi- (símbolo Ki), mebi- (Mi), gibi- (Gi), etc., generalmente no deben usarse excepto en [...] artículos en los que ambos tipos de prefijos se usan con ninguno de los dos claramente primario , o en el que convertir todas las cantidades a uno u otro tipo sería engañoso o perdería la precisión necesaria, o no sería práctico declarar el significado real de una unidad en cada uso.

Los artículos en cuestión usan prefijos mixtos y el uso de notas al pie inflacionarias no es práctico, en mi humilde opinión ( ver ejemplo ). No obstante, sigues revirtiendo, y tu forma de interrumpir la discusión y responder a los argumentos al menos raya en el acoso para mí. - Zac67 ( conversación ) 07:39, 20 de junio de 2021 (UTC)
@ Zac67 : Oh, sí ... acoso total. No como alguien que ... oh, no sé, toma más de un mes para responder a una conversación, o reanima conversaciones muertas hace mucho tiempo para tratar de usarlas como forraje para su punto de vista ( comentario original 2021-05-01T19: 12: 09 , responder 2021-06-14T07: 38: 22 ; comentario original de 2021-05-03T16: 06: 45 respuesta 2021-05-30T09: 57: 43 ; comentario original de 2020-05-25T17: 12: 18 , responder 2021-05 -03T10: 14: 13 (casi un año después) , hace ping al editor que nunca respondió a la conversación inicial casi un año después). No, tienes razón, por supuesto, he estado acosando completamente a la gente aquí esperando que usen la lógica y la razón y no solo argumentos de "ME GUSTA". TOTALMENTE.
En cuanto a su cita malinterpretada. A ustedes les encanta ignorar los bits sobre cuándo la mayoría de las fuentes citadas sobre el tema del artículo usan prefijos IEC; , o ignoremos eso (ustedes claramente lo son), si realmente creen que el "o" le da carta blanca para anular políticas como WP: V y WP: NOR de una guía (pista: MOS no tiene la capacidad de eludir WP : V y WP: NOR ; aún necesitaría fuentes que usen prefijos IEC). Y, por supuesto, también ignorar por completo o declarar el significado real de una unidad en cada uso sería poco práctico... no sería impracticable tener una nota al pie con valores relevantes para informar al lector de la diferencia utilizando un lenguaje simple y fácil de usar como "1 GB = mil millones de bytes" (o usar uno de los ejemplos para eliminar la ambigüedad siempre que no implican el uso de IEC). Espero que usar la lógica y la razón aquí no sea un hostigamiento torpe para ti, no quisiera que te sintieras acosado . Si necesito hacer algo para que esta respuesta sea menos molesta , hágamelo saber. Tal vez pueda dejar que su respuesta repose durante un mes y luego la responderé espontáneamente. Eso parece ser lo que pasa por un comportamiento perfectamente aceptable para ti. - Locke Cole • t • c 17:42, 20 de junio de 2021 (UTC)
@ Locke Cole : No hay WP: OR o WP: V involucrado cuando se usan prefijos IEC (por razones prácticas). Hemos establecido que se usan en publicaciones científicas, a pesar de su afirmación de que nadie los usa (tenga en cuenta que WP: RS no requiere fuentes científicas ). Luego siguió argumentando que la mayoría de las fuentes necesitaban usar prefijos IEC antes de que pudiéramos usarlos, eso no es requerido en ningún otro lugar excepto por usted. Además, es solo una excepción para su uso, la desambiguación es otra. Solo estoy tratando de usarlos para la desambiguación como WP: MOSNUM # Cantidades de bytes y bitssugiere - en artículos donde ambas variantes son razonables y para simplificar la desambiguación. No se requiere 'carta blanca'. Simplemente estoy pidiendo usar esos prefijos como actualmente lo garantiza WP: MOSNUM . Tus reversiones y las guerras de edición son disruptivas. - Zac67 ( conversación ) 18:44, 20 de junio de 2021 (UTC)
@ Zac67 : No voy en círculos contigo. Se requiere competencia y, claramente, no es competente a la hora de interpretar WP: COMPUNITS . Iniciar repetidamente incendios forestales para impulsar IEC en Wikipedia, ignorar repetidamente las conversaciones porque no le gusta a dónde van (pero luego responder semanas después para evitar que los hilos se archiven) es MUCHO MÁS disruptivo que cualquier cosa que haya hecho (no importa cuánto intente inflarlo para que sea más grande de lo que es; algo así como las unidades IEC, los fabricantes y las fuentes confiables nunca las usan , pero algunos niños en la universidad (a una tasa de menos del 2%) y ustedes piensan que he encontrado una mina de oro para el abastecimiento de IEC) ... - Locke Cole •t • c 20:10, 20 de junio de 2021 (UTC)
@ Locke Cole : Soy incompetente para leer. "Responder una semana más tarde para evitar que el hilo se archive" cuando acaba de publicar usted mismo. Eso es lo que quise decir con "al menos rayano en el acoso", gracias por dejarme claro. Aparentemente, no puede molestarse con hechos o políticas. El [...] nunca usarlos ha sido refutado, no hace falta reiterarlo. Exige fuentes científicas, y cuando se proporcionan son de "algunos niños en la universidad" (¿realmente ha verificado eso, o es una acusación descabellada?). Y no tengo idea de a qué te refieres con lo de la mina de oro. El hecho es que sus argumentos han sido refutados. WP: COMPUNITSes lo suficientemente claro, sin mucho espacio para la interpretación, pero aún reitera e insiste en que puede revertir las ediciones de acuerdo con nuestras políticas. ¿Quién es el acérrimo aquí? - Zac67 ( charla ) 05:16, 21 de junio de 2021 (UTC)
@ Zac67 : Literalmente, no tengo idea de cómo lo que citó incorrectamente sería "acoso". Entonces, sea cual sea el punto que haya dicho, enhorabuena, estoy seguro de que está muy satisfecho consigo mismo. Aparentemente, no le pueden molestar los hechos o la política. ¿En serio? ¿Crees que las siguientes semanas de conversación fueron simplemente imaginarias? Quiero decir que no respondió a la fuente de medios impresos, o al comentario de trabajos académicos, así que tal vez simplemente ignora las cosas que no le gustan . El hecho de que quieras fingir que el cielo es verde no significa que tenga que seguirle el juego. En cuanto a "hechos" y "política", claro, aquí tienes:
  • Hechos: Las unidades IEC se utilizan en menos del 2% de los trabajos académicos. Las unidades IEC se utilizan en menos de 1/10 del 1% de los medios de impresión. Los principales fabricantes de productos electrónicos de consumo no utilizan unidades IEC. Las unidades IEC no son utilizadas por la gran mayoría de los principales proveedores de software (Apple, Microsoft, etc.).
  • Política: WP: V (usar IEC en absoluto, dadas las fuentes generalmente inexistentes sería una violación), WP: NOR (ya que carecemos de fuentes, y mucho menos fuentes confiables creíbles, usarlas sería una investigación original), WP: NPOV (particularmente WP: UNDUE ; presentar unidades IEC junto con unidades tradicionales muy comunes y ampliamente utilizadas sería darles un peso indebido a nuestros lectores y confundirlas con términos que nadie más usa ).
El [...] nunca usarlos ha sido refutado ... oh ¿verdad? ¿Te importaría mostrarme dónde? Exige fuentes científicas, ... Yo no hice tal cosa. De hecho, no tengo idea de por qué Dondervogel presentó artículos académicos, mi única teoría es que tiene algo que ver con su mantenimiento casi religioso de User: Thunderbird2 / El caso en contra de la desaprobación de los prefijos IEC ( editar | hablar | historia | enlaces | ver | registros ) donde aparentemente han hecho su misión de aferrarse a la noción de que el uso en los documentos visibles de Google Académico es de alguna manera relevante (en realidad no creo que lo sean, creo que el uso más amplio en los medios (impresos / web / televisión) es más relevante , como es el uso por parte de fabricantes y empresas de software). ¿Quién es el acérrimo aquí? Uh ... ¿eso es retórico? Solo he estado involucrado en esta discusión durante unos meses. Algunos de ustedes han estado en esto durante más de una puta década y no se rendirán. Entonces ... ¿ quién es el acérrimo aquí? es que no me . Simplemente no tengo miedo de gritar tonterías. : DI odio seguir diciéndolo, pero WP: CIR sigue pareciendo cada vez más relevante. - Locke Cole • t • c 06:48, 21 de junio de 2021 (UTC)
Ya he intervenido, pero solo quiero ofrecer mi tuppence de que es evidentemente absurdo sugerir que el uso de una unidad definida en un estándar no es verificable. La definición de la unidad es trivialmente verificable consultando la norma. Demonios, incluso el suavees verificable, porque existen fuentes que lo definen. No tengo idea de qué más espera en términos de verificabilidad; una unidad de medida no es una proposición que pueda ser verdadera o falsa (por lo tanto, ni siquiera me resulta obvio lo que podría significar, conceptualmente, "verificarla") - es una definición. Debería "verificar" otras ocurrencias de la unidad determinando si cumplen con el estándar, pero a menos que sea un metrólogo, es poco probable que esto le preocupe. El uso de las definiciones de unidades tampoco es una investigación original mediante ninguna definición útil del término, como tampoco es una "investigación original" consultar el folleto SI del BIPM y usar el medidor SI. Usar un estándar no es investigación,literalmente, cualquier definición de esas palabras que he encontrado en aproximadamente 15 años de estudio y trabajo en campos STEM de alta precisión. Usar una unidad no es un punto de vista; Solo se puede decir que una proposición proviene de un punto de vista (este punto es muy discutido por nuestros agitadores antimétricos residentes, quienes parecen pensar que decir que un lago tiene 12 km de largo es una declaración política potencialmente imperdonable; la inanidad de esto es evidente por sí misma). Si está afirmando que cierto objeto pesa 12 kg, esa es una proposición simple que puede ser verdadera o falsa; No veo cómo entra en juego POV (porque es apolítico), independientemente de cuánto alguien pueda detestar el uso de unidades SI. Lo mismo para IEC, de hecho. Puede haber otras razones para no utilizar determinadas unidades (Solo se puede decir que una proposición proviene de un punto de vista (este punto es muy discutido por nuestros agitadores antimétricos residentes, quienes parecen pensar que decir que un lago tiene 12 km de largo es una declaración política potencialmente imperdonable; la inanidad de esto es evidente por sí misma). Si está afirmando que cierto objeto pesa 12 kg, esa es una proposición simple que puede ser verdadera o falsa; No veo cómo entra en juego POV (porque es apolítico), independientemente de cuánto alguien pueda detestar el uso de unidades SI. Lo mismo para IEC, de hecho. Puede haber otras razones para no utilizar determinadas unidades (Solo se puede decir que una proposición proviene de un punto de vista (este punto es muy discutido por nuestros agitadores antimétricos residentes, quienes parecen pensar que decir que un lago tiene 12 km de largo es una declaración política potencialmente imperdonable; la inanidad de esto es evidente por sí misma). Si está afirmando que cierto objeto pesa 12 kg, esa es una proposición simple que puede ser verdadera o falsa; No veo cómo entra en juego POV (porque es apolítico), independientemente de cuánto alguien pueda detestar el uso de unidades SI. Lo mismo para IEC, de hecho. Puede haber otras razones para no utilizar determinadas unidades (Si está afirmando que cierto objeto pesa 12 kg, esa es una proposición simple que puede ser verdadera o falsa; No veo cómo entra en juego POV (porque es apolítico), independientemente de cuánto alguien pueda detestar el uso de unidades SI. Lo mismo para IEC, de hecho. Puede haber otras razones para no utilizar determinadas unidades (Si está afirmando que cierto objeto pesa 12 kg, esa es una proposición simple que puede ser verdadera o falsa; No veo cómo entra en juego POV (porque es apolítico), independientemente de cuánto alguien pueda detestar el uso de unidades SI. Lo mismo para IEC, de hecho. Puede haber otras razones para no utilizar determinadas unidades (por ejemplo , son tontos como los smoots, o en desuso como los cables náuticos), pero el punto de vista no entra en juego. Y en cuanto al CIR, no veo ninguna indicación de que alguno de los participantes en esta discusión sea incompetente. Archon 2488 ( charla ) 12:07, 21 de junio de 2021 (UTC)
El estándar existe, el uso generalizado (que sería otro requisito de WP: V ) no lo es. A todos los efectos, las unidades IEC no son utilizadas en gran parte por la sociedad en general (fabricantes, proveedores, medios (web / impresos / etc.), trabajos académicos, etc.). En cuanto al punto de vista, como expliqué, WP: UNDUE es específicamente la preocupación allí, dado que menos del 1% de las fuentes generales que usan los términos de IEC (especialmente en contextos históricos) y la percepción del público en general, sería desequilibrado para proporcionar el mismo peso. / significado de los términos IEC. No permitimos eso como una cuestión de política . Y créame, WP: CIR es relevante aquí. Existe una alta probabilidad de que el efecto Dunning-Kruger también esté en juego aquí. - Locke Cole• t • c 17:39, 21 de junio de 2021 (UTC)
Así que ahora estamos insinuando abiertamente que los editores que no están de acuerdo con esta interpretación tan amplia de verificabilidad, NPOV y OR en este contexto son incompetentes y demasiado estúpidos y / o desinformados para entender que lo son, en virtud de el efecto DK? Básicamente, dejé pasar esto antes, pero es absolutamente inapropiado. Incluso ignorando lo sarcástico que es, ya que la mayoría de los que estamos aquí (presumiblemente) tenemos un trasfondo ampliamente STEM de un tipo u otro, esto no me parece plausible, por decirlo suavemente; en realidad parece claramente descortés y nada más que un ataque personal burdamente disfrazado. Y observo con interés que tiene, en su espacio de usuario, un ensayo que describe por qué "las unidades IEC son malas ". ¿Qué le parece eso para un punto de vista neutral?
Claramente ha clavado sus colores en el mástil y, por sus comentarios aquí, parece que ha decidido, independientemente de las circunstancias o el contexto, que cualquiera que sugiera el uso de prefijos IEC en cualquier situación debe ser tratado como un maniático peligroso o un incompetente. charlatán. Mierda, usted mismo nos lo ha dicho explícitamente; Incluso dejando a un lado la cortesía, por lo general se considera prudente no decirle a la gente con tanta franqueza lo que piensa de ellos. Por mi parte, no tengo mucho caballo en esta carrera, ya que mi preferencia personal actual es no tomar mis estancias en Wikipedia como vacaciones de busman.y, por lo tanto, rara vez edito artículos relacionados con la informática. Mucho menos defiendo qué unidades se usan en ellos: solo soy un observador que ocasionalmente interviene en MOSNUM cuando siente que tiene algo que decir. Entonces, en el espacio del artículo, si un editor cree que el 1 GiB más ordenado pero menos común, o la aproximación de forma estándar más clara pero indiscutiblemente más fea 1.074 × 10 9  B, es un medio más apropiado para comunicar información desambiguante, es realmente una cuestión de indiferencia para mí. La histeria absoluta que recibe al primero cada vez que se menciona es una de las más desconcertantes rarezas históricas perdurables de MOSNUM. Archon 2488 ( conversación ) 22:37, 21 de junio de 2021 (UTC)
El debate continúa ... - E Eng

@ Archon 2488 : Estoy empezando a pensar que no has leído mucho de este hilo. Así que ahora estamos insinuando abiertamente que los editores que no están de acuerdo con esta interpretación tan amplia de verificabilidad ... Entonces, mi opción alternativa es asumir que Dondervogel 2 está actuando de mala fe, no de incompetencia. Sin embargo, según WP: AGF , debo asumir de buena fe. Así que estoy. Supongo que la razón por la que continúan como lo hacen es porque no entienden de qué están hablando. Esta es una suposición mucho mejor que suponer una intención maliciosa. Y observo con interés que tiene, en su espacio de usuario, un ensayo que describe por qué "las unidades IEC son malas ". ¿Qué le parece eso para un punto de vista neutral? Maravilloso.Dondervogel 2 también tieneUsuario: Thunderbird2 / El caso en contra de la desaprobación de los prefijos IEC , estoy seguro de que esto también le "interesa". ¿O quizás no? Además, si ha leído el "ensayo" de mi espacio de usuario, verá que es simplemente una colección de mis argumentos de esta discusión más amplia en una forma más fácil de digerir.

... independientemente de las circunstancias o el contexto, cualquiera que sugiera el uso de prefijos IEC en cualquier situación debe ser tratado como un loco peligroso o un charlatán incompetente. Quiero decir, esas son tus palabras. Pero después de dos meses, y un comportamiento disruptivo de Dondervogel 2 (como iniciar múltiples conversaciones bifurcadas en casi una docena de páginas ahora, que he tenido que acorralar aquí, donde todavía insisten en fragmentar las discusiones de todos modos , aunque el tema es en gran parte lo mismo). Los he involucrado en sus "fuentes", he proporcionado contrapuntos, y como nadie aquí parece estar convencido de llevar esto más lejos, WP: COMPUNITS se mantiene. Nada va a cambiar, como dije anteriormente, por lo que el statu quo, la IEC antepone kibi- (símbolo Ki ), mebi ( Mi ), gibi- ( Gi ), etc., generalmente no se deben utilizar como soportes. Ahora, en cuanto a su ataque más amplio a MOSNUM en general, déjelo. Un manual de estilo que ayude a proporcionar una experiencia coherente a nuestros lectores es algo que los editores de este proyecto han decidido que creen que es valioso. Lamento que pienses que deberíamos crear excepciones en todo el proyecto, pero de esa manera hay confusión tanto para nuestros lectores como para nuestros editores. Tenemos métodos de desambiguación proporcionados, y ciertamente usar otros métodos no es inaceptable (especialmente si coinciden con lo que dicen nuestras fuentes), sin embargo, usar unidades IEC no es una de esas opciones. (excepto en casos muy específicos).

Lamento sinceramente no haberle llevado esto a AN / I inmediatamente como me dijeron que hiciera al comienzo de este hilo. Lamento tomarme el tiempo para escuchar a Dondervogel 2, considerar sus "fuentes", escuchar sus argumentos y tratar de mantener una mente abierta. Claramente, debería haber abordado el problema central de comportamiento antes de dejar que esto se descarrilara durante dos meses, y ese error es culpa mía. Gracias por hacérmelo muy claro ahora. - Locke Cole • t • c 03:50, 22 de junio de 2021 (UTC)

@ Locke Cole : Actualmente no tengo el tiempo para responder adecuadamente a su respuesta anterior, pero aún no comprende el punto. Incluso ha citado WP: COMPUNITS para adaptarse a su sesgo; hay una excepción en esa política. Una excepción es la desambiguación razonable. Las fuentes que utilizan prefijos IEC son otra excepción. La MOS no dice "dos de cuatro" o incluso "tres de cuatro" para estos criterios. Hay un simple "o". Eso no es una "carta blanca" como usted lo llama, sino más bien una llamada a un uso razonable , donde los prefijos IEC claramente tienen sentido práctico. Sin defenderlos ampliamente (no estoy demasiado con @ Dondervogel 2 :en este). Además, gran parte de su argumento es "ya lo hemos superado hace diez años": los tiempos cambian y hay una aceptación cada vez mayor de los prefijos IEC en el mundo. Eso se llama progreso, aunque lento. Su colección de argumentos de espacio de usuario vinculada arriba muestra su nivel de desinformación y atraso para mí.
La realidad es que los prefijos binarios solo se usaron inicialmente para la memoria, y que los desarrolladores de software mal informados comenzaron a usarlos para el almacenamiento (formateado) y especialmente para el tamaño de los archivos, haciendo que los usuarios los percibieran como "unidades de computadora", en su propio contexto. para aquellos "en el saber". Eso es un pensamiento elitista e incluso peligroso en su esencia. Antes de que preguntes, no, no tengo una fuente para eso, pero he estado allí y lo he visto. - Zac67 ( conversación ) 06:23, 22 de junio de 2021 (UTC)
Puedo asegurarles que he visto muchas discusiones sobre IEC en MOSNUM, gracias por su condescendencia, ¿o debo inferir que también soy un incompetente Dunning-Krugerite? ¿He subido al nivel de mi incompetencia de Wikipedia?por haberme escuchado en MOSNUM en el pasado, y ahora sobrepasé mi marca al pronunciar sobre el más polémico de los temas, ese Balrog que acecha en las profundidades de la historia de MOSNUM, un antiguo mal que acecha a los mineros imprudentes para despertarlo, el prefijos IEC temidos? Estos comentarios hostiles, seguidos de no disculpas como "la alternativa es asumir mala fe, y no se me permite hacer eso", son completamente venenosos, en varios niveles. Y he visto el ensayo de Dondervogel; lo que quiero decir es que un título como "el caso en contra de menospreciar a X" al menos no suena tan abiertamente sesgado y categóricamente desdeñoso como "X es malo". Es una afirmación mucho más débil, por lo tanto, mucho más fácil de justificar, de que podría haber circunstancias en las que X podría ser útil (lo cual observo, al igual que Zac67 arriba,que COMPUNITS ya dice, aunque con grandes salvedades, que es la sustancia de lo que estamos disputando aquí), que afirmar que X es obra del Diablo y nunca debe ser tocado por manos mortales (como, por ejemplo, Java) .
Y no le hace ningún favor a uno hacer declaraciones tan abiertamente obstinadas como esa (antes de preguntar, tampoco es aconsejable decir que usar IEC es la única forma aceptable). El hecho es que probablemente no haya nadie aquí que no sepa a estas alturas cuál es su opinión sobre este tema. Has dejado claro tu punto. El hecho de que no sea de ninguna manera Dondervogel (que bien podría estar pasando por encima de la marca en su apetito por IEC) quien no esté de acuerdo contigo sugiere que, sin embargo, has pasado un poco por alto los puntos que otros están haciendo en tu evidente entusiasmo por desterrar cualquier rastro de estos prefijos prohibidos de WP. No hay una conspiración pro-IEC en WP, hasta donde yo sé.
Ahora en cuanto a su ataque más amplio a MOSNUM en general ... Honestamente, no tengo idea de dónde sacó la idea de que estoy atacando a MOSNUM, sobre todo porque he participado en muchas discusiones aquí a lo largo de los años. Nunca dije nada en el sentido de crear excepciones en todo el proyecto ; lo más cerca que estuve fue implicando vagamente que estaría de acuerdo con que el MOS permitiera que IEC se usara en un alcance más amplio, y dado que ya recomendamos glosar las unidades menos comunes, las unidades desconocidas para los lectores generales deben presentarse como un par de nombre y símbolo en primer lugar. utilizar, vinculando el nombre de la unidad, Personalmente creo que es poco probable que esto sea un problema tanto para los lectores como para aquellos editores que se oponen estridentemente a la IEC. Pero como dije antes, este no es un tema en el que tenga un gran interés personal; Sin embargo, lo tomo como una buena señal cuando los editores que han estado menos involucrados en disputas MOS recurrentes y divisivas como esta se sientan cómodos para presentarse y ofrecer su opinión. Una gran parte del problema de gritar acusaciones de incompetencia, Dunning-Kruger o mala fe, no es tanto que sea abusivo para el editor al que se dirige directamente, sino que otros que están observando pero no participan activamente se sentirán mucho menos inclinados a unirse. una discusión tan tóxica. Por lo tanto, se termina con un efecto de "enfriamiento por evaporación" en el que todas las personas, excepto las más estridentes, se han ido, o lo han dejado bastante bien.
Tampoco necesito que me expliquen el propósito de un MoS como si tuviera cinco años. Simplemente me divierte oscuramente que hay ciertos temas que se repiten constantemente y que no se pueden discutir sin que se conviertan en una crueldad totalmente desproporcionada . Y esta lista de temas no ha cambiado mucho en la década que llevo viniendo aquí. Archon 2488 ( charla ) 09:48, 22 de junio de 2021 (UTC)

Discusión transferida desde SDRAM

WP: COMPUNITS no es una licencia para introducir ambigüedad en ningún artículo. He restaurado una versión estable anterior del artículo para que podamos discutir las ediciones en disputa desde el 20 de abril. Las declaraciones relevantes incluyen:

  • No asuma que el significado binario o decimal de los prefijos será obvio para todos.
  • La desambiguación debe mostrarse en bytes o bits, con una indicación clara de si es en base binaria o decimal. No hay preferencia en la forma de indicar el número de bytes y bits, pero el estilo de notación debe ser coherente dentro de un artículo.
  • Los prefijos IEC kibi- (símbolo Ki), mebi- (Mi), gibi- (Gi), etc., generalmente no deben usarse

La conclusión es que se necesita desambiguación. La única pregunta es cómo. Es difícil satisfacer los tres requisitos, lo que sugiere WP: IAR como la única guía práctica, y desambiguación utilizando el método más práctico disponible. ¿Qué piensan los demás? Dondervogel 2 ( charla ) 16:46, 24 de abril de 2021 (UTC)

Estoy de acuerdo , secundando eso en su totalidad. Las unidades ambiguas no ayudan a nadie y las explicaciones para los lectores que no están familiarizados con los prefijos IEC binarios están disponibles en la página vinculada. - Zac67 ( conversación ) 09:57, 25 de abril de 2021 (UTC)
Sigues intentando tener estas discusiones de whack-a-mole en páginas lejanas lejos de WT: MOSNUM . La ubicación correcta para esta discusión es WT: MOSNUM . Deje de iniciar incendios forestales y comience la discusión donde tenga sentido. No va a cambiar la redacción de WP: COMPUNITS aquí. - Locke Cole • t • c 16:48, 25 de abril de 2021 (UTC)
Para los propósitos de esta discusión, me limitaré a megabyte (MB) / mebibyte (MiB) (pero la misma lógica se aplica a kilobyte (KB) / kibibyte (KiB), gigabyte (GB) / gibibyte (GiB), terabyte (TB) ) / tebibyte (TiB), etc.). Dependiendo del uso, megabyte (MB) significa 1,000,000 (un millón) de bytes o 1,048,576 bytes (a pesar de algunos usos realmente extraños como se hizo en la fabricación de algunos disquetes). El uso de 1,000,000 es típicamente de fabricantes de discos duros / almacenamiento, mientras que el uso de 1,048,576 es típicamente de fabricantes de memoria / RAM. Hasta el día de hoy, los megabytes (MB y las unidades similares más pequeñas / más grandes) siguen siendo de amplio uso no solo en la documentación técnica, sino también en los medios más grandes en torno a temas informáticos, así como en materiales de marketing y empaques para productos relacionados con la informática. Puedo entrar en una Best Buy, elija una caja de disco duro y compruebe que Western Digital sigue vendiendo con orgullo una unidad de disco duro de 14 terabytes . Habrá un asterisco, y en la parte inferior del cuadro veré un descargo de responsabilidad que indica que "1 gigabyte = mil millones de bytes, 1 terabyte = 1 billón de bytes". Si me acerco al área de memoria de la computadora, puedo mirar un paquete de DDR4 SDRAM y ver que se vende en unidades de GB (gigabyte). Si me acerco a la tienda de Apple, veo que los iPad Pro vienen con opciones de almacenamiento como 64 GB y 256 GB, pero hay un descargo de responsabilidad cerca del final del material de marketing que dice que "1 GB = mil millones de bytes".
En pocas palabras, la adopción de unidades IEC es efectivamente inexistente. Aparte del trabajo académico en algunas situaciones irregulares, el mundo en general se ha apegado en gran medida a las unidades métricas que hemos tenido desde los primeros días de la informática. Wikipedia informa sobre el mundo tal como es , no cómo la gente quiere que sea. Es lamentable que este tipo de imprecisión se base en algo que exige precisión (informática y tecnología), pero para nuestros lectores que utilizan términos como "gibibyte" y "mebibyte" cuando están acostumbrados a ver términos como "gigabyte" y "megabyte". "simplemente crea una confusión innecesaria. Nuestra mejor opción es vincular estos términos según corresponda (para que los lectores puedan profundizar más si así lo desean), y tal vez proporcionar notas a pie de página vinculadas que brinden más precisión a instancias potencialmente problemáticas dentro de nuestros artículos (simplemente usando un lenguaje similar al que usarían Apple y Western Digital al menos elimine cualquier incertidumbre para nuestros lectores donde eso pueda ser un problema; por ejemplo, "1 MB = un millón de bytes").
Estoy abierto a opciones adicionales, pero el uso de KiB, MiB, GiB, etc. no es una de ellas, excepto como está exactamente proscrito en WP: COMPUNITS (que solo enumera cuatro instancias muy específicas en las que las usaríamos ). - Locke Cole • t • c 15:20, 26 de abril de 2021 (UTC)
Es bueno tener un experto a bordo, Locke. Tony (charla) 05:17, 27 de abril de 2021 (UTC)
Estas perdiendo el punto. COMPUNITS tiene muy claro el requisito de eliminar la ambigüedad:
  • No asuma que el significado binario o decimal de los prefijos será obvio para todos.
  • La desambiguación debe mostrarse en bytes o bits, con una indicación clara de si es en base binaria o decimal. No hay preferencia en la forma de indicar el número de bytes y bits, pero el estilo de notación debe ser coherente dentro de un artículo.
Usted es el editor que con esta edición introdujo ambigüedad en el artículo (y cuando sus ediciones fueron disputadas por otros editores, eligió revertir 3 veces [1] [2] [3] en lugar de participar en la página de discusión), así que la responsabilidad Depende de usted eliminar esa ambigüedad. ¿Cómo propone que el artículo en cuestión pueda eliminar la ambigüedad entre diferentes unidades que comparten el mismo símbolo? Dondervogel 2 ( charla ) 18:25, 26 de abril de 2021 (UTC)
No, soy muy consciente de tu punto. Pero lo que se ha perdido por completo es que Wikipedia no usa unidades IEC excepto en situaciones muy específicas . Punto final . Lo que también te has perdido es la respuesta a tu propia pregunta de WP: COMPUNITS . Ahora, considerando que ha sido dirigido allí docenas de veces hasta ahora (y debe saber que existe porque participó en las discusiones hace más de diez años que llevaron a que WP: COMPUNITS sea ​​lo que es hoy), y que ahora está fingiendo que no puedes leer inglés básico, estoy empezando a pensar que WP: CIR se aplica a tu situación. Desde WP: COMPUNITS :
  • La desambiguación debe mostrarse en bytes o bits, con una indicación clara de si es en base binaria o decimal. No hay preferencia en la forma de indicar el número de bytes y bits, pero el estilo de notación debe ser coherente dentro de un artículo. Los ejemplos aceptables incluyen:
    • A 64  MB ( 64  ×  1024 2 -byte) tarjeta de vídeo y un 100  GB (100  ×  1000 3 -byte) disco duro
    • A 64  MB ( 64  ×  2 20 -byte) tarjeta de vídeo y un 100  GB (100  ×  10 9 -byte) disco duro
    • Una tarjeta de video de 64  MB (67,108,864 bytes) y un disco duro de 100  GB (100,000,000,000 bytes)
Personalmente, creo que eso es una exageración, y que simplemente usar un lenguaje similar al que usan Western Digital y Apple ("1 GB = 1 millón de bytes" (y así sucesivamente, según corresponda) como nota al pie) sería suficiente. Wikipedia no usará KiB, MiB, etc. Si desea cambiar eso, finalmente estamos en la página correcta. Pero dados los comentarios anteriores, creo que encontrará que la discusión no tendrá el resultado que está buscando. - Locke Cole • t • c 19:34, 26 de abril de 2021 (UTC)
Sí, me gustaría proponer un cambio. Cuando la última discusión haya pasado 10 años, podría ser el momento de reconsiderarlo.
En mi último lugar de trabajo, los prefijos IEC eran obligatorios en la documentación donde los prefijos binarios tenían sentido (principalmente RAM), todo lo demás tenía que usar decimal. En mi trabajo actual, se recomiendan prefijos IEC para prefijos binarios. JEDEC simplemente no los usa porque usan prefijos binarios exclusivamente y necesitan un decimal. Sin embargo, cuando se trata de varios aspectos de las computadoras, es imposible evitar la ambigüedad al mezclar prefijos binarios y decimales sin señalar el significado actual todo el tiempo. Existen
Si esta política no se puede cambiar, ¿cómo se supone que debemos referirnos a una memoria con una capacidad de 2 36 bytes?
  • 64 GB (con nota a pie de página: G significa 1024 3 aquí y solo aquí )
  • 68.719.476.736 byte
  • California. 68,7 GB
¿No es 64 GiB mucho más simple? Por favor, no me malinterpretes: usar prefijos binarios de cualquier manera para cantidades arbitrarias (almacenamiento, red, telecomunicaciones) es simplemente una tontería, incluso si existe una tradición. Solo estoy hablando de los pocos casos en los que los prefijos binarios tienen sentido real. [perplejo] - Zac67 ( charla ) 21:28, 26 de abril de 2021 (UTC)
De las tres opciones que dio, solo una es válida, la primera con la nota a pie de página. # 2 probablemente entraría en conflicto con WP: POINT (y preocupaciones sobre WP: V y WP: RS que no usan ese tipo de lenguaje), y # 3 sería WP: ORya que no es así como nuestras fuentes usan los términos. En los últimos diez años, nada significativo ha cambiado para hacer que las unidades IEC sean más atractivas de lo que eran en 2008-2009. Al final, no cumplen con el requisito más básico de uso: ser ampliamente utilizados en nuestras fuentes y en la vida cotidiana. Apple no usa GiB. Microsoft no usa GiB. Los principales fabricantes de productos electrónicos no utilizan GiB. Los medios de comunicación, especialmente los que se ocupan de la tecnología y la informática, no utilizan GiB. Vaya a leer los archivos, intentaron usar IEC aquí durante años antes de WP: COMPUNITS , e IEC finalmente quedó en desuso debido a la falta de uso en nuestras fuentes y la confusión de nuestra preocupación más importante: los lectores . - Locke Cole • t • c 21:54, 26 de abril de 2021 (UTC)
Decir "G significa 1024 ^ 3 aquí y solo aquí" no es una solución viable. Necesitamos una mejor manera de eliminar la ambigüedad, y el mejor método de desambiguación probablemente variará de un artículo a otro. Locke Cole necesita detener la campaña para introducir ambigüedad en docenas de artículos mientras debatimos esto. Dondervogel 2 ( charla ) 10:15, 28 de abril de 2021 (UTC)
Creo que a largo plazo deberíamos dejar la elección al lector (similar a los formatos de fecha y unidades métricas vs imperiales). Por ahora, agregaré notas al pie de desambiguación, consulte DDR4 SDRAM . Difícil pero que así sea. Deberíamos crear una plantilla para las notas a pie de página para que haya un formato uniforme y sea más fácil de migrar (en caso de que eso suceda). - Zac67 ( conversación ) 10:23, 28 de abril de 2021 (UTC)
Apoyo esta forma de desambiguación cuando GB tiene un solo significado en un artículo. No lo apoyo cuando tiene dos o más significados. Dondervogel 2 ( charla ) 10:41, 28 de abril de 2021 (UTC)
Estoy operando con el consenso actual. Hasta que haya mostrado su apoyo a otro método, continuaré editando como lo hice porque la guía se ha mantenido estable durante más de una década con un apoyo significativo. Si desea cambiar eso, hágalo saber y presente su elección sobre cómo proceder. De lo contrario, déjelo y siga adelante y deje que aquellos de nosotros trabajemos dentro de las pautas actuales de MoS para mejorar Wikipedia mediante el uso de un lenguaje que nuestros lectores entienden y ven en todas partes. - Locke Cole • t • c 16:04, 28 de abril de 2021 (UTC)
No está trabajando dentro de las pautas actuales de MOS; usted reconoce que estos requieren desambiguación y, sin embargo, elige no seguir esa parte. Y no estoy abogando por un cambio en esas pautas. En cambio, estoy argumentando en contra de sus ediciones repetidas que introducen ambigüedad en SDRAM, cuando hay un consenso claro aquí de que la desambiguación es necesaria y requerida por MOSNUM. Y estoy argumentando que el artículo debe permanecer en su estado antes de que se asegure esta discusión hasta que acordamos cómo debe resolverse. Dondervogel 2 ( charla ) 16:19, 28 de abril de 2021 (UTC)
WP: COMPUNITS ya prescribe métodos para eliminar la ambigüedad . Mis ediciones se han centrado en eliminar las unidades IEC inapropiadas, ya que además de no seguir el consenso aquí, también violan WP: V y WP: NOR ya que casi todas nuestras fuentes utilizan las unidades binarias más tradicionales. WP: SOFIXIT si cree que algo no está claro, use uno de los métodos ya demostrados en WP: COMPUNITS . El statu quo es que no utilizamos unidades IEC. Hasta que demuestre un consenso para cambiar que no seré paralizado en un debate constante sobre algo que ya se ha resuelto durante más de una década. Tu problema es que crees que no tengo consenso cuando ya lo tengo. - Locke Cole • t• c 16:37, 28 de abril de 2021 (UTC)
Conoce el requisito de eliminar la ambigüedad, pero decide ignorarlo. Por lo tanto, sus ediciones no cumplen con COMPUNITS. He intentado eliminar la ambigüedad del artículo . Las mejoras sugeridas son bienvenidas. Una guerra de edición no es bienvenida. Dondervogel 2 ( charla ) 18:52, 28 de abril de 2021 (UTC)
@ Dondervogel 2 : Elijo aceptar que no todo en Wikipedia se hará simultáneamente, o nunca se hará nada: vea WP: NOTPERFECT . Su regreso a una versión en la que se utilizan unidades IEC, lo que va en contra del consenso aquí, así como la directriz de MoS, que dice que las unidades IEC no deben usarse excepto en un puñado de circunstancias muy específicas, es lo que definitivamente no es bienvenido. . Estás interrumpiendo Wikipedia al deshacer el trabajo constructivo. - Locke Cole • t • c 05:11, 29 de abril de 2021 (UTC)
De lo contrario. Estoy tratando de encontrar una solución que funcione. Más específicamente, como SDRAM usa G con un significado decimal y M con un significado binario, propongo reemplazar todas las apariciones binarias de 'G' con '1024 M' . Es desordenado y está lejos de ser ideal, pero funciona. Dondervogel 2 ( charla ) 13:01, 1 de mayo de 2021 (UTC)
@ Dondervogel 2 : ¿Qué te hace pensar que G se usa únicamente con el significado decimal? M, G, T también se usan comúnmente para referirse a poderes binarios, especialmente por JEDEC. - Zac67 ( charla ) 16:05, 1 de mayo de 2021 (UTC)
@ Zac67 : Mi punto es que GB / s se usa en este artículo en particular en sentido decimal. Supongo que podríamos definir 1 GB como 1000 ^ 3 B y 1 Gbit como 1024 ^ 3 bits, pero prefiero que G se use con un solo significado en cualquier artículo. Es probable que cualquier otra convención confunda al lector. Dondervogel 2 ( charla ) 16:56, 1 de mayo de 2021 (UTC)
@ Zac67 : Puse un par de etiquetas 'dudosas' en lugares donde creo que el artículo ahora tiene un error como resultado de cambios recientes. Mira lo que piensas. Dondervogel 2 ( charla ) 20:25, 1 de mayo de 2021 (UTC)
@ Dondervogel 2 : Ruego diferir. En telecomunicaciones y almacenamiento, no hay razón para usar prefijos binarios (salvo algunos casos de esquina). En consecuencia, "GB / s" siempre debe basarse en potencias de 1000. Las tasas de transferencia se definen utilizando prefijos decimales. Para ver un ejemplo, consulte los documentos JEDEC: para tamaños que usan 1024 xy para tasas 1000 x (los relojes base son 100 o 200 millones de Hz). Si eso realmente no tiene sentido, entonces tienes mi punto inicial. - Zac67 ( conversación ) 20:27, 1 de mayo de 2021 (UTC)
@ Zac67 : Lo siento, no me expliqué bien. El problema es que el artículo define Gbit como 1024 ^ 3 bits, y luego lo usa (donde coloqué las etiquetas 'dudosas') para significar 1000 ^ 3 bits. Dondervogel 2 ( charla ) 20:35, 1 de mayo de 2021 (UTC)
@ Dondervogel 2 : Hmm, no veo ninguna definición general en el artículo. Todos los prefijos binarios deben tener una nota al pie ahora, los simples deben ser decimales. - Zac67 ( conversación ) 21:01, 1 de mayo de 2021 (UTC)
@ Zac67 : solucioné el error. Es desordenado, pero al menos no está mal. Dondervogel 2 ( charla ) 00:29, 2 de mayo de 2021 (UTC)
@ Dondervogel 2 : Lo siento, no lo hiciste. No usamos prefijos binarios arbitrariamente. Cuando una velocidad de datos se define por una frecuencia basada en un prefijo decimal (por ejemplo, 200 MHz), no tiene ningún sentido usar un prefijo binario (ni siquiera JEDEC lo hace), por lo que debemos permanecer en decimales. En pocas palabras, el tamaño de la RAM se expresa en binario, la velocidad de RAM en decimal. Una rara excepción podría ser cuando la frecuencia es una potencia de dos, debido a la multiplicación binaria, pero ese no es el caso con la RAM estándar. ¿Necesitamos una nota al pie decimal también ...? - Zac67 ( conversación ) 07:43, 2 de mayo de 2021 (UTC)

No. Esa no es la solución. Un Gbit es 1000 ^ 3 bits o 1024 ^ 3 bits. Por el momento son ambos, pero tenemos que elegir entre ellos. Cual es Dondervogel 2 ( charla ) 09:08, 2 de mayo de 2021 (UTC)

@ Zac67 : No debemos suponer que el lector sabrá qué Gbit es decimal y cuál es binario, y esto se expresa en MOSNUM como "No asuma que el significado binario o decimal de los prefijos será obvio para todos" y "consistencia dentro de un el artículo es deseable ". No hay razón para introducir inconsistencias en este artículo. Dondervogel 2 ( charla ) 10:36, 2 de mayo de 2021 (UTC)
"Gbit" es decimal a menos que esté etiquetado como binario (lo cual es torpe, pero Locke Cole no permitiría usar prefijos IEC de manera razonable). Binary Gbit es razonable para tamaños o capacidades de memoria de semiconductores (y muy pocos otros casos). Las velocidades de datos, la capacidad del disco, etc., usan prefijos decimales porque no hay una matriz binaria fundamental detrás de ellos. Consulte WP: MOSNUM también. La coherencia es deseable, pero no hasta el punto de combinar velocidades de datos. (como "100 MHz × 8 bit / s = 95,4 MB / s", definitivamente no) - Zac67 ( hablar ) 11:21, 2 de mayo de 2021 (UTC)
LC no dicta las reglas ni tiene el monopolio de su interpretación. MOSNUM nos obliga a pensar en el lector y aclarar el significado de cada símbolo de unidad. Usar el mismo símbolo de unidad (Gbit) con dos significados diferentes no logra eso, por lo que la pregunta es de qué otra manera se puede hacer. Aquí hay 4 ejemplos de desambiguación en publicaciones científicas:
  • do Carmo et al 2007
  • Heithecker et al 2007
  • Blomer 2015
  • Gerhke et al 2016
En los 4 casos, la desambiguación se logra utilizando Gbit para la cantidad decimal y Gibit para la binaria. Ambos hemos buscado alternativas para aclarar este artículo, y ninguna hasta ahora ha tenido éxito. Propongo que sigamos el método de desambiguación utilizado en fuentes confiables. Dondervogel 2 ( charla ) 17:43, 2 de mayo de 2021 (UTC)
Es una pena que ninguna de esas cuatro fuentes se utilice enMemoria dinámica sincrónica de acceso aleatorio ( editar  | hablar  | historial  | proteger  | eliminar  | enlaces  | ver  | registros  | vistas ) . ¿Qué dicen nuestras fuentes utilizadas en el artículo? - Locke Cole • t • c 00:51, 3 de mayo de 2021 (UTC)
Creo que ahora hemos establecido suficientemente que las fuentes confiables usan prefijos IEC y prefijos tradicionales ambiguos, con y sin desambiguación adicional (ver más abajo). Eso también falsifica la declaración anterior de que "la adopción de unidades IEC es efectivamente inexistente". Además, MOSNUM actualmente permite prefijos IEC donde tanto los prefijos decimales como los binarios se usan razonablemente dentro de un artículo y se requiere desambiguación.
Por experiencia reciente, puedo decir que usar notas repetitivas con prefijos binarios es, en el mejor de los casos, torpe. ¿Podemos ahora usar prefijos IEC (con moderación y cuando sean realmente útiles, compatibles con MOSNUM) sin tener que temer las guerras de edición? - Zac67 ( conversación ) 09:02, 3 de mayo de 2021 (UTC)
¿Suficiente establecido? Dice eso como si quisiera decir que la mayoría de las fuentes confiables usan prefijos IEC. Pero solo ha establecido que algunas fuentes confiables del mundo académico usan prefijos IEC. Aún debe demostrar que la mayoría de las fuentes confiables (incluidas las fuentes oficiales, como las hojas de datos del fabricante y los organismos de estándares) usan prefijos IEC y no usan MB / GB / TB / etc. También debe demostrar que las fuentes que usan MB / GB / TB no son confiables.  Stepho   talk  11:57, 3 de mayo de 2021 (UTC)
Lo que se ha establecido es que todas las fuentes identificadas hasta la fecha que desambiguan sobre el tema de SDRAM, lo hacen utilizando prefijos IEC. Esa es una mayoría de aproximadamente 52 fuentes confiables que usan prefijos IEC a ninguna que usa los métodos tontos sugeridos por MOSNUM. Dondervogel 2 ( charla ) 12:07, 3 de mayo de 2021 (UTC)
@ Stepho-wrs : Requerir una mayoría general de RS antes de permitir prefijos IEC en una página no ayuda; podría llevar muy rápidamente a que el uso del prefijo se convierta en un criterio de selección del editor (sesgado) para RS, en lugar del valor de una fuente en términos de claridad y aplicabilidad. Además, no hay motivos para exigir la mayoría de las fuentes: el MOSNUM actual ya permite prefijos IEC cuando el etiquetado individual no es práctico (que en mi humilde opinión es claramente el caso en el artículo de SDRAM). - Zac67 ( conversación ) 12:57, 3 de mayo de 2021 (UTC)
He desambiguado Gbit y Gibit, para que el artículo no sea incorrecto. Sin embargo, sigue siendo un desastre. Dondervogel 2 ( charla ) 16:44, 3 de mayo de 2021 (UTC)

Invocación de WP: CALC en Talk: Jerarquía de memoria

@ Tom94022 y Dondervogel 2 : Citando la primera oración de WP: CALC : Los cálculos de rutina no cuentan como investigación original, siempre que haya consenso entre los editores de que el resultado del cálculo es obvio, correcto y un reflejo significativo de las fuentes .

Tomemos los requisitos uno por uno:

  • […] Siempre que haya consenso entre los editores […] - parece un punto importante;
  • […] Que el resultado del cálculo es obvio, correcto, […] - no hay desacuerdo allí, ya que las unidades IEC tal como se definen son un reemplazo directo de los nombres de unidades métricas clásicas;
  • […] Y un reflejo significativo de las fuentes -… y aquí es donde todo se desmorona, muy pocas fuentes confiables usan estas unidades / prefijos IEC. La gran mayoría, esperaría que en algún lugar al norte del 95% de las fuentes usen el clásico kilobyte / KB, megabyte / MB, gigabyte / GB, terabyte / TB, etc. E independientemente de eso, el lenguaje aquí en WP: COMPUNITS ha gozado de consenso durante más de una década. Es inaceptable interrumpir a los editores que trabajan para implementar nuestras pautas de estilo porque no está de acuerdo con el resultado de las discusiones aquí. Si desea cambiar WP: COMPUNITS , este es el lugar para mantener esa discusión. Dicho esto, el debate interminable porque no estás de acuerdo con lo que la mayoría apoya no va a funcionar: Wikipedia no tiene un filibustero.. - Locke Cole • t • c 16:23, 30 de abril de 2021 (UTC)
Contrariamente a su afirmación anterior, es este artículo el que permite prefijos IEC en el artículo en cuestión. Locke Cole está en guerra al imponer su punto de vista en la jerarquía de la memoria a pesar de la clara enseñanza en este artículo de que los prefijos IEC pueden usarse " en artículos en los que ambos tipos de prefijos se usan sin que ninguno sea claramente primario ... " El artículo en La pregunta ha utilizado prefijos IEC como se prescribe en este artículo para mayor claridad durante mucho tiempo, por lo que existe un claro consenso entre los editores del artículo para utilizar los prefijos y nadie hasta la fecha ha apoyado su punto de vista. Tom94022 ( conversación ) 16:48, 30 de abril de 2021 (UTC)
Tenga en cuenta que he denunciado a Locke Cole para editar en guerra sobre este tema. Tom94022 ( conversación ) 17:24, 30 de abril de 2021 (UTC)
Se perdió la cita restante de lo que leyó: […] o declarar el significado real de una unidad en cada uso no sería práctico. Mi edición muestra que el uso de {{ BDprefix }} hizo posible declarar el significado real de cada unidad. Esto también lo mantiene en línea con nuestras fuentes que no usan GiB o MiB o KiB. - Locke Cole • t • c 17:58, 30 de abril de 2021 (UTC)

El lugar apropiado para esta discusión es Talk: Memory_hierarchy # IEC_units donde los editores de ese artículo pueden decidir qué sección de este artículo es más aplicable. Locke Cole está haciendo compras al plantearlo aquí y cualquier editor que tenga conocimiento e interés en la aplicación de prefijos IEC a la jerarquía de memoria debería comentar allí. Tom94022 ( conversación ) 17:40, 30 de abril de 2021 (UTC)

No, esta aqui. Deja de intentar hacer ForestFires . Perdiste. Superalo. - Locke Cole • t • c 17:58, 30 de abril de 2021 (UTC)
Entonces, ¿de esto se trata? ¿Ganar y perder? No. Te estás comportando infantilmente con argumentos válidos. - Zac67 ( conversación ) 20:28, 30 de abril de 2021 (UTC)
@ Zac67 : Eso es una buena iluminación de gas. Anímate y lee esto: Charla de Wikipedia: Manual de estilo (fechas y números) / Archivo B16 # Gibibytes_versus_Gigabytes ; No me di cuenta de que Tom también había estado involucrado en la discusión de los mayores de 10 años y estuvo golpeando a un caballo muerto durante más de una década ... - Locke Cole • t • c 21:05, 30 de abril de 2021 (UTC)
¿Tengo que darles la vuelta a la manguera? E Eng 22:21, 30 de abril de 2021 (UTC)

Uso de IEC en medios impresos

Lista tomada de Lista de periódicos en los Estados Unidos , Lista de periódicos en el Reino Unido por circulación , Lista de periódicos en Australia por circulación y Lista de periódicos en Canadá por circulación .
Resultados de la consulta de Google
Periódicositio: <URL> "gibibyte"sitio: <URL> "gigabyte"sitio: <URL> " fatberg " [1]
usatoday.com074526
wsj.com1 [2]2.8902
nytimes.com14.610168
nypost.com0234130
latimes.com01.3905
washingtonpost.com097147
startribune.com04101
newsday.com02700
chicagotribune.com095241
bostonglobe.com02783
Entradas extra para divertirse
seattletimes.com061123
seattlepi.com03830
Internacional (de habla inglesa)
timesofindia.com04904
metro.co.uk01092,290
thesun.co.uk0137135
dailymail.co.uk0710318
www.standard.co.uk08817.900 [3]
mirror.co.uk0154170
thetimes.co.uk0439sesenta y cinco
www.telegraph.co.uk040772
theguardian.com05463.270 [4]
heraldsun.com.au07626
www.dailytelegraph.com.au08445
www.couriermail.com.au04934
www.smh.com.au01.03029
www.theaustralian.com.au03648
www.theglobeandmail.com06022
www.thestar.com038722
nationalpost.com05849
Sin filtro "site:", solo los términos entre comillas
213.00072,400,000238.000
  1. ^ Inspirado por Un fatberg de 330 toneladas está obstruyendo el alcantarillado de una ciudad inglesa y no se moverá durante semanas ; fatberg se acuñó por primera vez en 2008 según el diccionario en línea Merriam-Webster .
  2. ^ Hanrahan, Tim; Fry, Jason (22 de septiembre de 2003). "Encontrar a los perros en la red; caso de los bytes de PC que faltan" . El Wall Street Journal . Consultado el 1 de mayo de 2021 . (En 1997, un organismo de estándares trató de aclarar las cosas cambiando el nombre de las unidades derivadas de binarios a gibibytes , lo que le dice todo lo que necesita saber sobre la utilidad de que los ingenieros jueguen con el lenguaje).
  3. ^ Claramente, The Evening Standard cree que las historias de fatberg son particularmente dignas de noticias...
  4. ^ En serio, muchachos ... dejen de echar aceite de cocina por los desagües ...

Puedo expandir esto, pero como punto de datos pensé que sería interesante verlo. - Locke Cole • t • c 15:30, 1 de mayo de 2021 (UTC)

Estamos hablando de desambiguación en SDRAM y en jerarquía de memoria . ¿Alguno de estos artículos periodísticos desambigua? Si no, no son relevantes para la discusión. A continuación se muestran algunas publicaciones científicas sobre jerarquía de memoria o SDRAM. Todos eliminan la ambigüedad utilizando prefijos IEC. Dondervogel 2 ( charla ) 17:58, 1 de mayo de 2021 (UTC)
Si no, no son relevantes para la discusión. Perdon, que? ¿En qué universo crees que los medios de comunicación en general no usan los términos que estás promoviendo de alguna manera no es una sentencia de muerte para la idea desde el principio? Y diré de nuevo, todavía no he visto ninguna fuente en los artículos que cambié que utilizara unidades IEC, y mucho menos cualquiera con una proporción de IEC más prominente que las unidades métricas tradicionales. Wikipedia no es una plataforma para impulsar su agenda. - Locke Cole • t • c 19:11, 1 de mayo de 2021 (UTC)
@ Locke Cole : De su respuesta deduzco que los periódicos no desambiguan, lo que los hace irrelevantes para una discusión sobre desambiguación. Dondervogel 2 ( charla ) 07:38, 14 de junio de 2021 (UTC)
Solo quiero señalar que el uso enciclopédico (y, en general, el uso de publicaciones de referencia) no está restringido de ninguna manera a lo que hacen los periódicos, sobre todo porque la mayoría de las personas que escriben artículos relacionados con STEM para medios populares no lo son, en mi experiencia , abrumadoramente alfabetizado técnicamente (me recuerda un artículo de periódico sobre astronomía que parecía implicar que Júpiter era más grande que el Sol). Además, los periódicos tienen sus propios objetivos ( es decir, vender copias y obtener ganancias), que son distintos de los de Wikipedia. Estoy completamente de acuerdo con el punto anterior de Dondervogel sobre la primacía de la desambiguación; en una obra de referencia (y no tanto en un periódico), la ambigüedad que se evita fácilmente es un descuido imperdonable.
También me gustaría señalar que esta frase "unidades métricas tradicionales" es controvertida; bits y bytes no son (en mi humilde opinión) realmente "métricas", pero si vamos allí, el folleto de SI estipula (nota al margen en la p. 143 de la versión bilingüe de la novena edición, al comienzo de la sección 3, múltiplos decimales y sub -múltiplos de unidades SI ):

Los prefijos SI se refieren estrictamente a potencias de 10. No deben usarse para indicar potencias de 2 (por ejemplo, un kilobit representa 1000 bits y no 1024 bits). Los nombres y símbolos de los prefijos que se utilizarán con potencias de 2 se recomiendan de la siguiente manera: [prefijos IEC tabulados]

Archon 2488 ( charla ) 09:36, 14 de junio de 2021 (UTC)
Tenemos suerte de que, además de los periódicos que no utilizan los términos, nadie más parece estarlo de manera significativa. Esta tabla es solo un ejemplo de lo cómicamente mala que ha sido la adopción de unidades IEC. - Locke Cole • t • c 10:48, 1 de agosto de 2021 (UTC)

Desambiguación en publicaciones científicas sobre jerarquía de la memoria

Publicaciones científicas que utilizan prefijos IEC
  1. Ayers et al 2018
  2. Balkesen et al 2013
  3. Capodieci et al 2020
  4. Choe et al 2020
  5. Deakin y Price, 2017
  6. Endo 2016
  7. Gottscho et al 2016
  8. Hackenberg et al 2009
  9. Kim et al 2019
  10. Kloda et al, 2019
  11. Kodama et al 2019
  12. Kodama et al 2020
  13. Le Seur y Heiser 2010
  14. Molka et al, 2009
  15. Molka et al 2014
  16. Molka et al, 2017
  17. Monil et al 2020
  18. Moreira et al 2006
  19. Navarro et al 2019
  20. Perarnau et al 2016
  21. Ren et al 2021
  22. Sánchez et al 2018
  23. Schlosser et al 1999
  24. Sing et al 2009
  25. Thiemann 2020
  26. Yarom et al 2015
  27. Zlatanov 2016
Publicaciones científicas que utilizan otros métodos de desambiguación
  • Sol 2011
Discusión
Sostengo que las fuentes confiables que desambiguan sobre el tema de la jerarquía de la memoria, lo hacen usando prefijos IEC. ¿Hay contraejemplos? Dondervogel 2 ( charla ) 17:58, 1 de mayo de 2021 (UTC)
Aquí hay un contrapunto escogido con cereza contra sus ejemplos escogidos con cereza:
  • Guangyu Sun, 2011, Explorando el diseño de la jerarquía de la memoria con tecnologías de memoria emergentes (consulte la página 19)
¿No es divertido jugar al juego de la selección de cerezas?  Stepho   talk  01:03, 2 de mayo de 2021 (UTC)
Un comentario y una pregunta:
No estaba escogiendo cerezas (hay muchos más de donde vinieron)
No veo ninguna desambiguación en el ejemplo que encontró. ¿Dónde está la desambiguación?
Dondervogel 2 ( charla ) 07:31, 3 de mayo de 2021 (UTC)
Cuando hay millones de artículos por ahí, es poco probable que una selección sea representativa. Puede elegir cientos de artículos que muestren su punto de vista y yo puedo elegir cientos de artículos que muestren mi punto de vista. Ambas selecciones carecen de sentido. Por lo tanto, cualquier selección hecha a mano es intrínsecamente seleccionada, incluso si no es intencional.
Para el documento que mostré, mire la página 19 (use el número de página impresa, no el número de página del PDF). Dice "2 MB (16x128 KB)" y algunas expresiones similares, lo que muestra claramente que no es de 2.000 KB o 2.000.000 de bytes.
Pero vayamos a una fuente más autorizada. JEDEC define estándares para muchos dispositivos de memoria, incluidos los dispositivos eMMC / MMC / SDCard y DIMM / SDRAM. El estándar MMC se encuentra en https://www.jedec.org/sites/default/files/docs/JESD84-B51.pdf (deberá registrarse, pero es gratis). JEDEC utiliza KB / MB / GB exclusivamente.
Lo mismo para las tarjetas SD en https://www.sdcard.org/downloads/pls/pdf?p=Part1_Physical_Layer_Simplified_Specification_Ver8.00.jpg&f=Part1_Physical_Layer_Simplified_Specification_Ver8.00.pdf&e=EN_SS1_8 (se requiere otro registro gratuito).
O vuelva a JEDEC para estándares SDRAM en https://www.jedec.org/system/files/docs/4_20_10R19A.pdf .
Siéntase libre de explorar JEDEC: tienen muchos documentos que usan KB / MB / GB / TB / etc. y solo he encontrado uno que menciona prefijos IEC: "Diccionario de términos JEDEC para tecnología de estado sólido - 7ª edición" https: / /www.jedec.org/system/files/docs/JESD88F.pdf . En la página 135 (PDF página 141) da la definición de mega y la contrasta específicamente con mebi. Y luego nunca usan los prefijos IEC en ningún otro documento (al menos no el que he encontrado extrayendo documentos al azar).
Creo que esta discusión comenzó en el artículo de SDRAM. Los estándares SDRAM son mantenidos por JEDEC. Y JEDEC usa prefijos que no son IEC.  Stepho   talk  13:22, 3 de mayo de 2021 (UTC)
JEDEC usa prefijos mixtos . Usan binarios solo para capacidad de memoria y decimales / SI para velocidades de datos y demás. Si bien esta es una forma comúnmente entendida por los profesionales experimentados, no creo que sea la forma correcta de hacerlo para WP, dado el alcance de nuestro lector. Lo mismo ocurre con los "2 MB (16x128 KB) que [...] se muestran claramente" citados anteriormente. Incluso JEDEC ha reconocido buenos casos de uso para los prefijos IEC, simplemente no lo viven de esa manera (todavía); dada la falta de presión en estos círculos, un ajuste puede llevar décadas. Creo, y espero, que podamos ser más progresistas aquí. - Zac67 ( conversación ) 13:54, 3 de mayo de 2021 (UTC)
@ Stepho-wrs : En respuesta a sus diversos puntos
  • Sol de 2011: Gracias. Veo ahora que MB se desambigua de la forma que sugieres. No veo KB o GB sin ambigüedades en ninguna parte. Peor aún, la desambiguación de MB no me ayuda ni un ápice a descifrar (p94) "Se supone que el ancho de banda promedio proporcionado por la memoria principal es de 8GB / S". No es muy profesional y ciertamente no es un ejemplo que debamos seguir.
  • JEDEC: No podemos esperar que nuestros lectores estén familiarizados con los estándares JEDEC. JEDEC tampoco define todos los prefijos en un sentido binario. Consulte Plantilla: Cantidades_de_bytes .
  • Esta discusión comenzó en la jerarquía de la memoria , no en la SDRAM .
Dondervogel 2 ( charla ) 14:18, 3 de mayo de 2021 (UTC)
Independientemente de dónde se inició, para temas relacionados con la memoria (DRAM, SDRAM, GDDR, etc.), JEDEC es la organización que crea estándares y generalmente promueve los términos utilizados en los empaques y en la literatura del fabricante. Como se analiza a continuación en las unidades IEC en artículos académicos, las instancias de unidades IEC son extremadamente pequeñas en comparación con el uso de las unidades métricas tradicionales en artículos académicos. - Locke Cole • t • c 16:48, 3 de mayo de 2021 (UTC)
D, si se espera que el lector no entiende el origen de la mayoría de los estándares de memoria de ordenador, pero no esperar que comprendan trabajos académicos a continuación, sus gafas de color rosa se han convertido en vasos de color cereza. Ambos están escritos con aproximadamente el mismo nivel de complejidad y ambos serían aproximadamente iguales en comprensibilidad para el lector.  Stepho   talk  20:52, 4 de mayo de 2021 (UTC)
@ Locke Cole : Las "unidades métricas tradicionales" a las que se refiere en muchos casos no son unidades métricas, sino unidades binarias. Si no eliminan la ambigüedad, no podemos decirlo, y ese es mi punto. En mi experiencia, los que desambiguan usan prefijos IEC.
@ Stepho-wrs : No pongas palabras en mi boca.
Dondervogel 2 ( charla ) 12:51, 7 de mayo de 2021 (UTC)
@ Dondervogel 2 : Esa es una buena idea, pero el hecho de que sólo dos fuentes en medios impresos incluso utilizan esos términos en absoluto toma el aire de esa idea muy rápido. Luego, considerar que menos del dos por ciento de los trabajos académicos hacen referencia a esas unidades, nuevamente, hace que ese argumento sea muy increíble. Consulte la navaja de afeitar de Hitchens y el estándar Sagan . Se ha descubierto que incluso las fuentes que ha citado aquí no desambiguan como usted afirma, por lo que la afirmación de que las que desambiguan usan prefijos IEC simplemente no es cierta . - Locke Cole • t • c 15:32, 7 de mayo de 2021 (UTC)
¿Cuáles de las fuentes no eliminan la ambigüedad? Dondervogel 2 ( charla ) 07:47, 9 de mayo de 2021 (UTC)
Terminé de jugar tu juego de "No te escucho". La mayoría de los editores aquí no admiten el cambio de COMPUNITS. COMPUNITS ya dice que las unidades IEC son. Los prefijos IEC kibi- (símbolo Ki ), mebi- ( Mi ), gibi- ( Gi ), etc., generalmente no deben usarse . Ya existen métodos en COMPUNITS para eliminar la ambigüedad que no implican el uso de unidades IEC. No estás convenciendo a nadie con este juego en el que estás jugando donde bifurcas estas discusiones (que son en gran parte sobre lo mismo ) y luego finge que no ve o elige ignorar las conversaciones que no salen como usted quería. Las unidades IEC no son ampliamente utilizadas por nuestras fuentes confiables, por los medios de comunicación en general, por trabajos académicos o por empresas y fabricantes de la industria. Punto final, fin de la historia. He terminado aquí a menos que alguien además de usted diga algo ni remotamente convincente. - Locke Cole • t • c 08:08, 9 de mayo de 2021 (UTC)
Usted no respondió mi pregunta; ¿Es eso porque las fuentes desambiguan como se afirma? Y no recuerdo haber propuesto un cambio a COMPUNITS; esta discusión trata sobre ambigüedades en la jerarquía de la memoria . Dondervogel 2 ( charla ) 10:15, 9 de mayo de 2021 (UTC)
@ Dondervogel 2 : ¿puedes explicar qué palabras crees que estoy poniendo en tu boca? Presentaste un puñado de trabajos académicos y yo presenté el estándar oficial utilizado para la mayor parte de la producción de memoria de computadora. Ambos tienen niveles similares de complejidad y ambos son igualmente comprensibles (o al menos igualmente difíciles de entender). ¿Por qué aceptarías uno y rechazarías el otro?  Stepho   talk  23:55, 7 de mayo de 2021 (UTC)
Su publicación implica que "espero que el lector no comprenda la fuente de la mayoría de los estándares de memoria de computadora, pero espero que comprenda los trabajos académicos", que no es lo que dije. Mis palabras fueron "No podemos esperar que nuestros lectores estén familiarizados con los estándares JEDEC", lo que significa que si WP decide seguir los estándares JEDEC, WP necesita explicar las implicaciones desambiguando, que no es más de lo que COMPUNITS ya dice. Dondervogel 2 ( charla ) 07:54, 9 de mayo de 2021 (UTC)

Desambiguación en publicaciones científicas sobre SDRAM

Publicaciones científicas que utilizan prefijos IEC
  1. Andersson et al, 2017
  2. Biancolin et al 2019
  3. Carroll y Heiser, 2010
  4. Christmann y otros 2016
  5. Doonan et al 2006
  6. Engel et al, 2019
  7. Floris y otros 2004
  8. Frerking 2018
  9. Fujiwara et al, 2020
  10. Gamess et al 2020
  11. Gilbert 2016
  12. Goossens et al 2016a
  13. Goossens et al 2016b
  14. Gotzhein, 2020
  15. Grant et al 2010
  16. Gruhn y Muller 2013
  17. Heywood 2016
  18. Heinig et al 2013
  19. Heirman et al 2005a
  20. Heirman et al 2005b
  21. Heirman et al 2006
  22. Hirano et al 2017
  23. KARI 2021 (¿en coreano?)
  24. Kim et al 2020
  25. Knight et al 2016
  26. Caballero y Furber 2016
  27. Knight et al 2016
  28. Kokosa 2018
  29. Kurth et al 2016
  30. Lopez 2017 (en español)
  31. Mao et 2014
  32. Michard et al 2013
  33. Muller 2009
  34. Mundy et al 2015
  35. Neider 2011
  36. Park et al 2016
  37. Pedersen 2013
  38. Plefka et al 2011
  39. Rosa 2011
  40. Rowley et al 2019
  41. Sindelar 2012
  42. Smith 2013
  43. Sohn y Sander 2021
  44. Stockel 2015
  45. Sunter et al 2016
  46. Tang & Du 2021
  47. Tervo 2017
  48. Vohnik 2010 (¿en checo?)
  49. Weinert 2007 (en alemán)
  50. Zhou et al 2013
  51. Zhou 2019
  52. Zlatanov 2016
Publicaciones científicas que utilizan otros métodos de desambiguación
Ninguno identificado hasta la fecha
Discusión
Sostengo que las fuentes confiables que desambiguan sobre el tema de SDRAM, lo hacen usando prefijos IEC. ¿Hay contraejemplos? Dondervogel 2 ( charla ) 17:58, 1 de mayo de 2021 (UTC)
No tengo una cuenta IEEE o Springer, por lo que no puedo verificar esos enlaces, pero Carroll y Heiser, 2010 NO se trata de SDRAM. El título del artículo es Análisis del consumo de energía en un teléfono inteligente . Floris et al 2004 , que tampoco es un artículo sobre SDRAM sino que se titula Una nueva tarjeta PCI para lectura en experimentos de física de alta energía , analiza la SDRAM al discutir la tarjeta, pero no elimina la ambigüedad en absoluto. Asimismo, Fujiwara et al, 2020 tampoco es un artículo sobre SDRAM, pero lo menciona de pasada y no desambigua. Sunter et al 2016 , que no sorprenderá a nadie en este momento, TAMBIÉN no se trata de SDRAM. Es un papel tituladoPAYLOAD DE DOBLE CÁMARA para ESEO, que se trata de un sistema de doble cámara para un dispositivo de órbita terrestre baja. Tampoco elimina la ambigüedad como usted afirma (y de hecho no logra eliminar la ambigüedad de una tarjeta microSD que, según el documento, tiene 1 GiB de almacenamiento, lo que sería notable considerando que la mayoría de las tarjetas SD usan 1 GB = mil millones de bytes, y el fabricante anuncia sus tarjetas. como usar GB, no GiB). Esperaré a que alguien con acceso a IEEE y / o Springer confirme esos enlaces, pero no estoy impresionado con lo que estás presentando hasta ahora ... - Locke Cole • t • c 01:48, 3 de mayo de 2021 ( UTC)
Estoy seguro de que lamentaré esto, pero como una polilla a la llama no puedo resistir. Tengo acceso. No lo he estado siguiendo (excepto para agradecer a mis estrellas, no me importa el problema) pero si me dicen exactamente lo que estoy buscando, puedo copiar partes relevantes. E Eng 04:27, 3 de mayo de 2021 (UTC)
como una polilla a la llama que no puedo resistir ; siempre y cuando no se prenda fuego porque aún podría aceptar esa oferta de manguera anterior. Afortunadamente, puedo ver títulos y un resumen de los enlaces Springer / IEEE, por lo que realmente solo necesita ver 1) qué tan prominente es la SDRAM como tema del documento en general (se menciona de pasada como una especificación técnica seca, es SDRAM en sí mismo se analiza con gran detalle, o ...?), 2) ¿el documento utiliza unidades IEC (KiB / kibibyte, MiB / mebibyte, GiB / gibibyte, TiB / tebibyte, etc.) y 3) ¿el documento también utiliza versiones decimales? de las unidades métricas (KB / kilobyte, MB / megabyte, GB / gigabyte, TB / terabyte, etc.). Aquí están los enlaces en forma de tabla, solo complete los espacios en blanco:
EnlaceTítuloAutores1) prominencia SDRAM2) Utiliza unidades IEC3) Utiliza unidades métricas
[4]Dispositivos de procesador LEON para misiones espaciales: primeros 20 años de LEON en el espacioAndersson et al, 2017La totalidad de las referencias a SDRAM, KB, MB, GB, KiB, MiB, GiB, Kbit, Mbit, Gbit son:
  • Controlador de memoria PROM / SRAM / SDRAM ... 32 MiB PROM ... 32 MiB SRAM ... 512 MiB SDRAM ... 192 KiB de RAM en el chip
  • El bus se conecta a una SDRAM externa protegida por EDAC de 2 MiB [cahse] ...
  • con caché de 32 KB ... PROM / SRAM / SDRAM controlador de memoria ... hasta 32 MiB PROM ... 32 MiB SRAM ... 512 MiB SDRAM ... 192 KiB de RAM en el chip
  • con caché de escritura directa de 16 + 16 KiB ... Caché de escritura diferida L2 compartida de 2 MiB ... Interfaz de memoria SDRAM PC100 de datos de 64 bits ... RMAP @ 300 Mbit / s ... Interfaz Ethernet de 10/100/1000 Mbit. .. interfaz de destino a 33 MHz
  • Caché de nivel 2 y / o SDRAM externa.
  • Puertos Ethernet de 10/100/1000 Mbit
  • puertos con RMAP @ 300 Mbit / s ... 2x interfaz Ethernet 10/100/1000 Mbit
  • hasta 300 Mbit / s
  • núcleos de procesador con 32 KB
  • 192 KB de memoria EDAC protegida estrechamente acoplada
  • hasta 16 MB de ROM y 256 MB de SRAM
  • hasta 2,4 Gbit / s

[5]BiPS: un marco de protocolo con capacidad en tiempo real para sistemas de control en red inalámbricos y su aplicaciónEngel et al, 2019Controlador Intel XScale PXA 270 con 256 KiB SRAM, 32 MiB SDRAM y 32 MiB FLASH. Admite frecuencias de reloj de hasta 416 MHz
[6]Aspectos de implementación de ProNet 4.0Gotzhein, 2020Procesador Intel XScale PXA271 con SRAM de 256 KiB, SDRAM de 32 MiB y FLASH de 32 MiB ... velocidades de reloj de hasta 416 MHz ... ejecutado desde SDRAM ... la plataforma ofrece memoria flash de 32 MiB ... proporciona SRAM de 256 KiB y 32 MiB SDRAM ... consumió solo alrededor de 59 KiB ... 59 KiB de memoria estática y 26 KiB dinámica ... necesita al menos 140 KiB estática y 26 KiB dinámica ... consume alrededor de 350 KiB estática y 26 KiB dinámica ...
[7]Una implementación eficiente de SpiNNaker del marco de ingeniería neuronalMundy et al 2015
  • 32 KiB para instrucciones y 64 KiB para datos; y comparte 128 MiB de SDRAM fuera del chip
  • matriz asociada con la neurona de disparo de SDRAM
  • Esto es 8 MiB ya que a cada núcleo se le asigna 1/16 de la SDRAM de 128 MiB.
  • ocupa aproximadamente 2,28 GiB de memoria
  • cada núcleo solo tiene 8 MiB de SDRAM
  • recupera pesos sinápticos de SDRAM
  • requieren la SDRAM de tres chips SpiNNaker
  • 2. 4 MiB para almacenar la matriz de peso completo o 70. 0 KiB cada uno ... (un total de 140. 0 KiB)

Dejé comentarios HTML en el marcado de la tabla para que los complete a su discreción. - Locke Cole • t • c 05:31, 3 de mayo de 2021 (UTC)
¡Me debes una, tío! E Eng 07:42, 3 de mayo de 2021 (UTC)
¡Gracias! =) @ Dondervogel 2 : Todos estos parecen mencionar SDRAM, no artículos sobre SDRAM, y usted parece ser bastante laxo en su evaluación de que "desambiguan", ya que parece que la mayoría solo está usando unidades IEC directamente, con no se utilizan otras unidades de datos (como KB, MB, GB). Un papel que usa MiB y luego MHz no es lo que yo llamaría un ejemplo brillante. Creo que la gran confusión que todos estábamos tratando de resolver es que MB es 1.024 × 1.024 = 1.048.576 o 1.000 × 1.000 = 1.000.000. Dudo mucho que los lectores estén confundidos por MHz y MB / megabyte. - Locke Cole • t • c 16:06, 3 de mayo de 2021 (UTC)
Lo que veo es "512 MiB SDRAM" (Andersson 2017); "32 MiB SDRAM" (Engel 2019 y Gotzheim 2020); "128 MiB SDRAM" (Mundy 2015). Claramente sobre SDRAM y sin ambigüedad. Mencionar la cantidad en MB solo enturbiaría las aguas. Dondervogel 2 ( charla ) 09:57, 30 de mayo de 2021 (UTC)

Unidades IEC en escritos académicos

@ Dondervogel 2 : En User: Thunderbird2 / El caso en contra de la desaprobación de los prefijos IEC , que aparentemente ha actualizado religiosamente a lo largo de los años, hay un enlace de Google Scholars que usa para determinar cuántos artículos están usando unidades IEC. Observo que actualmente para el período 2020-2022 hay 582 hits para MiB / GiB. Esa misma búsqueda realizada con MB / GB devuelve 44,900. Por supuesto, algunos de ellos pueden ser falsos positivos (ya que es más probable que MB / GB aparezcan como iniciales de otros términos), por lo que, para mayor claridad, ejecuté la búsqueda usando mebibytes / gibibytes y megabytes / gigabytes. Hubo 28 aciertos para la unidad IEC y 1,560 para la unidad métrica tradicional.. Parecería, incluso entre los trabajos de investigación, que las unidades IEC constituyen un pequeño fragmento, alrededor del 1,76%. Las unidades métricas representaron el 98,23% de los resultados. Como ya expliqué anteriormente, los medios de comunicación en general no usan las unidades IEC en absoluto, y su uso en círculos académicos parece estar muy superado en número por las unidades métricas tradicionales. - Locke Cole • t • c 16:06, 3 de mayo de 2021 (UTC)

Y solo para continuar con la verificación de cordura "fatberg" desde arriba, arrojó 49 resultados para el mismo período. - Locke Cole • t • c 16:08, 3 de mayo de 2021 (UTC)

Dondervogel 2

Acabo de evitar que Dondervogel 2  ( talk  · contribs ) mueva otra conversación aquí desde Talk: tarjeta SD . ¿Existe algún consenso para tener múltiples discusiones casi idénticas? Cuando comencé esta discusión fue con el objetivo de permitirles ver si pueden convencer a los editores aquí para que cambien WP: COMPUNITSpara permitir un mayor uso de IEC. Dondervogel 2 ha bifurcado esta conversación en discusiones separadas innecesariamente, ya que el problema no es con estos artículos individuales, sino más bien con si las unidades IEC son algo que los editores creen que han llegado a un punto en el que deberían usarse en Wikipedia en general. Después del cierre de AN / EW pensé que podríamos ver una discusión real, pero en cambio veo que Dondervogel ha vuelto a iniciar incendios forestales y tratando de bifurcar estas conversaciones. Entonces, nuevamente: ¿Existe algún consenso para tener múltiples discusiones aquí sobre diferentes artículos? - Locke Cole • t • c 17:08, 3 de mayo de 2021 (UTC)

@ Locke Cole : Existe una regla no escrita de larga data sobre MOSNUM que establece que las discusiones sobre los cambios en MOSNUM se llevan a cabo una vez que se establece la necesidad de la discusión luego de un desacuerdo en las páginas de discusión del artículo. Fue su decisión traer discusiones sobre artículos individuales aquí y nadie se opuso, así que he participado en las discusiones aquí. Pero es importante distinguir entre discusiones sobre cambios en WP: COMPUNITS (aunque no he propuesto ninguno) y discusiones sobre artículos individuales sobre la implementación de COMPUNITS. Es hora de detener el acoso. Dondervogel 2 ( charla ) 17:27, 3 de mayo de 2021 (UTC)
@ Dondervogel 2 : Pero parece estar editando en contra del consenso de larga data aquí que las unidades IEC generalmente no deben usarse. Los métodos para la desambiguación ya existen en COMPUNITS, que usted conoce bien. El hecho de que esté tratando de bifurcar estas discusiones no infunde mucha buena fe en sus acciones. Es hora de que dejes de actuar en contra del consenso aquí y consideres otros usos de tu tiempo. Mi participación en este tema es reciente, donde parece que guardas un rencor muy largo y solo buscas excusas para socavar el lenguaje actual que ha estado aquí. Es perturbador e innecesario. - Locke Cole • t • c 18:16, 3 de mayo de 2021 (UTC)

Pregunta a los editores interesados

¿La discusión sobre los cambios en la tarjeta SD pertenece a la página de discusión del artículo o en MOSNUM? Dondervogel 2 ( charla ) 17:30, 3 de mayo de 2021 (UTC)

Coloque un aviso aquí, pero a menos que desee cambiar algo sobre la directriz, la discusión real estaría mejor en la página de discusión del artículo. Primergrey ( charla ) 17:43, 3 de mayo de 2021 (UTC)
Literalmente, dos administradores te han dicho que este es el mejor lugar para una discusión. Entiendo que prefiere mantener estas discusiones en páginas oscuras lejos de las miradas indiscretas de las personas interesadas en el tema para poder forzar estas unidades durante un largo período, pero ya es suficiente. Deja de hacer incendios forestales. - Locke Cole • t • c 18:30, 3 de mayo de 2021 (UTC)
Usuario: EdJohnston dijo que este sería "el mejor lugar para resolver el problema subyacente", es decir, determinar si un cambio en la directriz es apropiado o no. Si hay debates en varios artículos que se centran todos en la misma guía, entonces un posible cambio en dicha guía solo podría ocurrir aquí. No sabía que esto iba más allá del artículo único, tarjeta SD . Primergrey ( charla ) 21:01, 3 de mayo de 2021 (UTC)
Aquí hay una lista de artículos, plantillas, charlas y otras páginas que tanto Locke Cole como Dondervogel 2 han editado desde el 1 de marzo de 2021. Excluyendo WP: 3RRN y este WT: MOSNUM hay 39, de las cuales todas las que he revisado han involucrado a IEC unidades. Van desde x86-64 hasta WinZip y Template: Cantidades de bytes, pero sí, la tarjeta SD también está ahí. Por supuesto, puede haber disputas similares que involucren solo a uno de esos editores o ninguno, o disputas más antiguas. NebY ( conversación ) 22:42, 3 de mayo de 2021 (UTC)

La comunidad se ha pronunciado sobre este tema. Thunderbird2 fue sin duda el editor más tendencioso que jamás haya experimentado. No sé si el hecho de que hayan pasado los años hace que esta tendenciosidad sea más perdonable o menos. El propósito de una enciclopedia de interés general es comunicarse con claridad. Hay muchas cosas en el mundo que deberían haber tenido mejores convenciones de nomenclatura, como la nebulosa planetaria , que no tienen nada que ver con los planetas, pero una enciclopedia de interés general sigue la corriente y no intenta efectuar cambios en un " Oh, ¿no lo sabías? ”-Modelo usando terminología poco convencional que el 99% de nuestros lectores nunca ha visto antes… todo con la vana esperanza de que de alguna manera nuestro liderazgo pueda alcanzar al resto del mundo.

Como enciclopedia de interés general, Wikipedia sigue las convenciones estándar utilizadas en la mayor parte de la industria informática. La gran mayoría de la industria de las computadoras, incluidos los líderes de la industria de DRAM como Crucial ( aquí ) Micron ( aquí ), utilizan terminología convencional familiar para todos los usuarios de computadoras, desde el aficionado hasta los expertos. Los fabricantes de PC líderes en la industria, como Dell aquí ) y Apple ( aquí ) también utilizan tecnología convencional. Si desea comprar DRAM en un minorista en línea, estos son lo suficientemente inteligentes como para usar terminología convencional ( Amazon, aquí ). El uso de terminología no estándar es confuso y perjudica a nuestros lectores.

¿Por qué incluso estamos debatiendo Thunderbird2 / Dondervogel 2? Está en el jardín izquierdo inclinándose hacia los molinos de viento de tecnología. Tenemos mejores cosas que hacer en la vida que lidiar con los tendenciosos. ¿No tiene Wikipedia un sistema conveniente para decir simplemente “No. Siga adelante"? Greg L ( charla ) 05:50, 4 de mayo de 2021 (UTC)

Dado que las unidades ambiguas crean confusión, todos parecen estar de acuerdo en que la desambiguación es necesaria. La directriz actual permite utilizar unidades IEC para la desambiguación en artículos donde se mezclan ambos significados. Entonces, ¿por qué hay tanto clamor cuando alguien lo hace de esa manera? - Woodstone ( charla ) 07:22, 4 de mayo de 2021 (UTC)
Citándote “Entonces, ¿por qué hay tanto clamor cuando alguien lo hace así?”. Debido a que términos como "gibibits" son tan inusuales y desconocidos, los correctores ortográficos ni siquiera los reconocen. Ni siquiera medio centiuno del mundo usa la terminología. Es obvio. Hemos recorrido este camino hace más de una década y nada ha cambiado. La terminología desconocida simplemente confunde. Greg L ( charla ) 13:42, 4 de mayo de 2021 (UTC)
En el mundo especializado de DRAM y SDRAM, bastantes publicaciones utilizan unidades como GiB. Tanto por fabricantes como por sitios comunitarios. Subestimas el uso en el mundo real. - Woodstone ( charla ) 07:15, 7 de mayo de 2021 (UTC)
@ Woodstone : Subestimas el uso en el mundo real. # Uso de IEC en medios impresos , unidades de # IEC en escritos académicos ; y sobrestima enormemente su uso en el mundo real. - Locke Cole • t • c 07:48, 7 de mayo de 2021 (UTC)
@ Woodstone :, gracias por confirmarlo. Para mí, la discusión comenzó sobre la memoria dinámica sincrónica de acceso aleatorio el 24 de abril con reversiones repetitivas que mencionan WP: MOSNUM, que de hecho eran infundadas. Solo estoy tratando de usar "64 Gibit RAM" en lugar de torpe "~ 68.719 Gbit RAM" o torpe "64 Gbit RAM (aquí, G significa 1024 ^ 3)" cuando se requieren prefijos mixtos en un artículo y no hay una preferencia clara para cualquier variante. - Zac67 ( conversación ) 10:07, 4 de mayo de 2021 (UTC)
A juzgar por los reposnes de Primergrey y Locke Cole , el consenso parece ser que la discusión sobre la tarjeta SD debería tener lugar en WT: MOSNUM . Dondervogel 2 ( charla ) 08:14, 4 de mayo de 2021 (UTC)
Pero, ¿"64 Gbit RAM" usa G para significar 1024 ^ 3 o lo usa para significar 1000 ^ 3 y simplemente no es exacto? - Khajidha ( conversación ) 13:10, 4 de mayo de 2021 (UTC)
Veo que una chispa brillante ha declarado que gigabit es 10 9 a pesar de que su uso prácticamente universal significa 2 30 (1024 3 ). ¿ No se aplica wp: nombre común ? ¿Alguien en alguna parte usa gibibit con la cara seria? - John Maynard Friedman ( charla ) 13:59, 4 de mayo de 2021 (UTC)
Generalmente para cualquier unidad X, un gigaX es igual a 10 9 X. No es sorprendente que hacer una excepción para X = bit o X = byte cause confusión, especialmente porque incluso para esas unidades a menudo se usa para significar solo 10 9 como bien. La desambiguación es definitivamente lo correcto. Los círculos profesionales usan GiB y Gibit para el caso binario y esto parece una forma perfectamente aceptable de eliminar la ambigüedad del uso. - Woodstone ( conversación ) 15:12, 4 de mayo de 2021 (UTC)
@ John Maynard Friedman : El problema general es que el significado de "Gbit" depende del contexto. Por lo general, "Gbit" significa 1000 3 bits. En casos especiales como la capacidad de memoria, el tamaño de los chips, etc., significa 1024 3 bits, para aquellos que lo saben. Dado que tenemos una audiencia un poco más amplia, WP: MOSNUM razonablemente requiere que desambigüemos. La disputa actual es sobre si está bien usar "64 Gibit" en los casos en que se usan prefijos mixtos dentro de una página y no hay una preferencia clara (como en SDRAM ) (como creo que es claramente un mandato de MOSNUM), o si la desambiguación requiere torpe (en mi humilde opinión) notas a pie de página o similares. - Zac67 ( hablar ) 16:13, 4 de mayo de 2021 (UTC)
¿Puede explicar las unidades de #IEC en escritos académicos , arriba? Casi el 99% de los escritos académicos utilizan las unidades métricas. Los profesionales usan las unidades métricas (vea cualquier cosa, desde hojas de datos hasta notas técnicas y el empaque de productos fabricados profesionalmente como discos duros, memoria o SSD). Diez años después de la última vez que se discutió seriamente sobre esto y el uso ni siquiera ha movido la aguja, pero ¿cree que esto significa que deberíamos incluirlo en una enciclopedia? - Locke Cole • t • c 15:26, 4 de mayo de 2021 (UTC)
@ Locke Cole : Solo teníamos que preocuparnos por los escritos académicos, las hojas de datos, los comités de la industria o el uso de los líderes si era necesario cambiar WP: MOSNUM . No lo hay. La política está bien porque permite prefijos en casos especiales y razonables. Por lo tanto, deje de revertir las ediciones realizadas en esos casos, de conformidad con MOSNUM. (En caso de que esté todavía se pregunta, estoy no pidiendo el uso de prefijos IEC para cifras arbitrarias como () capacidades visibles para el usuario de las unidades de disco o tarjetas de memoria.) - Zac67 ( talk ) 16:13 4 de mayo 2021 (UTC)
@ Zac67 : Si sus ediciones siguen a COMPUNITS, siga lo que dicen nuestras fuentes y, de lo contrario, no son una investigación original , no tiene nada que temer de mí. Hasta la fecha, no se ha demostrado que ninguna fuente de SDRAM contenga unidades IEC o derivados. - Locke Cole • t • c 19:27, 4 de mayo de 2021 (UTC)
¿Por qué debería importar lo que utilicen las fuentes? No hay obligación de ubicar tales fuentes en WP: MOSNUM , es solo uno de los casos. - Zac67 ( conversación ) 19:36, 4 de mayo de 2021 (UTC)
WP: V y WP: NPOV me vienen a la mente. Sin embargo, realmente espero que estés bromeando con esa pregunta. - Locke Cole • t • c 19:57, 4 de mayo de 2021 (UTC)
Locke, las "unidades basadas en fuentes" se convirtieron en un anatema aquí después de que los editores fueron (acusados ​​de) elegir fuentes solo para que pudieran, por ejemplo, mostrar las alturas de los futbolistas en metros. En realidad. Fue parte de un largo conflicto sobre la estandarización de Wikipedia en unidades métricas y se puso feo. Usamos fuentes, otras guías de estilo, etc. cuando pensamos en lo que debería decir MOSNUM, y si estamos convirtiendo entre unidades en un artículo, debemos asegurarnos de que entendemos qué unidades están usando las fuentes, pero hay razones más allá de la Pregunta de IEC no permitir que una referencia determine las unidades utilizadas en un artículo. NebY ( charla ) 20:14, 4 de mayo de 2021 (UTC)
Y, sin embargo, COMPUNITS tiene actualmente cuando la mayoría de las fuentes citadas sobre el tema del artículo usan prefijos IEC; como una de las razones por las que se podría concebir el uso de unidades IEC. Lo que creo que es razonable, pero al final, es solo una forma diferente de abordar WP: V y WP: NPOV (específicamente, WP: UNDUE ). Y dados los datos que he presentado anteriormente, parece haber muy poco uso de unidades IEC en comparación con las unidades métricas tradicionales para los artículos de computación, por lo que realmente debería ser un punto discutible. Pero, aquí estamos ... - Locke Cole • t • c 20:53, 4 de mayo de 2021 (UTC)
cuando la mayoría de las fuentes citadas sobre el tema del artículo usan prefijos IEC se ve bien, pero me temo que se está exagerando demasiado. Por ejemplo, si la mayoría de las fuentes en RAM usaban prefijos IEC, eso podría justificar el uso de prefijos IEC en un artículo sobre RAM. Pero he encontrado prefijos IEC que se utilizan en artículos sobre iPads para decir cuánta RAM tienen. Hay 87 referencias para iPad 2 . No los he verificado todos, pero, francamente, si alguien quiere hacer la extraordinaria afirmación de que la mayoría de ellos usa prefijos IEC, debe presentar la prueba extraordinaria.
El problema con ese enfoque es que puede significar una guerra artículo por artículo que no termina realmente hasta que alguien sea sancionado. Me temo que COMPUNITS podría tener que ser más específico, por ejemplo, especificando con precisión qué familia de artículos usa prefijos IEC. NebY ( conversación ) 21:42, 4 de mayo de 2021 (UTC)

Estoy totalmente de acuerdo con lo que escribió NebY . Hablar simplemente sobre DRAM de "64 MB" en un artículo que también trata sobre los tamaños de los discos duros no significa ...

A) requieren necesariamente una aclaración de que las dos medidas son en realidad ligeramente diferentes, y
B) incluso si la aclaración fuera realmente necesaria, la necesidad de señalar la diferencia en el tamaño exacto de las dos medidas no requiere el uso de unidades extrañas que la gran mayoría de la industria de la computación ha ignorado, está ignorando y probablemente continuará ignorar.

En su mayor parte, basta con escribir simplemente que la computadora XYZ de Alpha tenía 4 GB de RAM y un disco duro de 1 TB, pero su computadora XYZ-8 tenía 8 GB de RAM. En la mayoría de los casos, el lector solo necesita saber, y solo quiere saber, que el XYZ-8 tiene el doble de RAM.

Es un caso raro que la mera mención de ambos atributos dentro de un artículo requiera "desambiguación", que a menudo en realidad solo significa "explicar la pequeña diferencia en la magnitud real". Un ejemplo que viene rápidamente a la mente es cuando uno está escribiendo sobre detalles técnicos muy misteriosos relacionados con el intercambio de datos dentro y fuera de un disco RAM . E incluso entonces , se pueden dejar perfectamente claros los detalles técnicos utilizando unidades de medida convencionales que se utilizan comúnmente en la industria informática y con las que 999 miliuno de nuestros lectores están perfectamente familiarizados.

Una buena redacción técnica es aquella que es adecuada para su público objetivo, informa y educa rápidamente, lo hace con facilidad y proporciona una experiencia agradable, y lo hace sin llamar la atención sobre sí mismo. Greg L ( charla ) 02:14, 5 de mayo de 2021 (UTC)

@ Greg L : Entonces, ¿esencialmente propones ignorar la ambigüedad y usar 1 TB de RAM (lo que implica 1024 4 ) y 1 TB HDD (que implica 1000 4 ) uno al lado del otro? Eso sí, el error "pequeño" es aproximadamente del 10% (1.024 4 ); la desviación ha crecido bastante desde que usamos kilobytes y no se detendrá allí. Además, esa ambigüedad ignora totalmente . No asuma que el significado binario o decimal de los prefijos será obvio para todos. - Zac67 ( charla ) 05:11, 5 de mayo de 2021 (UTC)
@ Zac67 : ¿En serio? ¿¿Seriamente?? Entonces, dime ... qué parte de mi publicación del 02:14, 5 de mayo de 2021 sugirió que cualquier wikipedista responsable debería ignorar una ambigüedad que (legítimamente) requiere una aclaración (en la medida en que 64 GB de DRAM frente a lo mismo en el espacio del disco duro) ? No podría haber sido más claro. Si no te vas a molestar en leer las publicaciones de otros y disparar tergiversaciones de lo que escribieron, ¿cómo puedes esperar que alguien te tome en serio?
En primer lugar, como otros escribieron aquí, las “ambigüedades” por las que profesa estar profundamente preocupado por lo general no necesitan ser aclaradas; la acusación de que sí parecen ser fachadas lógicas diseñadas para disfrazar una agenda de edición persistente contra el consenso y burlar una política MOSNUM clara y bien elaborada que tiene mucho sentido, va en contra de fuentes de medios confiables y va en contra de la computadora convencional industria. Su posición parece estar basada en la premisa errónea de que nuestra adopción aquí resultará en El mundo que sigue el gran liderazgo de Wikipedia hacia un nuevo mañana donde prevalecen la claridad lógica y los bienes científicos © ™ ® . Es una quimera. Lo probamos hace diez años (o algo así) y Wikipedia parecía una tontería por haberlo hecho. Nadie lo siguió.
Y en segundo lugar, siempre que exista una necesidad genuina de aclaración, uno puede hacerlo sin usar los extravagantes gigiagigibits de Porky Pig que nuestros lectores no reconocen y tendrían miedo de repetir en el mundo real por temor a que se rían de ellos. Siempre que la industria de la computación convencional percibe la necesidad de aclarar, se las arregla para llevar a cabo la tarea utilizando terminología convencional con la que todos están familiarizados. Greg L ( charla ) 00:48, 6 de mayo de 2021 (UTC)
Wikipedia tiene como objetivo brindar a los lectores información que sea accesible y fácil de contextualizar, sin hacerlos tropezar. Usamos nombres comunes y unidades comunes, tratamos de no ser obstructivamente precisos y tratamos de aceptar que no es nuestra misión ordenar el mundo y corregir todos sus errores.
Los lectores están familiarizados con la memoria que viene en grupos de 1, 2, 4, 8 ... GB. Lo entienden en términos de funcionalidad y facilidad de uso, y lo contextualizan al verlo expresado de la misma manera en las páginas de ventas, en los medios populares y en Wikipedia. No están tratando de calcular cuántas veces la memoria podría almacenarse en un almacenamiento de 16, 32, 64, 128, 256 ... GB. No les ayuda que les digan que algo tiene 0,96 GiB, entre paréntesis o no; eso solo hace que los lectores tropiecen.
Decirle a los lectores que WinZip pasó la barrera de los 4 gibibytes es demasiado técnico y sin valores similares para el contexto es potencialmente muy confuso: ¿tiene algo que ver con la diferencia entre bits y bytes, es un gibi un giga-giga? No puede ser básicamente lo mismo que 4 gigabytes o, de lo contrario, Wikipedia habría dicho 4 gigabytes en su lugar, ¿verdad? "Desambiguar" complica. Nuestros lectores conocen la diferencia entre 2 y 4 y pueden distinguir K, M y G, y eso debería ser suficiente.
Por supuesto, los editores también importan. Nos gustaría que los lectores encontraran un grado de coherencia y comparabilidad entre los artículos de Wikipedia, desde iPad Pro (cuarta generación) hasta Samsung Galaxy S8 y Surface Pro 6 , pero eso necesita que los editores estén a bordo. Si usted o Dondervogel 2 comienzan a convertir cada artículo, a menudo se revertirá. Si contrarrevierte explicando que es por el MOS, tendremos más editores apareciendo aquí para cambiar el MOS y hacer que exprese el consenso de manera más estricta. Lamentablemente, también tendremos más editores pensando que el MOS es totalmente basura y es mejor ignorar, WP: pavo real y WP: COMPUNITS por igual, y nuestros lectores van a sufrir. NebY ( charla ) 16:06, 5 de mayo de 2021 (UTC)

ejemplos

Aquí hay algunos ejemplos de las consecuencias para nuestros artículos, para aquellos de nosotros que nos resulta más fácil comparar ejemplos directamente en lugar de seguir un mar de enlaces. Son de versiones recientes de una selección bastante aleatoria de artículos de esta lista de interacción . Estos pueden no representar los mejores esfuerzos de los editores, por supuesto.

Artículoprefiriendo unidades IECno preferir las unidades IEC
X86-64Esto permite hasta 256 TiB (2 48 bytes ) de espacio de direcciones virtuales.

... esto permitiría direccionar hasta 4 PiB de RAM.

etc

Esto permite hasta 256 TB (2 48 bytes ) de espacio de direcciones virtuales.

... esto permitiría direccionar hasta 4 PB de RAM

WinZipA partir de WinZip 9.0, los archivos ZIP64 son compatibles, eliminando ... el límite de tamaño de 4 gibibytes

[única instancia en este artículo]

A partir de WinZip 9.0, los archivos ZIP64 son compatibles, eliminando ... el límite de tamaño de 4 gigabytes
tarjeta SDEl formato admite tarjetas de hasta 128 TiB o 140,737488355328 TB o 140737488355328 bytes (SI) o 154742504910672,534362390528 (Binario) y ofrece

... admite tarjetas de hasta 2 TiB (2199023255552 bytes)

... pero requiere el uso de clústeres de 64 KiB

etc

El formato admite tarjetas de hasta 128 TB y ofrece

... admite tarjetas de hasta 2 TB (2199023255552 bytes) ..

... pero requiere el uso de clústeres de 64 KB

IPad Pro (cuarta generación)[infobox] Memoria RAM de 6 GiB

... la RAM se incrementó de 4 a 6 GiB en los modelos de 128 GB, 256 GB y 512 GB

etc

Memoria 6 GB de RAM

.... la RAM se incrementó de 4 a 6 GB (4-6 GiB ) en los modelos de 128 GB, 256 GB y 512 GB

Memoria dinámica sincrónica de acceso aleatorioComo referencia, una fila de un dispositivo DDR3 de 1 Gibit tiene 2048 bits de ancho

etc

Como referencia, una fila de un dispositivo DDR3 de 1 Gbit [1] tiene 2048 bits de ancho

Referencias

  1. ^ Aquí, K , M , G o T se refieren a los prefijos binarios basados ​​en potencias de 1024.


Plantilla: Cantidades de bytes

Consulte la discusión en Template_talk: Quantities_of_bytes # Recent_Edit_to_Table

En la página de discusión para Plantilla: Cantidades de bytes  ( editar | hablar | historial | enlaces | ver | registros ) en la sección Edición reciente de la tabla, la discusión de alguna manera ha cambiado a cómo se les da un peso indebido a las unidades de memoria JEDECen la plantilla (a pesar de la presencia de unidades de IEC que, como se muestra arriba en los medios y el uso académico, son básicamente inexistentes en las fuentes o en los medios de comunicación en general). Los editores interesados ​​pueden querer intervenir allí; Inicialmente no moví la discusión aquí porque comenzó de manera bastante inocente como una discusión sobre si el terabyte JEDEC debería o no estar en la mesa, pero ahora la discusión ha dado un giro sobre si las unidades JEDEC pertenecen o no ... Personalmente, soy de la opinión de que las unidades IEC son las que reciben un peso indebido, y estamos impulsando efectivamente una teoría marginal incluso dándoles tanta vida fuera de los artículos de las normas IEC, pero más opiniones serían apreciado. - Locke Cole • t • c 16:42, 5 de mayo de 2021 (UTC)

tarjeta SD

¿Por qué las capacidades en las descripciones en miniatura se dan en potencias de 1000 (o 10 x donde x es un int), por ejemplo, MB, GB, TB, mientras que en otros lugares están en potencias de 1024 (o 2 x donde x% 10 = 0) , por ejemplo, MiB, GiB, TiB? Me preocupa porque a medida que aumentan las capacidades, especialmente para TB frente a TiB y PB frente a PiB , la diferencia en bytes es enorme.

Inconformidades destacadas de los poderes de 1000 y 1024, en la revisión https://en.wikipedia.org/w/index.php?title=SD_card&oldid=957885871

Fezzy1347 ( charla ) 17:12, 25 de mayo de 2020 (UTC)

Buena pregunta. Mi entendimiento (limitado) es que las capacidades máximas son binarias (ver exFAT ), pero que las capacidades publicadas son decimales. Dondervogel 2 ( charla ) 19:27, 25 de mayo de 2020 (UTC)
Como señaló Fezzy1347, la diferencia es importante. De ahí la reversión. Dondervogel 2 ( charla ) 10:14, 3 de mayo de 2021 (UTC)
@ Fezzy1347 : @ Locke Cole : esta edición introdujo ambigüedad en el artículo que no estaba presente anteriormente (por ejemplo, en el significado de "TB"). Lo revirtí porque WP: COMPUNITS requiere la desambiguación , pero mi edición se revirtió posteriormente , reintroduciendo la ambigüedad. La pregunta ahora es cómo eliminar esa ambigüedad. Dondervogel 2 ( charla ) 21:18, 11 de mayo de 2021 (UTC)
Permítanme señalar un ejemplo del problema que veo. Cerca del comienzo del artículo, "GB" se usa en sentido decimal (p. Ej., "Formato en exceso de 2 GB (2000 MB)", mientras que más adelante se implica un significado binario (p. Ej., "Hasta 32 GB (34359738368 bytes) ) "), lo que hace imposible que el lector sepa qué significado se pretende en casos específicos, lo que contraviene COMPUNITS. No me sorprendería encontrar problemas similares con MB y TB, pero en situaciones como esta, encuentro útil centrarme inicialmente en un problema específico. De lejos, la solución más simple es hacer explícitos los significados decimal y binario. ¿Alguien tiene una contrapropuesta? Dondervogel 2 ( charla ) 08:51, 14 de mayo de 2021 (UTC)
Este uso ambiguo está muy extendido en la industria, lo que hace que muchas fuentes poco fiables no sean fiables. Honestamente, está haciendo un King Canuto para afirmar que MB / GB / TB, etc.siempre y solo significa ^ 10 y que 'personas' deberían usar MiB / GiB / TiB cuando se refieren a ^ 2. No sucede en el mundo real. Las ventas continuarán usando 10 ^ y la ingeniería continuará usando 2 ^. Y las ventas usarán 'B' para bits y la ingeniería usará 'b'. La notación GiB nunca ha ganado aceptación y Wikipedia no puede asumir que los lectores (y muchos editores) la hayan visto alguna vez, y mucho menos saber lo que significa. Por tanto, la MOS debe exigir que los artículos indiquen explícitamente el significado que se pretende cuando se utilizan estas abreviaturas. - John Maynard Friedman ( charla ) 09:43, 14 de mayo de 2021 (UTC)
No estoy de acuerdo con su premisa de que una enciclopedia no puede explicar las cosas ( de hecho, creo que ese es el propósito de una enciclopedia ), pero creo que COMPUNITS ya dice lo que usted sugiere que debería decir. ¿Tiene una propuesta para adecuar el artículo a COMPUNITS? Dondervogel 2 ( charla ) 10:37, 14 de mayo de 2021 (UTC)
No, esa no es mi premisa. Una enciclopedia, como un diccionario, registra lo que es, no lo que debería ser. De lo contrario, nos lleva a wp: corregir grandes errores . Entonces, la política relevante es MOS: Abreviaturas : los iniciales siempre deben escribirse y eliminarse la ambigüedad si es necesario, en el primer uso. Entonces, si se describe una tarjeta SD con una capacidad de 1GB o 1 gigabyte, entonces, por COMPUNITS, el artículo debe especificar si "giga" significa 10 9 o 2 30. Supongo que una nota al pie podría ser apropiada para explicar las notaciones y hacer referencia al estilo preferido de las "instituciones educadas", pero NO ES DEBIDO insertar una mini-conferencia en línea en cada artículo.
De todos modos, para volver a su, permítanme señalar un ejemplo del problema que veo. El caso que cita es un flagrante fracaso de wp: piense en el lector . Cualquier artículo debe usar las iniciales con un solo y un solo significado en todas partes. (En mi opinión, también debería tener una nota de comentario que aconseje a los futuros editores de esa elección; estoy pensando en algo como {{ usar fechas DMY }}.) En el caso excepcional en el que se necesitan ambos significados, entonces será necesario usar ( y explicar) la notación MiB / GiB, etc. - John Maynard Friedman ( charla ) 16:30, 14 de mayo de 2021 (UTC)
Sentencia golpeada porque veo que COMPUNITS ha desaprobado la notación MiB. (Lo apruebo). Por tanto, se necesita una exponenciación explícita para los casos excepcionales. - John Maynard Friedman ( charla ) 16:39, 14 de mayo de 2021 (UTC)
¿Sugiere que cada aparición de 'GB' se reemplace por uno de 'GB (1000 3 B)' o 'GB (1024 3 B)', según corresponda? Dondervogel 2 ( charla ) 17:15, 14 de mayo de 2021 (UTC)
No estoy exactamente seguro de por qué estamos discutiendo esto aquí. Lo que sucede en el artículo de la tarjeta SD debe resolverse en la charla: tarjeta SD . Su 'un ejemplo del problema' es solo un ejemplo de edición deficiente en ese artículo: no veo un problema general que deba escalar a la página de discusión de MOS. No entiendo por qué la discusión se cerró de manera tan perentoria. ¿Claramente hay una historia en esto?
(Pero por si sirve de algo, sugiero que los artículos deben usar un significado u otro, dejar en claro desde el principio qué elección se ha hecho, y solo en circunstancias excepcionales se debe usar la misma abreviatura (o nombre) para significa dos cosas diferentes. IFF que es inevitable, sí, cada instancia necesita una calificación entre paréntesis.) - John Maynard Friedman ( charla ) 19:40, 14 de mayo de 2021 (UTC)
Dondervogel 2 prefiere usar los prefijos IEC oscuros y generalmente no utilizados. Desean operar en contra del consenso de larga data en WP: COMPUNITS . Si quieren usar unidades IEC, este es el lugar correcto para tener esa discusión. Si quieren discutir desviarse de los métodos sugeridos de desambiguación en COMPUNITS, entonces esta parece ser la mejor opción (ya que su método de desambiguación parece implicar el uso de unidades IEC que COMPUNITS dice explícitamente que "generalmente no se deben usar"). Si se han alejado de esa posición, no me importa dónde tengan la discusión. - Locke Cole • t • c 19:45, 14 de mayo de 2021 (UTC)
@ John Maynard Friedman : Creo que el mejor lugar para mantener la discusión sobre la tarjeta SD es en la página de discusión del artículo. Sin embargo, Locke Cole cerró una discusión en curso sobre la tarjeta SD y cuando le pregunté dónde debería llevarse a cabo, tanto Locke Cole como Primergrey prefirieron hacerlo aquí. Locke Cole es parece estar ahora de nuevo de seguimiento y afirma que no le importa donde se celebra la discusión. Dejemos ahora de debatir dónde debería realizarse y centrémonos en MEJORAR el artículo. Dondervogel 2 ( charla ) 20:58, 14 de mayo de 2021 (UTC)
@ John Maynard Friedman : Estoy de acuerdo en que el significado no debería cambiar dentro de un artículo, así que el truco es elegir uno y mantener ese significado en todo momento. El artículo comienza con GB decimal y luego cambia a binario, y luego cambia de un lado a otro como un yo-yo, creando un lío incomprensible. ¿Deberíamos elegir el significado decimal o el binario? Dondervogel 2 ( charla ) 21:08, 14 de mayo de 2021 (UTC)
Locke Cole ahora está retrocediendo y afirma que no le importa dónde se lleva a cabo la discusión ; yo no he hecho tal cosa. Deja de mentir. - Locke Cole • t • c 21:16, 14 de mayo de 2021 (UTC)
He reformulado mi publicación (de "es" a "parece ser") para aclarar que esa fue la impresión que dio. Acepto que podría haber tenido una intención diferente. Lea WP: AGF y WP: CIVIL y evite los ataques personales . Dondervogel 2 ( charla ) 21:31, 14 de mayo de 2021 (UTC)
Locke Cole dijo "si te has movido de esa posición entonces ..." así que parece que estás eligiendo convenientemente la segunda parte de su oración porque eso es lo que te conviene. Tensa AGF cuando haces ese tipo de cosas.
Así que déjame ser claro: justo al principio de esto dije que la notación GiB nunca ha ganado aceptación y Wikipedia no puede asumir que los lectores (y muchos editores) la hayan visto alguna vez, y mucho menos saber lo que significa. Esa sigue siendo mi posición. Esta notación no resuelve su ejemplo del problema porque los lectores no sabrán lo que significa, al igual que si hubiera sugerido que usemos el carácter chino. La única solución práctica es deletrear las abreviaturas claramente: si nos referimos a 1.073.741.824, entonces eso es lo que deberíamos decir. Lo que no debemos hacer en el mismo artículo es que GB signifique 10 9 en una oración y 2 30 en la siguiente oración. - John Maynard Friedman ( charla) 23:22, 14 de mayo de 2021 (UTC)

Este es el lugar correcto para discutirlo. Es un problema que surge en muchos artículos relacionados con la informática, por lo que resolverlo en la página de discusión de un solo artículo lo convertirá en una discusión que debe repetirse para todos y cada uno de los artículos, ¡qué pérdida de tiempo!

Para resumir el problema (usando GB en los ejemplos pero también aplicando a los otros prefijos): algunos usos de GB (giga bytes) significan 10 ^ 9 y algunos significan 2 ^ 30. Algunos editores prefieren:

  • Elimínelos mediante el uso de prefijos IEC como Gibi-. Pero estos no han logrado ganar tracción en la industria o los medios populares y permanecen relegados a algunas partes de la academia.
  • Elimine las ambigüedades mediante notas entre paréntesis o notas al pie. Funciona pero es repetitivo y tiende a desordenar los artículos.
  • No les quite la ambigüedad en absoluto. Deja el artículo limpio, pero algunos lectores se sentirán confundidos sobre cuándo usar 10 ^ 9 o 2 ^ 30.

La breve explicación es que la memoria es directamente direccionable por la CPU (por ejemplo, RAM, ROM) usa potencias de 2 mientras que prácticamente todo lo demás usa potencias de 10 (por ejemplo, discos duros, memorias USB y cualquier cosa que tenga que ver con tasas o tiempo). Es la parte directamente direccionable la que es crítica. Para RAM o ROM, la CPU debe proporcionar un cierto número de líneas de direcciones binarias, por lo que el tamaño debeser una potencia de 2. Para dispositivos que tienen algún tipo de interfaz (por ejemplo, IDE / PATA, SATA, USB), la dirección se envía como un número dentro de un comando. El dispositivo remoto tiene la libertad de reasignar esa dirección de la forma que le parezca adecuada (por ejemplo, los discos duros asignaron una única dirección al cilindro, cabezal, sector y los números de CHS generalmente no eran potencias de 2), por lo que la dirección no está limitada a poderes de 2. Esto es anecdótico pero basado en mis 3-4 décadas de experiencia profesional diseñando / programando computadoras.

Tratar de explicar para explicar esto en cada artículo de computadora simplemente desordenará todos los artículos. En cambio, sugiero que la mayoría de los artículos se dejen en el estado ambiguo. Después de todo, a la mayoría de los lectores realmente no les importa una diferencia del 7%; la mayoría de los lectores ni siquiera saben o no les importa cuánta RAM tiene su PC o teléfono, solo que tiene suficiente. Las personas que se preocupan tienden a saber ya cuándo usar 10 ^ 9 o 2 ^ 30. Pero algunos artículos que cubren un tema amplio como RAM , disco duro o tarjeta SD pueden detallar la forma apropiada (o formas si necesita especificar la capacidad en potencias de 2 y tasas en potencias de 10).  Stepho   talk  01:54, 15 de mayo de 2021 (UTC)

Después de un par de intentos fallidos (GB y TB), decidí usar MB como conejillo de indias. Por lo que puedo decir, se usa principalmente en el sentido decimal, y ya había una declaración en ese sentido cerca del principio, que ahora he calificado porque hay excepciones. También he etiquetado las excepciones. ¿Tiene sentido así para MB? Dondervogel 2 ( charla ) 08:47, 15 de mayo de 2021 (UTC)
Al no escuchar ninguna reacción, probé KB (solo uso binario) y GB (uso mixto) también. Eso todavía deja TB. Dondervogel 2 ( charla ) 16:36, 15 de mayo de 2021 (UTC)
Y ahora TB también. Aunque creo que es complicado. Dondervogel 2 ( charla ) 17:15, 15 de mayo de 2021 (UTC)

¿Cuál es la verdadera capacidad de almacenamiento formateada de un iPhone, iPad o iPod?

Este artículo del editor de Macworld explica la capacidad de almacenamiento de iPhones, iPads e iPods, y conduce con "¿Cuál es la verdadera capacidad de almacenamiento formateada de un iPhone, iPad o iPod? ¿Cuántas canciones, películas, aplicaciones y juegos pueden contener?" ¿Y por qué la capacidad real es inferior a la anunciada? ". Para aclararse, el autor usa GB para significar 1000 ^ 3 B y GiB para significar 1024 ^ 3 B. La introducción al artículo dice

  • "Antes de comenzar, aquí están las capacidades informadas que hemos estado viendo para cada uno de los cuatro niveles de almacenamiento actuales para dispositivos iOS. Tenga en cuenta que son aproximadas (hemos visto algunas variaciones entre modelos y versiones de iOS), pero Dé una idea del déficit que debe esperar de la capacidad de almacenamiento anunciada.
 128 GB: aprox. 114GiB 64 GB: aprox. 56,5 GiB 32 GB: aprox. 27,5 GiB 16 GB: aprox. 11,5 GiB
  • Notarás que he usado la unidad 'GiB', o gibibyte, aunque iTunes claramente usa la unidad GB. Explicaré por qué es así y la diferencia entre los dos en la siguiente sección ".

El artículo fue citado en varios artículos de Wikipedia, pero parece haber sido eliminado. Sugiero restablecer la referencia porque ayuda a explicar la capacidad de almacenamiento en un idioma que los lectores de WP puedan entender. Dondervogel 2 ( charla ) 08:19, 30 de mayo de 2021 (UTC)

A falta de respuesta, agregué algunos comentarios en este sentido en iPhone , iPad Pro , iPad Air y iPad mini . Sería útil realizar ediciones similares en el iPad mini 2 y el iPod touch . Dondervogel 2 ( charla ) 15:23, 9 de junio de 2021 (UTC)
Parece que mis cambios propuestos en iPad Pro , iPad Air , iPad Mini , iPad Mini 2 y iPod Touch se han revertido iPad Pro , iPad Air , iPad Mini , iPad Mini 2 , iPod Touch , con un resumen de edición que sugiere que los artículos se estaban trayendo “De conformidad con WP: COMPUNITS ”. Quizás los artículos ahora sean compatibles con COMPUNITS (no lo he verificado), pero la razón para plantear esto aquí es que la información sobre la capacidad de disponibilidad se eliminó sin explicación. La redacción en iPad Pro fue
  • “Las capacidades de almacenamiento anunciadas son 32, 64, 128, 256, 512, 1000 o 2000 GB . Las capacidades de almacenamiento reales de los modelos de 32 y 128 GB son 29,5 GB (27,5 GiB ) y 122,4 GB (114 GiB), respectivamente. [1] "
Ahora sugiero restablecer la información eliminada. Se invita a propuestas alternativas o sugerencias con redacción alternativa. Dondervogel 2 ( charla ) 00:09, 20 de junio de 2021 (UTC)
sí. Debemos ser precisos sobre el hecho de que las capacidades anunciadas no tienen en cuenta el sistema operativo y el bloatware preinstalado (generalmente no desinstalable) que aumenta con cada generación sucesiva. Estamos aquí para ayudar al lector, no a los fabricantes / anunciantes de dispositivos. Sin embargo, use palabras más claras, como "Las capacidades de almacenamiento anunciadas son ... Las capacidades utilizables, menos el SO y otro software preinstalado, son ..., respectivamente".  -  SMcCandlish ☏ ¢  😼  00:25, 20 de junio de 2021 (UTC)

Es una tontería tratar de precisar el tamaño exacto. ¿Qué talla buscas?

  • el número exacto de bytes en los chips flash? Entonces alguien lo demandará porque prometió X bytes, pero algunos de ellos están ocupados por archivos para el sistema operativo, aplicaciones incorporadas, etc. y no están disponibles para el usuario.
  • el número exacto de bytes no utilizados para almacenar archivos para el sistema operativo, aplicaciones integradas, etc. ¿Restamos los gastos generales por la información del directorio (fecha de creación, autor, etc.)? ¿Restamos los gastos generales para cosas como la tabla FAT? ¿Restamos los sectores de arranque?
  • el número exacto disponible para el usuario. Pero debido a problemas de tamaño del clúster , los archivos de diferentes tamaños desperdician espacio al final de cada clúster en diferentes proporciones. Con un tamaño de clúster de 4096 bytes, un millón de archivos ocupan 4.096.000.000 bytes de espacio de archivo (y más para información de directorio). Pero un millón de archivos de 4096 bytes ocupan exactamente el mismo espacio.

En su mayor parte, al usuario no le importa el número exacto, siempre que esté en el parque de pelota.  Stepho   talk  02:43, 20 de junio de 2021 (UTC)

Solo podemos guiarnos por lo que nos dicen las fuentes. En este caso, la fuente explica que el motivo principal de la discrepancia entre "128 GB" (capacidad comercializada) y "114 GB" (capacidad informada) es que la capacidad anunciada está en gigabytes (GB) mientras que la capacidad informada está en gibibytes ( GiB), siendo la conversión 128 GB = 119,2 GiB. La diferencia restante (entre 119,2 GiB y 114 GiB) se atribuye al "software del sistema operativo IOS y las aplicaciones ... preinstaladas que Apple coloca en su dispositivo ...". Teniendo todo esto en cuenta, sugiero:
"Las capacidades de almacenamiento anunciadas son 32, 64, 128, 256, 512, 1000 o 2000 GB . Las capacidades de almacenamiento informadas por el dispositivo son menores que esto, por dos razones. La razón principal es que las capacidades anunciadas están en gigabytes , mientras que las capacidades informadas por el sistema operativo en gibibytes . Un gibibyte (1 GiB) es aproximadamente un 7% más grande que un gigabyte (1 GB), por lo que para una capacidad de almacenamiento fija, el "número" de gibibytes es aproximadamente un 7% menor. Por ejemplo, 128 GB es aproximadamente 119 GiB, y si los 128 gigabytes estuvieran disponibles para almacenamiento, el sistema operativo lo informaría como "119 GB". Para el mismo modelo, el sistema operativo y las aplicaciones preinstaladas ocupan otros 5 GiB, dejando 114 GiB, que se informa como "114 GB".[2] "
Dondervogel 2 ( charla ) 16:51, 21 de junio de 2021 (UTC)
No. - Locke Cole • t • c 05:57, 22 de junio de 2021 (UTC)
@ SMcCandlish : @ Stepho-wrs : ¿Está de acuerdo con Locke Cole ? - Comentario anterior sin firmar agregado por Dondervogel 2 ( charla • contribuciones )
Si lo entiendo correctamente, entonces sí, los artículos de WP iPhome / iPad / iPod deberían copiar lo que sea que Apple los haya anunciado. Cualquier otra cosa es un campo minado atravesado con un mapa muy pobre.  Stepho   talk  00:42, 11 de julio de 2021 (UTC)
@ Stepho-wrs : La política de Wikipedia es preferir fuentes secundarias . ¿Por qué no se aplica la política aquí? Independientemente, si hay consenso para seguir una fuente primaria, buscaré una. Dondervogel 2 ( charla ) 07:43, 21 de julio de 2021 (UTC)
Encontré una fuente primaria . Se lee
  • 'El sistema operativo de su iPhone, iPad, iPod touch y Mac informa la capacidad de almacenamiento utilizando el sistema decimal (base 10), que calcula 1 GB como mil millones de bytes. Este es el mismo sistema de medición que se utiliza en el embalaje y las especificaciones del producto.
  • iOS 10 y versiones anteriores, Mac OS X Leopard y versiones anteriores, Microsoft Windows y watchOS utilizan el sistema binario (base 2), que calcula 1 GB como 1,073,741,824 bytes. Esta diferencia entre los sistemas de medición decimal y binario es la razón por la que la capacidad de almacenamiento informada difiere de la capacidad de almacenamiento en el embalaje o las especificaciones del producto.
¿Se prefiere aquí la fuente principal? Dondervogel 2 ( charla ) 09:47, 21 de julio de 2021 (UTC)
Ese artículo es solo un artículo de opinión, típico de un editorial. Y sus números no cuadran. En sus propias palabras, "Aún así, no es suficiente para tener en cuenta las discrepancias que vimos anteriormente" y luego agita un poco la mano para que el sistema operativo complete los bytes que faltan. Es cierto que el sistema operativo ocupa espacio (lo mencioné yo mismo) pero no sabemos exactamente cuánto. Por lo tanto, no podemos usar eso para decir mágicamente que los XX GB anunciados coinciden exactamente con YY GiB.  Stepho   talk  10:33, 21 de julio de 2021 (UTC)
Sigue siendo una fuente secundaria. De tu respuesta infiero que prefieres la fuente principal, así que usémosla. Dondervogel 2 ( charla ) 11:53, 21 de julio de 2021 (UTC)
Dondervogel 2, parece que está luchando por encontrar una fuente adecuada que diga lo que quiere que diga. En Wikipedia, es cuando no lo decimos. NebY ( conversación ) 13:48, 21 de julio de 2021 (UTC)
@ NebY : No, es todo lo contrario. Esta discusión comenzó con una fuente secundaria que respondió a una pregunta planteada por SMcCandlish . Pero Stepho-wrs se opuso a su uso porque no era una fuente primaria, por lo que ahora sugiero una fuente primaria que dice lo mismo. Dado que las dos fuentes son consistentes y responden a una pregunta legítima, ¿deberíamos utilizar la fuente primaria o secundaria? Dondervogel 2 ( charla ) 20:51, 21 de julio de 2021 (UTC)
No, Stepho_wrs no "se opuso a su uso porque no era una fuente primaria", sino que se opuso por otros motivos que usted no aborda. Usted "infiere de su respuesta [Stepho-wrs] que prefiere la fuente primaria", pero Stepho-wrs no dijo eso. Ahora lo replantea como una pregunta sobre qué fuente usar, pero no está escuchando la respuesta ya dada: Ninguna. La pregunta es si debe seguir intentando forzar su material en el artículo, pero no está escuchando las respuestas. NebY ( conversación ) 21:19, 21 de julio de 2021 (UTC)
Las palabras precisas eran "Los artículos de WP iPhome / iPad / iPod deberían copiar lo que sea que Apple los anuncie". Estoy de acuerdo en que la declaración no incluye las palabras "fuente primaria", pero en respuesta busqué lo que dice Apple sobre sus productos. En pocas palabras: ¿es apropiado incluir (en WP) declaraciones sobre la capacidad de almacenamiento de un iPhone? Dondervogel 2 ( charla ) 21:35, 21 de julio de 2021 (UTC)
No, la pregunta de fondo fue si incluir el tipo de declaración que desea hacer, que fue respondida, y la línea de abajo es qué hacer con WP: IDHT . NebY ( conversación ) 21:45, 21 de julio de 2021 (UTC)
No. Se hizo una solicitud para agregar tal declaración y estaba tratando de ayudar. No quieres mi ayuda y está bien, pero no trates de hacer esto por mí. Dondervogel 2 ( charla ) 09:11, 22 de julio de 2021 (UTC)
Me opuse a su fuente original no porque prefiera fuentes primarias, sino porque su fuente era un artículo de opinión (un editorial) con números no concluyentes. Si no podemos encontrar una fuente secundaria confiable, entonces una fuente primaria sobre algo sin importancia está bien (si Apple dice que tiene 128 GB, entonces es algo bastante normal y seguro para creer, pero si Apple dice que tiene una CPU de 500 GHz, entonces eso es bastante notable y me gustaría ver una fuente secundaria independiente).  Stepho   talk  14:44, 23 de julio de 2021 (UTC)
NebY dejó muy claro que mis contribuciones no son bienvenidas. Soy reacio a continuar la discusión sin un mensaje claro en sentido contrario de al menos un editor. Dondervogel 2 ( charla ) 15:09, 23 de julio de 2021 (UTC)

Referencias

  1. ^ David Price, ¿Cuál es la verdadera capacidad de almacenamiento formateada de un iPhone, iPad o iPod ?, 09 de febrero de 2016
  2. ^ Precio 2016

Wikipedia prefiere fuertemente las fuentes secundarias, por lo que objetar porque algo no es una fuente primaria no es un tipo de argumento que entretenga a WP.  -  SMcCandlish ☏ ¢  😼  14:24, 30 de julio de 2021 (UTC)

Elija, todos WP: RS , todos con las capacidades informadas por Apple:
  • Gibbs, Samuel (26 de noviembre de 2020). "Revisión del iPhone 12 Pro Max: el superphone más duradero de Apple" . The Guardian . Guardian Media Group . Consultado el 1 de agosto de 2021 .
  • Beavis, Gareth (19 de mayo de 2021). "Revisión del iPhone 12 Pro Max" . TechRadar . Future plc . Consultado el 1 de agosto de 2021 .
  • Mundy, Jon (21 de julio de 2021). "iPhone 12 Pro Max vs Samsung Galaxy Note 20 Ultra: los viejos rivales se vuelven ultra competitivos" . TechRadar . Future plc . Consultado el 1 de agosto de 2021 .
  • Wuerthele, Mike; Owen, Malcolm (23 de noviembre de 2020). "Revisión del iPhone 12 Pro Max de Apple: muchos teléfonos inteligentes, y no para todos" . AppleInsider . Quiller Media, Inc . Consultado el 1 de agosto de 2021 .
  • Holanda, Patrick (25 de diciembre de 2020). "Revisión: el iPhone 12 Pro Max merece un lugar en su bolsillo, si puede hacer que quepa" . CNET . Red Ventures . Consultado el 1 de agosto de 2021 .
  • de Looper, Christian (13 de julio de 2021). "Revisión del Apple iPhone 12 Pro: difícil de vender en un mundo con el iPhone 12" . BGR . Penske Media Corporation . Consultado el 1 de agosto de 2021 .
Y eso fue solo media hora de mirar. Ninguno de ellos usó gibibyte (o GiB ), y ninguno de ellos aparentemente sintió que las diferencias de capacidad anunciadas eran lo suficientemente relevantes como para discutirlo en sus revisiones / comparaciones. Todos ellos mencionaron que Apple ofrecía capacidades más altas (y luego procedieron a usar los valores proporcionados por Apple) o simplemente enumeraron las capacidades proporcionadas por Apple en una tabla de comparación. Para ser claros, estas fuentes son solo para el iPhone 12 Pro o Pro Max, habría muchas más fuentes si esto se expandiera a todos los iPhones, iPads o iPods que se hayan producido. Cherry eligió una fuente entre docenas para encontrar una que diga lo que quiere que diga, como dijo NebY anteriormente, cuando no agregamos ese contenido a Wikipedia. - Locke Cole •t • c 10:41, 1 de agosto de 2021 (UTC)

Plantillas de bits y bytes

Página principal: Charla sobre plantillas: Cantidades de bytes § En desuso

Algo relacionado con todo lo anterior, pero aparentemente un pequeño grupo de editores ha decidido que las definiciones JEDEC de kilobyte, megabyte, gigabyte, etc. están "desaprobadas" debido a una mala lectura de la definición aquí . Consulte {{ Cantidades de bits }} y {{ Cantidades de bytes }}, y la discusión en Charla de plantillas: Cantidades de bytes . Es relevante aquí porque {{ Prefijos de bits y bytes }} que está incluido en WP: COMPUNITS y está diseñado de manera similar, también contiene un encabezado "JEDEC". - Locke Cole • t • c 17:32, 21 de junio de 2021 (UTC)

Estas plantillas han sido nominadas para su eliminación. Los editores que deseen comentar pueden hacerlo en la discusión correspondiente . Dondervogel 2 ( charla ) 11:03, 28 de junio de 2021 (UTC)
A pesar de los intentos de varios editores de participar en la discusión, incluso en la nominación para su eliminación , Locke Cole ha reanudado [8] [9] su guerra de edición [10] [11] [12] [13] [14] en Template: Cantidades de bits . Realmente es hora de que termine la interrupción, incluidos los ataques personales [15] [16] [17] . Dondervogel 2 ( charla ) 08:14, 30 de junio de 2021 (UTC)
Estoy muy tentado de llevar esto a ANI, y apoyaría absolutamente a cualquiera que lo hiciera, ya que claramente es una continuación de un comportamiento obsesivo y perturbador, completo con resúmenes de edición abusivos como "si pudiera encontrar un consenso de editores aquí que pudieran leer, eso sería ideal ". Dado que soy uno de esos contribuyentes, estoy luchando por no leer esto como un ataque personal, y ya he tenido suficiente. Archon 2488 ( charla ) 14:22, 30 de junio de 2021 (UTC)
Solo estoy siguiendo lo que dicen nuestras fuentes, y no dicen nada sobre esas unidades que JEDEC desaprueba, ya que la afirmación se hizo en la página de discusión. Tampoco hay consenso sobre los cambios realizados. En cuanto a las afirmaciones de ataques personales, no es un "ataque personal" señalar que eres un mentiroso. ¿Quizás si no te gusta esa etiqueta deberías dejar de serlo? - Locke Cole • t • c 14:48, 30 de junio de 2021 (UTC)
Veo que Dondervogel está jugando la carta de víctima porque aparentemente ser un mentiroso (Wiktionary define "mentir" como [dar] información falsa intencionalmente con la intención de engañar ) es un problema para ellos, pero la prueba está en las diferencias donde ' han tergiversado repetidamente la verdad para sus propios fines: [18] [19] (a pesar de las afirmaciones de consenso por "desaprobar" unidades sin realmente tener consenso, o la distorsión de la realidad en la que uno tiene que vivir para impulsar las unidades IEC como lo hacen) . - Locke Cole • t • c 15:07, 30 de junio de 2021 (UTC)

Bien, esto ha ido lo suficientemente lejos y se está volviendo insalubre. Hice una publicación de ANI al respecto. Archon 2488 ( conversación ) 15:29, 30 de junio de 2021 (UTC)

El resultado de la RfD fue mantener todas las plantillas, pero no creo que el contenido sea estable. Las opiniones se solicitan en la página de discusión de bytes . Dondervogel 2 ( charla ) 12:17, 7 de julio de 2021 (UTC)

unidades arcaicas

Me pregunto sobre el uso de unidades más antiguas, cuando las referencias usan tales unidades. En el caso actual, me pregunto acerca de Mc / s (o más comúnmente solo Mc con implícita / s) para los primeros artículos en la radio. Dado que la radio se desarrolló antes que la unidad Hz, las referencias más antiguas no usan Hz. Parece verse bien usando la unidad apropiada para que coincida con la referencia, y dado que el número no cambia, no hace que sea más difícil de leer. Pero tampoco vi nada que mencione unidades más antiguas aquí. Gah4 ( charla ) 23:33, 9 de julio de 2021 (UTC)

Vea la discusión anterior de hace 1 mes en Wikipedia_talk: Manual_of_Style / Dates_and_numbers / Archive_160 # Historic_unit_name, _usage .  Stepho   talk  00:06, 10 de julio de 2021 (UTC)
Gracias. Eso parece ser para las estaciones de radio, donde los artículos que estaba viendo son sobre la historia real de la radio. Es decir, más técnico, y también es más probable que los lectores vayan a leer las referencias antiguas. Además, sospecho que es menos probable que se confunda con la notación. En cualquier caso, gracias por el enlace. Gah4 ( charla ) 00:17, 11 de julio de 2021 (UTC)
Buen punto de ser historia de la radio. Pero de la misma manera que los artículos sobre la antigua Roma no hacen mediciones en estadios , yo me mantendría en megahercios en lugar de megaciclos. Quizás una sola mención cerca de la parte superior que dice megaciclos es la antigua terminología equivalente para megahercios. El tipo de personas que siguen las referencias antiguas es el tipo de personas que pueden traducir la terminología. Asimismo, el tipo de personas que tienen problemas para traducir tampoco suelen seguir las referencias.  Stepho   talk  00:33, 11 de julio de 2021 (UTC)
Absolutamente, limítese a los megahercios, incluida la sustitución de [megahercios] entre comillas. Confundir al lector con ciclos sería como decir que la Declaración de Independencia promete la búsqueda de la felicidad. E Eng 00:52, 11 de julio de 2021 (UTC)

Tonelada métrica

Se solicitan comentarios en la charla del usuario: Mitch Ames # Toneladas métricas para ayudar a resolver un desacuerdo sobre si las "toneladas métricas" deben reemplazarse por "toneladas". Mitch Ames ( charla ) 09:33, 18 de julio de 2021 (UTC)

Obtenido de " https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Manual_of_Style/Dates_and_numbers&oldid=1036566478 "
Contribute a better translation