Не могу понять почему в ЯП так популярна индексация массивов с нуля, ведь это как-то не логично, да и преимуществ вроде нет.

  

Видимо сказывается традиция...

mimik, ваше предложение не содержит вопрос.
и не понятно пример чего вы хотите: яп индексуюзего с 0 или с 1 или вообще объяснения почему это так.
можете пояснить ?
 

по моему логичней начинать индексацию массивов с 1, 
первый элемент - индекс 1

Добавлено через 4 минуты и 29 секунд

  

ну положительные числа с нуля начинаются.

а это вот почему:
предположим, по адресу памяти A расположен массив.
тогда адрес первой ячейки это А, адрес второй - A+1, адрес i-й - A+i
представляя в форме доступа к элементу массива по индексу получаем
A[0], A[1]...A[i]

ноль не является ни положительным, ни отрицательным числом



это по-человечески логично, однако, говоря о ЯП надо принимать машинную логику. что такое массив? по сути, это регистр, где каждый физический элемент памяти содержит элемент массива. а элементы эти выстроены по порядку. наглядно по наиболее простым ЯП виден этот момент, так как среди функций работы с массивами могут отсутствовать многие, но функции pop() и push() будут всегда. эти функции дословно означают - положить элемент в массив или забрать. при этом массив растёт, либо уменьшается. чистое поведение регистров.

а в какой позиции регистра надо быть, чтобы получить первый элемент массива? конечно, в позиции ноль, ведь мы в него ещё не вошли. чтобы добраться до второго элемента - надо передвинуть считывающую головку на одну [1] позицию вглубь.

всё очень даже логично. сделать конвертор из системы 1,2,3... в систему 0,1,2... конечно не сложно, но когда мы говорим о машинной логике, то эффективность выходит на первое место.

и всё-таки аргументы в пользу индексации массивов с 0, имхо, я не услышал


  


нет, это задача компилятора, я пишу array[2], а компилятор сам сделает array[1]


Это сообщение отредактировал(а) mimik - 8.11.2010, 18:54

mimik, 
термин массив существует не только для языков высокаго уровня как Lisp/Java и т.д., но и для языков такого низкаго уровня как ассембли.
для того, чтобы не пояснять людям, изучающим информатику, что у одного языка индексация с 1 а у другого - 0, довольно умное решение вопроса - определить что такое массив концептуально, т.е. эстетическая причина.

Кроме того, в языках, работающих с памятью (без автоматических освободитлей мусора и т.д.), частенько удобно "шагать" через адреса посредством так называемой "арифметики указателей". Если бы первый элемент массива "A" был обозначен как "A+1" это намного некрасивее. (т.е. причина комфортабельности) 
С другой стороны можно было бы создать синтаксис, что если ты уже используешь арифметику указателей, т.е. разделитсь семантику A[i] от *(A+i), то нередко пришлось бы делать и без того уродливый синтаксис еще менее читабельным.
т.е. для единства подходов напр. в языке Си имеет смысл сделать и ту и другую нотации похожими (опять же, эстетика) 

Третья причина образовательная: инженер разработчик не "просто человек", а должен помнить об адресации памяти компьютера.
даже если он работает на языках высокаго уровня, ибо нефиг.

а сейчас разве не так?
открываю почти любую книгу и читаю что-то типо такого: помните что индексация массивов начинается с нуля


имхо, никак не связано


имхо, массивы это одно, а работа с памятью другое, хотя в некоторых языках это эквивалентно, что не есть гуд

mimik, Вам уже описали и преимущества, и логику. Повторюсь:
преимущества. не надо делать лишних усилий компилятору (да и программисту), переходя от обывательского понимания "первый" к математическому. меньше преобразований -> проще -> надежнее
логика. зависит от взгляда на массив и индексацию. если рассматривать индекс как смещение, то использовать ноль для индекса первого элемента логичнее, чем единицу.

Вы просто не привыкли. Операции вроде += в С/С++ тоже поначалу вызывают недоумение, неудобство, излишнее напряжение мысли. А когда втягиваешься, напрягать начинает a = a + b
Привыкнете, человек ко всему привыкает ;-)

почему это так работает я понял, а преимущества я не увидел


(index - 1) вроде ничего сложного

я уже привык к этому синтаксису, но хочется писать для людей, а не для компилятора   


Это сообщение отредактировал(а) mimik - 8.11.2010, 20:38

если вам это настолько мешает, и считаете что это имеет смысл, напишите свой ЯП, свой компилятор и отладчик.
А потом посмотрите как хорошо он "пойдет", если пойдет - флаг в руки, респект, и т.д.

Удачи.

Вообще-то в нормальных языках, в которых есть массивы, индексация может начинаться откуда угодно, более того, индекс нередко вообще может быть и не целым числом.   

Фиксированное начало индексации есть в тех языках, где есть не столько массивы, сколько области памяти с указателями на них. Там - именно из-за адресной арифметики - действительно проще начинать с нуля.

мы по-прежнему говорим о массивах? Или о мапах/хешах/гридах с синтаксисом таким же, как и у массивов?

преимуществ чего? одной записи над другой?
я вот не вижу преимуществ использования знака "+" для операции сложения. 
нашел, в чем искать просто оптимизации.
я понимаю ещё - протестовать против неопределенностей вроде "++n++". 
забудь, прими как данность.
в Pascal/Delphi - вон с единицы нумерация. 

Именно о массивах. Для этого вполне достаточно, чтобы между индексом массива и некоторым конечным набором целочисленных значений существовала биекция, устанавливаемая на этапе компиляции.   

А кстати, вроде ж в каком-то дремучем бейсике можно было явно указывать OPTION BASE - и пиши после как себе удобнее. В самом деле, почему от этого отказались?

никто не отказывался. во многих языках есть (хотя бы на уровне библиотек) возможность работать с массивами, указывая Ubound/Lbound

Добавлено @ 18:12

удобство удобству рознь. задачи, где в явном виде присутствуют массивы с заданными диапазонами, не так уж часто встречаются.
а в большинстве прочих случаев удобнее (см. выше) иметь базой 0

Это сообщение отредактировал(а) baldina - 11.11.2010, 18:12

понимаю, подсознательно 0 не хочется за число признавать, и считаем мы от одного. недаром даже такие великие умы как пифагор и декарт ноль (да и отрицательные числа тоже) за число не признавали.
конечно, ведь с точки зрения "здравого смысла" ноль это пустота, ничто. 
его особое положение понятно с точки зрения алгебры: ноль является специальным элементом множества. но таки элементом множества (т.е. числом), а не отдельным объектом. и именно свойство a+0=a и дает нам удобство начинать счет от 0. это если смотреть на операции с массивами с точки зрения машинной арифметики, арифметики указателей и алгебры.

Добавлено через 1 минуту и 17 секунд
с обывательской удобнее "адын два тры", но программы пишут программисты   

а с какого года начался первый век ? а компьютеров тогда еще не было    



Это сообщение отредактировал(а) mes - 21.11.2010, 21:51

И давно?

а при чем тут это?

да, что и начинается с нуля, например год, но только потому что он может быть а может и не быть(т.е. 0)
интересно а нулевой век есть?

имхо, не быавет массив без элемента

нет




пожалуйста

нет элементов. и даже count() покажет 0

имхо, это только определение типа


  

вывело:


ARRAY(0x810017c) - пустой массив, ссылка на массив   



Это сообщение отредактировал(а) gcc - 22.11.2010, 02:48

С первого, судя по всему...   

первый год, второй год...
сейчас 2010. сколько лет от РХ пройдет, когда он закончится (и начнется 2011)? правильно, 2010.
при i=0 мы обрабатываем первый элемент массива.
когда он будет обработан (цикл перейдет к следующему шагу) будет обработан один элемент, i будет равно 1.

Добавлено через 3 минуты и 49 секунд
все от подхода зависит, от определения. если считать индекс массива синонимом смещения от начала (что в некоторых языках таковым является по определению), никаких сомнений и неудобств не будет

Добавлено через 5 минут и 50 секунд

эт только ийхо. пустой карман бывает? а пустое множество? а пустой список, дерево?

это ∅ т.е. null/nil
я хотел сказать что если нет элементов то это пустое множество а не массив


нулевой карман бывает?

причём здесь диаметр?



а если есть элементы, то почему это массив, а не заполненное множество?

С нуля надо начинать и не пудрите другим мозги. Это ж легче застрелиться, если на индексацию с единицы перейти. У меня в каждом цикле ошибки будут. То есть я к тому, что ноль - это традиция, привычка, обычай - как угодно называйте. А на единицу не переходят ибо просто незачем. Вот вам красоты хочется, а смысла от такого перехода - пшик.

Хотя нет. Вот вы представьте, перейдём мы все (Java, C++, C# etc.) на единицу в этом вопросе... вот подумайте только, как потом, лет через дцать мы будем трепать молодых программистов по макушке и по-доброму говорить: "Ех, молодёжь, не застали вы время, когда индексы с нуля начинались... Даааа, были временааа!". Потом на выбор можно затянуться трубкой или выпить глоточек виски...

Иногда нумерация с нуля всё же выносит мозг. Например, месяцы в JS-ном Date. Везде, скажем, декабрь — 12-й: что в русском формате даты, что в американском, что в SQL-ном., даже в PHP он идет 12-м (если считать с нулября, как обычно;). Почему ж в JS он 11-й? Притом что дни нумеруются как надо привычно... 


...и так по цепочке до самого ООН... и удивимся очередному блестящему предсказанию 

Нумерация с нуля тяжкое наследие Си. И все прогрессивное программистское сообщество должно бороться с этим пережитком царизма!  

не вижу аргументов


от i = i + 1 к ++i как-то ж перешли, нет?


хорошие аргументы, ага   

вы на асме кодируете?

Конечно перешли. Толку от этого - удобнее на плавиатуре набирать, не более.
(оффтопик) хотя мне больше нравится i += 1;   




У меня аргументы просты - если нет разницы, то смысла переходить нет. И если в случае с ++ можно было пользоваться старыми методами (i = i + 1), то в случае с индексом надо будет переучиваться. Это и есть мой аргумент - я не вижу никакого смысла менять ноль на единицу и пытаться к этому привыкнуть пока в этом нет никакого смысла. И дело не в том, что переучиваться сложно, а в том, что НЕ переучиваться в бесконечность раз проще.

Добавлено @ 21:38

Я на шарпе кодирую. И разработчики шарпа вместо бреда типа перехода с нулей на единицу добавляют туда реально вкусный сахар (var, await, async etc.). И полагаю, что разрабы других ЯП тоже стремятся сделать что-нибудь полезное   

Это сообщение отредактировал(а) Kefir - 29.12.2010, 21:39

Странная постановка вопроса. Как по мне так сравнивать принудительную индексацию с нуля и принудительной индексацией с единицы нет вообще никакого смысла (ну с нуля предпочтительней, потому что традиция). ТС почему-то не задумывается о массивах с произвольным типом и множеством индексов

В массивах в квадратных скобках просто пишут не адрес а _смещение_. Всего делов.

  


а если а языке нет указателей, то смещение как-то не логично, не?

и что тут не сходится?

Что не сходится?

т.е. если массив начинается с 1, то о массивах с произвольным типом и множеством индексов задумывается не надо, а если с 0 то надо
вот и не сходится

Оооой блин. Нет.
Массив должен начинаться чем захочется тому кто его объявляет, а не автору языка.

т.е. я всегда должен указывать и индексы и элементы?

mimik, ты всегда указываешь размерность. Ничего не мешает указыввать при этом и стартовый индекс.

не знаю приводили ли уже это: 
http://www.ict.edu.ru/ft/004781/m2_obe.pdf

ну как тут спорить, если сам Никлаус Вирт, поклонник и прародитель всего человеку-удобного,  в своем стремлении довести Оберон до идеала, проголосовал за нуль в качестве нижней границы диапазона индексов массива.. 

И тем не менее во многих случаях это чрезвычайно неудобно. Хотя язык и его компиляцию, конечно, упрощает.

А вот так. Он в маразм мог спасть. Это ничего не означает.

интересно, в каких случаях?

мощно выглядят массивы вместе с хэшами и наоборот, например, массивы-хэшей (список пар хэшей)
где массив - это просто набор значений, а хэши как индексы...

для работы над элементами массивов, есть разные операторы: cross-, hyper-, reduce-, meta-operators
(где индексация не важна...)

Это сообщение отредактировал(а) gcc - 13.1.2011, 06:00

это не очень удобно, ведь массив мы можем получить и из функций, или надо перед использованием надо смотреть на объявление

к его мнению я прислушиваюсь, но не более



Это сообщение отредактировал(а) mimik - 13.1.2011, 12:52

Ну, лично для меня это вычислительные задачи, в которых индексация может быть достаточно причудливой, а ее смещение - громадной работой, чреватой ошибками.

если
a[b] === *(a+b) === *(b+a) === b[a],
то алгебраически мы должны иметь моноид. для данной структуры операцией является операция сложения указателя с числом, а единицей - 0
поэтому индексация должна вестись с 0.

индексация с другого числа - частный случай этого, формально мы работаем со срезами
другая точка зрения - индексом мы задаем систему отсчета. тогда 0 нравится любителям локальных координат, а прочие индексы - любителям глобальных

как говорит А.Степанов, "depends on the definition"   

Индексация с нуля — техническая оптимизация С, который складывал указатели, но она распространилась везде.

Если подумать, это совсем не естественно. Нужно постоянно держать в памяти этот −1. Почему, чтобы взять пятый элемент, я пишу arr[4]? Разве это удобно? Почему, если в списке 10 элементов, то взять десятый (arr[10]) — ошибка? Если беспокоитесь о производительности, храните указатель на начало массива−1.

Не исключаю, что неестественны нумерация с нуля, указания сначала адреса назначения, потом источника (функция CopyMemory), 1024 байта в килобайте и многое другое. Но неужели удаётся так прямо и думать об этом годами? Мне как-то всё это как-то стало привычным, и "неестественность" давным давно не замечаю.

тот же порядок что в операторе присваивания

Скорее это аналогия с

который повторяет структуру команды процессоров Intel. Но слышал, что в своё время были процессоры с противоположным порядком операндов. Да и в обычной речи мы скорее скажем из пункта A в пункт B, чем в пункт B из пункта A. Но подобные особенности современных процессоров для меня слишком привычны, чтоб замечать, что где-то присутствует такая неестественность.

Ну ёпта. Вы действительно думаете, что ПРОЦЕССОР видит команды в таком виде ? А АМД процессоры в каком виде команды видят ?   
Открою для тебя страшную тайну. Процессоры видят команды в виде битов, а ассемблерные мнемоники как раз для людей.
И кстати есть еще AT&T-синтаксис и процессор тут совсем не причем.
А слышали вы скорей всего о порядке байтов. И это не "в свое время", а есть и сейчас (little/big endian). 
Процессоров много и они не только в вашем системном блоке...

А по части нумерации - при чем тут какие то оптимизации ? В си массив - это просто указатель на область памяти, индекс смещение. Хотите создавайте массивы с размером на 1 элемент больше и индексируйте с 1, кто вам запрещает ?
Все таки си это язык с самыми большими возможностями выстрелить себе в ногу 

Это сообщение отредактировал(а) _zorn_ - 22.1.2015, 17:17

Ну если я ничего не путаю, то команды процессоров - префиксный битовый код, в котором после кода команды следуют операнды во вполне определённой последовательности. И в процессорах Intel, насколько знаю, в команде копирования данных идёт сначала код/адрес (в зависимости от того, это регистр процессора, RAM или ещё там что) адресата, потом код/адрес источника. Более того, насколько я знаю, в виду того, что коды команд тоже придумываются людьми, то разница между кодами команд и операндами условна, т. е. предопределённые команды для соседних регистров имеют похожий битовый код.

И ещё, насколько я знаю, хоть нынче структура самих логических элементов внутри кристалла не имеет полного дискретного аналога, всё ж сами триггеры расположены в определённой последовательности (как и конденсаторы RAM и прочее), поэтому можно вполне чётко сказать о порядке расположения битового кода внутри процессора.

Это вполне вероятно, я просто подразумевал доминирующие нынче процессоры. А Intel, насколько знаю, нынче не слабо потеснил конкурентов, притом и в desktop/серверах, и в мобильных устройствах, и много ещё где.


Но в C# и Java вольностей поменьше будет. Про Objective-C/Swift сказать затрудняюсь.

Это сообщение отредактировал(а) Ilya81 - 23.1.2015, 10:04

а что, кроме Си ЯП больше нет?

Про RISC процессоры я думаю нету смысла вам говорить. Но AMD же ? У них что все по другому ? При чем тут интел ? Вы про архитектуру х86 сейчас говорите, а не про процессоры интел. Кстати 64 битную архитектуру первыми замутили АМД, и набор инструкций сейчас называются AMD64  

Еще раз - типов процессоров намного больше чем в вашем системном блоке...


Вы о чем сейчас вообще ? О том что у программистов конденсаторы в мозгу расположены так же как в процессоре ?   


Есть, но большинство поглядывает на си хотя бы по синтаксису )
Ну и он самый кросплатформенный   



Мой вариант предпочтительней. В вашем еще лишние телодвижения придется делать типа

Да и чревато последствиями если ваш код будет потом кто то дописывать. Ваши привычки он не знает, и будет мусорить перед массивами )
А если вы еще макросов налепите, или стандартные переопределите, то вообще ужас...

Это сообщение отредактировал(а) _zorn_ - 25.1.2015, 06:21

чо правда?

 http://bash.im/quote/268036

А чо нет ? Линупс например в какие устройства только не пихают...

В области биологии я не знаток, а вот что касается устройства вычислительной техники - насколько знаю, RAM чаще всего основывается на конденсаторах, а вот cache-память разного уровня - на триггерах. Ибо хотя б гигабайт (а по нынешним временам это совсем мало) памяти на триггерах стоил б совершенно немыслимую сумму денег.

А ещё о том упомянул, что со времён первых Pentium'ов для дальнейшего повышения производительности процессоров придумали структуру самих логических элементов внутри кристалла, у которой не существует точного эквивалента в виде отдельных транзисторов, резисторов и диодов. Впрочем, всё это с той поры ещё не раз менялось, чтоб энергопотребление процессоров не становилось запредельным при частоте в несколько гигагерц.

Но при этом триггеры, регистры, сумматоры и прочее имеют вполне разделённую в пространстве структуру даже с учётом всех ухищрений по размещению их внутри кристалла.


Много что менялось с той поры, насколько знаю, Apple тоже стал использовать процессоры Intel позже. Да и тот ж x86 нынче в мобильных устройствах распространён куда больше, чем прежде. А пример про x86 я привёл от того, что 64-битные приложения я ни разу не писал на ассемблере и всех их особенностей не знаю.

Это сообщение отредактировал(а) Ilya81 - 26.1.2015, 09:34

Можешь назвать платформу для которой не существует компилятора Си?

 ENIAC подойдет?

ENIAC убийца ЯП. перемычки наше всё. 

на каком языке пишут дефчонки?


Добавлено через 47 секунд
им, счастливым, проблемы индексации массивов по барабану

Я знаю круче платформу

Заканчивайте флуд, пока я вас в Аншлаг не отправил.

А как насчет ПЭВМ Агат??   

Знаю точно на Агате можно было писать программы на бэйсике, а вот насчет С - точно не знаю!   

Инфа с википедии... мопед не мой короче   

Признаться немножко попотел нажимая на мышку 
Но нашел http://en.wikipedia.org/wiki/Aztec_C

Ну это еще бабушка на двое сказала! Первые версии Агата действительно использовали в качестве ПО переработанное яблочное! Но Агат поступивший в массовое производство имел ОС Школьница, написанный кстати на Рапире, был Бейсик. А вот был ли на нем хоть какая-то версия Си. А первые версии Агата это как раз из разряда ENIAC.  

Добавлено через 4 минуты и 32 секунды
http://deka18.tsk.ru/er/agat/Apps/Language.shtml - кстати вот здесь тоже пишут что был.... блин, но никаких архивов, никакого софта - на нем написанном не встречается и упоминание разве что в документах.

Добавлено через 5 минут и 9 секунд
     

ENIAC
Тактовая частота — 100 кГц
Вычислительная мощность — 357 операций умножения или 5000 операций сложения в секунду.
Объём памяти — 20 число-слов.
Потребляемая мощность — 174 кВт.
Вес — 27 тонн.
ЯП - двоичный десятичный код (задаваемый перемычками)

Агат
Тактовая частота — 1 МГц
Вычислительная мощность — 500 тыс. оп./с
Объем памяти — ПЗУ 2 КБ, ОЗУ 64—128 КБ 
Потребляемая мощность — 60 Вт.
Вес — 9 кг
ЯП — Ассемблер, BASIC, РАПИРА (а на Apple II ставились и Pascal, Лого. Под CP/M, который мог работать на Apple II при наличии платы расширения, были компиляторы Fortran и С)

для сравнения
Samsung Galaxy S5
Тактовая частота — 2.1 ГГц 
Вычислительная мощность — 1.57 DMIPS/MHz (без учета доп. свойств процессора и спец. процессоров)
Объем памяти — ОЗУ 2Гб, Flash 16/32 Гб
Вес — 145 г

Добавлено @ 14:36
http://deka18.tsk.ru/er/agat/Apps/C.shtml


Это сообщение отредактировал(а) baldina - 29.1.2015, 14:51

Это ты описываешь последние версии Агата(7-9), которые поступали уже в массовое производство! Но существовала еще версия Агат-4, выпущенная в небольшом количестве, но так и не поступившая в серийное производство, и ее характеристики были хуже того, что ты написал. Точно не знаю, это надо смотреть из архивных документов. А про версии Агат 1-2 и т.п. вообще молчу, про них никакой инфы уже не сохранилось!