Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Geniepro

Страницы: [1] 2 3 ... 131
1
Общий раздел / Re: Мы выиграли Старт!
« : Май 21, 2018, 11:12:35 am »
Что с проектом-то? Он жив? Или помер давно? Сайт не открывается...

2
А OberonJS даёт какие-то торможения по сравнению с обычным JS?

3
Говорят, Мозилла со свим Rust'ом оченно сильно ускорила свой JS-движок, какие сейчас там результаты этого теста?

4
Урочище Флуда / Re: Тихий пк
« : Февраль 21, 2018, 06:10:50 pm »
теоретически это всё можно запихнуть в герметичный ящик и залить маслом, а к ящику прикрутить большие радиаторы пассивные, тогда греться не должно...

5
Полгода прошло, какие выводы-то?
Сам я так и не осилил решение на Расте. Вроде на нём можно сделать вполне шустрый код, но выглядит он как говно, смотреть страшно, аж глаза кровоточат...

6
Общий раздел / Re: OberonJS
« : Февраль 18, 2017, 08:31:08 pm »
Вот такой еще вопрос.

PROCEDURE Sin* (x: REAL): REAL;
  VAR res: REAL;
BEGIN
JS.do("res = Math.sin(x)");
RETURN res
END Sin;

Возможно ли вернуть результат без создания переменной res?

А если вот так:
PROCEDURE Sin* (x: REAL): REAL;
BEGIN
JS.do("return Math.sin(x)");
END Sin;

7
Ну, мы уже знаем, в чём причина таких результатов -- в чьей-то криворукости )))

8
Предлагаю добавить в тесты файлы с нестандартными размерами, например 119 946 308 байт или 163 840 004 байт (достаточно большое простое число, умноженное на 4). Идея в том, что бы файл не делился на блоки равных размеров -- это может выявить ошибки в алгоритмах сортировки.
Особенно интересно в этом плане число 163 840 004 -- это 4*(80^4+1)...

9
Предлагаю добавить в тесты файлы с нестандартными размерами, например 119 946 308 байт или 163 840 004 байт (достаточно большое простое число, умноженное на 4). Идея в том, что бы файл не делился на блоки равных размеров -- это может выявить ошибки в алгоритмах сортировки.

10
Решение на модуле-2 (собираемое через gnu modula-2 compiler) работает похоже что корректно. Поэтому запустил прогон. И да, похоже comdiv выкатил новое решение которое снова самое быстрое. :-)

Через 3-4 часа будут результаты.
Чота ты это не в той теме написал ))

11
Хм, на FAT32 все работает, даже XDS.
На FAT32 же нельзя делать файлы объёмом даже в 4 гигабайта ровно -- только меньше...
Это если размер кластера не менять. Но если его увеличить, то и размер файла может быть гораздо больше, чем 4 ГБ.
И как это сделать? Вот я взял и отформатировал флешку 32 ГБт в FAT32, указав максимальный размер кластера -- 64 кБт, но файл размером 4.3 ГБт всё равно не записывается -- запись прерывается на 91% файла. Выходит, что не работает этот рецепт...

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

https://dzone.com/articles/duck-typing-scala-structural

Возможно, в питоне что-то такое есть, там же тоже "утиная типизация"...

13
Хм, на FAT32 все работает, даже XDS.
На FAT32 же нельзя делать файлы объёмом даже в 4 гигабайта ровно -- только меньше...

14
Я сравнивал суммы чисел - такая упрощенная статистика.
Ну, сумма чисел -- это упрощённая контрольная сумма, тогда уж лучше сразу хеш делать, например SHA-2, а не MD5...

15
Не понятно... Почему неубывающая последовательность неправильна?

И почему равенство значений подменяется равенством хэшей?

Потому, что вот псевдокод который пройдет твой тест:
in := open("input");
out := create("output");
for i:=0; i<in.size/4; ++i {
    out.write(i);
}
При этом он ничего сортировать не будет. Ему вообще плевать на входные данные, ему важно только сколько этих данных.
В таком случае надо добавить проверку статистики файла -- сколько тех или иных чисел в обоих файлах ))

Страницы: [1] 2 3 ... 131