В матрице найти число элементов, кратных k

Для целочисленной квадратной матрицы найти число элементов, кратных k, и наибольший из них

Сообщение от abit действительно имеет высокий порог вхождения, ну уверяю он того стоит!

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

Сообщение от abit Люди читают десятки книг про всякие атомик-операции, паттерны, симофоры, voltile и мьютексы, и это только в многопоточности, а в Rust вам достаточно подключить один трейт в cargo и компилятор ударит по рукам если что-то не так, и так всегда - почти всё там сделано именно по идеалу, не нужно читать кучу ложных путей, язык почти не позволит вам написать ерунду, только если специально стараться, там на уровне языка от тебя хотят хороший стиль

Впечатление что Вы переживаете "конфетно-букетный" период Но за ним будут суровые/серые будни, и кто знает, может бабочка упорхнет на новый (еще более прекрасный) цветок Жизненный опыт учит что "за все надо платить". Возможно поддержка multi-threading там действительно хороша, но смириться с ограничениями придется. Так всегда бывает если "за меня что-то делают" (пусть и хорошо). Вы так и не ответили насчет достигаемой масштабируемости.

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

0

Сообщение от Igor3D Впечатление что Вы переживаете "конфетно-букетный" период Но за ним будут суровые/серые будни, и кто знает, может бабочка упорхнет на новый (еще более прекрасный) цветок

ну тут как посмотреть, для С++ такого периода не было, вообще, это было жёстко, я не зря привёл пример с std::initializer_list<T>, там чёрт ногу сломит когда и какой конструктор будет вызываться, если пишешь что-то такое на С++ - это считай ты зарядил дробовик направил себе в колено!
и чем больше я погружался в это всё тем больше мне казалось что они специально так делают чтобы никто ничего не понял))) на этом фоне языки типа Haskell, Erlang или Rust выгодно отличаются, там всегда знаешь чего ожидать

опять же я вам привёл конкретные примеры что C++ хуже чем Rust на примерах что вы сами дали, не оставив С++ ни единого шанса...

думаю сравнивать с Фортраном не имеет смысла?

хотя чего, разнесём и Фортран!

Сообщение от WH if (b/=0) then !Если такие элементы есть, то выведем максимальный из них b = maxval (a, mod(a,k)==0)

это очевидно UB, если кратных элементов нет (b = 0), maxval с маской вернет минимальное значение integer, код на Rust разделят случаи есть элементы или нет

ВНИМАНИЕ!!! ВАРНИНГ!!! АХТУНГ!!! АТТЕНШЕН!!! УВАГА!!! Поведение mod в Fortran для отрицательных чисел зависит от реализации, Rust гарантирует, что a % b имеет знак делителя b

опять знаковая переменная для размера, возможны переполнения

очевидно код не распараллелен, приведённый нами код на C++ и Rust может исполняться параллельно) правда с одним нюансом в случае C++ приёдтся подумать а не будет ли гонка данных, юз афте фри, висячие ссылки, утечки памяти и прочая ерунда, в случае Rust - если скомпилировалось, то не парься

давайте ещё код решения этой задачи на своих любимых языках, расскажу почему Rust лучше)

Добавлено через 1 час 29 минут
p.s. я вообще не говорю что Rust это альфа и омега и остальные языки не нужны, все нужно, я лишь намекаю что если вы поймёте примеры как написать на Rust простые вещи, то вы по другому начнёте писать на своих языках, качественнее и без ошибок, если ты это можешь написать на Rust, то скорее всего ты это корректно напишешь на чём угодно и не встретишь внезапно UB

наверное стоит отослать к этому пример, не сочтите за рекламу, там по фактам

0

Сообщение от abit давайте ещё код решения этой задачи на своих любимых языках, расскажу почему Rust лучше)

А зачем "лучше"? Помню в разговоре о boost понравилась реплика типа

Если все хорошо решается и без этой вещи - значит эта вещь и не нужна

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

Сообщение от abit в случае C++ приёдтся подумать а не будет ли гонка данных, юз афте фри, висячие ссылки, утечки памяти и прочая ерунда

Ну для данной тупой задачи ничего этого нет. А вообще - да, есть такие (перечисленные) минусы, но они никогда не считались/рассматривались как серьезная проблемы. То же и со "сборщиком мусора" которым вечно пытаются тыкать в нос. Тоже мне, шедевр инженерной мысли.

Рассмотреть какую-то др задачу(и), более содержательную? Когда-то пробовал для Haskell, ничего не вышло. Дело упирается "собсно в задачу" (а не в язык). Давайте попробуем зайти с др стороны: организация базовых данных.

Вот данные полигонной 3D модели. Не все, те что есть всегда. Их может быть много (миллионы)

1) Вертексы. Каждый вертекс - это как минимум 3D координата (x, y, z) плюс любое число "атрибутов" (практически всегда нормали, часто UV, иногда цвет и др). Нюансы с атрибутами опускаем

2) Фейсы (они же индексы и.т.п). Малограмотные молодые люди спешат заявить "только треугольники !!", но это не так. Фейс может содержать от 1 до 4 индексов, а также могут поддерживаться "complex polygons" у которых >= 5 индексов, ну это опустим для простоты. Каждый индекс соответствует вертексу в контейнере

На плюсах все хранят это в виде std::vector (ов). Да, это отнюдь не идеальное решение. Удаление и вставка в std::vector работает медленно и делает адреса/итераторы на элементы невалидными, причина массы ошибок/UB. Иногда удается отмазаться типа "эти данные red-only, редактирования нет". Но не всегда

И вот у нас крутой язык. Что он нам здесь дает? Можно ли построить данные лучше/эффективнее?

0

Сообщение от Igor3D И вот у нас крутой язык. Что он нам здесь дает?

а вы не читали, открываем текущие уязвимости UAF, вот это всё найдено за последнее время в проектах типа GLPI, Microsoft Office, Linux kernel, Acrobat Reader, Foxit PDF Reader, Windows, зачастую даёт полный доступ к системе и возможность выполнить любой код - "allows an unauthorized attacker to execute code locally", "This vulnerability allows remote attackers to execute arbitrary code", увлекательно, тысячи багов только за 2 месяца 2025-го, а Rust в принципе не даёт возможности собрать такой код, только если специально стараться


Вообще вы мне пока не дали ни одного кода на любом языке где я бы не нашёл бага, даже на простой задаче, в моём коде Rust вы багов не нашли, подумайте над этим)

0

Сообщение от abit а вы не читали, открываем текущие уязвимости UAF

Не читал, и это не входит в мои планы, нет таких задач/необходимости.

Сообщение от abit Вообще вы мне пока не дали ни одного кода на любом языке где я бы не нашёл бага, даже на простой задаче, в моём коде Rust вы багов не нашли, подумайте над этим)

Лично я никакого кода не давал. А подумал я совсем о другом

Возиться с нашими вертексами/фейсами этот товарищ точно не будет, такая работа не для него. Он увлечен чудесным миром идей/концепций. Имеет право, каждому свое

0

Сообщение от Igor3D Лично я никакого кода не давал. А подумал я совсем о другом

я так и понял что у вас никаких аргументов нет)

0

Сообщение от abit давайте ещё код решения этой задачи на своих любимых языках, расскажу почему Rust лучше)

Запустить можно здесь: https://www.jdoodle.com/execute-jlanguage-online

0

Shamil1,
хорошая попытка, но нет, я, конечно не спец по J, но всё же...

1) динамическая типизация, это всё, сразу крест на нормальном, контролируемом, системном программировании, типизация J может приводить к неявным преобразования, ну например если k дробное, Rust имеет строгую типизацию, настолько строгую что просто так не позволит привести i32 к i64, не то что дробное к целому неявно

2)

Сообщение от Shamil1 (#;>./) ((0= k&|)#[) ,m

эта штука точно может различить между "нет элементов" и "есть элементы"? я попробовал по вашей ссылке, для матрицы без кратных k элементов J вернет __, Rust этим не страдает

3) Ваш код выполняется последовательно, это неэффективно, наши варианты на Rust и C++ лишены этого недостатка, можете сами прогнать матрицы скажем 10000x10000

4) та же проблема с отрицательными числами, что я описывал два раза выше, проверил в онлайн компиляторе по вашей ссылке, поведение для отрицательных чисел отличается
-60 % 7 в Rust = -4 (так как 7 * (-9) = -63, -60 - (-63) = 3

5)

0= k&|

ну деление на ноль, если k=0 )

И это при том что я нифига не знаю ни J ни APL, вот сразу навскидку говорю что такое лучше запускать где-то на виртуальной машине в вакууме и не доверять такому языку ничего дороже 1 доллара и трогать устройство запрограммированное на J я бы не стал и пятиметровой палкой

1

Сообщение от abit динамическая типизация, это всё, сразу крест

Вы описываете проблему слабой типизации, а не динамической. Я тоже не люблю слабую типизацию.

Сообщение от abit эта штука точно может различить между "нет элементов" и "есть элементы"?

Да.

Сообщение от abit Ваш код выполняется последовательно, это неэффективно

Почему Вы так решили? Например, один и тот же С++ код из примера выше выполняется последовательно или параллельно, в зависимости от директив компилятору.
J - это высокоэффективный, производительный язык, предназначенный для работы с огромными объёмами данных.

Сообщение от abit поведение для отрицательных чисел отличается

Если поведение с отрицательными числами в J и Rust отличается, то почему это проблема J, а не Rust?
Существует несколько вариантов деления. Например, в Haskell есть две пары операторов деления: div+mod (к минус бесконечности) и quot+rem (к нулю).

Сообщение от abit ну деление на ноль, если k=0 )

Это не приводит к ошибке (исключению).

Сообщение от abit не доверять такому языку ничего дороже 1 доллара

Это Вы зря. Язык используется для очень серьёзных вещей. Особенно его платная разновидность - K.
Единственно, что в нём дурацкого - это название, чрезвычайно затрудняющее поиск информации.

Сообщение от abit я, конечно не спец по J

Я тоже. Потратил один день на ознакомление специально для сообщения на форуме.

0

Сообщение от Shamil1 J - это высокоэффективный, производительный язык, предназначенный для работы с огромными объёмами дан

можете просто пустить матрицу 10000x10000 через наши блейзинг программы Rust и C++ и через свой "высокоэффективный, производительный язык"
думаю результаты вас удивят
и я это сделал) разница в сотни раз по производительности

Добавлено через 2 минуты

Сообщение от Shamil1 Да.

думаю нет)

Добавлено через 13 минут
на вашем месте я бы поборолся за Haskell, там есть шансы за счёт строгой типизации, J - язык бесполезный

0

Shamil1, а тот же вопрос, с точки зрения Haskell ?
Понимаю что дело может быть "и не в языке", для таких задач все везде примерно одинаково. Данные простые, но их может быть много (миллионы), выдумывать "нечто особенное" нет оснований т.к. нет устойчивого применения. Хотя не все так уж просто, напр есть разные "стратегии" хранения атрибутов. Да, и, надеюсь, крутые языки обеспечивают минимальный расход памяти (как std::vector) ?

0

Сообщение от Igor3D а тот же вопрос, с точки зрения Haskell ?

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

В C++ объявление типа - один файл. В Haskell объявление типа - одна строка. Поэтому в Haskell активно создаются новые типы под конкретную задачу.

0

Сообщение от Shamil1 Я не знаю, что такое вертексы и фейсы, для чего они нужны и как используются. Поэтому не могу сказать, как лучше объявить эти типы.

Помните мультик про деда Мороза

Темнота - лета не знает!

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

0

Сообщение от Igor3D Вы имели ввиду "не знаю и знать не хочу!"

Примерно так. У меня нет времени изучить всё. Приходится расставлять приоритеты.

0

Сообщение от abit ВНИМАНИЕ!!! ВАРНИНГ!!! АХТУНГ!!! АТТЕНШЕН!!! УВАГА!!! Поведение mod в Fortran для отрицательных чисел зависит от реализации, Rust гарантирует, что a % b имеет знак делителя b

Много заглавных букв, конечно. Но вообще в Фортране для этого есть modulo.

2