Интеллекту не нужна реализация. Интеллекту плевать на то что есть и чего нет. Абстракции "сильности" или "слабости" без привязки к полёту - и есть интеллект. И у вас он кстати искарёжен. Далеко не факт, что "сильный" полёт - это некие крылышки и т.д.
Вы заменили некий термин другим термином, но лучше от этого не стало. Ибо ни первому определению "сильному интеллекту", ни второму "мышлению как у человека" - вы определений не даёте. Вы термины подменяете и не более того.
Что есть мышление как у человека?
И смеха ради - дайте определение искусственному, естественно не выходя из общего контекста интеллекта. Не плодите сущности - оно вам зачем?
"Общий интеллект - это такой, который способен на то же, что и человек."
И на что же способен этот ваш человек?)) Далее бла-бла-бла как обычно.
Отличный научпоп. Тока он не катит. Вообще никак.
Предположим есть нечто называемое слабым интеллектом. А есть сильный интеллект. Причём что это - не суть. Вы говорите о том, что относительно сильного интеллекта есть ещё сильнее, и за ним не угнаться. Отлично, гнаться и не нужно. Только фишка тут в том, что между слабым интеллектом и сильным интеллектом есть некая разница. И между сильным интеллектом и интеллектом ещё сильнее - тоже есть разница. И так далее. И это ничего не меняет.
Понимание - это сравнение. Если вы поняли - ну так расскажите в чём разница между всеми этими интеллектами. А если не поняли - то не несите чушь. Чушь очень громко вижжит.
"Мой автомобиль имеет белый цвет. Это простое знание."
Это очень сложное знание. Пока до массовых дегенов сие не дойдёт - всё так и будет стоять на месте в плане интеллекта.
Ваш автомобиль имеет "белый цвет" и "цвет" - это разные абстракции. Белый цвет нафиг никому не интересен, как и чёрный и зелёный как и любой другой вообще. А вот абстрактный цвет как нереализованная абстракция очень даже интересен. Оно вообще то и является интеллектом - манипулирование чистыми абстракциями без их реализаций. Но все эти ваши ии и прочие интеллекты на это не способны.
Остальное не читал, ибо бред по определению. Так называемые люди занимающиеся так называемыми "интеллектами" вообще не понимают как оно работает на самом деле.
п.c.: И прекратите какие то нейроны сюда "подсовывать", оно всё прекрасно работает без них. И т.д. и т.п.
"Не увидел никакой внутренней логики в этом и предшествующем тексте."
Так это нормально) Если бы "увидели" - то я бы удивился.
Вариант 1:
В 18 приличный мозг знающий что ему нужно. В 25 ещё более приличный мозг, ещё сильнее знающий что ему нужно. При условии что далее этот мозг занимается тем же чем и ранее - профит очевиден, т.е. такого 25-летнего есть смысл брать и что то с ним делать. Старым такого 25-летнего не назвёшь. У него ещё 15 лет а у буржуинов праклятущщих 25 лет продуктивной деятельности. Старым такой человек станет когда ничего не сможет делать, т.е. в 40 а у буржуинов в 50. Профит на деятельность тут это 15-25 лет, у кого как.
Вариант 2:
В 18 никто, в 25 почти никто, в 25 опять же смена деятельности, т.е. ещё 10-15 лет переучиваться, в 40 уже больной и уже ничо не может. Продуктивная осмысленная деятельность тут если повезёт в районе 5 лет, не более.
Фокус: В 25 уже понятно стар человек или нет, т.е. бесполезен или нет, т.е. будет с него профит или нет. Логически понятно. Но не вам)) Наверное, это сверхсложная логическая задачька, для решения которой непременно нужен сверхразум. Ага?
"Человек, который все это говорит, вообще сам в жизни сделал какой-нибудь большой проект?"
Дело не в каких то там проектах, а в эффективности. Если вы делаете манструозный проект но пользуются им две калеки - то это хрень сабачья а не проект. И напротив - совершенно мелким проектом могут пользоваться миллионы - и это уже существенно.
"Понятно что капитан очевидность подсказывает, что надо отключать мозг и много спать."
Спать нужно сколько положено. А вот сколько положено - кэп нифига не подскажет. Условия всегда разные, всё меняется, и стандартные 8 часов давно ушли в нибытие как средняя температура по больнице.
"Но не работает так в ИТ. Обычно есть недели когда надо прямо сильно напрячься, а есть недели относительно спокойные."
Так это ваша проблема а не Асина. Если у вас есть некий псевдогероизм, который следует исключительно и только из обобщённой дурости заказчика/руководителя/исполнителя - то это ваша проблема и никак иначе. Музыканты, строители и продавцы массово такими проблемами не страдают.
"Про образование и 25 лет параграф меня просто потряс. Оказывается в России еще считают, что после 25 лет человек уже старый? Хм, напомните мне пожалуйста, какой сейчас век?..."
21-ый век. Многое поменялось. В этой вашей россии именно и считают что в 25 человек уже старый. Этому есть много причин. Во-первых никто не учится, точнее как то там учатся - но толку нет. Т.е. в 18 - это бесполезное существо. Далее идут в универы, но опять толку нет. Потому что после универов идут работать вообще не туда. И это в вашей раше абсолютная норма. В итоге в 25 - абсолютно чистый незапятнанный разум. Но что бы этот разум принёс пользу - его опять нужно учить по новой ещё лет 10-15. И только в 35-40 этот разум что-то да выдаст, и то далеко не факт. А в 55-60 уже помирать пора. Потому что снова и опять раша. У вас долго не живут, отбрасывают коньки массово, быстро и рано.
В итоге и получается, что в 25 - это условная старость, ибо +10+15 лет ещё учиться а там почти сразу и в ящщик. Не я это придумал, это у вас так и я тут вовсе ни при чём.
"Я не считаю что, допустим, в 40 мозги начинают работать хуже. Это совершенно голословное утверждение."
Если у вас они работают - то это ничего не значит. В основном опять же дело тут не в мозгах вовсе, а в общем состоянии здоровья, которого у этих ваших ращынцах нету - и это факт минздрава а не голословное утверждение. Если вы уже в 40 больны, то вам вообще ничего не нужно, ибо не до этого. Если потостоянно больно, если постоянно калбасит давление, если постоянно всё не так - то нихрена вы не сделаете даже если у вас и будут приличные мозги. Мозги то предположим есть, а пичонка/сердце отвалились. И таких у вас вся раша.
"Еще раз повторю: автор доклада выглядит чистым теоретиком."
Так точно. Только потому, что автор не прогер. Прогер учёл бы всё, на то он и прогер. Т.е. автор чистый теоретик, только потому что не досказал огромную кучу просто преогромную кучищщу всего, от чего у вас нихрена не работает и никогда работать и не будет.
Всё как обычно) Современные так называемые программисты паталогически не могут не засрать всё кривым ооп там где оно нафиг не нужно. И естественно не могут вникнуть в аглоритмы календаря ибо это же надо разбираться а зачем? И естественно не могут всё что есть свалить в байты и инты и из стека вообще никогда не вылезать. И т.д. и т.п.
Про парсер строк можно вообще промолчать. Парсить строки не наплодив горы строк сверху похоже совсем никак. В общем ужас и кошмар. Собственно ничего нового я не увидел. Ко мне такие каждую неделю ходят и ничего не могут))
"Господа" кодеры [нет, не программисты], я вам следующее скажу. Мне не нужен код который придётся переписывать. Сделайте так, что бы этого не касаться, вообще никогда. Мне ваш ооп вхрен не упирался, тем более там где он вообще не нужен. Мне нужно единственное. Что бы оно максимально быстро работало, и разумеется корректно. Всё остальное мне вообще глубоко пофигу.
У меня вопросов к "исполнителю" вообще нет. А вот к заданию есть) Какого хрена везде где только можно юзаются строки? Это бред собачий. Должны влетать инты и лонги и вылетать они же. Планировщик юзающий парсер дат... Мда... Это надо сильно упороться))))
Однако же никаких программных сбоев не бывает. Это фикция. Таких определений не существует. Бывает криво написанное по, а бывает отлично написанное по, которое учитывает если не всё, то почти всё. Собственно программист - есть человек учитывающий если не всё, то почти всё. Если программист плюёт на это - так это не программист, это кодер а не программист.
И скорее всего этот модуль а точнее его составные части при переводе из так называемого полётного режима в некий иной - не перевелись в этот иной режим. Т.е. эти части по программе так и пытались лететь к мкс/пытались сменить орбиту модуля и проч. Ну они не "знали", что стыковка уже произведена и лететь никуда не нужно. Такова программа.
Вероятность сего весьма высока.
"Ну так в таких отраслях и тестирование должно быть соответствующим, разве нет?"
Каким таким соответствующим? Ну например если вас "посадить" за это по - вы чего делать будете?) А нук расскажите как вы будете всё это тестировать.
Смеха ради можно задачьку доопределить: узнайте мне прям щяс исправна ли ваша убогая ничегонемогущщая нода, если не исправна - пусть она самовосстановится и заработает как положено. И докажите, что она заработает в любом случае, при условии исправности части железа конечно же. Заодно определите минимальную конфигурацию нужного железа, и заодно его тоже потестите и докажите что оно исправно. И сделайте всё так, что бы оно само за собой следило, и что бы вы этого всего вообще не касались. И т.д. и т.п. И как вам такие тесты? Осилите?
У вас не должно быть ни дефисов, ни двУеточий, ни даже ваших цыфр быть не должно.
Все эти вещи должны иметь собственные кодепойнты включая цифры. Т.е. времяразделитель - это собственный кодепойнт, не дефис и не двоеточее [не кодепойнт дефиса и не кодепойнт двоеточия]. А как он выглядит - это вообще не важно) Самое главное, что бы был отличный от всего разделитель, именно имеющий собственный кодепойнт. Все эти ваши цифры даты ровно так же должны иметь собственные кодепойнты. Таким образом оно всё должно находиться/парситься элементарно.
И совсем никто не запрещает пользовать визуальный дефис/двоеточее. Как удобнее так и пользуйте. Лишь бы кодепойнт вашего дефиса отличался от имеющегося.
Список разделителей может быть большим. Не вижу ничего страшного в этом. Есть официальный разделитель, есть внесистемный - почему нет?) Но я ещё раз напишу, снова и опять. Все эти разделители должны иметь собственные кодепойнты, отличные от имеющихся дефисов-двУеточий и т.д.
Ну сделайте не 90 а 100 градусов и 10-ичасовое время прекрасно впишется.
"Стоградусные" прямые углы давно существуют, измеряются в градах, а не в градусах.
И да, вот что пишет эта ваша википедия: "Град дуги земного меридиана имеет длину 100 километров, метрическая угловая минута - 1 км. Соответственно, если бы переход на грады вместо градусов состоялся, то километр вытеснил бы морскую милю (равную одной традиционной угловой минуте)."
Джентльмены, всё это палнейшая фигня. Пока вы будете цепляться за несущественные вещщи - оно так и будет всё сильно плохо. Однако же нужно увидеть что есть существенно, а что не существенно))
Вернёмся всё же ко времени. Время измеряется некими кусками. Секунды, дни и т.д.
Эти куски могут быть существенны, а могут и не быть. Да да, именно так. Исходя из существенности куска - к этому всему подгоняются [ключевой момент - ПОДГОНЯЮТСЯ] другие куски. А в этом и есть главная проблема. Подгонять вы можете по разному. Не существенное можно подгонять под существенное и наоборот. И вообще то это очень большая разница. Принцип - совой по пню или пнём по сове тут не работает.
Так вот, исходите из существенных кусков, т.е. тех которые используются. Что нынче активно используется? Иначе - какие временные куски максимально юзабельны? Перечислим:
Секунда и производные, мс и т.д., тут проблем нет, тут всё хорошо.
Минуты, часы - с этим тоже всё хорошо.
Добавить конечно же тут можно переход на кратные 10 единицы, тут проблем не будет, можно и перейти и это правда не проблема.
Пусть будет минута = 100 секундам и т.д., это не суть.
Дни - проблем нет, астрономическая штука, всё хорошо.
Недели - проблемы есть, 7-дневная неделя архаизм. Исследования показывают что уменьшенная неделя получше будет. Исходите из нужности того или иного, и всегда так делайте. 5-6-идневная неделя должна рассматриваться нынче совершенно точно как необходимейшая штука. Опять напишу и ещё раз напишу - что нужно то и пользуйте. Всё остальное - не нужно.
Месяцы - штука нужная. Ну вот никак без них. Опять имеем ввиду что месяц здесь - это не месяц нынешний. Это месяц 3-4-5-недельный, исходящий из "нормальных" недель, см выше. Месяц ровно так же нужно подобрать "эгрономически", в соответствии с исследованиями нужности и удобности современного месяца.
Ни в коем случае не нужно менять месяц, т.е. делать его переменным. Каждый месяц должен начинаться с 1-ого числа [а может быть и с нулевого], рассмотрите и это.
Обобщим. Сотни можно вводить без проблем. Т.е. сто секунд/сто минут в часах. Часы введите кратные хотя бы 20/25, скорее всего 25. Зафиксируйте неделю и месяц.
Вот и всё))) И на самом деле ага, это всё. Ещё раз. ЭТО ВСЁ)
Вам год не нужен. Ещё раз? Хорошо. ГОД НЕ НУЖЕН.
Давайте ищщо раз. Как гритя - на бис. А год как единица времени - не нужен) Ну потому что он не существеннен.
А теперь вернёмся к вышенаписанному. Оставляйте то что нужно, и выпиливайте то что не нужно. Год нужен или нет?)
Теперь главное. А КАКОГО ХРЕНА ВЫ ПОДСТРАИВАЕТЕСЬ ПОД ГОД?)))) ЕСЛИ ГОД - НЕ СУЩЕСТВЕННАЯ ЕДИНИЦА ИЗМЕРЕНИЯ?
Вы пока главных своих ошибок не поймёте - так и будете считать что то во что то шыворот на выворот) А у вас оно именно так и происходит. А зачем вам это?
Выпиливаем год как абсолютно не нужную хрень и всё встаёт на свои места.
Как выглядит осовремененная дата?
мес.день / день.мес
1234.23 / 23.1234 [а года нет, он не нужен]
Проблем с астрономией тут не будет) Вам Сурдин скажет когда новый астрономический год наступает, вы свой любимый НГ не пропустите, не переживайте.
Я говорю всего лишь про то, что необходима нормальная фиксация юзабельных временных отрезков, не более того. Хуманы, вам не стыдно вообще, что на вас смотрят сверху, а вы даже время разгребсти не можете? А именно - оставьте то что нужно, и выпилите то что не нужно.
Для особо одарённых я вовсе не говорю что год нужно выпиливать насмерть. Год один фиг должен быть, но он должен быть как внесистемная единица времени. Т.е. не основная.
Т.е. дата с учётом года может выглядеть вот так:
мес(мес).день / день.мес(мес)
1234(2).23 / 23.1234(2)
В скобках месяц этого года.
И не надо сказки петь про то, что это всё сложно будет пересчитать. Вы уже сильно сложно считаете. Потому что у вас уже введены не только високосные годы, но и високосные секунды. Оно уже всё сильно усложнилось. Упрощайте систему насколько это возможно. Я всего лишь про это.
И я ещё раз повторюсь) Привязка чего либо к некоему переменному объекту - это полнейшая дичь. Но вы почему то запросто привязываетесь к переменным объектам. Зачем вам это, хуманы?
Дело не в системе единиц времени, а в общем времени) Хуманы настолько презабавны, что у вас всё равно время разное, даже при одной системе, вообще то.
А ведь казалось бы, какая разница когда вы встаёте формально, в 8 или 17 часов?))) Для вас утро - вы и вставайте когда оно утро. Зачем в принципе иметь часовые поясы? Общепланетарного времени вам не достаточно что ли?
Так давно никто не делает. Всё это решает ооп, где всё сильно упрощается [впрочем, и усложняется тоже].
Если ооп, то у вас всё это разлетится на кучу объектов, где совершенно не будет монструозных длинных имён.
Объект Файл, у него функция Файл.Загрузить();
Абстрактные объекты записей будут, от них наследованы ваши записи.
У вас там выше не товарные вагоны должны добавляться, а записи.
СписокЗаписей.Добавить(Запись); А то что под записью это запись товарного вагона - за это и отвечает ооп. И не важно что у вас там - товарные вагоны или не товарные, буратины или боенги с кирпичами, ооп разгребёт всё само, на то оно и ооп.
И т.д. и т.п.
Если фрагмент повторяется многократно - то зовут вменяемого программиста, который накорячит архитектуру под определённый язык и сообразит библиотеку базовых типов под это всё дело, а так же основные базовые действия с типами, их преобразования и т.д. Обычно оно называется фреймворком.
Не использование ооп там где это действительно может помочь - глупейшая ошибка. Впрочем, использование ооп там где оно нафиг не нужно и можно обойтись без ооп - ещё более глупая ошибка.
Однако же т.к. автор - учоный [вроде бы], то и спрашивать с него нечего. Понять, простить.
Разбить на функции проще простого можно тогда и только тогда, когда нет абстракций. А у учоных их нет) Учоный мир живёт на композициях, потому то оно и не интересно.
Специально для учоного:
Понимание - это сравнение. Но механизмов сравнения абстракций у учоного мира не существует. Отсюда все беды. И эти беды у программистов отсутствуют.
Как обычно пример на пальцах. У меня знакомый физик есть, и он упоротый как любой учоный. Я ему так и смог объяснить что Солнце - это не звезда, а имя собственное. Вот хоть тресни - не получается. А ведь человек публикуется в очень крутых местах. А уж собрать базовую систему типов астрономических объектов для учоного - это вообще нерешаемая задачька по определению.
Причём понятное дело что Солнце как имя собственное должно быть приляпано как интерфейс к абстракции астрономического объекта, смех в том что в этот интерфейс ещё и абстракции народности надо забрасывать, ибо всё у всех называется по-разному.
На экране не известно сколько тайлов помещяется, всё зависит от разрешения экрана. Даже при условии что если ваши картиночки константны (256x256) то не факт что выводить вы их будете в родном разрешении. Практика показывает что картиночки лучче вывести в чуть ужатом виде, изначально они у вас 256x256, рендерьте их 192x192 и поглядите что получится. Проблемы и с рендерами имеются, иногда рендеры рендерят по дифолту с прозрачностью, но когда они рендерят - края полупрозрачные получатся, а это значит что вы увидите сеточку. В общем смысле я щяс говорю про то, что не факт что у вас будут константные сетки, совпадающие с родным разрешением тайлов. А отсюда следует что даже при константном разрешении экрана вы не можете утверждать что у вас константное кол-во тайлов будет. Учитывайте это. И т.д. и т.п. Рендеры тут не совсем интересны даже, это та ещё отдельная песня. В любом случае рендер должен иметь возможность получить указатель на картинку, если этого в рендере нет - это совсем пагримушка какая то а не рендер.
Что значит достать тайл из бинарника?)))) Его не нужно доставать. Вообще никак не нужно. Нужно бинарник положить целиком в память, и найти офсет на начало нужно картинки в бинарнике. Вам указатель на картиночку нужен а не картиночка. Вы как обычно плодите буферы на буферы которые буферами погоняют. А зачем вам это?
Это как? Большинство систем настроены на виртуализацию памяти. И все файлики дифолтно читаются в память, а затем с ними можно что либо делать. Если вы используете иные механизмы - это такое себе... Потестируйте апи, я вот не знаю про линуксовые апи в случае с IO, но железки везде одинаковые. Обратите внимание на железо прежде всего. Никакое проганье не должно быть оторвано от железа, иначе это не проганье а порнография. У винта есть кеш. Кеш большой. Кеш больше вашей картинки. Причём нынче уже сильно больше, десятки мегабайт, уже иногда и сотни и более. Как вы читаете картинку с диска? Вы читаете её как то через кеш диска. Но если вы читаете по одной картинке, то вы не используете кеш по максимуму. Иначе говоря картинка у вас мегабайт (условно), вы читаете в кеш диска, из кеша в куда то там [в оперативку конечно же, но у вас не так, ну да ладно], однако же проще и эффективнее зачитывать куски примерно равные размеру кеша диска [или кратные ему]. Т.е. файлики и должны быть прилично большими, но не слишком большими.
Возьмите и потестируйте IO-операции. Наплодите 256 файликов пофиг с чем каждый размером мегабайт, и один файлик размером 256 мегабайт. И читайте в оперативку и то и то. Или куда оно вам надо. Один большой кусок прочитается быстрее.
Линукс это не лучшая ос. Для прогера - совершенно нет. Для прогера это ацкий ужас и кошмар. И вообще то линукс это не ос, это вроде бы как ядро. А вот то что поверх ядра накарячено в виде конечной ос - это уже ос и есть. Все ос разные, ядро вроде как одно. Как настроены ос - так они и работают. И все эти опирационки разные. Линкус вроде как один, а толку особо от этого нету. Ещё раз подчеркну - для прогера нету. Потому что операционки слишком отличаются. И запрогать под это всё что бы оно хотя бы работало везде - это проблема. А вот запрогать так, что бы оно везде хотя бы быстро работало - это очень сложно. А уж запрогать так что бы оно максимально быстро работало везде - это нерешаемая задача. Ну и как? Линукс лучшая ос? А для кого лучшая то?) Для дурачька торвальдса который двадцать лет ядро не меняет и векторы в ядро завести не может? Который не может уже накорячить прям в ядро линукса аналог GDI который работает вообще без видеокарты и выпилить нахрен никому не нужные бестолковые иксы? Вот потому то в этих ваших линуксах ничего и не работает. Для прогера. Потому что даже шрифт толком однообразно не прикрутишь. Потому что убожественное ядро линукса ничего не может. Потому и даже шрифты "у вас" никогда толком и не работали. А казалось бы это банальность вроде как. Ну да ну да. Везде это банальность, кроме линуксов. Отличная "ос" что тут скажешь. И т.д. и т.п.
У вас не какой то непонятный плагин должен картиночки загружать. Он вообще ничего не должен. Боже упаси))) Потому что не должен. Ибо непонятно будет ли "постпроцессинг" с картиночками в дальнейшем.
Нужен "калупатор" картиночек с диска. Это одно. С калупатора вам нужен указатель на картиночку и всё.
Нужен рендер картиночек получающий пачку указателей на картиночки.
Нужен "пробросчик" указателей из одного в другое. Это отдельный модуль. Смысл тут в том, что вы можете имея этот отдельный "пробросчик" - что либо сделать с картиночками ещё, дорисовать на них что-то изменить, балансы цвета подправить, анализировать это всё можно как то и т.д. и т.п. Не факт что оно будет юзаться в прадакшене, так оно вам должно быть нужно а не прадакшену)) Похоже у вас там как обычно набраны никчомные либы которые как обычно не соединяются) Впрочем нынче прогать так модно стильно маладёжно. Глючная фигня получается как обычно, ну да ладно. Пробросчик изменит картиночку, но она доложна в памяти как то лежать уже готовая, иначе как её изменить то?
Да просто реализовали, ибо чем проще - тем быстрее [почти всегда].
Там условный хеадер должен быть и его длина, в хеадере офсеты на другие хеадеры. В свою очередь эти хеадеры содержат офсеты на начала картиночек. В итоге этот бинарник это немножко офсетов на начала данных и собственно данные.
Библиотека читает всю бд с диска, кладёт целиком в память, далее "парсит" байтики, т.е. находит смещения по заголовкам на начала данных. Причём эти начала данных всмысле указатели на начала не нужно где то держать в очередном массиве. Всё должно быть "линейно" - подайте число на вход [номер вашего тайла], получите число на выходе [всмысле указатель]. Вот и всё. Более ничего и не нужно.
Что можно и нужно добавить сюда. Опять и снова проблемы архитектуры. Межбиблиотечные взаимодействия губят производительность. Иначе говоря не плодите библиотеки на каждый чих, либо же делайте библиотеки так, что бы обмен данными между ними был минимальным.
Пример: реализуйте собственные перечисления. Пихните это всё в библиотеку. Наследуйтесь от этой библиотеки и вы погубите производительность перечислений примерно до полутора раз.
Смысл: если вы тащщите много данных из библиотеки - это не выход. ТащИте мало данных, библиотека должна "обсчитывать" всё что можно в пределах библиотеки и не выходить за эти пределы, и в итоге вы должны получать маленькие данные, которыми уже и пользуйтесь на выходе из библиотеки.
Иначе говоря у вас есть библиотека "калупающая" эти самые бинарники, где лежат картиночки. Внимательно потестируйте выходное апи этого всего. И проведите тест безбиблиотечный. Код который вы запихаете в библиотеку иногда есть смысл не пихать в библиотеку, а прям "заинлайнить" "копипастой" туда где оно вызывается непосредственно. Межбиблиотечные вызовы иногда могут оказаться критичными, учитывайте это.
Бинарники должны быть короткими. Выше написано что лучше всё читать с диска куском враз. Например кусок может содержать в себе 256 картиночек. Целиком читайте этот кусог в оперативку, из него берите то что нужно, а нужно из него будет многое, потому то и проще читануть приличный кусог, но не шибко большой конечно же. Тут нужны тесты.
Далее. Вы же это всё обновлять как то будете. Ну не вы а юзер конечно же. Что юзеру надо - он то и обновит. Обновлять как обновляют нынче всё что есть гигантскими кусками - это вообще путь дегенерата. Но это почему то повсеместно практикуется. Почему? Ахз почему. Стильно модно маладёжно. Наверное. Правда это дичайшая дичандра, но кого это волнует?
Проблемы с бг-мерским линуксом не забывайте. Они все настроены по разному, это не вёнда где всё всегда одинаково. В вёнде что либо затюнить под производительность почти пара пустяков, ну потому что всё у всех одинаково насторено. Линуксы же в этом плане это аццкий гимарой на сраку ибо они все разные настроено всё по разному и учесть все возможные конфигурации настроек в линуксе и подстроить под это производительность это тот ещё квест.
Не совсем верный подход у вас, впрочем заказчику конечно же виднее. Однако же заказчик в этом всём ничерта не понимает, вот в чём проблема. Так что решать в любом случае вам, а не заказчику.
Так вот, всё что вы делаете - должно работать, это очевидно. Но как работать? Вы пишете - максимально быстро. "Максимально быстро" и "быстро" - сильно отличаются. Максимально быстро - это значит быстрее и быть не может. Причём это самое "максимально быстро" придётся доказывать. Т.е. что бы утверждать что оно "максимально быстро" - нужно доказать то, что все прочие реализации будут медленнее. А как вы это докажете?) Проблема.
Вы скажете это словоблудие? Отнюдь нет. Вы сказали - ну значит и делайте как сказали. Опять проблема, потому что вы доказать ничего не сможете.
Вы сами же пишете - изобрели велосипед, но стоило ли оно того, если сравнивать не с чем? Проблема))
Это я всего лишь про то, на что как обычно влетают начинающие прогеры. Прогают не на том, прогают не туда, прогают не то. Всё как обычно, и конечно же в этом ничего страшного нет.
Первое что вы должны получить - это валидный продукт, это значит напишите быстро и получите 100% работающее. С какой скоростью оно работает - это вообще не важно.
Про скорости. Вам пол-жизни не хватит, что бы написать рендер на 30 картиночек, такой что максимально быстрый. Вовсе не шучу. Оно так и есть. Пишите лишь бы работало, а уже после причём не кому то а себе - напишете куски быстрых реализаций, но на это у вас пол-жизни уйдёт, ещё раз говорю) Не верите? А это не вопрос веры. Давайте по существу, почему нет?
Как оно работает? Есть бд - пусть это файловая система [это тоже бд], или узкоспециализированная штука которые и называются бд - это не суть. Есть и есть. Как они работают? По каким то там запросам они отдают объекты. Объекты иногда кешируются, иногда нет, оно иногда настраивается, иногда нет. Бд может следить за собой ну например как файловая система и быть отказоустойчивой, а иногда бд за собой не следят как тот же скюель и в общем то это почти бесполезные бд [ну потому что бесполезные]. Все они работают как обычно на "вставку"/"удаление"/"изменение" и т.д. всё стандартно, иногда сами самовосстанавливаются и прочее прочее. Суть - они все динамические, а динамический - это изменяющийся по времени [по определению]. Далее вы тут сами напишите портянку про бд себе, и допишите сюда всё то что сейчас существует.
А ТЕПЕРЬ ДАВАЙТЕ ПОСМОТРИМ НА ВСЁ ЭТО И НА ТО ЧТО ВАМ НУЖНО)))))
Вам не нужна динамическая бд, вам не нужны объекты, вам не нужны запросы, вам не нужны поиски, вам не нужно от этого всего вообще ничего. А то что вам нужно - в этом всём НЕТУ)
Что вам нужно? Максимально быстро, отказоустойчиво, просто и желательно иметь поверх такое апи, что бы оно было по вашей задаче максимально простым и даже тривиальным. Иначе говоря вы суёте число и получаете картинку. Вот что нужно.
Теперь конкретно. Статических бд нет, статических бд отдающщих не объекты а указатели на них нет, статических отказоустойчивых бд нет, ничерта нет) Гонг вопрос: сколько это всё вы будете писать? И дело не в писанине тут. До писанины вы даже не дойдёте. Потому что перед тем как что то писать - нужно вообще то понимать что будет в итоге. А в итоге получается вообще принципиально иная архитектура, нежели имеющиеся. Ну вы же хотели максимально быстро? Хотели? Ну получите. У вас джиельобёртки напрямую и должны получать по hex-числу указатель на кусог бд И ВСЁ)))))) В случае чего бд должна самовосстановиться. Более ничего тут и не нужно.
А теперь сколько по времени вы это всё собираетесь писать? Понятно или нет?) Никогда вы сие не напишете, потому что это очень сложно, почти невозможно это. Для вас во всяком случае сейчас и ещё лет десять сверху - это в принципе не реализуемая задачька. Так вот я всего лишь про то, что пишите как есть, как вы задумали - так и пишите. И разбирайтесь в алгоритмах, это очень важно. Под алгоритмами я вовсе не понимаю тут какие то мат.алгоритмы, это не то, про них можно почитать и потестить и всё такое. Разбирайтесь в алгоритмах как что работает на самом деле. Алгоритм в данном случае - это как раз таки пример того что написано выше про бд в целом. Ещё это всё называют архитектурой. Вот для вас это важно. Как и что работает на самом деле.
И не слушайте брюзжащих старпёров, ибо да они сильно знают как и что работает на самом деле. Но писать то вам, а не мне) Так что пишите как задумали, и никого не слушайте. А вот когда напишете - тогда может быть [и то не факт] и поглядите что можно исправить и подправить. Даже могу объяснить почему это выгодно. Вы являетесь по сути программой, конечным автоматом с ножками и ручками. Вы как программа запущены в треде. Если кто-то лезет в тред - он тормозит тред) Нельзя лочить тред, от этого будет только хуже, причём сильно хуже. Вы как программа запущены и исполняетесь, ну и исполняйтесь. Вот когда ваше исполнение закончится, вот тогда можно анализировать результаты вашего исполнения, смотреть время, корректность результата и т.д. А до тех пор влезать в ваш тред никак нельзя, так что удачи вам а точнее вашему треду, как напишете - так и приходите с результатами) Оно будет конечно не интересно, глупо, ужасно, убого, дебильно, монструозно, велосипедно, ужасающе медленно - ну и что? Оно будет ваше и оно будет работать. Это главное.
"тайл с x=45917, y=53960 на зуме в 100 по пути root/100/45/917/53/960"
Там квадранты которые можно и нужно держать в hex, зума 100 не будет, максимум 14-16, может быть под 18 но это редкость.
"а для доступа к картинке обращаетесь к root/<n / N>/<n % N>.png, где первое — целочисленное деление, второе — взятие остатка"
Своя алгебра у квадрантов, делений никаких тут не нужно, всё на сдвигах.
Автору рекомендую сильно пережать картинки в jpeg и запаковать в архивы без сжатия. В моём варианте я в рар упаковал блоками по 256 (64 и т.д. по зуму) штук, без сжатия но с информацией для восстановления. Если коннектор до картинок колупает картинку с ошибкой, то запускается восстановление архива и иногда оно действительно помогало. Заодно напишите чекер этих баз, что бы проверять корректность всех картинок враз. Отказоустойчивость - хорошая и удобная штука.
Если у автора нет квадрантов - рекомендую перейти на них, но вроде бы у автора они как раз таки и есть.
Реализовывал такую же хрень лет 10 назад тестил на древних атомах первых - работало отлично, тормозов не было. Писалось на шарпе с почти готовой обёрткой вокруг unrar.dll и прикручено оно было естественно на обёртках OpenGL для отрисовки.
Плюсы тут не совсем нужны, если есть возможность - юзайте попроще, разницы почти не будет. Ей неоткуда браться. Всё слишком просто тут и почти топорно. По оперативке можете чютка просесть, но и это решаемо.
п.с.: Автор, усиленно на квадранты перейти рекомендую) Никаких xy тут нет, тут одно число, четверичное. Ваш x,y = {00, 01,10,11} = {0,1,2,3} в четверичной. Далее нужна алгебра от этого четверичного числа влево/вправо/вверх/вниз - это 4 операции условно два сложения два вычитания. Всё это не даёт коллизий. Картинки тоже так же переподпишите. Тайл x,y = 3FA0A7.jpeg, папки так же шестнадцатеричные. Это математика. Да да, без неё никак. Придётся кое что придумать и реализовать самостоятельно. Работать будет и работать будет хорошо.
Ньютону для [пусть и не совсем корректного] определения сил гравитации не потребовался гравитон. А вам зачем нейрон?
«Красный», «кирпич» и «землекоп» представлены тремя нейронными репрезентациями
Если между ними нет разницы, а у вас нет никакой разницы - то вы ничего и не нашли. Выше написано про понимание. А понимание - есть сравнение. Какую разницу "вы" нашли в этих трёх репрезентациях [причём это непонять что] по результатам сканирования мозга?
Есть компьютер, там "дрейфуют" электроны/дырки и прочее полупроводниковое не суть. Каким образом по дрейфу этого всего вы определите где там "красный", "кирпич" и "землекоп"? Однако же они там есть [если они там есть] и почти прекрасно описываются абстракциями. Однако же никакое сканирование процессора эти абстракции не покажет. И проблема тут на самом деле грандиозная. Если вы не знаете что искать - так вы никогда и не найдёте. А что вы ищете? Прежде чем что-либо искать - вообще то моделируют то что ищут. Смоделируйте абстракцию на бумашке - тогда и ищите. А сможете смоделировать?
Миф - это то, что можно заранее, умозрительными рассуждениями, надёжно предсказать какие исследования приблизят к пониманию чего-либо, а какие нет.
Это не миф, это логика. Единственное что можно добавить сюда - это надёжность предсказаний. Иногда эта надёжность не достаточная - но это всего лишь значит, что логика не полна.
Самый устойчивый миф к сожалению не приведён, впрочем это нормально.
Миф: Что бы понять как работают мозги - нужно их непременно расколупать и что-то померить. Или не колупать, и всё равно что-то померить.
Однако же никакие колупания и измерения никогда не приблизят "колупателей" и "измерителей" к пониманию абстракций ну например "красного", "кирпича" и "землекопа".
Ок, ещё раз)
Интеллекту не нужна реализация. Интеллекту плевать на то что есть и чего нет. Абстракции "сильности" или "слабости" без привязки к полёту - и есть интеллект. И у вас он кстати искарёжен. Далеко не факт, что "сильный" полёт - это некие крылышки и т.д.
Вы заменили некий термин другим термином, но лучше от этого не стало. Ибо ни первому определению "сильному интеллекту", ни второму "мышлению как у человека" - вы определений не даёте. Вы термины подменяете и не более того.
Что есть мышление как у человека?
И смеха ради - дайте определение искусственному, естественно не выходя из общего контекста интеллекта. Не плодите сущности - оно вам зачем?
"Общий интеллект - это такой, который способен на то же, что и человек."
И на что же способен этот ваш человек?)) Далее бла-бла-бла как обычно.
Отличный научпоп. Тока он не катит. Вообще никак.
Предположим есть нечто называемое слабым интеллектом. А есть сильный интеллект. Причём что это - не суть. Вы говорите о том, что относительно сильного интеллекта есть ещё сильнее, и за ним не угнаться. Отлично, гнаться и не нужно. Только фишка тут в том, что между слабым интеллектом и сильным интеллектом есть некая разница. И между сильным интеллектом и интеллектом ещё сильнее - тоже есть разница. И так далее. И это ничего не меняет.
Понимание - это сравнение. Если вы поняли - ну так расскажите в чём разница между всеми этими интеллектами. А если не поняли - то не несите чушь. Чушь очень громко вижжит.
"Мой автомобиль имеет белый цвет. Это простое знание."
Это очень сложное знание. Пока до массовых дегенов сие не дойдёт - всё так и будет стоять на месте в плане интеллекта.
Ваш автомобиль имеет "белый цвет" и "цвет" - это разные абстракции. Белый цвет нафиг никому не интересен, как и чёрный и зелёный как и любой другой вообще. А вот абстрактный цвет как нереализованная абстракция очень даже интересен. Оно вообще то и является интеллектом - манипулирование чистыми абстракциями без их реализаций. Но все эти ваши ии и прочие интеллекты на это не способны.
Остальное не читал, ибо бред по определению. Так называемые люди занимающиеся так называемыми "интеллектами" вообще не понимают как оно работает на самом деле.
п.c.: И прекратите какие то нейроны сюда "подсовывать", оно всё прекрасно работает без них. И т.д. и т.п.
"Не увидел никакой внутренней логики в этом и предшествующем тексте."
Так это нормально) Если бы "увидели" - то я бы удивился.
Вариант 1:
В 18 приличный мозг знающий что ему нужно. В 25 ещё более приличный мозг, ещё сильнее знающий что ему нужно. При условии что далее этот мозг занимается тем же чем и ранее - профит очевиден, т.е. такого 25-летнего есть смысл брать и что то с ним делать. Старым такого 25-летнего не назвёшь. У него ещё 15 лет а у буржуинов праклятущщих 25 лет продуктивной деятельности. Старым такой человек станет когда ничего не сможет делать, т.е. в 40 а у буржуинов в 50. Профит на деятельность тут это 15-25 лет, у кого как.
Вариант 2:
В 18 никто, в 25 почти никто, в 25 опять же смена деятельности, т.е. ещё 10-15 лет переучиваться, в 40 уже больной и уже ничо не может. Продуктивная осмысленная деятельность тут если повезёт в районе 5 лет, не более.
Фокус: В 25 уже понятно стар человек или нет, т.е. бесполезен или нет, т.е. будет с него профит или нет. Логически понятно. Но не вам)) Наверное, это сверхсложная логическая задачька, для решения которой непременно нужен сверхразум. Ага?
"Человек, который все это говорит, вообще сам в жизни сделал какой-нибудь большой проект?"
Дело не в каких то там проектах, а в эффективности. Если вы делаете манструозный проект но пользуются им две калеки - то это хрень сабачья а не проект. И напротив - совершенно мелким проектом могут пользоваться миллионы - и это уже существенно.
"Понятно что капитан очевидность подсказывает, что надо отключать мозг и много спать."
Спать нужно сколько положено. А вот сколько положено - кэп нифига не подскажет. Условия всегда разные, всё меняется, и стандартные 8 часов давно ушли в нибытие как средняя температура по больнице.
"Но не работает так в ИТ. Обычно есть недели когда надо прямо сильно напрячься, а есть недели относительно спокойные."
Так это ваша проблема а не Асина. Если у вас есть некий псевдогероизм, который следует исключительно и только из обобщённой дурости заказчика/руководителя/исполнителя - то это ваша проблема и никак иначе. Музыканты, строители и продавцы массово такими проблемами не страдают.
"Про образование и 25 лет параграф меня просто потряс. Оказывается в России еще считают, что после 25 лет человек уже старый? Хм, напомните мне пожалуйста, какой сейчас век?..."
21-ый век. Многое поменялось. В этой вашей россии именно и считают что в 25 человек уже старый. Этому есть много причин. Во-первых никто не учится, точнее как то там учатся - но толку нет. Т.е. в 18 - это бесполезное существо. Далее идут в универы, но опять толку нет. Потому что после универов идут работать вообще не туда. И это в вашей раше абсолютная норма. В итоге в 25 - абсолютно чистый незапятнанный разум. Но что бы этот разум принёс пользу - его опять нужно учить по новой ещё лет 10-15. И только в 35-40 этот разум что-то да выдаст, и то далеко не факт. А в 55-60 уже помирать пора. Потому что снова и опять раша. У вас долго не живут, отбрасывают коньки массово, быстро и рано.
В итоге и получается, что в 25 - это условная старость, ибо +10+15 лет ещё учиться а там почти сразу и в ящщик. Не я это придумал, это у вас так и я тут вовсе ни при чём.
"Я не считаю что, допустим, в 40 мозги начинают работать хуже. Это совершенно голословное утверждение."
Если у вас они работают - то это ничего не значит. В основном опять же дело тут не в мозгах вовсе, а в общем состоянии здоровья, которого у этих ваших ращынцах нету - и это факт минздрава а не голословное утверждение. Если вы уже в 40 больны, то вам вообще ничего не нужно, ибо не до этого. Если потостоянно больно, если постоянно калбасит давление, если постоянно всё не так - то нихрена вы не сделаете даже если у вас и будут приличные мозги. Мозги то предположим есть, а пичонка/сердце отвалились. И таких у вас вся раша.
"Еще раз повторю: автор доклада выглядит чистым теоретиком."
Так точно. Только потому, что автор не прогер. Прогер учёл бы всё, на то он и прогер. Т.е. автор чистый теоретик, только потому что не досказал огромную кучу просто преогромную кучищщу всего, от чего у вас нихрена не работает и никогда работать и не будет.
И т.д. и т.п.
Как может спать то, чего не существует?
Всё как обычно) Современные так называемые программисты паталогически не могут не засрать всё кривым ооп там где оно нафиг не нужно. И естественно не могут вникнуть в аглоритмы календаря ибо это же надо разбираться а зачем? И естественно не могут всё что есть свалить в байты и инты и из стека вообще никогда не вылезать. И т.д. и т.п.
Про парсер строк можно вообще промолчать. Парсить строки не наплодив горы строк сверху похоже совсем никак. В общем ужас и кошмар. Собственно ничего нового я не увидел. Ко мне такие каждую неделю ходят и ничего не могут))
"Господа" кодеры [нет, не программисты], я вам следующее скажу. Мне не нужен код который придётся переписывать. Сделайте так, что бы этого не касаться, вообще никогда. Мне ваш ооп вхрен не упирался, тем более там где он вообще не нужен. Мне нужно единственное. Что бы оно максимально быстро работало, и разумеется корректно. Всё остальное мне вообще глубоко пофигу.
У меня вопросов к "исполнителю" вообще нет. А вот к заданию есть) Какого хрена везде где только можно юзаются строки? Это бред собачий. Должны влетать инты и лонги и вылетать они же. Планировщик юзающий парсер дат... Мда... Это надо сильно упороться))))
В данном случае скорее всего именно так.
Однако же никаких программных сбоев не бывает. Это фикция. Таких определений не существует. Бывает криво написанное по, а бывает отлично написанное по, которое учитывает если не всё, то почти всё. Собственно программист - есть человек учитывающий если не всё, то почти всё. Если программист плюёт на это - так это не программист, это кодер а не программист.
И скорее всего этот модуль а точнее его составные части при переводе из так называемого полётного режима в некий иной - не перевелись в этот иной режим. Т.е. эти части по программе так и пытались лететь к мкс/пытались сменить орбиту модуля и проч. Ну они не "знали", что стыковка уже произведена и лететь никуда не нужно. Такова программа.
Вероятность сего весьма высока.
"Ну так в таких отраслях и тестирование должно быть соответствующим, разве нет?"
Каким таким соответствующим? Ну например если вас "посадить" за это по - вы чего делать будете?) А нук расскажите как вы будете всё это тестировать.
Смеха ради можно задачьку доопределить: узнайте мне прям щяс исправна ли ваша убогая ничегонемогущщая нода, если не исправна - пусть она самовосстановится и заработает как положено. И докажите, что она заработает в любом случае, при условии исправности части железа конечно же. Заодно определите минимальную конфигурацию нужного железа, и заодно его тоже потестите и докажите что оно исправно. И сделайте всё так, что бы оно само за собой следило, и что бы вы этого всего вообще не касались. И т.д. и т.п. И как вам такие тесты? Осилите?
Стандартная ошибка "стандартизаторов")
У вас не должно быть ни дефисов, ни двУеточий, ни даже ваших цыфр быть не должно.
Все эти вещи должны иметь собственные кодепойнты включая цифры. Т.е. времяразделитель - это собственный кодепойнт, не дефис и не двоеточее [не кодепойнт дефиса и не кодепойнт двоеточия]. А как он выглядит - это вообще не важно) Самое главное, что бы был отличный от всего разделитель, именно имеющий собственный кодепойнт. Все эти ваши цифры даты ровно так же должны иметь собственные кодепойнты. Таким образом оно всё должно находиться/парситься элементарно.
И совсем никто не запрещает пользовать визуальный дефис/двоеточее. Как удобнее так и пользуйте. Лишь бы кодепойнт вашего дефиса отличался от имеющегося.
Список разделителей может быть большим. Не вижу ничего страшного в этом. Есть официальный разделитель, есть внесистемный - почему нет?) Но я ещё раз напишу, снова и опять. Все эти разделители должны иметь собственные кодепойнты, отличные от имеющихся дефисов-двУеточий и т.д.
Так у вас и градусы кривые ахаха!))
Ну сделайте не 90 а 100 градусов и 10-ичасовое время прекрасно впишется.
"Стоградусные" прямые углы давно существуют, измеряются в градах, а не в градусах.
И да, вот что пишет эта ваша википедия: "Град дуги земного меридиана имеет длину 100 километров, метрическая угловая минута - 1 км. Соответственно, если бы переход на грады вместо градусов состоялся, то километр вытеснил бы морскую милю (равную одной традиционной угловой минуте)."
Джентльмены, всё это палнейшая фигня. Пока вы будете цепляться за несущественные вещщи - оно так и будет всё сильно плохо. Однако же нужно увидеть что есть существенно, а что не существенно))
Вернёмся всё же ко времени. Время измеряется некими кусками. Секунды, дни и т.д.
Эти куски могут быть существенны, а могут и не быть. Да да, именно так. Исходя из существенности куска - к этому всему подгоняются [ключевой момент - ПОДГОНЯЮТСЯ] другие куски. А в этом и есть главная проблема. Подгонять вы можете по разному. Не существенное можно подгонять под существенное и наоборот. И вообще то это очень большая разница. Принцип - совой по пню или пнём по сове тут не работает.
Так вот, исходите из существенных кусков, т.е. тех которые используются. Что нынче активно используется? Иначе - какие временные куски максимально юзабельны? Перечислим:
Секунда и производные, мс и т.д., тут проблем нет, тут всё хорошо.
Минуты, часы - с этим тоже всё хорошо.
Добавить конечно же тут можно переход на кратные 10 единицы, тут проблем не будет, можно и перейти и это правда не проблема.
Пусть будет минута = 100 секундам и т.д., это не суть.
Дни - проблем нет, астрономическая штука, всё хорошо.
Недели - проблемы есть, 7-дневная неделя архаизм. Исследования показывают что уменьшенная неделя получше будет. Исходите из нужности того или иного, и всегда так делайте. 5-6-идневная неделя должна рассматриваться нынче совершенно точно как необходимейшая штука. Опять напишу и ещё раз напишу - что нужно то и пользуйте. Всё остальное - не нужно.
Месяцы - штука нужная. Ну вот никак без них. Опять имеем ввиду что месяц здесь - это не месяц нынешний. Это месяц 3-4-5-недельный, исходящий из "нормальных" недель, см выше. Месяц ровно так же нужно подобрать "эгрономически", в соответствии с исследованиями нужности и удобности современного месяца.
Ни в коем случае не нужно менять месяц, т.е. делать его переменным. Каждый месяц должен начинаться с 1-ого числа [а может быть и с нулевого], рассмотрите и это.
Обобщим. Сотни можно вводить без проблем. Т.е. сто секунд/сто минут в часах. Часы введите кратные хотя бы 20/25, скорее всего 25. Зафиксируйте неделю и месяц.
Вот и всё))) И на самом деле ага, это всё. Ещё раз. ЭТО ВСЁ)
Вам год не нужен. Ещё раз? Хорошо. ГОД НЕ НУЖЕН.
Давайте ищщо раз. Как гритя - на бис. А год как единица времени - не нужен) Ну потому что он не существеннен.
А теперь вернёмся к вышенаписанному. Оставляйте то что нужно, и выпиливайте то что не нужно. Год нужен или нет?)
Теперь главное. А КАКОГО ХРЕНА ВЫ ПОДСТРАИВАЕТЕСЬ ПОД ГОД?)))) ЕСЛИ ГОД - НЕ СУЩЕСТВЕННАЯ ЕДИНИЦА ИЗМЕРЕНИЯ?
Вы пока главных своих ошибок не поймёте - так и будете считать что то во что то шыворот на выворот) А у вас оно именно так и происходит. А зачем вам это?
Выпиливаем год как абсолютно не нужную хрень и всё встаёт на свои места.
Как выглядит осовремененная дата?
мес.день / день.мес
1234.23 / 23.1234 [а года нет, он не нужен]
Проблем с астрономией тут не будет) Вам Сурдин скажет когда новый астрономический год наступает, вы свой любимый НГ не пропустите, не переживайте.
Я говорю всего лишь про то, что необходима нормальная фиксация юзабельных временных отрезков, не более того. Хуманы, вам не стыдно вообще, что на вас смотрят сверху, а вы даже время разгребсти не можете? А именно - оставьте то что нужно, и выпилите то что не нужно.
Для особо одарённых я вовсе не говорю что год нужно выпиливать насмерть. Год один фиг должен быть, но он должен быть как внесистемная единица времени. Т.е. не основная.
Т.е. дата с учётом года может выглядеть вот так:
мес(мес).день / день.мес(мес)
1234(2).23 / 23.1234(2)
В скобках месяц этого года.
И не надо сказки петь про то, что это всё сложно будет пересчитать. Вы уже сильно сложно считаете. Потому что у вас уже введены не только високосные годы, но и високосные секунды. Оно уже всё сильно усложнилось. Упрощайте систему насколько это возможно. Я всего лишь про это.
И я ещё раз повторюсь) Привязка чего либо к некоему переменному объекту - это полнейшая дичь. Но вы почему то запросто привязываетесь к переменным объектам. Зачем вам это, хуманы?
Дело не в системе единиц времени, а в общем времени) Хуманы настолько презабавны, что у вас всё равно время разное, даже при одной системе, вообще то.
А ведь казалось бы, какая разница когда вы встаёте формально, в 8 или 17 часов?))) Для вас утро - вы и вставайте когда оно утро. Зачем в принципе иметь часовые поясы? Общепланетарного времени вам не достаточно что ли?
"Зачем тут вообще ООП"
"в подавляющем большинстве случаев ООП — это такие модули"
"X as File"
Гонг вопрос: где тут ооп, а где тут нет ооп?
Всё смешалось... Кони... Люди... (с) кто-то
Так давно никто не делает. Всё это решает ооп, где всё сильно упрощается [впрочем, и усложняется тоже].
Если ооп, то у вас всё это разлетится на кучу объектов, где совершенно не будет монструозных длинных имён.
Объект Файл, у него функция Файл.Загрузить();
Абстрактные объекты записей будут, от них наследованы ваши записи.
У вас там выше не товарные вагоны должны добавляться, а записи.
СписокЗаписей.Добавить(Запись); А то что под записью это запись товарного вагона - за это и отвечает ооп. И не важно что у вас там - товарные вагоны или не товарные, буратины или боенги с кирпичами, ооп разгребёт всё само, на то оно и ооп.
И т.д. и т.п.
Если фрагмент повторяется многократно - то зовут вменяемого программиста, который накорячит архитектуру под определённый язык и сообразит библиотеку базовых типов под это всё дело, а так же основные базовые действия с типами, их преобразования и т.д. Обычно оно называется фреймворком.
Не использование ооп там где это действительно может помочь - глупейшая ошибка. Впрочем, использование ооп там где оно нафиг не нужно и можно обойтись без ооп - ещё более глупая ошибка.
Однако же т.к. автор - учоный [вроде бы], то и спрашивать с него нечего. Понять, простить.
Разбить на функции проще простого можно тогда и только тогда, когда нет абстракций. А у учоных их нет) Учоный мир живёт на композициях, потому то оно и не интересно.
Специально для учоного:
Понимание - это сравнение. Но механизмов сравнения абстракций у учоного мира не существует. Отсюда все беды. И эти беды у программистов отсутствуют.
Как обычно пример на пальцах. У меня знакомый физик есть, и он упоротый как любой учоный. Я ему так и смог объяснить что Солнце - это не звезда, а имя собственное. Вот хоть тресни - не получается. А ведь человек публикуется в очень крутых местах. А уж собрать базовую систему типов астрономических объектов для учоного - это вообще нерешаемая задачька по определению.
Причём понятное дело что Солнце как имя собственное должно быть приляпано как интерфейс к абстракции астрономического объекта, смех в том что в этот интерфейс ещё и абстракции народности надо забрасывать, ибо всё у всех называется по-разному.
И т.д. и т.п.
На экране не известно сколько тайлов помещяется, всё зависит от разрешения экрана. Даже при условии что если ваши картиночки константны (256x256) то не факт что выводить вы их будете в родном разрешении. Практика показывает что картиночки лучче вывести в чуть ужатом виде, изначально они у вас 256x256, рендерьте их 192x192 и поглядите что получится. Проблемы и с рендерами имеются, иногда рендеры рендерят по дифолту с прозрачностью, но когда они рендерят - края полупрозрачные получатся, а это значит что вы увидите сеточку. В общем смысле я щяс говорю про то, что не факт что у вас будут константные сетки, совпадающие с родным разрешением тайлов. А отсюда следует что даже при константном разрешении экрана вы не можете утверждать что у вас константное кол-во тайлов будет. Учитывайте это. И т.д. и т.п. Рендеры тут не совсем интересны даже, это та ещё отдельная песня. В любом случае рендер должен иметь возможность получить указатель на картинку, если этого в рендере нет - это совсем пагримушка какая то а не рендер.
Что значит достать тайл из бинарника?)))) Его не нужно доставать. Вообще никак не нужно. Нужно бинарник положить целиком в память, и найти офсет на начало нужно картинки в бинарнике. Вам указатель на картиночку нужен а не картиночка. Вы как обычно плодите буферы на буферы которые буферами погоняют. А зачем вам это?
Это как? Большинство систем настроены на виртуализацию памяти. И все файлики дифолтно читаются в память, а затем с ними можно что либо делать. Если вы используете иные механизмы - это такое себе... Потестируйте апи, я вот не знаю про линуксовые апи в случае с IO, но железки везде одинаковые. Обратите внимание на железо прежде всего. Никакое проганье не должно быть оторвано от железа, иначе это не проганье а порнография. У винта есть кеш. Кеш большой. Кеш больше вашей картинки. Причём нынче уже сильно больше, десятки мегабайт, уже иногда и сотни и более. Как вы читаете картинку с диска? Вы читаете её как то через кеш диска. Но если вы читаете по одной картинке, то вы не используете кеш по максимуму. Иначе говоря картинка у вас мегабайт (условно), вы читаете в кеш диска, из кеша в куда то там [в оперативку конечно же, но у вас не так, ну да ладно], однако же проще и эффективнее зачитывать куски примерно равные размеру кеша диска [или кратные ему]. Т.е. файлики и должны быть прилично большими, но не слишком большими.
Возьмите и потестируйте IO-операции. Наплодите 256 файликов пофиг с чем каждый размером мегабайт, и один файлик размером 256 мегабайт. И читайте в оперативку и то и то. Или куда оно вам надо. Один большой кусок прочитается быстрее.
Линукс это не лучшая ос. Для прогера - совершенно нет. Для прогера это ацкий ужас и кошмар. И вообще то линукс это не ос, это вроде бы как ядро. А вот то что поверх ядра накарячено в виде конечной ос - это уже ос и есть. Все ос разные, ядро вроде как одно. Как настроены ос - так они и работают. И все эти опирационки разные. Линкус вроде как один, а толку особо от этого нету. Ещё раз подчеркну - для прогера нету. Потому что операционки слишком отличаются. И запрогать под это всё что бы оно хотя бы работало везде - это проблема. А вот запрогать так, что бы оно везде хотя бы быстро работало - это очень сложно. А уж запрогать так что бы оно максимально быстро работало везде - это нерешаемая задача. Ну и как? Линукс лучшая ос? А для кого лучшая то?) Для дурачька торвальдса который двадцать лет ядро не меняет и векторы в ядро завести не может? Который не может уже накорячить прям в ядро линукса аналог GDI который работает вообще без видеокарты и выпилить нахрен никому не нужные бестолковые иксы? Вот потому то в этих ваших линуксах ничего и не работает. Для прогера. Потому что даже шрифт толком однообразно не прикрутишь. Потому что убожественное ядро линукса ничего не может. Потому и даже шрифты "у вас" никогда толком и не работали. А казалось бы это банальность вроде как. Ну да ну да. Везде это банальность, кроме линуксов. Отличная "ос" что тут скажешь. И т.д. и т.п.
У вас не какой то непонятный плагин должен картиночки загружать. Он вообще ничего не должен. Боже упаси))) Потому что не должен. Ибо непонятно будет ли "постпроцессинг" с картиночками в дальнейшем.
Нужен "калупатор" картиночек с диска. Это одно. С калупатора вам нужен указатель на картиночку и всё.
Нужен рендер картиночек получающий пачку указателей на картиночки.
Нужен "пробросчик" указателей из одного в другое. Это отдельный модуль. Смысл тут в том, что вы можете имея этот отдельный "пробросчик" - что либо сделать с картиночками ещё, дорисовать на них что-то изменить, балансы цвета подправить, анализировать это всё можно как то и т.д. и т.п. Не факт что оно будет юзаться в прадакшене, так оно вам должно быть нужно а не прадакшену)) Похоже у вас там как обычно набраны никчомные либы которые как обычно не соединяются) Впрочем нынче прогать так модно стильно маладёжно. Глючная фигня получается как обычно, ну да ладно. Пробросчик изменит картиночку, но она доложна в памяти как то лежать уже готовая, иначе как её изменить то?
Да просто реализовали, ибо чем проще - тем быстрее [почти всегда].
Там условный хеадер должен быть и его длина, в хеадере офсеты на другие хеадеры. В свою очередь эти хеадеры содержат офсеты на начала картиночек. В итоге этот бинарник это немножко офсетов на начала данных и собственно данные.
Библиотека читает всю бд с диска, кладёт целиком в память, далее "парсит" байтики, т.е. находит смещения по заголовкам на начала данных. Причём эти начала данных всмысле указатели на начала не нужно где то держать в очередном массиве. Всё должно быть
"линейно" - подайте число на вход [номер вашего тайла], получите число на выходе [всмысле указатель]. Вот и всё. Более ничего и не нужно.
Что можно и нужно добавить сюда. Опять и снова проблемы архитектуры. Межбиблиотечные взаимодействия губят производительность. Иначе говоря не плодите библиотеки на каждый чих, либо же делайте библиотеки так, что бы обмен данными между ними был минимальным.
Пример: реализуйте собственные перечисления. Пихните это всё в библиотеку. Наследуйтесь от этой библиотеки и вы погубите производительность перечислений примерно до полутора раз.
Смысл: если вы тащщите много данных из библиотеки - это не выход. ТащИте мало данных, библиотека должна "обсчитывать" всё что можно в пределах библиотеки и не выходить за эти пределы, и в итоге вы должны получать маленькие данные, которыми уже и пользуйтесь на выходе из библиотеки.
Иначе говоря у вас есть библиотека "калупающая" эти самые бинарники, где лежат картиночки. Внимательно потестируйте выходное апи этого всего. И проведите тест безбиблиотечный. Код который вы запихаете в библиотеку иногда есть смысл не пихать в библиотеку, а прям "заинлайнить" "копипастой" туда где оно вызывается непосредственно. Межбиблиотечные вызовы иногда могут оказаться критичными, учитывайте это.
Бинарники должны быть короткими. Выше написано что лучше всё читать с диска куском враз. Например кусок может содержать в себе 256 картиночек. Целиком читайте этот кусог в оперативку, из него берите то что нужно, а нужно из него будет многое, потому то и проще читануть приличный кусог, но не шибко большой конечно же. Тут нужны тесты.
Далее. Вы же это всё обновлять как то будете. Ну не вы а юзер конечно же. Что юзеру надо - он то и обновит. Обновлять как обновляют нынче всё что есть гигантскими кусками - это вообще путь дегенерата. Но это почему то повсеместно практикуется. Почему? Ахз почему. Стильно модно маладёжно. Наверное. Правда это дичайшая дичандра, но кого это волнует?
Проблемы с бг-мерским линуксом не забывайте. Они все настроены по разному, это не вёнда где всё всегда одинаково. В вёнде что либо затюнить под производительность почти пара пустяков, ну потому что всё у всех одинаково насторено. Линуксы же в этом плане это аццкий гимарой на сраку ибо они все разные настроено всё по разному и учесть все возможные конфигурации настроек в линуксе и подстроить под это производительность это тот ещё квест.
И т.д. и т.п.
Не совсем верный подход у вас, впрочем заказчику конечно же виднее. Однако же заказчик в этом всём ничерта не понимает, вот в чём проблема. Так что решать в любом случае вам, а не заказчику.
Так вот, всё что вы делаете - должно работать, это очевидно. Но как работать? Вы пишете - максимально быстро. "Максимально быстро" и "быстро" - сильно отличаются. Максимально быстро - это значит быстрее и быть не может. Причём это самое "максимально быстро" придётся доказывать. Т.е. что бы утверждать что оно "максимально быстро" - нужно доказать то, что все прочие реализации будут медленнее. А как вы это докажете?) Проблема.
Вы скажете это словоблудие? Отнюдь нет. Вы сказали - ну значит и делайте как сказали. Опять проблема, потому что вы доказать ничего не сможете.
Вы сами же пишете - изобрели велосипед, но стоило ли оно того, если сравнивать не с чем? Проблема))
Это я всего лишь про то, на что как обычно влетают начинающие прогеры. Прогают не на том, прогают не туда, прогают не то. Всё как обычно, и конечно же в этом ничего страшного нет.
Первое что вы должны получить - это валидный продукт, это значит напишите быстро и получите 100% работающее. С какой скоростью оно работает - это вообще не важно.
Про скорости. Вам пол-жизни не хватит, что бы написать рендер на 30 картиночек, такой что максимально быстрый. Вовсе не шучу. Оно так и есть. Пишите лишь бы работало, а уже после причём не кому то а себе - напишете куски быстрых реализаций, но на это у вас пол-жизни уйдёт, ещё раз говорю) Не верите? А это не вопрос веры. Давайте по существу, почему нет?
Как оно работает? Есть бд - пусть это файловая система [это тоже бд], или узкоспециализированная штука которые и называются бд - это не суть. Есть и есть. Как они работают? По каким то там запросам они отдают объекты. Объекты иногда кешируются, иногда нет, оно иногда настраивается, иногда нет. Бд может следить за собой ну например как файловая система и быть отказоустойчивой, а иногда бд за собой не следят как тот же скюель и в общем то это почти бесполезные бд [ну потому что бесполезные]. Все они работают как обычно на "вставку"/"удаление"/"изменение" и т.д. всё стандартно, иногда сами самовосстанавливаются и прочее прочее. Суть - они все динамические, а динамический - это изменяющийся по времени [по определению]. Далее вы тут сами напишите портянку про бд себе, и допишите сюда всё то что сейчас существует.
А ТЕПЕРЬ ДАВАЙТЕ ПОСМОТРИМ НА ВСЁ ЭТО И НА ТО ЧТО ВАМ НУЖНО)))))
Вам не нужна динамическая бд, вам не нужны объекты, вам не нужны запросы, вам не нужны поиски, вам не нужно от этого всего вообще ничего. А то что вам нужно - в этом всём НЕТУ)
Что вам нужно? Максимально быстро, отказоустойчиво, просто и желательно иметь поверх такое апи, что бы оно было по вашей задаче максимально простым и даже тривиальным. Иначе говоря вы суёте число и получаете картинку. Вот что нужно.
Теперь конкретно. Статических бд нет, статических бд отдающщих не объекты а указатели на них нет, статических отказоустойчивых бд нет, ничерта нет) Гонг вопрос: сколько это всё вы будете писать? И дело не в писанине тут. До писанины вы даже не дойдёте. Потому что перед тем как что то писать - нужно вообще то понимать что будет в итоге. А в итоге получается вообще принципиально иная архитектура, нежели имеющиеся. Ну вы же хотели максимально быстро? Хотели? Ну получите. У вас джиельобёртки напрямую и должны получать по hex-числу указатель на кусог бд И ВСЁ)))))) В случае чего бд должна самовосстановиться. Более ничего тут и не нужно.
А теперь сколько по времени вы это всё собираетесь писать? Понятно или нет?) Никогда вы сие не напишете, потому что это очень сложно, почти невозможно это. Для вас во всяком случае сейчас и ещё лет десять сверху - это в принципе не реализуемая задачька. Так вот я всего лишь про то, что пишите как есть, как вы задумали - так и пишите. И разбирайтесь в алгоритмах, это очень важно. Под алгоритмами я вовсе не понимаю тут какие то мат.алгоритмы, это не то, про них можно почитать и потестить и всё такое. Разбирайтесь в алгоритмах как что работает на самом деле. Алгоритм в данном случае - это как раз таки пример того что написано выше про бд в целом. Ещё это всё называют архитектурой. Вот для вас это важно. Как и что работает на самом деле.
И не слушайте брюзжащих старпёров, ибо да они сильно знают как и что работает на самом деле. Но писать то вам, а не мне) Так что пишите как задумали, и никого не слушайте. А вот когда напишете - тогда может быть [и то не факт] и поглядите что можно исправить и подправить. Даже могу объяснить почему это выгодно. Вы являетесь по сути программой, конечным автоматом с ножками и ручками. Вы как программа запущены в треде. Если кто-то лезет в тред - он тормозит тред) Нельзя лочить тред, от этого будет только хуже, причём сильно хуже. Вы как программа запущены и исполняетесь, ну и исполняйтесь. Вот когда ваше исполнение закончится, вот тогда можно анализировать результаты вашего исполнения, смотреть время, корректность результата и т.д. А до тех пор влезать в ваш тред никак нельзя, так что удачи вам а точнее вашему треду, как напишете - так и приходите с результатами) Оно будет конечно не интересно, глупо, ужасно, убого, дебильно, монструозно, велосипедно, ужасающе медленно - ну и что? Оно будет ваше и оно будет работать. Это главное.
"тайл с x=45917, y=53960 на зуме в 100 по пути root/100/45/917/53/960"
Там квадранты которые можно и нужно держать в hex, зума 100 не будет, максимум 14-16, может быть под 18 но это редкость.
"а для доступа к картинке обращаетесь к
root/<n / N>/<n % N>.png, где первое — целочисленное деление, второе — взятие остатка"Своя алгебра у квадрантов, делений никаких тут не нужно, всё на сдвигах.
Автору рекомендую сильно пережать картинки в jpeg и запаковать в архивы без сжатия. В моём варианте я в рар упаковал блоками по 256 (64 и т.д. по зуму) штук, без сжатия но с информацией для восстановления. Если коннектор до картинок колупает картинку с ошибкой, то запускается восстановление архива и иногда оно действительно помогало. Заодно напишите чекер этих баз, что бы проверять корректность всех картинок враз. Отказоустойчивость - хорошая и удобная штука.
Если у автора нет квадрантов - рекомендую перейти на них, но вроде бы у автора они как раз таки и есть.
Реализовывал такую же хрень лет 10 назад тестил на древних атомах первых - работало отлично, тормозов не было. Писалось на шарпе с почти готовой обёрткой вокруг unrar.dll и прикручено оно было естественно на обёртках OpenGL для отрисовки.
Плюсы тут не совсем нужны, если есть возможность - юзайте попроще, разницы почти не будет. Ей неоткуда браться. Всё слишком просто тут и почти топорно. По оперативке можете чютка просесть, но и это решаемо.
п.с.: Автор, усиленно на квадранты перейти рекомендую) Никаких xy тут нет, тут одно число, четверичное. Ваш x,y = {00, 01,10,11} = {0,1,2,3} в четверичной. Далее нужна алгебра от этого четверичного числа влево/вправо/вверх/вниз - это 4 операции условно два сложения два вычитания. Всё это не даёт коллизий. Картинки тоже так же переподпишите. Тайл x,y = 3FA0A7.jpeg, папки так же шестнадцатеричные. Это математика. Да да, без неё никак. Придётся кое что придумать и реализовать самостоятельно. Работать будет и работать будет хорошо.
Лицензия бессрочная, а толку то? Если её в любой момент могут сменить на такую, которая вас никак не устроит, например.
И т.д. и т.п.
нейрон != мозг
Ньютону для [пусть и не совсем корректного] определения сил гравитации не потребовался гравитон. А вам зачем нейрон?
Если между ними нет разницы, а у вас нет никакой разницы - то вы ничего и не нашли. Выше написано про понимание. А понимание - есть сравнение. Какую разницу "вы" нашли в этих трёх репрезентациях [причём это непонять что] по результатам сканирования мозга?
Есть компьютер, там "дрейфуют" электроны/дырки и прочее полупроводниковое не суть. Каким образом по дрейфу этого всего вы определите где там "красный", "кирпич" и "землекоп"? Однако же они там есть [если они там есть] и почти прекрасно описываются абстракциями. Однако же никакое сканирование процессора эти абстракции не покажет. И проблема тут на самом деле грандиозная. Если вы не знаете что искать - так вы никогда и не найдёте. А что вы ищете? Прежде чем что-либо искать - вообще то моделируют то что ищут. Смоделируйте абстракцию на бумашке - тогда и ищите. А сможете смоделировать?
Это не миф, это логика. Единственное что можно добавить сюда - это надёжность предсказаний. Иногда эта надёжность не достаточная - но это всего лишь значит, что логика не полна.
Самый устойчивый миф к сожалению не приведён, впрочем это нормально.
Миф: Что бы понять как работают мозги - нужно их непременно расколупать и что-то померить. Или не колупать, и всё равно что-то померить.
Однако же никакие колупания и измерения никогда не приблизят "колупателей" и "измерителей" к пониманию абстракций ну например "красного", "кирпича" и "землекопа".
А тогда зачем это всё?)