Деление в языках программирования

Навеяно обсуждением в скайпе В C-подобных языках программирования (по крайней мере в С, С++, java, C# - как в других - не в курсе) операция a / b, когда a и b целые выполняет целочисленное деление. Меня удивило, что многие считают такое поведение логичным, несмотря на то, что случайно перепутав типы, заюзать целочисленное деление когда нужно обычное в разы проще (и наверняка все не раз на него наступали), чем обычное когда нужно целочисленное. Лично я считаю, что как в питоне или, прости господи, в паскале - всегда обычное, а для целочисленного надо использовать другой оператор - гораздо логичнее. А как думаете вы?

С одной стороны, удобнее другой оператор (как у того же vb есть "/" и "\"), но, уже привык к явному приведению, сишный вриант тоже не плох. Хуже, когда выполняется полноценное деление, затем приходится округлять результат - лишние операции же

Цитата VisualProg @ 29.01.16, 11:01

С одной стороны, удобнее другой оператор (как у того же vb есть "/" и "\"), но, уже привык к явному приведению, сишный вриант тоже не плох.

Вот я тоже привык. Причём привык так, что использовал обычное деление по ошибке вместо целочисленного в питоне по-инерции после плюсов. Но когда писал на дельфи (до плюсов) - такой ошибки не делал ни разу. Что также говорит в пользу второго варианта.

Это вопрос не логичности, а принятой в языке системы типов.

Цитата Qraizer @ 29.01.16, 11:15

Это вопрос не логичности, а принятой в языке системы типов.

Почему? Что принципиально поменяется в плюсовой системе типов с вводом оператора "поделить нацело"?

Если язык не предназначен для мат.вычислений, пусть типы аргументов определяют тип операции (нефиг юзать магические константы). То бишь как в C
Если предназначен, то... пусть типы аргументов определяют тип операции тоесть, все циферки -- вещественные по-дефолту, но там ещё могут появится комплексные числа, рациональные и ещё куча других. C возможностью зафорсить правильную (желаемую) операцию.

Сообщение отредактировано: negram - 29.01.16, 11:21

Цитата negram @ 29.01.16, 11:19

Если язык не предназначен для мат.вычислений, пусть типы аргументов определяют тип операции (нефиг юзать магические константы). То бишь как в C

А причём тут магические константы?

Цитата OpenGL @ 29.01.16, 11:27

А причём тут магические константы?

Ну как... в реальной жизни обычно используются переменные, уже имеющие какой-то тип. И этот самый тип предопределяет операцию. Если написал "1/2" то ну тебя нафиг

Цитата negram @ 29.01.16, 11:31

Если написал "1/2" то ну тебя нафиг

А если get_foo() / get_bar()?

Цитата OpenGL @ 29.01.16, 11:33

А если get_foo() / get_bar()?

ну тогда эти самые ф-ции возвращают правильный тип
Ну а если например нужно поделить количество резидентной памяти процесса на общее, ну я готов в этом случае добавить приведение типов

Я за разные операции для целочисленного и "обычного" деления. Соответственно, далее все зависит от системы типов в языке.

Цитата negram @ 29.01.16, 11:36

Ну а если например нужно поделить количество резидентной памяти процесса на общее, ну я готов в этом случае добавить приведение типов

Ну так это понятно. Я тоже готов Вопрос же не в этом, а в том, почему приведение типов ты считаешь логичным (и, следовательно, более простым с т.з. программиста), нежели введение отдельной операции?

Цитата OpenGL @ 29.01.16, 10:56

целочисленное деление.

С точки зрения математики эта операция полный бред. Программисты конечно могут позволить себе вольности, но есть же предел.

Для операции a/b надо a,b преобразовать как минимум в рациональное число и соответственно результат будет такого же типа. Ну дальше можете из результата получить целое число, если вам погрешность округления не важна.

Цитата OpenGL @ 29.01.16, 12:09

Вопрос же не в этом, а в том, почему приведение типов ты считаешь логичным (и, следовательно, более простым с т.з. программиста), нежели введение отдельной операции?

я считаю правильнее использовать всегда целочисленную арифметику, тк она точна (ну, с поправкой на возможные переполнения) и в большенстве случаев её хватает, а плавточка существует не от хорошей жизни и черевата бОльшим количеством подводных камней. Ну, в довесок раньше она была быстрее (ща не думаю, к тому же это мелочь). А вот вводить отдельную операцию для нецелочисленного деления мне кажется странно

Соответственно, переходить на вещественные числа следует только, когда это действительно необходимо (вот при мат вычислениях это как-раз практически всегда требуется, поэтому то, что в R по-дефолту именно нецелочисленная арифметика -- это правильно).

Добавлено 29.01.16, 12:45

Цитата Pavlovsky @ 29.01.16, 12:14

Цитата OpenGL @ 29.01.16, 10:56

целочисленное деление.

С точки зрения математики эта операция полный бред.

да ладно

Добавлено 29.01.16, 12:48

Цитата Pavlovsky @ 29.01.16, 12:14

Для операции a/b надо a,b преобразовать как минимум в рациональное число и соответственно результат будет такого же типа. Ну дальше можете из результата получить целое число, если вам погрешность округления не важна.

даже если не вспоминать что такое рациональное число... Зачем делать три операции вместо одной, да ещё и гонять данные из одного представления в другое?

Сообщение отредактировано: negram - 29.01.16, 13:14

Цитата OpenGL @ 29.01.16, 11:19

Почему? Что принципиально поменяется в плюсовой системе типов с вводом оператора "поделить нацело"?

Вопрос влияния новой операции на систему типов языка некорректен. В нём попутаны местами причина и следствие. Наоборот, отсутствие такой операции является следствием свойств системы типов в C. Поэтому вопрос следовало бы задать в форме "как нужно изменить систему типов, чтобы такая операция была оправдана".

Добавлено 29.01.16, 12:57
Хотя я могу себе представить Палькальное поведение, где мы имеем две разные операции для вещественного и целочисленного деления, но каждая из них неприменима для операндов неверного типа.

В Фортране операция определяется типом операндов. Вот там это несколько напрягало, поскольку не было возможности нормально вещественно поделить два целых. Поскольку тип переменных там по умолчанию зависит от первой буквы имени ошибиться с типом операндов затруднительно.
Когда я активно программировал на Паскале не напрягало использовать div для деления целых, как не напрягало (даже страховало) отсутствие неявного приведения вещественного к целому (при присваивании и использовании в качестве аргументов).
В C приходится следить за типами операндов и это немного напрягает, но поскольку работа с числами в этом языке не основное, то на зависимость операции от типа натыкаешься относительно редко. Функции короче, чем в фортране, имена длиннее, за типами следить не сильно накладно.
В Питоне поступили последовательнее. Там деление и деление с остатком - две разные операции, обе применимые и к вещественным и к целым числам. Более того деление с остатком там более последовательно при получении отрицательного частного.

Проголосовал за "другое", привык к Перл'овке Там результат деления - скаляр. А вот уже его представление зависит от его значения. Коротенький пример из дебага:

  DB<1> x 1/2
0  0.5
 
  DB<2> x 1/3
0  0.333333333333333
 
  DB<3> x 2/2
0  1
 
  DB<4> x 4/2
0  2
 
  DB<5> x 1/81
0  0.0123456790123457

Считаю это естественным выражением смысла деления. В строго типизированных языках с этим засада.

Думаю, и так довольно очевидно, что логичнее сделано в VB/Pascal и т.д., где два разных оператора для целочисленного и с плавающей точкой деления. В C/C++ легко можно создать себе труднообнаруживаемый баг, лишь сменив тип одной переменной, участвующей в выражении. Компилятор, при этом, будет тихо переваривать выражение как валидное, а то, что там в результате изменения типа результат приводится к другому типу, это уже твои проблемы -- не уследил. В VB, используя строго определенный оператор деления, на такую ситуацию попасть невозможно.

Добавлено 29.01.16, 14:40
P.S.
Промахнулся с пунктом, проголосовал за первый. Кто хочет выбрать первый, голосните за второй плиз, я уже за вас голос отдал

Цитата B.V. @ 29.01.16, 14:38

Компилятор, при этом, будет тихо переваривать выражение как валидное, а то, что там в результате изменения типа результат приводится к другому типу, это уже твои проблемы -- не уследил.

Ворнинг по идее должен выдать. По крайней мере MSVS выдает ворнинг аля:

warning C4244: '=': conversion from 'int' to 'float', possible loss of data

Цитата OpenGL @ 29.01.16, 10:56

А как думаете вы?

В Си все логично.

Цитата shm @ 29.01.16, 15:17

В Си все логично.

Особенно первый взгляд на строку: a = a+1;

Цитата Славян @ 29.01.16, 15:27

a = a+1;

А что с ней не так?

Ему, видимо, не нравится, что одиночный знак "равно" означает не равенство, а присваивание.
Так он в таком качестве не выступает только в языках Н.Вирта.

Цитата amk @ 29.01.16, 16:40

Ему, видимо, не нравится, что одиночный знак "равно" означает не равенство, а присваивание.

Операция присваивания используется намного чаще, чем сравнение.

Цитата Qraizer @ 29.01.16, 12:56

Хотя я могу себе представить Палькальное поведение, где мы имеем две разные операции для вещественного и целочисленного деления, но каждая из них неприменима для операндов неверного типа.

И разве это не логичный вариант? / - деление чисел с плавающей точкой, а какой-нибудь div делит целочисленно.

Добавлено 29.01.16, 20:10

Цитата shm @ 29.01.16, 18:25

Операция присваивания используется намного чаще, чем сравнение.

Зависит от задачи. Сейчас пошла мода на иммутабельность, да и в ООП присваивание не такая уж частая операция. По разному бывает.

Добавлено 29.01.16, 20:12

Цитата amk @ 29.01.16, 16:40

Так он в таком качестве не выступает только в языках Н.Вирта.

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

Есть ещё три, хоть и не распространённых, подварианта:
1) Ocaml (не знаю, как в других ML'ах): целочисленное деление «/», деление чисел с плавающей точкой «/.» («+», «-», «*» аналогично, без точки — int, с точкой — float). Никакого неявного приведения типов, никаких случайных ошибок. Но писать код может быть менее удобно из-за необходимости явно конвертировать int во float.
2) Haskell: тайпкласс Fractional определяет тип функции деления «/» как (a → a → a), т.е. оба операнда должны иметь одинаковый тип, а т.к. субтипирования в Хаскелле нет, то и неявного приведения, например, из Int в Double тоже быть не может и опять никаких случайных ошибок. Писать код, опять же, может быть менее удобно по той же причине, что и в первом пункте.
3) Lisp: в целом, деление работает так же, как в Python, но при делении двух целых происходит не целочисленное деление, а создание рациональной дроби. Т.е. «(/ 2 3) ⇒ 2/3», «(/ 4 6) ⇒ 2/3» и т.д.

Добавлено 29.01.16, 20:27

Цитата amk @ 29.01.16, 16:40

Так он в таком качестве не выступает только в языках Н.Вирта.

А ещё *ML, Lisp, SmallTalk, Tcl, Limbo, Ada (впрочем, если под «языками Н.Вирта» подразумевать языки с алголовским синтаксисом, то Ада туда попадает, пожалуй).

Сообщение отредактировано: korvin - 29.01.16, 20:29

Цитата D_KEY @ 29.01.16, 20:07

И разве это не логичный вариант? / - деление чисел с плавающей точкой, а какой-нибудь div делит целочисленно.

В системе типов C — нет. Операция / реализована по-разному для разных типов, но смысл её одинаков безотносительно к типам. Фактически тут классический полиморфизм. Другой вопрос, насколько логична сама система типов в C. Но это будет не голосовалка, это холивар.
Плюс, как уже упоминали, создание вдруг "из ниоткуда" значений новых типов, пусть даже в теории и логично, но крайне не практично во многих случаях. Компилятор должен делать то, что ему сказал человек. Если компилятор не уверен, что понял правильно, логично переспросить, именно так поступают на практике люди. В большинстве случаев. Сходный с ТС вопрос: надо ли возвращать complex из sqrt() при отрицательном аргументе?

Цитата Qraizer @ 29.01.16, 20:39

Операция / реализована по-разному для разных типов, но смысл её одинаков безотносительно к типам. Фактически тут классический полиморфизм.

В сочетании с неявным приведением это работает не очень хорошо.

Добавлено 29.01.16, 22:36
Да и в принципе мне кажутся более логичным отдельные div и mod для деления по модулю.

Сообщение отредактировано: D_KEY - 29.01.16, 22:36

Цитата D_KEY @ 29.01.16, 20:07

А как же пролог какой-нибудь?

В Прологе вообще нет операции присваивания. Так же, строго говоря, нет операции присваивания в функциональных языках (имеются в видц именно функциональные, а не императивные со средствами функционального программирования). Вообще, в декларативных языках с операцией присваивания плохо. Там её или нет, или она присутствует на птичьих правах.

Операция присваивания изменяет значение переменной. Там где "переменная" создаётся с некоторым значением и живёт с ним, пока её не уничтожат присваивания нет.

Цитата D_KEY @ 29.01.16, 22:33

В сочетании с неявным приведением это работает не очень хорошо.

Разве? О мультиметодах слышал?

Цитата D_KEY @ 29.01.16, 22:33

отдельные div и mod

Если уж по-честноку, то аббревиатура "div" давно и надежно занята дифференциальным оператором "Дивергенция".

Считаю, что альтернативный оператор деления нужно обозначать так: ÷ (ссылка)

Цитата D_KEY @ 29.01.16, 20:07

И разве это не логичный вариант? / - деление чисел с плавающей точкой, а какой-нибудь div делит целочисленно.

+1, но писать много букв (div вместо косой) не хочется сильно-сильно.

Цитата D_KEY @ 29.01.16, 22:33

Да и в принципе мне кажутся более логичным отдельные div и mod для деления по модулю.

Эх, а вот я бы оставил '%' за темой целочисленного деления, а вот хочется плавающее - fmod дёргайте.

Цитата Qraizer @ 29.01.16, 20:39

Операция / реализована по-разному для разных типов, но смысл её одинаков безотносительно к типам.

Т.е. целочисленное деление с твоей точки зрения имеет тот же смысл, что и обычное? Интересный взгляд на вещи.

Цитата Qraizer @ 29.01.16, 20:39

Сходный с ТС вопрос: надо ли возвращать complex из sqrt() при отрицательном аргументе?

Тогда непонятно, какой из двух корней возвращать. Да и комплексные числа на практике требуются значительно реже вещественных.

Цитата Славян @ 30.01.16, 05:55

+1, но писать много букв (div вместо косой) не хочется сильно-сильно.

В питоне деление нацело - a // b.

Цитата OpenGL @ 30.01.16, 06:32

В питоне деление нацело - a // b.

Да, когда не было таких комментариев, то счёл бы за вполне 'зер гут' такой вариант!

Добавлено 30.01.16, 07:42

Цитата OpenGL @ 30.01.16, 06:32

Тогда непонятно, какой из двух корней возвращать.

Верхний, = так же, как и сейчас при положительных возвращается правый.

Цитата Славян @ 30.01.16, 07:38

Да, когда не было таких комментариев, то счёл бы за вполне 'зер гут' такой вариант!

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

Цитата OpenGL @ 30.01.16, 07:57

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

Увы, но сильно сомневаюсь:
1.Знаковая ASCII схема должна была быть лаконичной, а потому одного иного значка трудно найти.
2.Знак должен быть как можно понятнее, а школьно-естественный уже задействован.
3.Набор же букв(знаков) будет или дольше писать, либо разбираться сознанием будет труднее.

Добавлено 30.01.16, 08:27
П.С. впрочем, есть шикарный вариант - ':', но вот и его несколько наспех использовали в тернарной операции ?:

Пара знаков вполне приемлема. // в Питоне - ок.

Цитата D_KEY @ 30.01.16, 10:22

Пара знаков вполне приемлема. // в Питоне - ок.

Да и три знака- нормуль, на мой взгляд. Лишь бы понятно было. div и mod- вполне понятно.

Цитата OpenGL @ 30.01.16, 06:32

Т.е. целочисленное деление с твоей точки зрения имеет тот же смысл, что и обычное?

Конечно. Тот факт, что результаты отличаются, является следствием свойств типов. Напомню, деление нацело есть и вещественное, только выполняется оно std::функцией. Это – другая операция. И остаток от деления в виде функции тоже есть. А почему сделали функции? Потому что ведут себя иначе, чем / и %.

Сообщение отредактировано: Qraizer - 30.01.16, 14:58

Цитата Qraizer @ 30.01.16, 14:56

Цитата OpenGL @ 30.01.16, 06:32

Т.е. целочисленное деление с твоей точки зрения имеет тот же смысл, что и обычное?

Конечно. Тот факт, что результаты отличаются, является следствием свойств типов.

Эм. Но ведь на множестве целых не определена операция деления. Только операция деления с остатком.

Цитата Qraizer @ 30.01.16, 14:56

Конечно. Тот факт, что результаты отличаются, является следствием свойств типов.

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

Цитата Qraizer @ 30.01.16, 14:56

А почему сделали функции?

Подозреваю, что из-за исторических причин - остаток от деления для вещественных был нужен, % для них не работал, а менять его семантику означало нарушить обратную совместимость.

Добавлено 30.01.16, 15:53
Кстати, а в Rust как деление устроено?

Цитата OpenGL @ 30.01.16, 15:52

Вообще, складывается впечатление, что для тебя система типов нечто незымблемое, что никак не может быть нелогичным, из-за чего ты при любом удобном случае апеллируешь к ней. Религия какая-то.

Ну вообще-то так и есть. Только религия тут ни причём. Свойства системы типов являются краеугольным камнем для C. И он далеко не единственный язык с этим свойством, я бы даже сказал, что не знаю языков, где система типов не играла бы такую же по важности роль. Поэтому делать исключений из неё нелогично. Но как я говорил, можно порассуждать о логичности самой системы типов C.

Цитата OpenGL @ 30.01.16, 15:52

одозреваю, что из-за исторических причин - остаток от деления для вещественных был нужен, % для них не работал, а менять его семантику означало нарушить обратную совместимость.

Да, из-за исторических. Но не поэтому. Исторически так сложилось, что ранние компьютеры работали так, как было удобнее их спроектировать. Эти свойства перетекли в правила арифметики языка Фортран, одного из первых и долгое время наиболее популярного ЯВУ. Первые процессоры и микропроцессоры также делались с оглядкой на этот принцип, поэтому язык C перенял Фортрановую арифметику, ибо она отражала реалии правил аппаратно реализованной арифметики в процессорах.
Но вот пришёл IEEE на плавающую точку, и с удобностью пришлось завязать в пользу математической корректности. Вот так и получилось, что / и % работают не по математическим правилам, тогда как от вещественной арифметики интуитивно ожидается математически правильное поведение. Отсюда и деление на операторы и функции, выполняющие на первый взгляд одно и то же, но на самом деле по-разному.

Сообщение отредактировано: Qraizer - 30.01.16, 22:38

Цитата Qraizer @ 30.01.16, 22:37

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

Почему "ранние", они и сейчас так работают. И долго ещё будут так работать.
Это реалии не компьютеров и языков программирования, а выполняемых операций.
И здесь проявляется различие между чистой математикой и практикой программирования.

Для целых чисел в принципе не определена операция точного деления (только в частных случаях). Зато имеется "алгоритм деления" или деление с остатком
Для вещественных, как правило, деление осуществляется по возможно как можно более точно, а в тех случаях, когда надо что-то другое, вполне можно обойтись округлением (к ближнему, верхнему, нижнему) и усечением до целого.
Поэтому, вполне естественным выбором разработчиков сперва автокодов, а потом ЯВУ назвать обе эти операции просто делением (оговаривая в описании, что для целых это "деление с остатком").

С другой стороны в математике деление целых обычно производят в поле рациональных чисел, и ничто не мешает определить операцию деления для целых так, чтобы результат был рациональным или вещественным числом и выполнить "истинное" деление.
Кроме того можно доопределить деление с остатком так, чтобы результат такого деления для вещественных и рациональных чисел совпадал с результатом деления целых.
Именно это сделали в Питоне.

Цитата Qraizer @ 30.01.16, 22:37

Ну вообще-то так и есть. Только религия тут ни причём. Свойства системы типов являются краеугольным камнем для C.

Но разговор ведь не о Си.

Цитата

И он далеко не единственный язык с этим свойством

Но у других языков другая система типов.

А я на первый пост отвечаю, D_KEY. Почему "так" сделано в "С-подобных языках". Правильнее их было бы назвать Фортран-подобными, правда... То, что в других языках бывает иначе, я в курсе, естественно. Я не считаю систему типов C лучше других, но изменять / тем не менее я логичным не считаю тоже. "Изменять" не в смысле сделать его математически правильным, против этого я как бы ничего не имею (хотя будут иметь уйма легаси кода), а в смысле что б float возвращал. Почему вот кстати float? А вдруг мне нужен long double? И кстати, как быть с шаблонами? Ой-ёй-ёй не выйдет в результате?

Более логичным считаю как в Питоне/Паскале - операция a / b всегда выполняет вещественное деление, а для целочисленного деления и получения остатка от деления целых чисел вводятся специальные операции.

Только вот мнемоники div и mod мне не нравятся (да задрали просто!). Удобнее, на мой взгляд, было бы ввести знак процента (%) для целочисленного деления и обратный слэш (\) для получения остатка.

Цитата Bug Hunter @ 04.02.16, 22:39

Удобнее, на мой взгляд, было бы ввести знак процента (%) для целочисленного деления и обратный слэш (\) для получения остатка.

А питоновские // для целочисленного деления и % для остатка тебе не нравятся?

Цитата D_KEY @ 05.02.16, 09:31

А питоновские // для целочисленного деления и % для остатка тебе не нравятся?

Не нравятся. Знак процента (%) похож на знаки, традиционно используемые для обозначения операции деления (на два из трех), ему и следует быть используемым для обозначения операции целочисленного деления. А операция взятия остатка она как бы обратная к операции деления, так что для нее логичнее использовать обратный слэш (\). Я так думаю... (С)

Сообщение отредактировано: Bug Hunter - 05.02.16, 11:10

Цитата Bug Hunter @ 05.02.16, 11:09

А операция взятия остатка она как бы обратная к операции деления

А мужики-то и не знали (с)

Цитата Bug Hunter @ 05.02.16, 11:09

А операция взятия остатка она как бы обратная к операции деления

В кольце целых чисел (а также в кольце многочленов и некоторых других кольцах) существует "алгоритм деления", называемый также "деление с остатком", который на входе принимает два числа (многочлена, ...) "делимое" и "делитель" и выдаёт два других числа (многочлена, ...) "частичное частное" и "остаток". Так что это не две обратные друг другу операции, а две половинки одной операции.

Цитата amk @ 05.02.16, 13:15

Так что это не две обратные друг другу операции, а две половинки одной операции.

Во фразе Bug Hunter'а "как бы" подразумевается, что при делении образуется нечто, но внимание всё переключается именно на хвостик=остаток, а потому происходит взгляд не на суть, а обратно - на мелочь, потому он и озвучил сие "она как бы обратная к операции деления".

Цитата OpenGL @ 05.02.16, 11:41

Цитата Bug Hunter @ 05.02.16, 11:09

А операция взятия остатка она как бы обратная к операции деления

А мужики-то и не знали (с)

Похоже я понял - это соревнование по чтению форума жопой за пост председателя клуба читателей форума жопой.

Поздравляю - Вы вырвали важное очко!

Цитата amk @ 05.02.16, 13:15

В кольце целых чисел (а также в кольце многочленов и некоторых других кольцах) существует "алгоритм деления", называемый также "деление с остатком", который на входе принимает два числа (многочлена, ...) "делимое" и "делитель" и выдаёт два других числа (многочлена, ...) "частичное частное" и "остаток". Так что это не две обратные друг другу операции, а две половинки одной операции.

Я знаю, что из себя представляет операция деления. И про кольца с полями тоже знаю - не умничайте. И читайте форум глазами - Славян вон понял, что я имел в виду.

Цитата Bug Hunter @ 05.02.16, 21:18

И читайте форум глазами - Славян вон понял, что я имел в виду.

Тогда руками пишите.
Я тоже понял. Но слово "обратная" в математике и в программировании имеет несколько другое значение.
Сторона медали, обращённая к телу, "оборотная", а не "обратная". Но к операции это слово не применимо.

Цитата Bug Hunter @ 05.02.16, 21:18

Я знаю, что из себя представляет операция деления. И про кольца с полями тоже знаю - не умничайте. И читайте форум глазами - Славян вон понял, что я имел в виду.

Утипути какие мы напыщеные

Цитата amk @ 05.02.16, 21:29

слово "обратная" в математике и в программировании имеет несколько другое значение.

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

Добавлено 05.02.16, 21:45

Цитата KILLER @ 05.02.16, 21:41

Утипути какие мы напыщеные

Тьфу на Вас! (С)

Цитата Bug Hunter @ 05.02.16, 21:44

Тьфу на Вас! (С)

Зачем так быстро сливаться? Судя по Вашей аватарке - я надеялся что вы придумаете что то более оригинальное, а на деле - Лошок обыкновенный.

Добавлено 05.02.16, 21:56
Посмотрел профиль 433 тематических сообщения из 831 в теме про Паскаль! Паскаль Карл!!! Да ты зачетный Лошок, с большой буквы,

Сообщение отредактировано: KILLER - 05.02.16, 21:57

Тьфу на Вас еще раз! (С)

Цитата Bug Hunter @ 05.02.16, 22:20

Тьфу на Вас еще раз! (С)

Ок, Лошок, я больше не буду тебя добивать в этой теме. Пусть тебя добьют другие. Я лишь посмакую

Цитата Bug Hunter @ 05.02.16, 21:12

Похоже я понял - это соревнование по чтению форума жопой за пост председателя клуба читателей форума жопой.

Тебя это так задело? Бедняжка. Как же плохо быть тобой

Цитата OpenGL @ 29.01.16, 10:56

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

А какой тип возвращает в питоне функция взятия корня второй степени?

math.sqrt принимает вещественное число в качестве аргумента и возвращает вещественное число как результат.
cmath.sqrt принимает комплексное число в качестве аргумента и возвращает комплексное в качестве результата.
Куда интереснее ведут себя функция pow (с двумя аргументами) и операция **, которые могут возвращать в качестве результата и целое, и вещественное, и комплексное числа, в зависимости от того, что получается.

Добавлено 14.02.16, 01:14
Это в Python 3. Но похоже и в предыдущем так же было.

Цитата amk @ 14.02.16, 01:10

math.sqrt принимает вещественное число в качестве аргумента и возвращает вещественное число как результат.
cmath.sqrt принимает комплексное число в качестве аргумента и возвращает комплексное в качестве результата.

А деление, значит, принимает целые, но возвращает вещественные

Цитата MyNameIsIgor @ 14.02.16, 02:14

А деление, значит, принимает целые, но возвращает вещественные

Ну, в sqrt тоже можно передать целое, он всё равно вернёт вещественное.

Цитата amk @ 14.02.16, 05:41

Цитата MyNameIsIgor @ 14.02.16, 02:14

А деление, значит, принимает целые, но возвращает вещественные

Ну, в sqrt тоже можно передать целое, он всё равно вернёт вещественное.

А почему не комплексное?

Потому что решили, что math.sqrt должен, как и в других языках, возвращать вещественное.

Проголосовал за №2 потому, что считаю, что чем ближе к записи в математике, тем правильнее. В математике "/" означает "разделить", "1/2" в математике будет равно "0.5", и тут не может быть вариантов. А целочисленное деление - это отражение конструкции реального процессора, это может быть полезно с точки зрения оптимизации, но это не математическое деление, даже если брать деление для первоклашек, которые ещё дробей не знают, то там деление целых чисел возвращает ДВА результата - частное и остаток.
И ещё, вариант №1 плохо стыкуется с неопределённым типом данных (Variant).

Цитата Mikle @ 25.03.16, 06:26

И ещё, вариант №1 плохо стыкуется с неопределённым типом данных (Variant).

А что, неопределенный тип данных (Variant) еще и делить можно? Мне казалось для начала в таких случаях необходимо сделать преобразование типа.

Я отвечал, прочитав только первую страницу (попадаюсь иногда на это, кажется, что вижу последний пост). Во многом повторился.

Цитата KILLER @ 25.03.16, 06:40

А что, неопределенный тип данных (Variant) еще и делить можно?

А о каком ЯП речь? Тема, вроже как, про ЯП вообще, вот так я и отвечал.
А делить Variant - можно, если речь про VB.

Цитата Mikle @ 25.03.16, 06:53

А делить Variant - можно, если речь про VB.

И что получится в результате, если например в вариант запихали BSTR строку, и поделили это на 3 ?

Цитата KILLER @ 25.03.16, 06:55

И что получится в результате, если например в вариант запихали BSTR строку, и поделили это на 3 ?

Создаёшь текстовый документ с таким содержимым:

dim a,b
a="345"
b=3
msgbox a/b

Переименовываешь его в test.vbs.
Сохраняешь... запускаешь... ответ 115!

Цитата Mikle @ 25.03.16, 07:02

Переименовываешь его в test.vbs.
Сохраняешь... запускаешь... ответ 115!

Так я не то имел ввиду. Но спасибо за код. Немного подправил:

dim a,b
a="_34a5"
b=3
msgbox a/b

Получил исключение, как и ожидалось. Т.е. фраза:

Цитата Mikle @ 25.03.16, 06:26

И ещё, вариант №1 плохо стыкуется с неопределённым типом данных (Variant)

Лишена смысла. Так как такие типы как Variant делить без приведения типа слишком опасно. Мы же не знаем что он там будет хранить.

Сообщение отредактировано: KILLER - 25.03.16, 08:09

Цитата KILLER @ 25.03.16, 08:09

такие типы как Variant делить без приведения типа слишком опасно.

В общем согласен, по крайней мере в применении к VB. Тут Variant может содержать даже не строку, а вообще объект. Но это, скорее, чересчур вольное приведение типов в VB, в противовес к чересчур жёсткому контролю в том же шарпе. Скажем так, не Variant, а некий "Number", то есть неопределённый тип, но только для чисел, вообще мог бы вполне существовать.
А в бейсике, по крайней мере для строк, если уж приводить их тип автоматически к числовому, можно было сделать логичнее - чтобы приведение работало аналогично функции Val(), для всех строк, не интерпретируемых как число, возвращать 0.

Сообщения были разделены в тему "Spam"