Владимир (Все сообщения пользователя)

Артем, Посчитать тангенс - не серьезный, а вот проверить акцию на предмет просадки - серьёзный.  

Юрий Волошин, Инвестор отличается от трейдера разве что масштабом по времени.  

Артем, Проверьте хоть одну "на предмет просадки"!   Это Вам не "использовать массив вместо одной переменной"- это алгоритм, и алгоритм весьма серьёзный. Кстати, мой скрипт определяет как раз не "целый список", а именно "один отдельный инструмент", чтобы вложить деньги здесь и сейчас именно туда, куда нужно, а не распылять их по всему "целому списку".

Юрий Волошин, А никак! Что значит "просела в цене"? На каком таймфрейме? Минутном? Часовом? Месячном? Годовом? А уж насчёт "временно" и сам Господь не ответит - тем более, "быстро и красиво". И не существует в природе никакого "нормального уровня" - здесь все уровни ненормальные!  

Илья,
Код инструмента Код класса
CHFRUB_1 EES_CETS
EURRUB_1€ EES_CETS
GBPRUB_1 EES_CETS
USDRUB_1$ EES_CETS

Для полных лотов:
CHFRUB_TOM CETS
CNYRUB_TOM CETS
EUR_RUB__TOM CETS
GBPRUB_TOM CETS
JPYRUB_TOM CETS
USD000UTSTOM CETS

Там ещё что-то есть, но лень ковыряться - выборку когда-то сделал для себя

Юрий Волошин, Да как нефиг делать! Только не "через таблицу Купить/Продать", а самостоятельно всё рассчитав. Считаем сумму мгновенной ликвидности по каждому тикеру, делим её на сумму затрат по нему же, умножаем на 100% и отнимаем 100%. Получаем процент прибыли/убытка (в моей таблице это восьмой столбец). Сортируем по нему и смотрим на первую (или последнюю, в зависимости от вида сортировки) строку таблицы.

Реальность, правда, несколько более сложная, а потому я (и скрипт мой) на данные 8-го столбца почти никогда не смотрим, а принимаем решения, ориентируясь на данные 12-го, 13-го и частично 14-22 столбцов.  

TGB, В ЭТОМ у меня никаких претензий к Lua. Но и насчёт "всё это надо учитывать" я не согласен: нет торговли кроме Квика и терминал - Пророк её! Это всё уже НЕ НАШИ проблемы, не скрипта и не языка.

Да, язык дерьмовенький, диалог на таблицах QUIK убогий и сами таблицы глючные. Зато код не зависит ни от версий Квика, ни от версий языка вообще никак! Сам Квик падает, а скрипт - нет. И это дорогого стоит! В этом и заключается недостаток двухуровневости. К тому же, если бы язык был хорош, то кто бы стал переходить "на второй уровень"? Для чего?

Не, после того, как у меня в портфеле появится 1 000 000 акций, мне не надо даже трогать разработанный мною код, он прекрасно справится и с миллионом! Я так ДУМАЮ!(с)    

Артем, Спасибо,я в курсе,что "каждое ядро это отдельный физический процессор". Представьте, что на компьютере один ОДНОЯДЕРНЫЙ процессор. Это ничуть не мешает организовать многопроцессную работу - примерно так, как я описал выше.

Не знаю, каким образом "люди пытаются натянуть сову на глобус и заставить однопоточный Lua работать сразу на несколько процессоров" (с их-то несчастными возможностями тупого интерпретируемого кода), но с "вылетами скриптов на пустом месте" я разобрался - больше не вылетает, исправил все свои ошибки и обвистовал чужие. А вот вылет самого Квика на ровном месте встречается всё чаще: несколько часов назад рухнул и сегодня у одного из брокеров (у которого версия 8.11 - у второго версия 8.8 работает уже несколько месяцев без нареканий). И эта тенденция мне СОВСЕМ не нравится! Кстати, этот брокер порекомендовал мне перейти на новую версию, которая оказалась 8.13, и началось такое, что торги вообще пришлось остановить! Завтра буду разбираться с брокером.

Артем, А при чём тут "работа на нескольких физических процессорах"? И одного вполне достаточно! Нет, "в обозримом будущем" действительно никто ничего не найдёт, я мало сомневаюсь. А вот "в обозримом прошлом" это особых проблем не составляло. Тоже мне бином Ньютона!(с) В частности, я сам делал нечно подобное на JS. А описание "нормального" монитора (сишного) приведено у меня в книге. Фрагмент:

Идея монитора довольно проста – он обслуживает процесс, то есть набор управляющих данных, представленных в виде стека очередей. Новая группа (объектов или событий) просто заносится как очередь (LIFO) на вершину стека (FIFO), т.е. очередь на вершине стека – это самые приоритетные на данный момент данные, которые обслуживаются по своей очереди «вне очереди». Ниже по стеку расположены те очереди, которые не будут обслужены до обработки всех верхних очередей стека. Собственно, именно так работает любой процессор: обслуживание текущей очереди определяется регистром счётчика команд, а выполнение вложенных процедур – регистром указателя стека. Для доступа к возвращаемым значениям методов используется стек аккумуляторов, устроенный аналогично стеку регистров сопроцессора, для неоднородных объектов – специальный стек системного уровня. Очередное событие из стека очередей обслуживается текущим обработчиком. Размер стека составляет обычно 64 очереди.

И далее:

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

Юрий Волошин, Может, и нужная, но глючная до невозможности! Давным-давно всё своё считаю сам.

Старатель, А на кой? Меня дата-время вообще не интересует, но при желании кто мешает собрать это в обычную строку? Сортировка работать будет - гарантирую! Что такое "фильтры" - не в курсе.

Артем, Многопоточность достаточно тривиально реализуется на ЛЮБОМ языке - это разновидность программирования данными. Многопроцессность - с этим значительно сложнее, но тоже нет ничего "принципиально не поддерживаемого". Ну, а если "запускать отдельную виртуальную машину на каждый тред", то дурное дело нехитрое. А какой простор для труднонаходимых глюков!..  

Оставьте хоть sleep в покое - чуть ли не единственное осталось, что пока работает!

Юрий Волошин, Что делать? Видимо, то же, что и я: ВААПЩЕ не использовать TRADINGSTATUS! Примерно так:

https://forum.quik.ru/messages/forum10/message54262/topic6339/#message54262

TGB, Тут важнее другая особенность: Lua не просто язык, но язык для работы в "многопроцессорной" системе:  скрипт, который просто кусок текста, интерпретируемый Квиком, сам Квик, сервер брокера, к которому обращения идут через провайдера и (в теории) биржа. Ошибки и рассогласования возможны при движении по всей этой цепочке, причём в обе стороны.

1. Сам факт, что "двухуровневость была заложена в проект языка и реализована изначально" уже доказывает, что Lua не есть хороший язык, а эта "интегрированность с C/C++ имеет целый ряд весьма неприятных следствий,из-за которых я и писал с самого начала скрипт на чистейшем Lua, благо ни особая функциональность, ни особая эффективность для задач торговли не требуется.

2. Да, "сам Lua очень компактный" - код моего скрипта (который делает всё, что должен был делать по изначальному замыслу) на данный момент составляет 18744 байта, и вряд ли когда-либо вылезет за 20К. Ну так ведь это же ИНТЕРПРЕТАТОР! Точнее, интерпретируемый текст.

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

Ну и два сегодняшних подарочка, две новые диагностики, в дополнение к более ранним "счёт депо не найден" теперь получаем и "неверно указан торговый счёт" и даже оглушающее "превышен общий лимит кредитования"! До удобства ли языка при таком поведении всей системы?

Юрий Волошин, Я ещё на один "бардак" сегодня напоролся. Точнее, на их комбинацию: у буржуев всё просто: минимальный размер лота всегда 1 акция, а у нас их может быть, мягко говоря, МНОГО (например, размер лота у ВТБ 10000 акций). Сначала я записывал размер лота в файл и читал их оттуда - напоролся на то, что у некоторых моих тикеров он вдруг изменился и, соответственно, стала неправильно вычисляться сумма покупки/продажи. Тогда я стал читать размер лота при запуске скрипта через getParamEx-LOTSIZE. Всё было прекрасно, пока не начались утренние торги, к которым рублёвые акции подключаются только в 10 часов. А при раннем запуске LOTSIZE у них нулевой! А больше-то я его не перечитываю. Придётся, видимо, сделать так: файл результатов я теперь записываю не только по выходу, но и периодически, примерно раз в полчаса (Квик заставил, который пару раз издох на ровном месте), так в этот момент я теперь буду и перечитывать LOTSIZE, "на всякий пожарный".

Что до "кто утром есть, а кого утром нет" - я на днях давал набросок алгоритма в одной из местных веток, как с этим бороться.

Евгений, Не знаю - у меня нет ни графиков, ни меток, ни текста в них, а все строки в скрипте заданы именно в кодировке 1251.

Евгений, А вот если принудительно перевести блокнот в режим UTF, то все символы отображаются корректно, но коды у них уже E296B2, E296BC, E296BA и E29784.

Евгений, Копипаст показывает символы правильно как в кодировке 1251, так и в 866, и коды символов там именно такие (даже при копипасте в блокнот), но правильно их отображает только редактор Far.

Евгений,
 - 16
 - 17
 - 30
 - 31
УПС! Ваще-то, код этой стрелочки должен быть именно 16. В Блокноте отображается только код 16, в редакторе Far Manager все 4 символа, а копипаст туда первого поста этой ветки указывает именно эти перечисленные коды: 16, 17, 30, 31.

Nikolay, Я в курсе.   Один из самых первых моих постов в этом форуме содержал слова:
Спасибо, Роман! Очень понравился ваш сервис общения с клиентами. Вы ведь сотрудник компании? Передайте руководству мою искреннюю благодарность.

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

Бывает и так.   Следовательно, ни автор,ни тема никому не интересны.

НАДО! Причём не только автору, но и нам! Если автор нас не устраивает, а тема интересная, заводим свою ветку по той же тематике и ведём дискуссию уже там.

Nikolay,и Я сроду не навязывал своего мнения! Никому и никогда. И себе не позволял навязывать. И только на этом форуме неоднократно предлагал решение тех проблем, которые меня вообще не интересовали. А я уже и не знаю, с чем мне ещё придётся столкнуться - на сегодняшний момент я решил абсолютно все проблемы, с которыми столкнулся. И реализовал абсолютно всё, что я хотелреализовать.

TGB, Почему "лишнее"? Почему "перегибы"? Автор ветки как никто заинтересован в её качестве, а также в притоке туда других участников! Ему и вожжи в руки! Бразды правления, в смысле. Он и будет убирать флуд и поощрять предметные дискуссии. А если не будет, никто к нему не пойдёт. Саморегулирующаяся система!  

TGB, А я ещё тогда предлагал наделять хозяина ветки правами её модератора - это снимает почти все вопросы. Реализовано это было много позже, на Фейсбуке, но не как замену модераторам, а как дополнение к ним. Результат - налицо: ФБ тоже фактически угроблен!

TGB, Это путь в тупик. Я в Инете с 1992 года, и я ещё помню времена, когда никаких модераторов вообще не было. Качество дискуссий при этом было на порядок выше и обеспечивалось самими участниками. А угроблено это качество было в начале "нулевых", и угроблено именно модераторами.

Как-то раз на "Хоботе" (кстати, там были вообще лучшие правила ведения дискуссий, которые я когда-либо видел) сцепились мы с одним программистом из Вильнюса. Всерьёз сцепились, по принципиальным вопросам - только пух и перья летели! И вдруг какая-то шавка влезла в разговор и затявкала на меня "с его стороны". Максим раньше меня увидел этот пост и так на неё рыкнул,  что больше я того ника вообще не видел! Увы, и этот форум был угроблен, и тоже модераторами, и теперь там тихо, как в могиле. А раньше там были ежедневные драки, дискуссии моги длиться месяцами, а число участников исчислялось десятками. С некоторыми мы не раз встречались в реале, и "морды друг другу били" уже за кружкой пива. Кое с кем мы друзья до сих пор! Ну и, наконец, оскорбить невозможно даже теоретически - можно лишь оскорбитьСЯ.

Господа! Примите как данность, что данные В ЛЮБОЙ МОМЕНТ могут быть неполными, недостоверными или просто ошибочными (как и при работе с любой базой данных). А потому алгоритм должен учитывать эту возможность, а не ловить "правильную" точку отсчёта. Ну что толку ловить окончание загрузки, если здесь и сейчас, МНОГО ПОЗЖЕ её окончания, акции COTY или MOMO - торгуются, а ZYXI или MGY - нет. И раньше 10:00 нипочём не сменят свои вчерашние данные на сегодняшние. То есть торговля как бы идёт, но в то же время как бы не идёт: одни акции (на той же бирже, того же класса, в тот же момент) торгуются, а другие нет. НУ ЗАЧЕМ ВАМ это дурацкое "окончание загрузки"? И какая вам разница, идёт торговля или нет, если стакан полон, объёмы приличные, а сделок не происходит - участники затаились и ждут? НУ КАКАЯ ВАМ РАЗНИЦА?

Ну, хорошо: представим, что мы выключили комп в 3 чаа ночи (когда любая торговля гарантированно завершилась), а включили в 5 утра (когда никакая торговля ещё не начиналась). Или вообще не выключали. Какие вам "заполнения таблиц" понадобились? Вам нужно знать, идёт ли торговля по тому тикеру, по которому вы в данный момент хотите совершить сделку - больше вас НИЧЕГО не интересует! По крайней мере, я не могу вообразить, что ещё вас может интересовать. Ну так какие проблемы?

У меня первую минуту после запуска скрипт "прогревается" и ничего не делает. Это сделано именно с целью осмотреться и не принять поспешных решений по недостоверным данным. За это время скрипт начинает считать лёгонькие 15-секундные свечи. Сам считает, сам, по своему таймеру и по данным ТТТ (ориентируясь на цену последней сделки). По тем тикерам, по которым торги не идут (по любой причине) свечи будут похожи, как однояйцевые близнецы, динамика их изменения равна нулю. И ВСЁ, блин! Либо торги ПО ДАННОМУ ТИКЕРУ не начались, либо остановлены, либо ПРИостановлены - какая нам разница? Торги не идут, сделок делать нельзя! Ну, а если и сделали ненароком, то через некоторое время (у меня это три минуты, чтобы и возможный "дребезг" при случае сработал, и все возможные прерывания пришли своими полными колодами) заявка снимается. Это решение ТОЖЕ принимается по собственному таймеру,  который тикает у нас на компе. Ну и, наконец, все данные, относящиеся непосредственно к портфелю, обрабатываются тоже самим скриптом и хранятся на своём же компе - ничего "загружать" не требуется. Ну сказка же, господа! Ну говорилось уже тыщу раз даже в этой ветке: хоть сто лет думайте - ничего лучшего не найдёте!    

Михаил Понамаренко, Ох, ни!..

Я не понял: 4 минуты загружались ВАШИ заявки?! Вот прям 1494 штуки?!

Оценим...

Утро, 7:00. Началась торговля на Санкт-Петербургской бирже. Торгуем только на доллары и только парой десятков акций. У неторгующихся бумаг цены вчерашние.

10:00. Подключилась Мосбиржа, торгуем на рубли причём данные незадолго до открытия обнуляются, и реальные цены поступают только после совершённых сделок - иногда это секунды, иногда минуты, иногда даже десятки минут. На СПб началась торговля на доллары (для большинства акций это начало торгов) и на евро. Цены не обнулялись - оставались вчерашними.

17:30. Резкий всплеск активности на СПб - подключились буржуины. Строго говоря, только теперь и началась настоящая торговля.

18:45. Мосбиржа закрывает сессию. Перекур!

19:05. Началась вечерняя сессия Мосбиржи. От торгуемых акций остался небольшой огрызок.

20:00. Торговля на евро (СПб) закончена.

23:50. Торговля на рубли (Мосбиржа) закончена.

01:45 Торговля на доллары (СПб) закончена.

Это не считая того, что биржи не работают по выходным и праздникам, причём праздники у нас и у буржуинов разные, не считая всяких аукционов закрытия и открытия и того, что я говорю только о фондовом рынке. И вы всерьёз хотите учесть всё это какими-то флагами об окончании каких-то загрузок? Оптимисты...  

Незнайка, Нет этого в Lua. Нет, не было и не будет.

В моём случае как раз сняты все 146% проблем! Так что "такие" пишут РАБОЧИЕ скрипты, а вот "не такие" постоянно скулят про свои проблемы.

Артем, Никто никому ничего не "должен" - дайте юзеру возможность САМОМУ определять тип данных - и все дела! Добрая половина проблем тут же снимется.

Артем, Вот именно! Тоже давным-давно писал, что эта долбаная "проблема" с 19-значными номерами заявок и сделок высосана из пальца, ибо в UI64 спокойно влезают ВСЕ 19-значные числа и даже часть 20-значных!

Лично мне уже всё по барабану - мой скрипт работает даже в этих "антисанитарных" условиях. Единственное пожелание: оставьте язык в покое: того, что есть - ДОСТАТОЧНО для организации автоматической торговли в Квике!

Артем, Нахера мне нужны хеш-таблицы, да ещё, прости, Господи, "с оптимизацией"? Мне нужны целочисленные ПЕРЕМЕННЫЕ! И индексы тоже 7не помешают, которых в языке тупо НЕТ.  

Артем, Какие "индексируемые таблицы" - побойтесь Бога! Мне чуть ли не с первого дня стало очевидно, что тут постоянно путают индексы и имена, что является источником многочисленных глюков - в том числе, и в основном ПО Квика (таблица заявок, я об этом не раз писал). Язык отвратителен, и только за убийство типа integer и замену его на вонючий "тип number" создателей нельзя подпускать к компу ближе, чем на километр - об этом и о многом другом я тоже писал. Как и о том, что синтаксис, про который Вы здесь соловьём заливаетесь, вообще не имеет значения - профессионалу всё равно, на каком языке писать, была бы обеспечена требуемая функциональность. О "качестве" языка говорит хотя бы то, что я, возможно, единственный на этом форуме, кто пишет на чистом Lua, и это включая лично Вас! Какие ещё нужны доказательства?

Господи, какая разница, как устроен сам Lua - тыщу раз говорил, что мы не разработчики языка, а пользователи, и потому нам ПО БАРАБАНУ его внутренности, включая эту долбаную "иммутабельность" - у меня лично все переменные, включая строки, вполне себе "мутабельные": s=s..s1..s2 - и пошли все на! И весь этот долбаный "оверхед" тоже по барабану! Мало того, что это интерпретатор, так у меня он ещё и почти всё время спит!

Для справки: все эти "далеко ушедшие вперёд" неучи, которыми написана заметка в Вики, на которую здесь давалась ссылка, всё-таки в курсе, что элементы строки не обязательно байты, но, судя по всему, ВААПЩЕ без понятия, что строки могут быть НЕ ТОЛЬКО текстом, что это именно АЛГОРИТМИЧЕСКОЕ понятие (и пофиг какая у них конкретная реализация): строки событий или, скажем, мультиязычные строки для них тайна за семью печатями. Или что тривиальная буферизация файловых операций даже при работе с текстовыми файлами читает и пишет, с точки зрения прикладника, именно строками, а обмен с диском при этом происходит массивами (секторами или там кластерами).

Строки НЕЛЬЗЯ "индексировать как таблицы", какие бы не делать "финты ушами": индекс - это НЕ имя, и об этом я тоже писал буквально в первых же своих постах (а Ваш убогий "финт ушами" эмулирует обращение по индексу как массива, а не "как таблицы", и абсолютно бесполезен - разве что для пущего оверхеда). У меня все элементы моих таблиц именуются, типа, индексами, так что в коде полно конструкций вида:
for k=j+1,a[i][12][0][0] do if a[i][12][j][0]==a[i][12][k][0] then...
но ежу понятно, что никаких индексов нет, не было и не будет. Ещё 29.09.2020 10:31:16 я писал:
Ну вот, по Вашей ссылке, первым же предложением: "Tables in Lua are not a data structure; they are the data structure. All structures that other languages offer---arrays, records, lists, queues, sets---are represented with tables in Lua". Иными словами, никаких структур данных просто НЕТ! Печально... А уж "обоснование" и вообще курам на смех: "Хотя мы МОЖЕМ (!) реализовать массивы и списки, таблицы мощнее. Многие алгоритмы упрощаются до тривиальности с использованием таблиц". И дальше вообще издевательство: "Например, вы редко пишете поиск в Lua, потому что таблицы предлагают прямой (!!!) доступ к любому типу". Ребятки, доступ по ключу - это не прямой, а как раз КРИВОЙ доступ к данным! Даже если обозвать ключи "индексами". Уши бы надрать этому "Роберто Иерусалимскому!

swerg, Тяф-тяф-тяф! ПО ДЕЛУ, как я понимаю, возразить нечего?    

swerg,Тьфу ты! Так Вы про стиль, лапочка, а не про код. Стиль у меня замечательный, много лет испытанный и используемый. В том числе, и стиль программирования на клиенте, испытан и отлажен на генераторе перловых и JS-скриптов (сам генератор, естественно, на С). Ещё фрагмент из моей книги - теперь уже по поводу стиля, чтобы разные шибка вумные не вякали своей бредятины:

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

swerg,Чо, лапуль, аж в истерике бьёмся? Это можно, только вот корчить из себя крутого программера в моём присутствии - это уже чревато.  

Михаил Понамаренко, Насколько я заметил, это ничего не значит: валюта расчётов определяется кодом класса, что бы там ни было написано в этом столбце: SPBXM - это всегда доллар, SPBDE - всегда евро, хотя там иногда показан и фунт, и франк, и лира, и ещё что-то там.

s_mike@rambler.ru, Так не несите ахинею, плиз! Про пустую ТТТ больше не вякаем? И про строковый тип не советую - я на этом собаку съел. И не одну.

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

Общие метаданные физического слоя, вроде очереди событий, помещены в БД как субграф с прописанной в паспорте БД точкой входа для доступа к ним. Поскольку семантический смысл полей данных на этом уровне значения не имеет (важен лишь физический адрес полей и их размер), здесь необходимо лишь минимальное количество типов данных: BYTE, WORD, DWORD, QWORD (т.е. поля размером 1, 2, 4 и 8 байт соответственно) и два типа групп: ARRAY (массив полей одного из вышеуказанных типов) и STRING (массив полей, оканчивающийся терминатором).

Ещё одно возможное определение множества (SET) показано в классе Сотрудник: неатомарные атрибуты Договор {43.4} и Телефон {43.5} хранятся не как массивы {12.2}, а как строки {45.3}-{45.4}. Таким образом, мы можем иметь в БД произвольное число договоров и телефонов на одного сотрудника. Важный нюанс состоит в том, что сотрудник {46} имеет два договора {46.3}, а один из этих договоров {51} имеет сразу три исполнителя (т.е. реализовано отношение «многие-ко-многим»), и даже разных классов {51.2}: одна Компания, и двое Сотрудников.

Ах, да - и у меня прямо противоположное мнение на тему, кто именно хамит.  

swerg, Ну хватит тяфтяфкать, милок! За слова свои отвечать квалификации не хватает - понимаю, но тогда уж приличнее помолчать.  

Андрей, А какая разница, куда там Квик что посылает? Представьте, что вся торговля происходит прямо в Квике! Код упростится в разы, да и надёжность повысится.

У меня прямо противоположное мнение: сопровождение софта неприлично высокое! Только за полгода только на моей памяти три версии сменилось! Нафиг нужно такое сопровождение?

Согласен: Lua - редкостное дерьмо, но раз уж так сложилось, то искать что-либо ещё нет ни малейшего желания! Свой "скрипт для игрушек" я написал, и теперь желаю лишь одного: оставьте всё как есть, хватит улучшать! Версию стабильную даждь нам днесь и избави нас от дебаггера!  

swerg, Такое, милок, существует "независимо от воли и сознания", как медицинский факт.    

Андрей, Осторожно нужно относиться буквально ко всему. Я первые месяца два матерился чуть ли не на каждую строчку кода. А сегодня поймал последнюю, которая проявлялась не каждый день. Оказалось, моя и совсем дурная: вместо a[i][1][5] стояло a[i[1][5]]. Раз двадцать глядел на это место - не видел!  

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

Андрей, Ну, во-первых, приведённая строка НЕ "запрашивает данные с сервера" - она берёт их из Квика. Во-вторых, во "времена ДОС" софт был на порядки более эффективным и менее глючным. В-третьих, за эту долбаную "динамическую типизацию" я бы разработчикам яйца пообрывал. В-четвёртых, заворачивание в tostring помогает в 9 случаях из 10.

О! И у меня то же самое! Я запрограммировал алгоритм снятия не сработавших (или частично сработавших) заявок, всё работает, но... не всегда: время от времени скрипт вылетает с похожей диагностикой. Стал проверять на nil возвращаемую таблицу - не помогает.  

Артем, Так документация-то глупая! Язык паршивый, и документация соответствующая. По ней в языке вообще ничего нет, кроме строк.

Я не знаю, что там за "классические языки программирования", но различие между строкой и массивом алгоритмическое, и не "основано на содержимом". В языке как-то определены операции именно со строками, при этом lines читает строки из файла именно как строки, причём терминатором там 13+10 (или, может, просто 10), sub вырезает кусок строки как из массива - там нет места для терминатора, каким бы он ни был, find ищет подстроку вообще непонятно как - ни размера, ни терминатора там не определено. В результате полная каша. Но если вообразить, что это именно строки, и терминатор у них именно нулевой байт, то вся эта кухня худо-бедно работает. И строки - это НЕ "подмножество массивов в любом случае" - возможны строки, составленные из нескольких массивов, возможны строки строк, строки структур, строки объектов. И нетекстовые символы в Lua прекрасно уживаются, и "иммутабельность" вместе с "валидностью текста" им по барабану, какая бы чушь ни была написана в этой долбаной "документации".

TGB, А ХОТЬ КАКОЙ-НИБУДЬ - считается? Если нет, то это не строка, а именно массив. Если мы не знаем размер этого массива, то для нас это всё равно строка. Я, кстати, отношусь к переменным Lua именно как к строкам с нулевым байтом в качестве терминатора. Я точно знаю (и использую), что в строках этих могут встречаться байты \1, \2, \3, \4, но вот нулевой байт, а также символы 13 и 10 не использую. Так, на всякий случай.

TGB, Ошибка, как всегда, в терминологии. Я, по-моему, впервые в жизни увидел термин "бинарные строки" именно на этом форуме, а уж "бинарные строки с указанной длиной" - это вообще БСК. Это как Шеннон назвал свою теорию передачи данных "теорией информации" - и началось... Массив от строки отличается столь же радикально, как и данные от информации: строка есть кусок памяти, размер которой не известен и определяется по заранее специфицированному значению терминатора (не обязательно байтового и, тем более, нулевого). Размер же массива всегда известен заранее, и потому никаких терминаторов не требуется. А потому Вы не ошиблись: если нулевой байт считается терминатором, то "a" и "a\0b" И В САМОМ ДЕЛЕ "эквивалентные строки" (но разные массивы данных).
Как я когда-то писал:
Кроме атомарных, существуют также элементы данных, представляющие собой группы полей, называемые разными авторами «сегментами», «наборами» и другими терминами. Существует два типа групп однородных элементов: массив (множество элементов заданного размера) и строка (размер этой группы определяется по заранее установленному значению терминатора). Группы же разнородных элементов фактически отличаются друг от друга лишь названием: узел (графовая модель), кортеж (реляционная модель), класс (объектный подход), структура (языки программирования). Так, понятие class отличается от struct разве что возможностью заполнять поля структуры конкретными значениями при её описании (за это «в нагрузку» получаем конструкторы с деструкторами).