Знаешь, но не придаёшь значения. Ты пофигительски относишься к тэгам, я вижу у тебя перехлёст нескольких, которые нельзя так использовать.Сообщение от zebest
ps - откуда лишний спролер - не знайю
Знаешь, но не придаёшь значения. Ты пофигительски относишься к тэгам, я вижу у тебя перехлёст нескольких, которые нельзя так использовать.ps - откуда лишний спролер - не знайю
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
zebest, а ты не нервничай, аппетит пропадёт. Вчера я просто нажал "цитата" и увидел, что тэг COLOR у тебя закрывался следом за открытием SPOILER. Сам SPOILER в цитате был один, но предпросмотр порождал два, как в твоём сообщении. Я перенёс закрытие тэга COLOR до открытия тэга SPOILER и всё починилось. А вот правильная расстановка тэга это ответственность пользователя. Например, для чего ты поставил тэг COLOR#000000? Это чёрный цвет и он по умолчанию.
Ну, молодец, молодец, ускорил в 5 раз
Теперь напиши это на псевдоассемблере и ещё ассемблер, генерирующий прогу для любого из компов, что есть у меня в эмуляторе
[/sarcasm detection off]
А тебя не смущает, что по ссылке, которую приводил litwr, программа на си считает 800 знаков за 1,458,354,526 тактов? Если попробовать сравнить, то 535 знаков она посчитала бы примерно за 1,458,354,526/2,2=662888420 тактов. Т.е. сейчас программа на асме 8080 наконец-то стала считать быстрее программы на си для z80. Как то не очень круто, если учесть, что в той проге используются и 32 битные операции. Алгоритм, который используется в сишном варианте по ссылке очень похож на spigot, но, если я правильно понимаю, переводит не по одной цифре, а по 4.
[/sarcasm detection on]
А это и есть тот же spigot только переводит в систему с основанием 10000. Ну и массив 32-битный, чтобы не переполнялись члены. Кстати, возможно, там ошибка - если будет 9999 и перенос из следующего разряда. Вероятность небольшая, но пи - число иррациональное и трансцендентное
LLVM с его IR (intermediate representation, по факту это псевдоассемблер), возможно "спасет отца русской демократии"Теперь напиши это на псевдоассемблере и ещё ассемблер, генерирующий прогу для любого из компов, что есть у меня в эмуляторе
Из интереса посчитал той программкой 1600 знаков - все ОК, т.е. по крайней мере в этом районе все нормально.
На i5 показывает время расчета в районе сотых долей секунды, насколько все же далеко вперед ушло развитие процессоров.
Если совсем грубо, то вероятность появления "цифры" означающей 9999 - порядка 1/10000, да еще и перенос должен быть из следующего разряда, то есть вероятность около 1/100К, поэтому ошибка от 100К знаков может вылезти. Это если она там есть (вдруг ряд сходится так быстро что перенос не возникает), пока это только мое подозрение.
Смущает. Там есть одна хитрость, которая позволит ускорить наш spigot ( уже наш
- - - Добавлено - - -
Может просто тупо тот алгоритм на асме переписать? Хотя, основная масса времени это всё равно умножение/деление, не думаю, что в сишном рантайме они какие-то неоптимальные.
- - - Добавлено - - -
Если только использовать не чисто 32-битные умножение/деление, а смешанные 32/16 битные. В том алгоритме явно указано, что нужно умножать uint32 на uint32, ну и делить также. А на самом деле нужно uint16*uint16 -> uint32, а затем uint32/uint16 -> uint16.
У тебя есть готовые арифметические процедуры для 32 разрядных? Если да, то я за "тупое переписывание". Пусть даже будет медленнее, чем pirk20, зато больше цифр можно считать.
У меня были процедурки для 32битных, но они, насколько помню, в архиве на другом компе, который сдох (но винт целый).
Ну и у нас ещё одно преимущество: вместо двух операций / и % мы делаем это за одну операцию. Фактически, тоже ускорение почти в два раза.
- - - Добавлено - - -
16*16 -> 32 вроде где-то было (FAT?), а вот деления точно не было. Но что нам стоит дом построить?
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
