#f#
#f#
Вопрос:
Я вижу, что в F # тип List.length равен ‘список -> int
Можно ли с уверенностью предположить, что int всегда будет достаточно большим, чтобы содержать размер любого списка, который я мог бы создать, и это потому, что списки ограничены элементами 4G?
В книге, которую я изучаю (эксперт F # 2.0), говорится, что int и int32 имеют одинаковый размер, поэтому я начал писать свою первую программу с typedef для size_t . Это проблема, потому что это требует от меня явного указания компилятору, какие константы типа я имею в виду (например, 7UL вместо просто 7), хотя я ожидаю, что этого можно было бы избежать, превратив size_t в объект с помощью конструктора int. Я также ожидаю, что это вызовет ряд других проблем 🙁
Итак, каково обычное решение, пожалуйста? Должен ли я просто использовать целые числа везде и игнорировать барьер 4G? Индексы массива тоже являются целыми числами, поэтому я не смог бы сделать много полезного с моим типом size_t, даже если я смогу реализовать его достаточно хорошо для использования.
Заранее большое спасибо.
Комментарии:
1. Буквальным эквивалентом
size_tв F # являетсяunativeint, но вы редко используете этот тип на практике, кроме как при выполнении P / Invoke .
Ответ №1:
В .NET вы можете выделить только массив размером 2 ГБ (даже если вы используете 64-разрядную версию и у вас достаточно памяти). Если вы действительно хотите сохранить такое количество данных, то вы, вероятно, захотите использовать массивы, потому что списки F # имеют большие накладные расходы.
По этой причине вам, вероятно, не нужно беспокоиться о том, что длина ограничена 32 int битами. Единственный случай, когда вам было бы интересно, это если бы вы писали структуру данных, чтобы обойти это ограничение в 2 ГБ.
Комментарии:
1. Большое спасибо. Это довольно разочаровывает, и бородавка на в остальном превосходном языке. Хотя мне сейчас не нужны структуры данных с элементами> 2G, я ожидаю, что в конечном итоге они понадобятся всем, так же как все в конечном итоге хотели больше, чем 640 КБ оперативной памяти. Это также означает, что нужно вводить очень много явных проверок, потому что целые числа обтекаются бесшумно. Тем не менее, еще раз спасибо.
2. @user982776: тогда вы, вероятно, могли бы найти лучшую структуру данных. Например, при 3D-рендеринге вы храните текстуру размером, скажем, 16k * 16k пикселей в одном большом массиве, а скорее вектор mipmaps, каждый mipmap представляет собой вектор небольших блоков, удобных для кэша, которые могут быть загружены по требованию.
3. @user982776 Да — это немного неудачная вещь о .NET. Первые пользователи F # в Microsoft Research, которые занимались машинным обучением на огромных наборах данных, столкнулись с этим ограничением, но тогда вы можете найти некоторое иерархическое представление (массив массивов), которое будет работать нормально…
Ответ №2:
Для массива целых чисел 4G потребуется 16 ГБ оперативной памяти, и это только для целых чисел (и ничего более сложного). Если у вас не так много памяти, нет причин беспокоиться об этом ограничении. Если вы действительно хотите использовать столько памяти, рассмотрите возможность разделения вашего массива на 2-3 массива.
Комментарии:
1. Кроме того: если вы достигнете точки, когда вам понадобится 16 ГБ оперативной памяти, есть хорошие изменения, вы просто делаете что-то не так. Это сумасшедший объем оперативной памяти.
Ответ №3:
В .NET используйте «int» для размеров коллекции. Он достаточно велик для случая 99,999%, и лучше всего иметь стандартные типы во всех API.