Здравствуйте, vsb, Вы писали:

vsb>Здравствуйте, netch80, Вы писали:

vsb>>>Мне нравится, как в JS сделали. float64 без вариантов.

N>>Они даже это сделать не сумели.
N>>Битовые операции в JS выполняются после конверсии в int32_t, с автоокруглением.

vsb>А что в этом плохого?

Ну, например, что в double 53 бита целых, а урезают до 32. Нелепица какая-то.

vsb> Какие альтернативы?

Постановить выполнение этих операций в тех же 53 битах, например.

Здравствуйте, Alekzander, Вы писали:

N>>В вашей реплике есть принципиальная ошибка и подтасовка
A>Вот как удивительно: а я увидел подстасовку в приведении такого примера, где ошибку совершать нельзя. И показал в ответ, как это обойти.

Просто "обойти" было и так очевидно, как. А вот чтобы это было эффективно для кодирования, отладки и сопровождения — уже нет.

A>А вообще, тезис в том, что (ИМХО) не надо на компиляцию возлагать больших надежд, связанных с проверкой корректности функционирования программы. Что может проверить компилятор?

Очень многое.

A> Соответствие грамматике и т.п. К правильному функционированию это имеет оооооочень опосредованное отношение.

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

A> Чекеры это уже лучше, это уже тесты, хоть и чисто модульные. А основные выводы о готовности к проду надо делать по результатам интеграционных.

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

A>А поскольку я сторонник подхода, что если что-то работает ненадёжно, то и использовать это не надо

А оно работает ненадёжно? Это где и когда?

A> (идея та же, по которой люди запрещают security through obscurity),

Не вижу связи.

A> я считаю, что не стоит использовать все эти a: int 1..100 ни для чего, кроме как для декларации о намерениях (а вот для этого — надо). По сути, можно в имени или комментарии то же написать, но просто менее удобно. Ну, ещё логгер нарушений для дебажной версии, раз он всё равно халявный, но чисто для удобства отладки, не для выяснения, есть ли ошибки.

Я надеюсь, с таким подходом вы ничего серьёзного не разрабатываете...

Здравствуйте, netch80, Вы писали:

CC>>>Открой для себя С++ где ты можешь себе сделать такой тип сам, с любыми проверками
CC>>>Возможно уже даже в std завезли какой нить готовый template.
CC>>>И он будет работать везде автоматически, никаких вписываний проверок вручную.

A>>А не подскажете, дяденька, C++, случайно, не Тьюринг-полный язык?

A>>P.S. Ещё можно понять рекомендацию языка с синтаксическими макросами, где генерация типа с любыми проверками (1..100) идёт на лету, но C++ с его ручными проверками, в которых лучшая реализация is_in_set сделана на шаблонах...

N>А какая разница, если на выходе получается ровно код проверки при укладке в переменную?

Довольно странно при обсуждении фичи "a: int 1..100" рекомендовать язык, который не умеет это ни из коробки, ни за счёт расширений (синтаксических макросов), а умеет только за счёт Тьюринг-полноты.

Ну ладно, шаблоны это всё-таки нечто промежуточное. Т.е. рекомендовать открыть для себя C++ в данной ситуации это всё-таки лучше, чем, например, ассемблер.

Здравствуйте, netch80, Вы писали:

vsb>>А что в этом плохого?

N>Ну, например, что в double 53 бита целых, а урезают до 32. Нелепица какая-то.

vsb>> Какие альтернативы?

N>Постановить выполнение этих операций в тех же 53 битах, например.

Для чего тебе вообще нужны битовые операции?

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

Ну некоторые упоротые заменяют Math.trunc на ||0 или деление на сдвиг, но я считаю это кулхацкерской дуростью.

Эти юз-кейсы в основном покрываются 1/2/4 байтами.

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

В общем я не убеждён, что это плохой дизайн. Свою задачу он решает. Как работает V8 и как он обеспечивает быстрое выполнение подобного кода, я не вполне представляю и если для поддержки 53 битов придётся сильно пожертвовать производительностью в 32 битах, тогда это плохой вариант. Если можно поддерживать 53 бита без снижения производителности для 32 битов, ну можно и так. Я не против этого принципиально, в конце концов если работает для 53 битов, то и для 32 битов, очевидно, будет работать ровно так же, но тут вся суть в том, можно ли это реализовать так, чтобы оно работало с нужной скоростью.

Здравствуйте, netch80, Вы писали:

N>Я не про это, а про использования именно округления как средства обогащения.

Так это про воровство, округление лишь способ. Тебя посодют, а ты не воруй

Здравствуйте, netch80, Вы писали:


N>Упоминание Карацубы тут крайне странно.
N>В текущем GMP на x86-64, например, переход к нему (точнее, к Тоому-Куку 2*2, но считаем эквивалентным) начинается от 27 лимбов, то есть от 216 бит. До этого "столбиком" ("schoolbook") считается эффективнее. Да, это цена out-of-order, кэшей и т.п.

Странно, я делал умножение столбиком для Long Decimal, было жопно долго для любых чисел, потом сделал на каких-то свёртках вроде, на порядок ускорился, про Карацуб и Куков не встретил инфы, когда делал

Здравствуйте, Marty, Вы писали:

N>>Упоминание Карацубы тут крайне странно.
N>>В текущем GMP на x86-64, например, переход к нему (точнее, к Тоому-Куку 2*2, но считаем эквивалентным) начинается от 27 лимбов, то есть от 216 бит. До этого "столбиком" ("schoolbook") считается эффективнее. Да, это цена out-of-order, кэшей и т.п.

M>Странно, я делал умножение столбиком для Long Decimal, было жопно долго для любых чисел, потом сделал на каких-то свёртках вроде, на порядок ускорился, про Карацуб и Куков не встретил инфы, когда делал

Ты вроде писал, что посмотрел на FFT, а затем сделал по Фюреру.
Но как можно было при этом пропустить Тоома-Кука, я не знаю.

Здравствуйте, netch80, Вы писали:

Ой, начался нитпикинг. Давай я тебе сразу поясню кое-что. На ваш этот C++ мне, в целом, наплевать. Пациент всё равно скорее мёртв, чем жив. (Я имею в виду не C/C++ или C++/Qt или ещё что-то, на чём пишут вменяемые разработчики, а настоящий C++ с религией const, наиболее упоротыми конструкциями из std и шаблонным метапрограммированием). На что мне не плевать — это когда вчерашние плюсовики приходят в JS и начинают лепить из него Typescript, потому, что верят в то, что без компилятора у них ошибок будет больше. Хотя с виртуальной машиной там и ошибок-то таких не бывает, как в сях. Поэтому когда я вижу, как кто-то предлагает на компилятор наложить ещё больше проверок, я автоматически триггерюсь. Тесты, тесты, тесты.

Здравствуйте, netch80, Вы писали:

M>>Странно, я делал умножение столбиком для Long Decimal, было жопно долго для любых чисел, потом сделал на каких-то свёртках вроде, на порядок ускорился, про Карацуб и Куков не встретил инфы, когда делал

N>Ты вроде писал, что посмотрел на FFT, а затем сделал по Фюреру.

Да, точно, вроде Фюрер


N>Но как можно было при этом пропустить Тоома-Кука, я не знаю.

Ну вот как-то так

Но я про то, что столбиком — это крайне неэффективно в любом случае

Здравствуйте, vsb, Вы писали:

vsb>Для чего тебе вообще нужны битовые операции?
vsb>Мне они нужны для разбора протоколов в основном. Для разборки байтов в биты и для сборки байтов из битов. Не припомню ни одного юз-кейса, где бы я использовал их для чего-либо ещё.

Ну да.
Но народ на JS вообще видеокодеки пишет.

vsb>Эти юз-кейсы в основном покрываются 1/2/4 байтами.

Хм, в IP6 заголовке и 16-байтные поля есть, аж два

vsb>Где мне были бы полезны битовые операции в 53 бита, я вообще представить не могу. Ну можно придумать, типа приходят 7 байтов, и в них 53 бита значащие , но это явно будет придумка.

Ну тут я согласен, что случаев, когда надо именно 53, как-то мало, мягко говоря.
Хотя на 48 уже можно найти. Мак-адрес, например.

vsb>В общем я не убеждён, что это плохой дизайн. Свою задачу он решает. Как работает V8 и как он обеспечивает быстрое выполнение подобного кода, я не вполне представляю и если для поддержки 53 битов придётся сильно пожертвовать производительностью в 32 битах, тогда это плохой вариант.

На 64-битных платформах жертв уже нет.

vsb> Если можно поддерживать 53 бита без снижения производителности для 32 битов, ну можно и так. Я не против этого принципиально, в конце концов если работает для 53 битов, то и для 32 битов, очевидно, будет работать ровно так же, но тут вся суть в том, можно ли это реализовать так, чтобы оно работало с нужной скоростью.

Можно. Сейчас. Но захардкодили усечение, которое имело смысл только для 32.

Здравствуйте, Alekzander, Вы писали:

A>Довольно странно при обсуждении фичи "a: int 1..100" рекомендовать язык, который не умеет это ни из коробки, ни за счёт расширений (синтаксических макросов), а умеет только за счёт Тьюринг-полноты.

Тьюринг-полнота ни при чём.

Шаблон вида

template <int _T_min, int _T_max>
RangedInteger& operator=(int new_value) {
  if (new_value < _T_min || new_value > _T_max) { throw range_error(); }
  mValue = new_value;
  return *this;
}

ничего такого не требует. Это тупой шаблон без всякой хитрой логики и рекурсии.

A>Ну ладно, шаблоны это всё-таки нечто промежуточное. Т.е. рекомендовать открыть для себя C++ в данной ситуации это всё-таки лучше, чем, например, ассемблер.

Разве что из-за оптимизаций. В ассемблере есть макры.

Здравствуйте, Alekzander, Вы писали:

A>Здравствуйте, netch80, Вы писали:

A>Ой, начался нитпикинг.



A> На что мне не плевать — это когда вчерашние плюсовики приходят в JS и начинают лепить из него Typescript, потому, что верят в то, что без компилятора у них ошибок будет больше.

Чего "верить", это реальность.

A> Хотя с виртуальной машиной там и ошибок-то таких не бывает, как в сях.

Ну да, там другие ошибки:



Зато не вылетает, продолжает куда-то ехать.

A> Поэтому когда я вижу, как кто-то предлагает на компилятор наложить ещё больше проверок, я автоматически триггерюсь.

Ещё больше чем TypeScript?

A> Тесты, тесты, тесты.

Халва, халва, халва.

Здравствуйте, Alekzander, Вы писали:

A>Ещё можно понять рекомендацию языка с синтаксическими макросами, где генерация типа с любыми проверками (1..100) идёт на лету

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

Здравствуйте, netch80, Вы писали:

N>Другой вопрос, что CC почему-то решил поадмиральствовать там, где C++ никак не обязателен и может и не подходить по 100500 причин...
Это был пример языка достаточной выразительности.

Здравствуйте, Alekzander, Вы писали:

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

Здравствуйте, vsb, Вы писали:

vsb>Для чего тебе вообще нужны битовые операции?
Отдельные психопаты пишут криптографию на JS и пихают это везде как "новое и молодёжное"

Здравствуйте, netch80, Вы писали:

N>Но народ на JS вообще видеокодеки пишет.
Проблема в том, что езыг, который никогда не проектировался быть полноценным, всякие вьюноши со взором горящим начали использовать как тот самый молоток и забивать им всё подряд.

Здравствуйте, Marty, Вы писали:

M>Но я про то, что столбиком — это крайне неэффективно в любом случае
А в "столбике" у тебя значения были какой разрядности?

Здравствуйте, CreatorCray, Вы писали:

M>>Но я про то, что столбиком — это крайне неэффективно в любом случае
CC>А в "столбике" у тебя значения были какой разрядности?

У меня один байт — одна десятичная цифра

Здравствуйте, Marty, Вы писали:

M>>>Но я про то, что столбиком — это крайне неэффективно в любом случае
CC>>А в "столбике" у тебя значения были какой разрядности?
M>У меня один байт — одна десятичная цифра
Ух! Не, ну тогда понятно почему всё так безумно медленно.