В общем случае - нет.
В качественном коде ненулевой указатель указывает на объект допустимого типа. При разрушении указатель обнуляется, чтобы больше не указывать на объекты.
becks: Если брать остаток от деления на простое число, то вероятность коллизий ооооочень низкая. С учётом того, что GUID всего вдвое больше остатка, то на практике вероятность коллизий почти нулевая. Главное, чтобы делитель 65 битным был простым числом, тогда остаток будет 64 бита.
uvelichitel: Я не знаю возможностей golang. Если разруливать коллизии (про несколько деревьев уже писали в первом ответе), то достаточно ксорить все символы строки. Если коллизии постараться избежать, то md5, но там много битовых операций. Если golang умеет в деление больших чисел, то можно остаток от деления на простое число считать. Ради словаря в 500 слов нет смысла заморачиваться и можно обычное дерево строить (8 сравнений строк в среднем потребуется). Даже ради 10000 слов особого смысла нет (всего 14 сравнений потребуется).
uvelichitel: Я понял. Дороговизна хэш-функции зависит от того, что за хэш функция. Можно хоть CRC считать, хоть банально ксорить буквы (но не надо)...
Сортированный массив имеет смысл делать только если заранее известно количество разных слов (а это не известно). Так что строй дерево и не парься, тем более памяти полно.
uvelichitel: "дешевле" только по использованию памяти и времени поиска в дереве. Хэш - сравнительно небольшое бинарное число (4-8 байт). Слова в юникоде будут иметь гораздо больший объём и сравниваться будут посимвольно. Т.е. чем больше длина слов и, чем больше вообще слов (больше высота дерева), тем больше будет выгода от хэширования.
Не знаком со спецификой golang, может на нём и нет разницы, но на настоящих языках программирования с числами работа происходит существенно быстрее, чем со строками.
Алексей Михайлусов: Слабо знаком с системой исключений Java. Не исключаю, что придётся создавать новый объект Scanner. Если нарушен инвариант, то другого выбора может не быть.
Сергей Соколов: Жаль, что не повторяются. Но! Раз данных много и числа не повторяются, то чем этих данных больше, тем меньше становится вариантов распределения разниц, между числами! В пределе, у тебя останется всего одна разница, равная "1".
Вариант из UPD обеспечит от почти никакого, до почти четырёхкратного сжатия, что само по себе неплохо. Но! Чем больше данных, тем меньше вариантов инкрементов. Так что для них вполне имеет смысл динамически строить дерево Хаффмана. Только я пока не сильно представляю, как его передавать в файле. Возможно, уменьшить блоки до трёх чисел и в свободном байте кодировать либо код Хаффмана, либо что реальные инкременты записываются. Тогда, чем больше будет размер файлов, тем более эффективно будет сжатие инкрементов работать. Опять же, в пределе, каждый блок из 3-4 чисел будет сжат в один бит. Это когда вся последовать будет различаться на единичку.)
На практике, твоего решения должно быть достаточно, если трёхкратное сжатие тебя устроит.
Сергей Соколов: Я потому и говорю о потоковом сжатии, а не об отдельном зиповании (для эксперимента это было быстрее и я всё-равно не знаю php). Я говорю об архивировании данных на лету, когда ты посылаешь байт в поток вывода, он не просто пишется на диск, а предварительно архивируется (т.е. в поток может и не попасть, пока хотя бы один байт не сформируется). Только не знаю, как это сделать на php и можно ли вообще так сделать.
Если есть много повторяющихся данных, то есть смысл попробовать RLE компрессию. Это когда сперва пишешь количество одинаковых чисел, а потом само число. При чтении они будут записаны нужное число раз. Но это сработает только если бОльшая часть чисел повторяется хотя бы по два раза. Мне опять стало интересно, я сейчас это на своём тестике проверю, что получится. У меня много повторяющихся чисел там.
Сергей Соколов: Для эксперимента написал программку, которая генерирует 100 миллионов чисел, отсортировал по возрастанию и сохранил как есть и разницу между соседними. Получилось два 400 мегабайтных файла. Сжал зипом с настройками по умолчанию, получилось 115 мегабайт для полного файла и 81 мегабайт для файла с разницами. У меня была "плохая" случайность чисел, поэтому различие между полными числами и разницами не существенная. Чем больше у тебя объём данных и чем случайнее числа, тем больше будет разница между двумя вариантами. Так что я всё-таки рекомендую именно потоковое сжатие.
Если ты будешь как-то более хитро обрабатывать данные, например, сохранять разницу в виде 1-3 байтов и флаг того, сколько байтов используется (два бита), то ты лишь увеличишь энтропию и данные будут гораздо хуже сжиматься архиваторами. Без архивирования, в лучшем случае, получится каждый 32 битный int уменьшить до 10 бит. Т.е. на треть. В моём примере это было бы 133 мегабайта. При этом код будет сложным и медленным. И вообще, на php есть возможность работы на уровне битов?
Сергей Соколов: Я на 100% уверен, что в php есть сжатие/распаковка потоковых данных чем-нибудь типа зипа. Код Хаффмана применённый непосредственно к последовательности данных будет мало эффективен, особенно, если кодировать по 32 битному числу. В том же зипе кодом Хаффмана кодируется только словарь (если не ошибаюсь), а данные кодируются прогрессивным алгоритмом (не помню названия), в котором кодируемые блоки постепенно увеличиваются в размере... В общем, я настоятельно не советую изобретать велосипед. php не для этого придумали, а чтобы использовать готовое.
Сергей Соколов: Не-не-не, никакого распределения. Сохряняются инкременты для 32 битных чисел. Т.е. в большинстве случаев это будут малые числа. Даже зип такую последовательность хорошо пожмёт. Это на случайных данных такой алгоритм ничего не даст, но тут же упорядоченные. Т.е. доподлинно известно, что разница будет положительным числом или нулём, и дополнительный бит для знака не понадобится. Мне даже захотелось написать программку, чтобы проверить гипотезу о резком улучшении качества сжатия.)
Flie: Если есть документация (даже не сильно актуальная), то полистай её. Если в коде есть комментарии, то прогони все исходники через doxygen со включённой генерацией диаграмм и иерархий классов - наглядно увидишь иерархии наследования и вызовов.
Было бы неплохо прогнать все исходники через какую-нибудь утилиту форматирования (типа решарпера в С#), чтобы привести весь код к единому стилю. Разобраться в хаосе проще, если он выглядит более-менее однообразно.
Разбирая код, сразу же комментируй функции и участки кода, которые смог понять. Потом ещё раз прогонишь доксигеном и у тебя будет документация к коду.
Почитать... По рефакторингу есть книжек несколько, а вот по разбору чужого кода нету, кажется.
Flie: Начинать лучше под надзором синьора. Когда ты один и не у кого спросить помощи... Это очень интересно и захватывающе! Но очень сложно. Главное, не теряй веры в свои силы, даже если сперва не будет получаться.
В чужом коде разбираться может быть очень сложно. Особенно, если была текучка программистов и каждый писал кучку говнокода.
pudovMaxim: И постоянный шум есть, но иногда его и нет. И от СМС не всегда шумит. Грешу на какое-нибудь высокочастотное оборудование у соседей, которое по электросети помехи пускает, но ведь пилот и бесперебойник... Наберусь смелости и раскурочу колонки.)
Я правильно понимаю, что усилитель это индукционная катушка и именно её мне и нужно искать на плате? И фольгу припаять к "земле", обернув катушку и изолировав фольгу от самой катушки? Паяльником владею на уровне мартышки, которой указывают, куда ткнуть. Но тыкаю уверенно и точно.)
3G только у соседей может быть есть. Роутеров ловится пять штук (включая мой), но гудит-то не постоянно. И от телефона пискающий треск пару секунд идёт (обычно), а тут может хоть пол часа гудеть.
Вот хочется как-то им указать, чтобы выбранные диски даже не пытались дёргать. Чтобы даже не видели их инсталляторы, вполне устроит. Задержки порой дольше, чем вся установка. Сидишь, секунд 5-7 ждёшь, пока инсталлятор тупит, потом мгновенно на SSD всё ставит. Так грустно от этого.
В качественном коде ненулевой указатель указывает на объект допустимого типа. При разрушении указатель обнуляется, чтобы больше не указывать на объекты.