Что вы думаете о таком методе деления?

думаю, что из-за того, что делят в убогом языке

Никакого профита. Результат будет тот же при меньшей производительности.

а если нацело не делится?

Как у такого метода с точностью, когда числа большие?

> а если нацело не делится?

деление с остатком

возьми и проверь, тут всё от языка зависит

В данном случае речь идет о реализации команды деления в процессоре

Исполни в питоне, посмотри результат.

round округляет до ближайшего целого

никак — тоже самое, что и интовое деление:

1024 / 49 = 20

1024.0 / 49.0 = (int)20.89795918367346938775 = 20

поддерживаю segfault — производительность сильно падает, особенно на микроконтоллерах, а профита — ноль целых, ноль десятых

> 1024.0 / 49.0

Это небольшие числа.

Ну да, и что? Не сказано же, как обратно в целое переводится.

> Не сказано же, как обратно в целое переводится.

под делением целых чисел обычно понимается деление с остатком

и что? ну, добавь пятьдесят нулей, будет тоже самое.

На больших эффективнее:

#! /usr/bin/env python3

for i in range(1, 2**20):
        2**102/(2**55-2**33+34435)

$ time ./tst1.py 

real    0m0.447s
user    0m0.440s
sys     0m0.000s

#! /usr/bin/env python3

for i in range(1, 2**20):
        2**102//(2**55-2**33+34435)

$ time ./tst2.py 

real    0m0.597s
user    0m0.590s
sys     0m0.000s

это ещё ни о чём не говорит — не известно как оно в питоне устроенно

в процессоре используют команды div или сдвиги. на входе два целых, на выходе частное и остаток. если компилятор компиляет как-то иначе, выбросить и поискать другой

Это говорит о том, что в питоне long менее эффективен, чем float.

исходя из использованных тобой 2**102 там вообще bignum, а не float с long'ом. на отрезание остатка уходит соответственно больше времени.

Что вы думаете о таком методе деления?

Мейоз - наше всё!

Кроссинговером по конъюгациям!

Почитайте http://ridiculousfish.com/blog/posts/labor-of-division-episode-i.html

>Что вы думаете о таком методе деления?

не вижу проблемы. если скорость от этого повышается.

>Как у такого метода с точностью, когда числа большие?

все нормально должно быть. Так как деление - это «хорошая» операция. Она уменьшает «ошибку ввода».

>Как у такого метода с точностью, когда числа большие?

хотя может возникнуть проблема, если сопроцессор вернет число к примеру не 0.45e10, а 0.4499999999999e10. тогда непонятно, делится ли число без остатка, или нет.

>производительность сильно падает, особенно на микроконтоллерах, а профита — ноль целых, ноль десятых

В прошлом веке сопроцессор Intel 8087 использовался как самостоятельный микроконтроллер в компактных «спец.железяках» для нелинейного управления.

>Как у такого метода с точностью, когда числа большие?

вот тебе пример. даже больших чисел не надо:

если ты выберешь функцию round, как «базу», то тогда такой пример не заработает:

делишь 9 на 2. получаешь от сопроцессора 0.45e1, round отдает 5. А получаешь 0.44999999e1, round отдаст 4.

А выберешь функцию floor, как «базу», то тогда при делении 10/1 можешь получить 0.99999999e1, с понятным результатом :)

> все нормально должно быть.

double - 64 бита всего. Из них 52 - мантисса, 11 - степень и знак

Это значит, что точность деления чисел от 2^53 до 2^64-1 будет ниже, чем при использовании int

>> все нормально должно быть.

double - 64 бита всего. Из них 52 - мантисса, 11 - степень и знак

Это значит, что точность деления чисел от 2^53 до 2^64-1 будет ниже, чем при использовании int

хых. Я думал, что данный очевидный «минус» этого метода был уже учтен.

Но даже если бы это было не так, то есть мантисса была бы тоже 64 бита, как и int. То трабл был бы все равно. И как его победить, так с наскоку не видно (см. мой предыдущий пост).

> хых. Я думал, что данный очевидный «минус» этого метода был уже учтен.

А теперь представь, что у процессора команда деления целых чисел именно так и поступает!

В данном случае речь идет о мцст-шном r500, который спарк. И это, блин, ставили на ракеты!

>В данном случае речь идет о мцст-шном r500, который спарк. И это, блин, ставили на ракеты!

Ну и как в r500 решили данную проблему? Ведь ошибка в целочисленном делении не может не вылезти даже на самых ранних этапах тестирования.

либо точность при целочисленном делении так же должна быть по паспорту 52 бита (ну или сколько там). Но в данном случае мне интересно, как решена проблема в принципе (см. пост выше).

Об этом они умалчивают. Зато пишут о 9 битах результата за такт.

Наводит на мысль, что эта проблема была оставлена как есть, ибо деваться некуда.

Впрочем, можешь сам посмотреть:

http://www.mcst.ru/doc/1107/1107-5.doc

>Об этом они умалчивают. Зато пишут о 9 битах результата за такт.

Наводит на мысль, что эта проблема была оставлена как есть, ибо деваться некуда.

не может быть такого. Такой баг просто не может остатьяс не замеченным. Любая ОС будет зависать практически сразу.

> Такой баг просто не может остатьяс не замеченным.

остаться незамеченным не может. Остаться неисправленным вполне.

А ОС как правило не делит числа порядка 2^53

Они пишут, что на новых процессорах вернулись к классической схеме делителя целых чисел.

>>остаться незамеченным не может. Остаться неисправленным вполне.

А ОС как правило не делит числа порядка 2^53

ну а как быть с приведенным мной примером, где маленькие числа?

глянь сюда:

google SRT-алгоритм деление

третья ссылка сверху

А в linux-ядре используется ли деление не на степени двойки?

>А в linux-ядре используется ли деление не на степени двойки?

не вижу причин, почему бы не быть делению на 3. или 9/2.

Надо будет проверить. Вставить детектор в код виртуальной машины

>Что вы думаете о таком методе деления?

Когда делят два целых числа переводя их в вещественные, а потом обратно в целые?

Ты пытаешься изобрести паскалевские операторы целочисленного деления div и mod. Выброси из техпроцесса перевод в вещественное число и у тебя всё получится!

>Ты пытаешься изобрести паскалевские операторы целочисленного деления div и mod. Выброси из техпроцесса перевод в вещественное число и у тебя всё получится!

ты тред хоть почитай немного.

>ты тред хоть почитай немного.

Если в кратце, что там гениального? А то читал и полезности не обнаружил, лишь небольшое сомнительное ускорение одной операции за счёт дополнительного разогрева камня и увеличенного энергопотребления. Несколькими постами выше описывалось что камень выдаёт при целочисленном делении, в x86_64 всё уже есть без костылей.

В твоем тесте самое накладное это range (1, 2**20)

В твоем тесте самое накладное это range

python3

Только сейчас про процессор прочитал. Так вот, на x86 у div делимое в два раза длиннее делителя, частного и остатка. Так что поделить на еденицу не выйдет.

> Исполни в питоне, посмотри результат.

Исполнил, но предварительно подправив. ТС говорил про _приведение_, а не _округление_. Так что:

[code]>>> 2/3 == int(2.0/3.0) True[/code]

> Как у такого метода с точностью, когда числа большие?

Главное, чтоб битность дробного была где-то в полтора раза больше целого. Хотя, не факт, что в противном случае метод обязательно сфейлит.