Ультрафинитизм в действии
Чота чувак проснулся.
Этот баг известен уже лет двадцать и в книжке Кнута лежит правильный алгоритм + обоснование, почему нельзя делать просто (a+b)/2. Это если я ничего не путаю, конечно.
Более того, я в этот глюк один раз сам воткнулся - когда писал какое-то половинное деление, причём вроде как даже на этом форуме запостил глючную программу, а потом вспомнил, что типа глюк.
Не читай людей, прочно зависших в прошлом веке =)
Этот баг известен уже лет двадцать и в книжке Кнута лежит правильный алгоритм + обоснование, почему нельзя делать просто (a+b)/2. Это если я ничего не путаю, конечно.
Более того, я в этот глюк один раз сам воткнулся - когда писал какое-то половинное деление, причём вроде как даже на этом форуме запостил глючную программу, а потом вспомнил, что типа глюк.
Не читай людей, прочно зависших в прошлом веке =)
So what's the best way to fix the bug? Here's one way:А чем варианты 2 и 3 лучше изначально плохого
1: int mid = low + high - low) / 2);
Probably faster, and arguably as clear is:
2: int mid = (low + high) >>> 1;
In C and C++ (where you don't have the >>> operator you can do this:
3: mid = unsigned) (low + high >> 1;
6: int mid =(low + high) / 2;
?
И там и там сложение, т.е. возможность глюка и там и там одинаковая.
ЛООООЛ, а я и не заметил.
Контра читает каких-то идиотов =)
int mid = (high + low) / 2 глючит если high + low >= 2^31. Варианты 2 и 3 глючат если high + low >= 2^32.
Наверное, имелось в виду, что массив всё-таки не длиннее двух гигов.
Контра читает каких-то идиотов =)
int mid = (high + low) / 2 глючит если high + low >= 2^31. Варианты 2 и 3 глючат если high + low >= 2^32.
Наверное, имелось в виду, что массив всё-таки не длиннее двух гигов.
Догадайся с первого раза, какой знак у числа 2^31.
---
...Я работаю антинаучным аферистом...
---
...Я работаю антинаучным аферистом...
> Это если я ничего не путаю, конечно.
А если путаешь?
> + обоснование, почему нельзя делать просто (a+b)/2.
Я знаю, навскидку, три веских причины, почему надо делать просто (a+b)/2.
---
...Я работаю антинаучным аферистом...
А если путаешь?
> + обоснование, почему нельзя делать просто (a+b)/2.
Я знаю, навскидку, три веских причины, почему надо делать просто (a+b)/2.
---
...Я работаю антинаучным аферистом...
Я знаю, навскидку, три веских причины, почему надо делать просто (a+b)/2.
, не тогда, если .Чего-чего?
ЗЫ: +1 к КОНТРЕ.
ЗЫ: +1 к КОНТРЕ.
Я знаю, навскидку, три веских причины, почему надо делать просто (a+b)/2.При написании mergesort, qsort, bsearch и подобных процедур следует сразу расставить правильные приоритеты: 1) корректность на всех входных данных, 2) скорость, 3) ограниченная переносимость и корректность используемых алгоритмов (так как наверняка кто-нибудь будет выдирать куски из bsearch с какими-то своими целями).
> 1) корректность на всех входных данных,
Перезаклад.
> 2) скорость,
"(a+b)/2" быстрее или, по крайней мере, не медленнее.
> 3) ограниченная переносимость
"(a+b)/2" переносимее.
> и корректность используемых алгоритмов
"(a+b)/2" корректнее.
> (так как наверняка кто-нибудь будет выдирать куски
> из bsearch с какими-то своими целями).
Это их личные трудности.
---
...Я работаю антинаучным аферистом...
Перезаклад.
> 2) скорость,
"(a+b)/2" быстрее или, по крайней мере, не медленнее.
> 3) ограниченная переносимость
"(a+b)/2" переносимее.
> и корректность используемых алгоритмов
"(a+b)/2" корректнее.
> (так как наверняка кто-нибудь будет выдирать куски
> из bsearch с какими-то своими целями).
Это их личные трудности.
---
...Я работаю антинаучным аферистом...
> 1) корректность на всех входных данных,Что значит - перезаклад? Ты предлагаешь писать в описании bsearch что, типа, мы очень извиняемся, конечно, но вы не сможете использовать нашу функцию на массивах больше гигабайта - типа, сами пишите проверки, что у вас меньше? Или поставить вначале проверку и кидать какой-нибудь системно-зависимое исключение? Или что вообще?
Перезаклад.
Или ты не веришь в существование гигабайтных массивов?
Лол. В каком месте (А + Б) / 2 переносимее и корректнее, чем А + (Б - А) / 2 ? Или тебе лишь бы поспорить с насильниками?
> Что значит - перезаклад?
То и значит --- перезаклад.
> Ты предлагаешь писать в описании bsearch
> что, типа, мы очень извиняемся, конечно, но вы не сможете
> использовать нашу функцию на массивах больше гигабайта -
> типа, сами пишите проверки, что у вас меньше?
Да.
Потому что массивы более гигабайта* --- это уже пограничный случай,
где обычное решение требует замены на другое, более сложное или медленное.
> Или поставить вначале проверку и кидать какой-нибудь системно-зависимое исключение?
Можно и так.
> Или что вообще?
Можно вообще --- ловить арифметическое переполнение
и сильно ругаться, если словили.
---
...Я работаю антинаучным аферистом...
*) Правильно говорить не "байт," а объектов, потому что указатели --- зло,
и не "гига", а MAX-INT/2, потому что целый тип может быть не 32-разрядным,
То и значит --- перезаклад.
> Ты предлагаешь писать в описании bsearch
> что, типа, мы очень извиняемся, конечно, но вы не сможете
> использовать нашу функцию на массивах больше гигабайта -
> типа, сами пишите проверки, что у вас меньше?
Да.
Потому что массивы более гигабайта* --- это уже пограничный случай,
где обычное решение требует замены на другое, более сложное или медленное.
> Или поставить вначале проверку и кидать какой-нибудь системно-зависимое исключение?
Можно и так.
> Или что вообще?
Можно вообще --- ловить арифметическое переполнение
и сильно ругаться, если словили.
---
...Я работаю антинаучным аферистом...
*) Правильно говорить не "байт," а объектов, потому что указатели --- зло,
и не "гига", а MAX-INT/2, потому что целый тип может быть не 32-разрядным,
В месте, где "unsigned"-чего-то-там.
"a+(b-a)/2" сложнее и дольше.
Это не говоря о том, что неочевидно, почему "a+(b-a)/2" нельзя упрощать,
то есть надо сказать компилятору, что, мол, вот здесь надо оставить, как есть.
---
...Я работаю антинаучным аферистом...
"a+(b-a)/2" сложнее и дольше.
Это не говоря о том, что неочевидно, почему "a+(b-a)/2" нельзя упрощать,
то есть надо сказать компилятору, что, мол, вот здесь надо оставить, как есть.
---
...Я работаю антинаучным аферистом...
>> Потому что массивы более гигабайта* --- это уже пограничный случай
Тут есть одна маленькая проблемка - пограничность этого случая целиком и полностью происходит из-за выбранного способа вычисления (a+b)/2. А пользователя метода bsearch детали реализации еб*ть не должны ВООБЩЕ, более того, все пользователи в это свято верят и не будут смотреть описание метода в поисках каких-то левых ограничений. Вот два гигабайта - это да, это понятный пограничный случай.
Ещё всё усугубляется тем, что по природе своей bsearch простой как два пальца, и предполагать там внутри какие-то сложные требования никому даже в голову не придёт.
>> Можно вообще --- ловить арифметическое переполнение
Тут есть ещё одна маленькая проблемка - все эти способы будут генерить ошибку в рантайме, причём только в определённых случаях.
>> Это не говоря о том, что неочевидно, почему "a+(b-a)/2" нельзя упрощать,
>> то есть надо сказать компилятору, что, мол, вот здесь надо оставить, как есть.
Компилятору - очевидно, и ничего ему говорить не надо. Компилятор, в отличие от программиста, точно знает, какая у него разрядность target machine, какие там есть операции, и никогда ни за что не будет делать оптимизации, изменяющие семантику кода, на основе каких-то своих догадок относительно того, что имел в виду программер. Это С, тут границы "абстрактности" выражения a + b вполне чётко заданы.
Короче, если я правильно тебя понимаю, ты не считаешь, что выражение int mid = (a + b) / 2 ошибочно. Так вот, ты не прав, оно ошибочно. Его семантика не соответсвует заявленной задаче - вычислить среднее арифметическое a и b. Причём эту семантику определяет не конкретный компилятор, а стандарт языка.
Более того, даже если на какой-то платформе семантика отклоняется в ещё какую-нибудь сторону, например из-за того, что там сложение с насыщением, то будет стоять вполне конкретная задача написания правильно работающего bsearch для неё.
Кстати, это очень хороший пример того, как стремление к "абсолютной переносимости" (то есть когда bsearch не нужно будет переписывать при переходе на 17-битные инты) приводит к плохому результату - появляются дополнительные неочевидные ограничения.
Разве что можно определить новую примитивную функцию int Mid(int a, int b) (с платформозависимой реализацией тогда сам bsearch станет полностью платформонезависимым. Может быть.
Тут есть одна маленькая проблемка - пограничность этого случая целиком и полностью происходит из-за выбранного способа вычисления (a+b)/2. А пользователя метода bsearch детали реализации еб*ть не должны ВООБЩЕ, более того, все пользователи в это свято верят и не будут смотреть описание метода в поисках каких-то левых ограничений. Вот два гигабайта - это да, это понятный пограничный случай.
Ещё всё усугубляется тем, что по природе своей bsearch простой как два пальца, и предполагать там внутри какие-то сложные требования никому даже в голову не придёт.
>> Можно вообще --- ловить арифметическое переполнение
Тут есть ещё одна маленькая проблемка - все эти способы будут генерить ошибку в рантайме, причём только в определённых случаях.
>> Это не говоря о том, что неочевидно, почему "a+(b-a)/2" нельзя упрощать,
>> то есть надо сказать компилятору, что, мол, вот здесь надо оставить, как есть.
Компилятору - очевидно, и ничего ему говорить не надо. Компилятор, в отличие от программиста, точно знает, какая у него разрядность target machine, какие там есть операции, и никогда ни за что не будет делать оптимизации, изменяющие семантику кода, на основе каких-то своих догадок относительно того, что имел в виду программер. Это С, тут границы "абстрактности" выражения a + b вполне чётко заданы.
Короче, если я правильно тебя понимаю, ты не считаешь, что выражение int mid = (a + b) / 2 ошибочно. Так вот, ты не прав, оно ошибочно. Его семантика не соответсвует заявленной задаче - вычислить среднее арифметическое a и b. Причём эту семантику определяет не конкретный компилятор, а стандарт языка.
Более того, даже если на какой-то платформе семантика отклоняется в ещё какую-нибудь сторону, например из-за того, что там сложение с насыщением, то будет стоять вполне конкретная задача написания правильно работающего bsearch для неё.
Кстати, это очень хороший пример того, как стремление к "абсолютной переносимости" (то есть когда bsearch не нужно будет переписывать при переходе на 17-битные инты) приводит к плохому результату - появляются дополнительные неочевидные ограничения.
Разве что можно определить новую примитивную функцию int Mid(int a, int b) (с платформозависимой реализацией тогда сам bsearch станет полностью платформонезависимым. Может быть.
> Вот два гигабайта - это да, это понятный пограничный случай.
Нифига не понятно.
Почему выбрано 32 разряда, а не 64?
В современных сях уже есть такое.
Получается, что твой способ реализации через 32-разрядные целые
приводит к ограничению неизвестного происхождения.
> предполагать там внутри какие-то сложные требования никому даже в голову не придёт.
Эти требования задаются не внутри, а снаружи.
Если в сях невозможно определить длину массива,
то это трудности всех программистов, не способных
прочитать примечания к используемому коду.
>> Это не говоря о том, что неочевидно, почему "a+(b-a)/2" нельзя упрощать,
>> то есть надо сказать компилятору, что, мол, вот здесь надо оставить, как есть.
> Компилятору - очевидно, и ничего ему говорить не надо.
> Компилятор, в отличие от программиста, точно знает,
> какая у него разрядность target machine, какие там есть операции,
> и никогда ни за что не будет делать оптимизации,
> изменяющие семантику кода,
Ты считаешь, что "(a+b)/2" и "a+(b-a)/2" семантически различны?
Так вот, ты неправ.
Оба этих выражения вычисляют одно и то же.
5-й класс средней школы, если ты не в курсе.
И если вдруг у целевой машины есть быстрая операция взятия полусуммы,
то компилятор должен использовать её в обоих случаях.
Потому что большинство действий выполняется глубоко внутри
области допустимых значений, а не на краях.
> Его семантика не соответствует заявленной задаче -
> вычислить среднее арифметическое a и b.
Расскажи про твоё среднее арифметическое MAX-INT и MIN-INT.
---
...Я работаю антинаучным аферистом...
Нифига не понятно.
Почему выбрано 32 разряда, а не 64?
В современных сях уже есть такое.
Получается, что твой способ реализации через 32-разрядные целые
приводит к ограничению неизвестного происхождения.
> предполагать там внутри какие-то сложные требования никому даже в голову не придёт.
Эти требования задаются не внутри, а снаружи.
Если в сях невозможно определить длину массива,
то это трудности всех программистов, не способных
прочитать примечания к используемому коду.
>> Это не говоря о том, что неочевидно, почему "a+(b-a)/2" нельзя упрощать,
>> то есть надо сказать компилятору, что, мол, вот здесь надо оставить, как есть.
> Компилятору - очевидно, и ничего ему говорить не надо.
> Компилятор, в отличие от программиста, точно знает,
> какая у него разрядность target machine, какие там есть операции,
> и никогда ни за что не будет делать оптимизации,
> изменяющие семантику кода,
Ты считаешь, что "(a+b)/2" и "a+(b-a)/2" семантически различны?
Так вот, ты неправ.
Оба этих выражения вычисляют одно и то же.
5-й класс средней школы, если ты не в курсе.
И если вдруг у целевой машины есть быстрая операция взятия полусуммы,
то компилятор должен использовать её в обоих случаях.
Потому что большинство действий выполняется глубоко внутри
области допустимых значений, а не на краях.
> Его семантика не соответствует заявленной задаче -
> вычислить среднее арифметическое a и b.
Расскажи про твоё среднее арифметическое MAX-INT и MIN-INT.
---
...Я работаю антинаучным аферистом...
> Нифига не понятно.
> Почему выбрано 32 разряда, а не 64?
> В современных сях уже есть такое.
> Получается, что твой способ реализации через 32-разрядные целые
> приводит к ограничению неизвестного происхождения.
Выбрано не 32 разряда, а разрядность входных данных. У функции bsearch есть параметр - размер массива. Пользователь вправе предполагать, что для любых его осмысленных значений (если 32битный знаковый то от 0 до 2^31-1, если беззнаковый - то до 2^32-1, аналогично для 64битных) метод будет работать правильно. У него, пользователя, может болеть голова в других местах - например, он же не знает, какой именно у него инт, но он точно знает, что если он передаёт правильные значения, то получает правильный результат. Как этого добиться - проблемы разработчика bsearch и составителя стандартной библиотеки под данную конкретную платформу.
> Ты считаешь, что "(a+b)/2" и "a+(b-a)/2" семантически различны?
> Так вот, ты неправ.
Неправ ты, в следующей строчке:
> Оба этих выражения вычисляют одно и то же.
> 5-й класс средней школы, если ты не в курсе.
Определись - если ты говоришь о пятом классе средней школы, то выражения ничего не вычисляют, а если о языке программирования С - то вычисляют разные вещи.
Тебя, надеюсь, не шокирует то, что a < a + 1 не всегда истинно, если речь идёт о языках программирования?
> И если вдруг у целевой машины есть быстрая операция взятия полусуммы,
> то компилятор должен использовать её в обоих случаях.
К счастью для программистов разработчики компиляторов находятся в несколько более здравом рассудке. Видишь ли, неоптимальная программа значительно лучше неработающей.
> Расскажи про твоё среднее арифметическое MAX-INT и MIN-INT
В случае bsearch покатит uint Mid(uint a, uint b) { return a + (b - a) / 2; } - поскольку при её использовании в данном контексте можно гарантировать положительность a и b во-первых и положительность результата обратного преобразования во-вторых.
> Почему выбрано 32 разряда, а не 64?
> В современных сях уже есть такое.
> Получается, что твой способ реализации через 32-разрядные целые
> приводит к ограничению неизвестного происхождения.
Выбрано не 32 разряда, а разрядность входных данных. У функции bsearch есть параметр - размер массива. Пользователь вправе предполагать, что для любых его осмысленных значений (если 32битный знаковый то от 0 до 2^31-1, если беззнаковый - то до 2^32-1, аналогично для 64битных) метод будет работать правильно. У него, пользователя, может болеть голова в других местах - например, он же не знает, какой именно у него инт, но он точно знает, что если он передаёт правильные значения, то получает правильный результат. Как этого добиться - проблемы разработчика bsearch и составителя стандартной библиотеки под данную конкретную платформу.
> Ты считаешь, что "(a+b)/2" и "a+(b-a)/2" семантически различны?
> Так вот, ты неправ.
Неправ ты, в следующей строчке:
> Оба этих выражения вычисляют одно и то же.
> 5-й класс средней школы, если ты не в курсе.
Определись - если ты говоришь о пятом классе средней школы, то выражения ничего не вычисляют, а если о языке программирования С - то вычисляют разные вещи.
Тебя, надеюсь, не шокирует то, что a < a + 1 не всегда истинно, если речь идёт о языках программирования?
> И если вдруг у целевой машины есть быстрая операция взятия полусуммы,
> то компилятор должен использовать её в обоих случаях.
К счастью для программистов разработчики компиляторов находятся в несколько более здравом рассудке. Видишь ли, неоптимальная программа значительно лучше неработающей.
> Расскажи про твоё среднее арифметическое MAX-INT и MIN-INT
В случае bsearch покатит uint Mid(uint a, uint b) { return a + (b - a) / 2; } - поскольку при её использовании в данном контексте можно гарантировать положительность a и b во-первых и положительность результата обратного преобразования во-вторых.
> а если о языке программирования С - то вычисляют разные вещи.
Потому что в языке программирования С выражение a + (b - a) / 2 соответствует математическому выражению (a + b - a) mod 2^31) div 2) mod 2^31 mod 2^31, которое вовсе не равно a + b) mod 2^31) div 2. Вот такая сложная вещь - программирование.
Потому что в языке программирования С выражение a + (b - a) / 2 соответствует математическому выражению (a + b - a) mod 2^31) div 2) mod 2^31 mod 2^31, которое вовсе не равно a + b) mod 2^31) div 2. Вот такая сложная вещь - программирование.
> Выбрано не 32 разряда, а разрядность входных данных.
> У функции bsearch есть параметр - размер массива.
Что мешает сделать автомагическое расширение разрядности?
Достаточно расширить на один(!) разряд --- и наступит счастье.
> Пользователь вправе предполагать
Здесь нет поблизости ни одного пользователя.
Программист не вправе ничего предполагать,
он обязан прочитать примечания к коду.
> Тебя, надеюсь, не шокирует то, что a < a + 1 не всегда истинно,
> если речь идёт о языках программирования?
Меня не шокирует даже 2 * 2 = 5.
> К счастью для программистов разработчики компиляторов
А разработчики процессоров?
> находятся в несколько более здравом рассудке.
> Видишь ли, неоптимальная программа значительно лучше неработающей.
Неоптимальной программу делает прикладной программист,
которому лень сделать особый случай для очень больших объёмов данных.
> В случае bsearch покатит uint Mid(uint a, uint b) { return a + (b - a) / 2; }
Я уже продумал этот ход.
Расскажи, что происходит, если a > b.
---
...Я работаю антинаучным аферистом...
> У функции bsearch есть параметр - размер массива.
Что мешает сделать автомагическое расширение разрядности?
Достаточно расширить на один(!) разряд --- и наступит счастье.
> Пользователь вправе предполагать
Здесь нет поблизости ни одного пользователя.
Программист не вправе ничего предполагать,
он обязан прочитать примечания к коду.
> Тебя, надеюсь, не шокирует то, что a < a + 1 не всегда истинно,
> если речь идёт о языках программирования?
Меня не шокирует даже 2 * 2 = 5.
> К счастью для программистов разработчики компиляторов
А разработчики процессоров?
> находятся в несколько более здравом рассудке.
> Видишь ли, неоптимальная программа значительно лучше неработающей.
Неоптимальной программу делает прикладной программист,
которому лень сделать особый случай для очень больших объёмов данных.
> В случае bsearch покатит uint Mid(uint a, uint b) { return a + (b - a) / 2; }
Я уже продумал этот ход.
Расскажи, что происходит, если a > b.
---
...Я работаю антинаучным аферистом...
> Что мешает сделать автомагическое расширение разрядности?
> Достаточно расширить на один(!) разряд --- и наступит счастье.
Я не понял, что ты имеешь в виду под расширением разрядности и что под счастьем.
> Программист не вправе ничего предполагать,
> он обязан прочитать примечания к коду.
Приличные программисты пишут код так, чтобы не приходилось читать примечания к нему. Это позволяет другим программистам программировать с использованием его кода быстро и без ошибок.
> А разработчики процессоров?
?
> Неоптимальной программу делает прикладной программист,
> которому лень сделать особый случай для очень больших объёмов данных.
В данном случае которого программиста ты считаешь ленивым - разработчика или пользователя bsearch?
Вообще если в некоей машине есть быстрая операция взятия полусуммы, то неленивый разработчик оптимизированной библиотеки под неё сделает функцию halfsum, причём в двух вариантах - прямом и эмулируемом. А неленивый программист будет эту функцию использовать.
> Расскажи, что происходит, если a > b.
Ох. Вот именно поэтому, наверное, попытки сделать платформонезависимую реализацию bsearch не имеют смысла.
> Достаточно расширить на один(!) разряд --- и наступит счастье.
Я не понял, что ты имеешь в виду под расширением разрядности и что под счастьем.
> Программист не вправе ничего предполагать,
> он обязан прочитать примечания к коду.
Приличные программисты пишут код так, чтобы не приходилось читать примечания к нему. Это позволяет другим программистам программировать с использованием его кода быстро и без ошибок.
> А разработчики процессоров?
?
> Неоптимальной программу делает прикладной программист,
> которому лень сделать особый случай для очень больших объёмов данных.
В данном случае которого программиста ты считаешь ленивым - разработчика или пользователя bsearch?
Вообще если в некоей машине есть быстрая операция взятия полусуммы, то неленивый разработчик оптимизированной библиотеки под неё сделает функцию halfsum, причём в двух вариантах - прямом и эмулируемом. А неленивый программист будет эту функцию использовать.
> Расскажи, что происходит, если a > b.
Ох. Вот именно поэтому, наверное, попытки сделать платформонезависимую реализацию bsearch не имеют смысла.
>> Что мешает сделать автомагическое расширение разрядности?
>> Достаточно расширить на один(!) разряд --- и наступит счастье.
> Я не понял, что ты имеешь в виду под расширением разрядности и что под счастьем.
Полусумма берётся вот так:
>> Программист не вправе ничего предполагать,
>> он обязан прочитать примечания к коду.
> Приличные программисты пишут код так, чтобы не приходилось читать примечания к нему.
Расскажи, как можно использовать bsearch, если ты не знаешь порядка параметров.
Определять последний подбором?
> Это позволяет другим программистам программировать
> с использованием его кода быстро и без ошибок.
>> А разработчики процессоров?
> ?
Про слишком агрессивную оптимизацию только сейчас услышал?
Оно уже есть и давно есть.
>> Неоптимальной программу делает прикладной программист,
>> которому лень сделать особый случай для очень больших объёмов данных.
> В данном случае которого программиста ты считаешь ленивым -
> разработчика или пользователя bsearch?
Разработчика bsearch давай будем относить к системным,
ибо bsearch лежит где-то в /usr/src/lib/libc.
>> Расскажи, что происходит, если a > b.
> Ох. Вот именно поэтому, наверное, попытки сделать
> платформонезависимую реализацию bsearch не имеют смысла.
Выше показано, как это делается просто и ясно.
---
"Расширь своё сознание!"
>> Достаточно расширить на один(!) разряд --- и наступит счастье.
> Я не понял, что ты имеешь в виду под расширением разрядности и что под счастьем.
Полусумма берётся вот так:
: mid 0 tuck d+ d2/ drop ;
>> Программист не вправе ничего предполагать,
>> он обязан прочитать примечания к коду.
> Приличные программисты пишут код так, чтобы не приходилось читать примечания к нему.
Расскажи, как можно использовать bsearch, если ты не знаешь порядка параметров.
Определять последний подбором?
> Это позволяет другим программистам программировать
> с использованием его кода быстро и без ошибок.
>> А разработчики процессоров?
> ?
Про слишком агрессивную оптимизацию только сейчас услышал?
Оно уже есть и давно есть.
>> Неоптимальной программу делает прикладной программист,
>> которому лень сделать особый случай для очень больших объёмов данных.
> В данном случае которого программиста ты считаешь ленивым -
> разработчика или пользователя bsearch?
Разработчика bsearch давай будем относить к системным,
ибо bsearch лежит где-то в /usr/src/lib/libc.
>> Расскажи, что происходит, если a > b.
> Ох. Вот именно поэтому, наверное, попытки сделать
> платформонезависимую реализацию bsearch не имеют смысла.
Выше показано, как это делается просто и ясно.
---
"Расширь своё сознание!"
> Полусумма берётся вот так:
гы гы гы. Отлично! В твоём любимом языке есть встроенная возможность работать с числами двойной разрядности, поздравляю. В С есть соответствующая библиотека, названия которой я не знаю, но могу сам написать под любую архитектуру. И?
> Расскажи, как можно использовать bsearch, если ты не знаешь порядка параметров.
[ mode]я пишу bsearch жму ctrl+space и вижу список и типы параметров. Вот так я использую bsearch[/ mode]
> Выше показано, как это делается просто и ясно.
И неэффективно, по сравнению с непосредственным вычислением "a + (b - a) / 2". Собственно, проблема как раз в том, что тут нам нужна мега-функция int Mid_where_A_and_B_are_nonnegative_and_A_is_smaller_than_B(int a, int b но именно такая функция нам нужна только тут (скорее всего а просто функция Mid наверняка будет медленнее.
гы гы гы. Отлично! В твоём любимом языке есть встроенная возможность работать с числами двойной разрядности, поздравляю. В С есть соответствующая библиотека, названия которой я не знаю, но могу сам написать под любую архитектуру. И?
> Расскажи, как можно использовать bsearch, если ты не знаешь порядка параметров.
[ mode]я пишу bsearch жму ctrl+space и вижу список и типы параметров. Вот так я использую bsearch[/ mode]
> Выше показано, как это делается просто и ясно.
И неэффективно, по сравнению с непосредственным вычислением "a + (b - a) / 2". Собственно, проблема как раз в том, что тут нам нужна мега-функция int Mid_where_A_and_B_are_nonnegative_and_A_is_smaller_than_B(int a, int b но именно такая функция нам нужна только тут (скорее всего а просто функция Mid наверняка будет медленнее.
> Расскажи, что происходит, если a > b.Друзья, но ведь в bsearch a всегда меньше b!
Ох. Вот именно поэтому, наверное, попытки сделать платформонезависимую реализацию bsearch не имеют смысла.
Собственно, проблема как раз в том, что тут нам нужна мега-функция int Mid_where_A_and_B_are_nonnegative_and_A_is_smaller_than_B(int a, int b но именно такая функция нам нужна только тут (скорее всего а просто функция Mid наверняка будет медленнее.
т.е. ты не читаешь документацию на библиотеки?
понятно, откуда берутся люди, которые не понимают, например, что функция *scanf может что-то вернуть и смысл возвращаемого значения
понятно, откуда берутся люди, которые не понимают, например, что функция *scanf может что-то вернуть и смысл возвращаемого значения
> т.е. ты не читаешь документацию на библиотеки?
это нормально
правильная библиотека (программа, вещь) обязана поддерживать подход "попробуй использовать сразу(на интуиции но если ничего не получилось, то прочитай инструкцию".
это нормально
правильная библиотека (программа, вещь) обязана поддерживать подход "попробуй использовать сразу(на интуиции но если ничего не получилось, то прочитай инструкцию".
Я знаю, что как правило функции, которые могут не сработать, возвращают специальный код, который следует сравнивать с нулём, чтобы узнать, была ли функция успешной. Если кто-нибудь напишет функцию, которая возвращает 13 если ей удалось сделать то, что я от неё хочу, или 42 - если не удалось, я назову этого человека мудаком и плохим программистом.
А вообще я считаю, что описание функции в коде это а) возвращаемое значение, б) типы параметров, в) имена параметров, г) имя функции (порядок произволен). Хорошая функция позволяет мне себя использовать на основе только этих данных.
А вообще я считаю, что описание функции в коде это а) возвращаемое значение, б) типы параметров, в) имена параметров, г) имя функции (порядок произволен). Хорошая функция позволяет мне себя использовать на основе только этих данных.
как из кода прототипа сканфа ты узнаешь смысл возвращаемого значения?
или более феерический пример - fgetc
или более феерический пример - fgetc
scanf и fgetc - это идеал написания библиотечных функций?
Йопт, понятно что если речь идёт о функции типа fgetc, у которой основной смысл заключён именно в возвращаемом значении, то мне придётся посмотреть в ман, чтобы узнать, что именно она возвращает. Хотя и так можно догадаться, конечно =)
Тут речь вообще-то немножко не о том.
Тут речь вообще-то немножко не о том.
Кто тебе это сказал?
---
...Я работаю антинаучным аферистом...
---
...Я работаю антинаучным аферистом...
> названия которой я не знаю, но могу сам написать под любую архитектуру.
Переносимо?
>> Расскажи, как можно использовать bsearch, если ты не знаешь порядка параметров.
> [ mode]я пишу bsearch жму ctrl+space и вижу список и типы параметров. Вот так я использую bsearch[/ mode]
То есть ты всё-таки заглядываешь в документацию.
Религия мешает вставить в эту же документацию кроме списка и типов ещё и ограничения?
> И неэффективно
С какой стати?
Монстропроцессоры делают оба действия за одно время.
Или ты считаешь, что расширение нулём занимает много времени?
Хочешь, кстати, расскажу фишку?
То есть по любому прямая дорога лучше окольной.
---
...Я работаю антинаучным аферистом...
Переносимо?
>> Расскажи, как можно использовать bsearch, если ты не знаешь порядка параметров.
> [ mode]я пишу bsearch жму ctrl+space и вижу список и типы параметров. Вот так я использую bsearch[/ mode]
То есть ты всё-таки заглядываешь в документацию.
Религия мешает вставить в эту же документацию кроме списка и типов ещё и ограничения?
> И неэффективно
С какой стати?
Монстропроцессоры делают оба действия за одно время.
Или ты считаешь, что расширение нулём занимает много времени?
Хочешь, кстати, расскажу фишку?
add a, b
rcr a
То есть по любому прямая дорога лучше окольной.
---
...Я работаю антинаучным аферистом...
Я чего-то не понимаю. Если у нас 32-битная машина, то программе доступно максимум 2Гб памяти, и массив на 10^9 элементов хотя бы шорт интов в нее не влезет ни как. А если у нас 64-битная машина, то фиг ли использовать 32-битный int?
a(i) совсем не обязательно находится в RAM,
он туда может появляться лишь по требованию.
> А если у нас 64-битная машина, то фиг ли использовать 32-битный int?
Я скажу даже больше: даже если у нас 32-разрядная машина,
это не мешает использовать 64-разрядные числа.
---
...Я работаю антинаучным аферистом...
он туда может появляться лишь по требованию.
> А если у нас 64-битная машина, то фиг ли использовать 32-битный int?
Я скажу даже больше: даже если у нас 32-разрядная машина,
это не мешает использовать 64-разрядные числа.
---
...Я работаю антинаучным аферистом...
> Переносимо?
Переносимо с точки зрения пользователя библиотеки.
> Религия мешает вставить в эту же документацию кроме списка и типов ещё и ограничения?
Если я увижу в ограничениях на bsort фразу вида "Ни за что не давайте сюда массив размером больше MAX_INT/2", мне станет плохо и я умру.
> Монстропроцессоры делают оба действия за одно время.
для них маза написать свою версию bsearch.
> Хочешь, кстати, расскажу фишку?
Прикольная фишка. К чему это ты? Что таки можно написать функцию Mid? Окей, можно.
Переносимо с точки зрения пользователя библиотеки.
> Религия мешает вставить в эту же документацию кроме списка и типов ещё и ограничения?
Если я увижу в ограничениях на bsort фразу вида "Ни за что не давайте сюда массив размером больше MAX_INT/2", мне станет плохо и я умру.
> Монстропроцессоры делают оба действия за одно время.
для них маза написать свою версию bsearch.
> Хочешь, кстати, расскажу фишку?
Прикольная фишка. К чему это ты? Что таки можно написать функцию Mid? Окей, можно.
Зато туда влезет массив байтов! И он будет занимать как раз два гигабайта!
Я уж не говорю о массиве битов =)
Я уж не говорю о массиве битов =)
Если я увижу в ограничениях на bsort фразу вида "Ни за что не давайте сюда массив размером больше MAX_INT/2", мне станет плохо и я умру.Лучше, если ты не умрёшьЮ тебе будет хорошо и ты с чистой совестью подашь туда массив больше MAX_INT/2, после чего всё упадёт?
>> Переносимо?
> Переносимо с точки зрения пользователя библиотеки.
Даже если пользователь библиотеки начнёт выдирать куски?
> Если я увижу в ограничениях на bsort фразу вида
> "Ни за что не давайте сюда массив размером больше MAX_INT/2",
> мне станет плохо и я умру.
Напиши главным насильникам, чтобы ввели поддержку ограничений в язык.
> Прикольная фишка. К чему это ты?
К тому, что насильники сами себе находят трудности,
запирая в разрядной сетке int/long и вынуждая тем самым
придумывать хаки, наподобие
---
...Я работаю антинаучным аферистом...
> Переносимо с точки зрения пользователя библиотеки.
Даже если пользователь библиотеки начнёт выдирать куски?
> Если я увижу в ограничениях на bsort фразу вида
> "Ни за что не давайте сюда массив размером больше MAX_INT/2",
> мне станет плохо и я умру.
Напиши главным насильникам, чтобы ввели поддержку ограничений в язык.
> Прикольная фишка. К чему это ты?
К тому, что насильники сами себе находят трудности,
запирая в разрядной сетке int/long и вынуждая тем самым
придумывать хаки, наподобие
umid = a/2 + b/2 + (a%2 + b%2)/2;
---
...Я работаю антинаучным аферистом...
> Религия мешает вставить в эту же документацию кроме списка и типов ещё и ограничения?
теоретически никто не мешает, но меня в первую очередь интересует практическая сторона:
кто это будет делать, каким образом и за чьи деньги?
ps
у большинства методов большое (вернее даже очень большое) кол-во скрытых ограничений.
например, ограничения по кол-ву свободной памяти в куче, стеке.
теоретически никто не мешает, но меня в первую очередь интересует практическая сторона:
кто это будет делать, каким образом и за чьи деньги?
ps
у большинства методов большое (вернее даже очень большое) кол-во скрытых ограничений.
например, ограничения по кол-ву свободной памяти в куче, стеке.
Особенно bsearch полезен для работы с гигантскими массивами байтов и битов.
---
...Я работаю антинаучным аферистом...
---
...Я работаю антинаучным аферистом...
>> Религия мешает вставить в эту же документацию кроме списка и типов ещё и ограничения?
> теоретически никто не мешает, но меня в первую очередь интересует практическая сторона:
> кто это будет делать, каким образом и за чьи деньги?
Один человек за четверть часа исправит man page и протолкнёт это в CVS.
Это не настолько сложно.
> ps
Это уже давно проехали, следи за разговором.
---
...Я работаю антинаучным аферистом...
> теоретически никто не мешает, но меня в первую очередь интересует практическая сторона:
> кто это будет делать, каким образом и за чьи деньги?
Один человек за четверть часа исправит man page и протолкнёт это в CVS.
Это не настолько сложно.
> ps
Это уже давно проехали, следи за разговором.
---
...Я работаю антинаучным аферистом...
> Один человек за четверть часа исправит man page и протолкнёт это в CVS.
> Это не настолько сложно
это будет до наступления на грабли, или после?
если до - то каким образом - это скрытые ограничения будут искаться?
> Это не настолько сложно
это будет до наступления на грабли, или после?
если до - то каким образом - это скрытые ограничения будут искаться?
> это будет до наступления на грабли, или после?
По-хорошему --- до.
Вообще --- безразлично.
> если до - то каким образом - это скрытые ограничения будут искаться?
Скрытых ограничений нет, следи за разговором.
---
...Я работаю антинаучным аферистом...
По-хорошему --- до.
Вообще --- безразлично.
> если до - то каким образом - это скрытые ограничения будут искаться?
Скрытых ограничений нет, следи за разговором.
---
...Я работаю антинаучным аферистом...
> Вообще --- безразлично.
т.е. будет не общий подход:
1. для каких-то методов ограничения в man-е записаны, для каких-то нет.
2. да еще и документация плыть будет, т.е. если ты вчера увидел, что ограничений нет, не факт, что сегодня - все так же и осталось.
т.е. получается, что необходимо постоянно:
1. при каждом новом использовании метода - залезть в man, и посмотреть ограничения
2. для всех старых использований - каждую секунду лазить в man, и смотреть ограничения.
ps
имхо, теоретиков не надо подпускать к решению реальных задач.
т.е. будет не общий подход:
1. для каких-то методов ограничения в man-е записаны, для каких-то нет.
2. да еще и документация плыть будет, т.е. если ты вчера увидел, что ограничений нет, не факт, что сегодня - все так же и осталось.
т.е. получается, что необходимо постоянно:
1. при каждом новом использовании метода - залезть в man, и посмотреть ограничения
2. для всех старых использований - каждую секунду лазить в man, и смотреть ограничения.
ps
имхо, теоретиков не надо подпускать к решению реальных задач.
> Скрытых ограничений нет, следи за разговором
ты как всегда стараешься быть умнее всех и пытаешься думать за других.
с чего ты взял, что мои вопросы про скрытые ограничения уже были освещены в этом треде?
ты как всегда стараешься быть умнее всех и пытаешься думать за других.
с чего ты взял, что мои вопросы про скрытые ограничения уже были освещены в этом треде?
Мы с Fj уже давно договорились, что о скрытых ограничениях не говорим.
---
"Студенту надо повторять всё три раза, Ганс. Три раза. Запомни, Ганс: три раза."
---
"Студенту надо повторять всё три раза, Ганс. Три раза. Запомни, Ганс: три раза."
> т.е. получается, что необходимо постоянно:
Нет.
Необходимо просматривать список изменений CVS,
особенно тех, которые могут затрагивать работоспособность приложения.
Это обычная задача поддержки, которая одинакова везде.
> имхо, теоретиков не надо подпускать к решению реальных задач.
"Мой дед сохой пахал, мой отец сохой пахал, я сохой пахал, пашу и буду пахать.
И не допущу, чтобы кто-то каким-то трактором!.."
Достижения НТР прошли мимо насильников.
Всё те же 70-е.
---
...Я работаю антинаучным аферистом...
Нет.
Необходимо просматривать список изменений CVS,
особенно тех, которые могут затрагивать работоспособность приложения.
Это обычная задача поддержки, которая одинакова везде.
> имхо, теоретиков не надо подпускать к решению реальных задач.
"Мой дед сохой пахал, мой отец сохой пахал, я сохой пахал, пашу и буду пахать.
И не допущу, чтобы кто-то каким-то трактором!.."
Достижения НТР прошли мимо насильников.
Всё те же 70-е.
---
...Я работаю антинаучным аферистом...
> Мы с Fj уже давно договорились, что о скрытых ограничениях не говорим.
так вы уже договорились, чем скрытое ограничение отличается от нескрытого?
так вы уже договорились, чем скрытое ограничение отличается от нескрытого?
> Необходимо просматривать список изменений CVS,
опять же почему ты опять за всех решаешь, что у других этот список изменений обозримый?
опять же почему ты опять за всех решаешь, что у других этот список изменений обозримый?
> > имхо, теоретиков не надо подпускать к решению реальных задач.
>Достижения НТР прошли мимо насильников.
вывод неправильный делаешь.
правильный вывод, теоретиков подпускать нельзя к реальным задачам, потому что они думают, что их идеальный утопический мирок, придуманными ими - покрывает все реальные задачи.
это хорошо видно на тебе - ты постоянно считаешь, что твои способы решения проблемы, которые хорошо работают в твоем идеальном теоретическом мирке - обязаны работать и у всех других в их реальном мире.
>Достижения НТР прошли мимо насильников.
вывод неправильный делаешь.
правильный вывод, теоретиков подпускать нельзя к реальным задачам, потому что они думают, что их идеальный утопический мирок, придуманными ими - покрывает все реальные задачи.
это хорошо видно на тебе - ты постоянно считаешь, что твои способы решения проблемы, которые хорошо работают в твоем идеальном теоретическом мирке - обязаны работать и у всех других в их реальном мире.
Слушай, если ты не в курсе, о чём разговор, перечитай ещё раз.
Все ограничения известны в явном виде _по_условию_, уже давно.
Ты пришёл в самом конце и начинаешь ставить несовместимые условия.
Я ещё раз повторю свои вопросы, на которые ты тогда не ответил:
1. Ты всегда пытаешься подменить условия своими?
2. Ты и с заказчиком так работаешь, подменяя _его_ условия своими?
---
...Я работаю антинаучным аферистом...
Все ограничения известны в явном виде _по_условию_, уже давно.
Ты пришёл в самом конце и начинаешь ставить несовместимые условия.
Я ещё раз повторю свои вопросы, на которые ты тогда не ответил:
1. Ты всегда пытаешься подменить условия своими?
2. Ты и с заказчиком так работаешь, подменяя _его_ условия своими?
---
...Я работаю антинаучным аферистом...
Этот список --- обозримый.
Практика.
Если ты его сделал необозримым, значит ты допустил грубые ошибки при проектировании.
---
...Я работаю антинаучным аферистом...
Практика.
Если ты его сделал необозримым, значит ты допустил грубые ошибки при проектировании.
---
...Я работаю антинаучным аферистом...
> 1. Ты всегда пытаешься подменить условия своими?
да, если мои условия более общие, более системные, более логичные
2. Ты и с заказчиком так работаешь, подменяя _его_ условия своими?
заказчику честно говорю, что его условия имеют ряд проблем (противоречивы, решают не всю задачу, требуют лишние ресурсы) и предлагаю условия, которые минимизируют эти проблемы
если заказчик продолжает настаивать на своих условия, то решают задачу в его условиях.
да, если мои условия более общие, более системные, более логичные
2. Ты и с заказчиком так работаешь, подменяя _его_ условия своими?
заказчику честно говорю, что его условия имеют ряд проблем (противоречивы, решают не всю задачу, требуют лишние ресурсы) и предлагаю условия, которые минимизируют эти проблемы
если заказчик продолжает настаивать на своих условия, то решают задачу в его условиях.
> Все ограничения известны в явном виде _по_условию_, уже давно.
на практике - это означает, что ты сейчас можешь мне дать легким движением руки ссылочку на полный список этих ограничений, иначе это опять же теоретический треп.
на практике - это означает, что ты сейчас можешь мне дать легким движением руки ссылочку на полный список этих ограничений, иначе это опять же теоретический треп.
> Этот список --- обозримый.
> Практика.
> Если ты его сделал необозримым, значит ты допустил грубые ошибки при проектировании.
ню-ню
какой список изменений надо просматривать для следующего метода:
File::Open(name)
если этот метод многоплатформенный, многопротокольный и вдобавок внешним образом умеет подключать плагины.
> Практика.
> Если ты его сделал необозримым, значит ты допустил грубые ошибки при проектировании.
ню-ню
какой список изменений надо просматривать для следующего метода:
File::Open(name)
если этот метод многоплатформенный, многопротокольный и вдобавок внешним образом умеет подключать плагины.
>> 1. Ты всегда пытаешься подменить условия своими?
> да, если мои условия более общие,
Тогда почему ты занимаешься программированием, а не поиском смысла жизни?
> более системные, более логичные
То есть ради общности, системности и логичности
ты готов решать другую, куда более сложную задачу?
И кто из нас более практик?
>> 2. Ты и с заказчиком так работаешь, подменяя _его_ условия своими?
> заказчику честно говорю, что его условия имеют ряд проблем
> (противоречивы, решают не всю задачу, требуют лишние ресурсы)
"Согрешил!"
> и предлагаю условия, которые минимизируют эти проблемы
"Покайся!" и "Позолоти ручку!"
> если заказчик продолжает настаивать на своих условиях,
Понял я, что ты за птица.
Это вы любите делать тройной перезаклад по ресурсам:
"Файл-сервер --- одна машина, веб-прокси --- одна, почта --- одна,
дозвон --- одна, и ещё <<система слежения>> --- одна."
(Что-то я забыл... А! Ещё одна "система слежения." Теперь всё на месте --- 6.)
"Систему слежения" ещё ставите какую-нибудь очень дорогую и бесполезную,
ибо всё слежение заключается к сохранению почтового журнала
и подведению еженедельной и ежемесячной статистики,
кто, кому и сколько писал.
Узел на сто рабочих мест, блин.
Весь перезаклад из-за того, что "а вдруг они расширятся и захотят."
---
"Мы диалектику учили не по Гегелю.
Бряцанием боёв она врывалась в стих..."
> да, если мои условия более общие,
Тогда почему ты занимаешься программированием, а не поиском смысла жизни?
> более системные, более логичные
То есть ради общности, системности и логичности
ты готов решать другую, куда более сложную задачу?
И кто из нас более практик?
>> 2. Ты и с заказчиком так работаешь, подменяя _его_ условия своими?
> заказчику честно говорю, что его условия имеют ряд проблем
> (противоречивы, решают не всю задачу, требуют лишние ресурсы)
"Согрешил!"
> и предлагаю условия, которые минимизируют эти проблемы
"Покайся!" и "Позолоти ручку!"
> если заказчик продолжает настаивать на своих условиях,
Понял я, что ты за птица.
Это вы любите делать тройной перезаклад по ресурсам:
"Файл-сервер --- одна машина, веб-прокси --- одна, почта --- одна,
дозвон --- одна, и ещё <<система слежения>> --- одна."
(Что-то я забыл... А! Ещё одна "система слежения." Теперь всё на месте --- 6.)
"Систему слежения" ещё ставите какую-нибудь очень дорогую и бесполезную,
ибо всё слежение заключается к сохранению почтового журнала
и подведению еженедельной и ежемесячной статистики,
кто, кому и сколько писал.
Узел на сто рабочих мест, блин.
Весь перезаклад из-за того, что "а вдруг они расширятся и захотят."
---
"Мы диалектику учили не по Гегелю.
Бряцанием боёв она врывалась в стих..."
---
...Я работаю антинаучным аферистом...
...Я работаю антинаучным аферистом...
> То есть ради общности, системности и логичности
> ты готов решать другую, куда более сложную задачу?
наоборот.
благодаря общности, системности и логичности - я решаю более простую задачу, чем предлагал решать заказчик.
> Это вы любите делать тройной перезаклад по ресурсам
это не совсем про меня
ps
почему бы такой перезаклад не сделать, если такой перезаклад стоит копейки?
> ты готов решать другую, куда более сложную задачу?
наоборот.
благодаря общности, системности и логичности - я решаю более простую задачу, чем предлагал решать заказчик.
> Это вы любите делать тройной перезаклад по ресурсам
это не совсем про меня
ps
почему бы такой перезаклад не сделать, если такой перезаклад стоит копейки?
> Тогда почему ты занимаешься программированием, а не поиском смысла жизни?
в первом есть конкретные результаты, во втором случае - я не нашел.
в первом есть конкретные результаты, во втором случае - я не нашел.
> какой список изменений надо просматривать для следующего метода:
Зависимости определяются с помощью cflow(1).
> и вдобавок внешним образом умеет подключать плагины.
Корректность работы плагинов обеспечивается написателем плагинов.
Если ты заложил плагины, если ты решился, значит доверяешь.
---
...Я работаю антинаучным аферистом...
Зависимости определяются с помощью cflow(1).
> и вдобавок внешним образом умеет подключать плагины.
Корректность работы плагинов обеспечивается написателем плагинов.
Если ты заложил плагины, если ты решился, значит доверяешь.
---
...Я работаю антинаучным аферистом...
> Легко.
т.е. все известные проблемы, это то, что (a+b)/2 выдает корректный результат только для чисел, которые в два раза меньше, чем макс. ограничение типа?
т.е. все известные проблемы, это то, что (a+b)/2 выдает корректный результат только для чисел, которые в два раза меньше, чем макс. ограничение типа?
Весь перезаклад из-за того, что "а вдруг они расширятся и захотят."Во ВСЕХ проектах, которые мы делали, перезаклад по ресурсам был минимум в 2-5 раз. И это нормально, все заказчики именно этого хотели...
>> То есть ради общности, системности и логичности
>> ты готов решать другую, куда более сложную задачу?
> наоборот.
> благодаря общности, системности и логичности -
> я решаю более простую задачу, чем предлагал решать заказчик.
Ближе к делу.
То есть, вместо того, чтобы написать просто "(a+b)/2",
ты решаешь задачу, как бы так переписать "(a+b)/2",
чтобы оно сработало в том, не реализуемом у заказчика случае,
когда "a+b" переполняет разрядную сетку.
Причём так, чтобы учесть случаи сложения-вычитания с насыщением
и неупорядоченности значений a и b.
Так?
>> Это вы любите делать тройной перезаклад по ресурсам
это не совсем про меня
> почему бы такой перезаклад не сделать, если такой перезаклад стоит копейки?
Он стоит не копейки.
Если брать исходную задачу, то копейки стоит assert,
а не головоломные трюки с арифметикой.
---
...Я работаю антинаучным аферистом...
>> ты готов решать другую, куда более сложную задачу?
> наоборот.
> благодаря общности, системности и логичности -
> я решаю более простую задачу, чем предлагал решать заказчик.
Ближе к делу.
То есть, вместо того, чтобы написать просто "(a+b)/2",
ты решаешь задачу, как бы так переписать "(a+b)/2",
чтобы оно сработало в том, не реализуемом у заказчика случае,
когда "a+b" переполняет разрядную сетку.
Причём так, чтобы учесть случаи сложения-вычитания с насыщением
и неупорядоченности значений a и b.
Так?
>> Это вы любите делать тройной перезаклад по ресурсам
это не совсем про меня
> почему бы такой перезаклад не сделать, если такой перезаклад стоит копейки?
Он стоит не копейки.
Если брать исходную задачу, то копейки стоит assert,
а не головоломные трюки с арифметикой.
---
...Я работаю антинаучным аферистом...
>> Весь перезаклад из-за того, что "а вдруг они расширятся и захотят."
> Во ВСЕХ проектах, которые мы делали, перезаклад по ресурсам был минимум в 2-5 раз.
> И это нормально, все заказчики именно этого хотели...
Я очень хотел бы знать, каким образом они собираются расширяться,
и каким образом они хотят при этом расширении обойти те условия,
которые они сами и задали, без перепроектирования.
---
...Я работаю антинаучным аферистом...
> Во ВСЕХ проектах, которые мы делали, перезаклад по ресурсам был минимум в 2-5 раз.
> И это нормально, все заказчики именно этого хотели...
Я очень хотел бы знать, каким образом они собираются расширяться,
и каким образом они хотят при этом расширении обойти те условия,
которые они сами и задали, без перепроектирования.
---
...Я работаю антинаучным аферистом...
> Так?
нет.
общий случай будет - это просто поднять разрядность int-а много выше, чем разрядность задачи клиента
> чтобы оно сработало в том, не реализуемом у заказчика случае, когда "a+b" переполняет разрядную сетку
это ты как раз хочешь рассматривать вырожденные случаи, а не общий случай
нет.
общий случай будет - это просто поднять разрядность int-а много выше, чем разрядность задачи клиента
> чтобы оно сработало в том, не реализуемом у заказчика случае, когда "a+b" переполняет разрядную сетку
это ты как раз хочешь рассматривать вырожденные случаи, а не общий случай
> Если брать исходную задачу, то копейки стоит assert,
assert стоит очень дорого, потому что приводит к отказам у пользователя на реальных больших задачах.
т.е. если допустим полное время исправления ошибки - неделя, а программа обслуживает транзакции оборотом 1 млн. $ в месяц, то assert стоит 250 тыс $.
assert стоит очень дорого, потому что приводит к отказам у пользователя на реальных больших задачах.
т.е. если допустим полное время исправления ошибки - неделя, а программа обслуживает транзакции оборотом 1 млн. $ в месяц, то assert стоит 250 тыс $.
Странный метод подсчёта... я бы сказал, так обычно не считают. Вот у нас недавно падение было - наверное полчаса или час простоя. Оборот за день порядка 1-3 млрд евро. Ежели твоим методом посчитать, то мы бы давно разорились 
> Странный метод подсчёта... я бы сказал, так обычно не считают
нормальный метод подсчета - если транзакции мы не умеем обрабатывать задним числом.
возьмем приложение типа сайта, телекоммуникационное ПО или ПО по управлению реальной системой (например, тем же аэропортом)
> Вот у нас недавно падение было - наверное полчаса или час простоя. Оборот за день порядка 1-3 млрд евро
это только означает, что ваши транзакции можно откладывать на полчаса или час.
нормальный метод подсчета - если транзакции мы не умеем обрабатывать задним числом.
возьмем приложение типа сайта, телекоммуникационное ПО или ПО по управлению реальной системой (например, тем же аэропортом)
> Вот у нас недавно падение было - наверное полчаса или час простоя. Оборот за день порядка 1-3 млрд евро
это только означает, что ваши транзакции можно откладывать на полчаса или час.
>> чтобы оно сработало в том, не реализуемом у заказчика случае, когда "a+b" переполняет разрядную сетку
> это ты как раз хочешь рассматривать вырожденные случаи, а не общий случай
Ты упорно не хочешь понимать разницу между общим случаем и (совсем) произвольным.
Я разбираю как раз _общий_ случай.
---
"Математик может говорить, что ему хочется,
но физик должен, хотя бы в какой-то мере, быть в здравом рассудке."
> это ты как раз хочешь рассматривать вырожденные случаи, а не общий случай
Ты упорно не хочешь понимать разницу между общим случаем и (совсем) произвольным.
Я разбираю как раз _общий_ случай.
---
"Математик может говорить, что ему хочется,
но физик должен, хотя бы в какой-то мере, быть в здравом рассудке."
>> Если брать исходную задачу, то копейки стоит assert,
> assert стоит очень дорого, потому что приводит к отказам
> у пользователя на реальных больших задачах.
> т.е. если допустим полное время исправления ошибки - неделя,
> а программа обслуживает транзакции оборотом 1 млн. $ в месяц, то assert стоит 250 тыс $.
Объясни, чем отличается простой, вызванный остановкой по assert,
от того же простоя, вызванного остановкой по другому условию,
полностью равнозначному тому же assert, но написанному в другом месте.
Я даже скажу, что тот другой assert значительно хуже, чем соответствующий в bsearch, потому что:
а) находится в совершенно другом, не относящемся к bsearch месте;
б) очень неочевиден и потому может быть выкинут каким-нибудь умником,
решившим, что вводится ненужное ограничение;
в) даже если не "б", из-за "а" затрудняется поиск ошибки,
то есть удлинняются сроки исправления, если вдруг.
---
...Я работаю антинаучным аферистом...
> assert стоит очень дорого, потому что приводит к отказам
> у пользователя на реальных больших задачах.
> т.е. если допустим полное время исправления ошибки - неделя,
> а программа обслуживает транзакции оборотом 1 млн. $ в месяц, то assert стоит 250 тыс $.
Объясни, чем отличается простой, вызванный остановкой по assert,
от того же простоя, вызванного остановкой по другому условию,
полностью равнозначному тому же assert, но написанному в другом месте.
Я даже скажу, что тот другой assert значительно хуже, чем соответствующий в bsearch, потому что:
а) находится в совершенно другом, не относящемся к bsearch месте;
б) очень неочевиден и потому может быть выкинут каким-нибудь умником,
решившим, что вводится ненужное ограничение;
в) даже если не "б", из-за "а" затрудняется поиск ошибки,
то есть удлинняются сроки исправления, если вдруг.
---
...Я работаю антинаучным аферистом...
> Объясни, чем отличается простой, вызванный остановкой по assert,
смотря, конечно, что понимать под assert-ом.
если это assert который стопит все приложение, то понятно почему это приводит к убыткам, в отличии - от его отсутствия. получается, что второстепенный код запросто может убить главную ветку.
если это assert в виде exception, то я не понимаю, чем этот exception будет отличаться от overflow exception-а, который и так вызовется, если a+b выходит за границы int-а
смотря, конечно, что понимать под assert-ом.
если это assert который стопит все приложение, то понятно почему это приводит к убыткам, в отличии - от его отсутствия. получается, что второстепенный код запросто может убить главную ветку.
если это assert в виде exception, то я не понимаю, чем этот exception будет отличаться от overflow exception-а, который и так вызовется, если a+b выходит за границы int-а
> Я разбираю как раз _общий_ случай.
это вопрос, конечно, больше терминологический, но все-таки ты скорее разбираешь полный случай, а не общий, т.к. общий случай как раз обычно рассматривается без деталей.
это вопрос, конечно, больше терминологический, но все-таки ты скорее разбираешь полный случай, а не общий, т.к. общий случай как раз обычно рассматривается без деталей.
>> Объясни, чем отличается простой, вызванный остановкой по assert,
> смотря, конечно, что понимать под assert-ом.
Проверка требования "sine qua non".
> если это assert который стопит все приложение, <...>
> если это assert в виде exception
Ты никогда не видел assert, что ли?
> если это assert в виде exception, то я не понимаю,
> чем этот exception будет отличаться от overflow exception-а,
> который и так вызовется, если a+b выходит за границы int-а
Тем, что перед объявлением исключения он напечатает, что и где не срослось.
Это значительно упростит поиск ошибки, ибо не потребуется:
а) пересборки исходников с отладочными данными;
б) воспроизведения ошибочного состояния;
в) разбора полётов по выгрузке памяти.
---
...Я работаю антинаучным аферистом...
> смотря, конечно, что понимать под assert-ом.
Проверка требования "sine qua non".
> если это assert который стопит все приложение, <...>
> если это assert в виде exception
Ты никогда не видел assert, что ли?
> если это assert в виде exception, то я не понимаю,
> чем этот exception будет отличаться от overflow exception-а,
> который и так вызовется, если a+b выходит за границы int-а
Тем, что перед объявлением исключения он напечатает, что и где не срослось.
Это значительно упростит поиск ошибки, ибо не потребуется:
а) пересборки исходников с отладочными данными;
б) воспроизведения ошибочного состояния;
в) разбора полётов по выгрузке памяти.
---
...Я работаю антинаучным аферистом...
В общем случае, прямые не параллельны.
В полном случае --- бывают.
---
...Я работаю антинаучным аферистом...
В полном случае --- бывают.
---
...Я работаю антинаучным аферистом...
> Это значительно упростит поиск ошибки, ибо не потребуется:
в современных языках - это все видно будет и по самому exception-у
в современных языках - это все видно будет и по самому exception-у
>> Это значительно упростит поиск ошибки, ибо не потребуется:
> в современных языках - это все видно будет и по самому exception-у
У тебя промышленный код идёт со всеми отладочными примочками?
---
...Я работаю антинаучным аферистом...
> в современных языках - это все видно будет и по самому exception-у
У тебя промышленный код идёт со всеми отладочными примочками?
---
...Я работаю антинаучным аферистом...
> У тебя промышленный код идёт со всеми отладочными примочками?
конечно.
вспоминается выражение: отключать диагностику в промышленном коде, это все равно, что делать реальный прыжок без запасного парашюта
конечно.
вспоминается выражение: отключать диагностику в промышленном коде, это все равно, что делать реальный прыжок без запасного парашюта
Ну не со всеми, наверное.
То есть оптимизация включена, не правда ли? Так что стек трейс в эксепшене может быть достаточно загадочным, что, впрочем, не должно особо помешать в локализации ошибки.
То есть оптимизация включена, не правда ли? Так что стек трейс в эксепшене может быть достаточно загадочным, что, впрочем, не должно особо помешать в локализации ошибки.
Диагностика --- это "assert", а отладочные --- это вплоть до сохранения разбиения на строчки исходного кода.
У тебя промышленный код идёт с никакой оптимизацией?
---
...Я работаю антинаучным аферистом...
У тебя промышленный код идёт с никакой оптимизацией?
---
...Я работаю антинаучным аферистом...
> Диагностика --- это "assert", а отладочные --- это вплоть до сохранения разбиения на строчки исходного кода.
диагностика - это много большее, чем assert-ы - диагностика, это и отслеживание производительности, отслеживание ошибок, востановление состояний после сбоев, watchdog-и и т.д.
> У тебя промышленный код идёт с никакой оптимизацией?
пока я совсем не понимаю - почему оптимизация должна отказывать в стремлении оставить в коде информацию о разбиении на строки исходного кода.
диагностика - это много большее, чем assert-ы - диагностика, это и отслеживание производительности, отслеживание ошибок, востановление состояний после сбоев, watchdog-и и т.д.
> У тебя промышленный код идёт с никакой оптимизацией?
пока я совсем не понимаю - почему оптимизация должна отказывать в стремлении оставить в коде информацию о разбиении на строки исходного кода.
> востановление состояний после сбоев, watchdog-и
У тебя весьма странные понятия о диагностике.
Ты б в словарь заглянул, что ли, раз смысла слов не понимаешь.
>> У тебя промышленный код идёт с никакой оптимизацией?
> пока я совсем не понимаю - почему оптимизация должна отказывать
> в стремлении оставить в коде информацию о разбиении на строки исходного кода.
Потому что оптимальный машинный код может очень сильно
отличаться от написанного на языке высокого уровня.
Например, может оказаться так, что вместо вызова функция будет вшита прямо так,
циклы могут быть развёрнуты, а счётчик --- не существовать.
assert от этого работать не перестанет, а вот некоторые другие средства --- очень даже могут.
---
...Я работаю антинаучным аферистом...
У тебя весьма странные понятия о диагностике.
Ты б в словарь заглянул, что ли, раз смысла слов не понимаешь.
>> У тебя промышленный код идёт с никакой оптимизацией?
> пока я совсем не понимаю - почему оптимизация должна отказывать
> в стремлении оставить в коде информацию о разбиении на строки исходного кода.
Потому что оптимальный машинный код может очень сильно
отличаться от написанного на языке высокого уровня.
Например, может оказаться так, что вместо вызова функция будет вшита прямо так,
циклы могут быть развёрнуты, а счётчик --- не существовать.
assert от этого работать не перестанет, а вот некоторые другие средства --- очень даже могут.
---
...Я работаю антинаучным аферистом...
> У тебя весьма странные понятия о диагностике.
это примеры тех средств - которые уже пользуются результатами диагностики
их я как раз привел для того, чтобы показать, что нельзя диагностику отключать в промышленном коде.
> Потому что оптимальный машинный код может очень сильно отличаться от написанного на языке высокого уровня.
на данный момент развития средств разработки - отличается очень слабо.
не меняется самое главное - структура классов и методов, т.к. только редкий метод - inline-ится
> Например, может оказаться так, что вместо вызова функция будет вшита прямо так,
> циклы могут быть развёрнуты, а счётчик --- не существовать.
это все очень локальные изменения, которые совсем не влияют на понимание работы кода
это примеры тех средств - которые уже пользуются результатами диагностики
их я как раз привел для того, чтобы показать, что нельзя диагностику отключать в промышленном коде.
> Потому что оптимальный машинный код может очень сильно отличаться от написанного на языке высокого уровня.
на данный момент развития средств разработки - отличается очень слабо.
не меняется самое главное - структура классов и методов, т.к. только редкий метод - inline-ится
> Например, может оказаться так, что вместо вызова функция будет вшита прямо так,
> циклы могут быть развёрнуты, а счётчик --- не существовать.
это все очень локальные изменения, которые совсем не влияют на понимание работы кода
на данный момент развития средств разработки - отличается очень слабо.Что-то ты гонишь, по-моему. Номер строки с ошибкой является весьма важным компонентом стектрейса, а в, кхм, промышленном бинарном коде (добываемом угрюмыми операторами компиляторов) его просто не может быть. Ассерты же позволяют явно указать компилятору те довольно немногие места, для которых нужно сохранить подробную Debug Info. Я правильно понимаю?
не меняется самое главное - структура классов и методов, т.к. только редкий метод - inline-ится
> Номер строки с ошибкой является весьма важным компонентом стектрейса
он важен только - если тела методов писать строк на 200-1000.
если же тела методов разумные - 5-10 строк, то даже причину самого неинформативного exception-а (null reference) и то можно понять, имея на руках stack trace вызовов методов, и исходный код этих методов
он важен только - если тела методов писать строк на 200-1000.
если же тела методов разумные - 5-10 строк, то даже причину самого неинформативного exception-а (null reference) и то можно понять, имея на руках stack trace вызовов методов, и исходный код этих методов
> если же тела методов разумные - 5-10 строк
> если же тела методов разумные - 5-10 строк,
Допустим, что даже так --- чёрт с ним.
> то даже причину самого неинформативного exception-а (null reference)
> и то можно понять, имея на руках stack trace вызовов методов,
Допустим, развернули пять уровней вызовов,
из-за чего эти вложения стека просто не отражаются.
Что ты будешь делать?
А что ты будешь делать, если глубина вложений возрастёт,
но они точно так же будут разворачиваться компилятором?
---
"Мы диалектику учили не по Гегелю."
Допустим, что даже так --- чёрт с ним.
> то даже причину самого неинформативного exception-а (null reference)
> и то можно понять, имея на руках stack trace вызовов методов,
Допустим, развернули пять уровней вызовов,
из-за чего эти вложения стека просто не отражаются.
Что ты будешь делать?
А что ты будешь делать, если глубина вложений возрастёт,
но они точно так же будут разворачиваться компилятором?
---
"Мы диалектику учили не по Гегелю."
>> Потому что оптимальный машинный код может очень сильно
>> отличаться от написанного на языке высокого уровня.
> на данный момент развития средств разработки - отличается очень слабо.
Ну да!
Ты не видел оптимизирующих компиляторов?
> не меняется самое главное - структура классов и методов,
Эта структура относится к языку высокого уровня,
машинный код может никак её не отражать.
> т.к. только редкий метод - inline-ится
Отсюда можно сделать такие выводы:
а) ты пишешь на языке очень низкого уровня, либо
б) ты пишешь очень неоптимально, чуть ли не намеренно препятствуя оптимизатору, либо
в) у тебя очень хреновый компилятор.
---
"Мы диалектику учили не по Гегелю."
>> отличаться от написанного на языке высокого уровня.
> на данный момент развития средств разработки - отличается очень слабо.
Ну да!
Ты не видел оптимизирующих компиляторов?
> не меняется самое главное - структура классов и методов,
Эта структура относится к языку высокого уровня,
машинный код может никак её не отражать.
> т.к. только редкий метод - inline-ится
Отсюда можно сделать такие выводы:
а) ты пишешь на языке очень низкого уровня, либо
б) ты пишешь очень неоптимально, чуть ли не намеренно препятствуя оптимизатору, либо
в) у тебя очень хреновый компилятор.
---
"Мы диалектику учили не по Гегелю."
Оставить комментарий
Ivan8209
http://googleresearch.blogspot.com/2006/06/extra-extra-read-...---
"А я обучался азбуке с вывесок,
листая страницы железа и жести."