Rust 1.34

Я лично не люблю C-шные массивы. Плюс тут хотелось показать инициализацию std::vector сразу при создании. Плюс в лямбду можно спрятать проверку индексов. Плюс не нужно вручную delete[] вызывать.

нет уверенности, что промежуточные результаты не окажутся бесконечными величинами

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

там где очень важны точность связанная с порядком операций

Если я правильно понимаю, такое возможно в случае если в выражении переменная используется несколько раз и хотя бы один из них меняет содержимое переменной, т.е пресловутый i = ++i + ++i а это UB. Или я что-то не понимаю?

правилами округления и вообще строгое соответствие IEEE754

Числа с плавающей точкой это в любом случае аппроксимация и завязываться на точность в общем случае, это, наверное, чревато печальными последствиями.

Нет.

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

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

А насчёт округления - в куче задач на него действительно забивают на фоне других допущений.

хотелось показать инициализацию std::vector сразу при создании

new double[Mi][Mj](). Правда, тут всегда дефолтным значением.

Плюс не нужно вручную delete[] вызывать.

auto array = std::unique_ptr<double[][Mj]>(new double[Mi][Mj]);
array[i][j] = x;

Имхо, с вектором все равно удобнее и надежнее.

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

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

Пусть так, но я не понимаю, что изменится с ffast-math если эта бесконечность-таки выскачет?

Даже если переменная не меняется, то погрешность может накапливаться просто от перестановки нескольких множителей в выражении

Да, про погрешность не подумал. Теперь понятно.

что изменится с ffast-math если эта бесконечность-таки выскачет

Он это не отловит (дополнительная проверка отключена на inf и NaN) и может это место проскочить, вместо того, чтобы сообщить об ошибке, особенно, если такие ситуации обрабатываются прямо в коде - он их неправильно обработает.

массив в этом случае гарантировано непрерывен в памяти?

Конечно.

Эх, вот так всегда - возьмёшь самый простой способ использования двумерного массива, а он уже слишком старый и «простой». Но надо на заметку всё взять надо.

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

Простой, в том смысле, что он всем известен, самый дубовый и наиболее часто встречающийся в чужом старом коде.

Так как до сих пор никто не предоставил proof of concept fast-math для rust. Собирать с nightly (cargo +nightly build --release), т.к. интринсики f{add,sub,mul,div}_fast не стабилизированы.

В Cargo.toml после [dependencies] добавить. Этот репозиторий — форк fast-floats (обёртка над интринсиками) с фиксами и доп. функционалом.

fast-floats = { git = "https://github.com/AugmentedFifth/fast-floats.git" }

#![feature(core_intrinsics)]

extern crate fast_floats;

use fast_floats::Fast;

fn main() {
    const XSIZE: usize = 501;
    const YSIZE: usize = 251;
    const WEST: f64 = 0.0;
    const NORTH: f64 = 0.0;
    const SOUTH: f64 = 400.0;
    const EAST: f64 = 400.0;
    const X0: f64 = 2.0;
    const Y0: f64 = 1.0;
    const DX: f64 = X0 / (XSIZE - 1) as f64;
    const DY: f64 = Y0 / (YSIZE - 1) as f64;
    const DX2: f64 = DX * DX;
    const DY2: f64 = DY * DY;
    const OSTT: f64 = 2.0 / DX2 + 2.0 / DY2;
    const RELAX: f64 = 1.9;
    const EPS: f64 = 0.000001;

    println!("# Solving numerical Laplace equation. Please wait ...");

    let mut matrix = vec![[0.0; YSIZE]; XSIZE];

    for x in 0..XSIZE {
        matrix[x][0] = NORTH;
        matrix[x][YSIZE - 1] = SOUTH;
    }

    for y in 0..YSIZE {
        matrix[0][y] = WEST;
        matrix[XSIZE - 1][y] = EAST;
    }

    let mut i = 2;
    loop {
        let mut delta = Fast(0.0);

        for x in 1..XSIZE - 1 {
            for y in 1..YSIZE - 1 {
                let left = Fast(matrix[x - 1][y]);
                let right = Fast(matrix[x + 1][y]);
                let old = Fast(matrix[x][y]);
                let top = Fast(matrix[x][y - 1]);
                let bottom = Fast(matrix[x][y + 1]);

                let fad = |a, b, c| (a + b) / c;
                let tzv = fad(fad(left, right, DX2), fad(top, bottom, DY2), OSTT);
                let new = tzv * RELAX + Fast(1.0 - RELAX) * old;
                delta += (old - new).abs();
                matrix[x][y] = new.get();
            }
        }

        delta /= (XSIZE * YSIZE) as f64;

        if i % 200 == 0 {
            println!("iterat = {}  oxt = {}", i, delta.get());
        }

        if delta.get() <= EPS {
            println!("it_fin = {}", i);
            break;
        }

        i += 1;
    }
}

vec![[0.0; YSIZE]; XSIZE];

А так можно было? Я думал статический слайсы нельзя копировать.

Массивы Copy типов можно копировать с Rust 1.0, но vec! хочет Clone. Клонировать массивы любого размера можно начиная с Rust 1.23.

Разобрался. Оно работает из-за const. Если подсунуть переменную - то будет ошибка. А именно это я и пытался делать когда-то.

Я и сам удивлён, почему, когда начинаешь искать как реализовать двумерный массив в Си++ чаще всего встречается способ создания массива указателей на массив указателей, где два раза вызывается new, а в конце два раза delete. В случае многомерных массивов количество вложенных new/delete соответствующим образом возрастает. А перечисленные вами с eao917 способы действительно удобнее, но почему в учебных материалах на подобный метод не ссылаются - для меня загадка.

Потому, что этот способ менее универсален. В том смысле, что иногда хочется иметь разный размер «строк»

На счет двумерных массивов аноним уже посказал общий случай. Как вариант этого случая — симметричность или ленточность матрицы. Кстати, показанное мной выше решение с matrix_accessor и row_accessor было в свое время сделано как раз для случая симметрической и полуленточной матрицы.

Раст никогда и не претендовал на нишу числодробилки. Что, кто-то всерьез думал иначе?

Borrow-checker в этой области ну вот просто нахрен не нужен*. Весь горячий код принципиально unsafe. Если мне кто-нибудь предъявит неигрушечную числодробилку на safe Rust, то я заранее (вслепую) гарантирую, что её можно ускорить кратно, а возможно и на порядок. Просто потому что знаю специфику HPC.

А вот что для числодробилок реально нужно, так это поддержка различных ускорителей, работа на кластерах. Всего этого в Rust нет и не будет ещё очень долго

*BTW, многие фишки современного C++, там тоже не нужны, а зачастую даже вредны.

Раст никогда и не претендовал на нишу числодробилки. Что, кто-то всерьез думал иначе?

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

Ниши у раста никакой нет. Вообще. Это говно, где страдать нужно в 10раз больше, чем в С++ и получать меньше. А если можно получать меньше, то можно взять какой-нибудь C# и не страдать.

У него бы была ниша, если бы он был хотя-бы так же удобен как С++ и более безопасен(менее фичастный). Что-то уровня go в сравнении с сишкой.

*BTW, многие фишки современного C++, там тоже не нужны, а зачастую даже вредны.

Да ты ахренеть какой эксперт. Именно фишки 17+ там именно и нужны.

unsafe нужно везде и всюду, где нужна работа с памятью

Кулстори бро

У него бы была ниша, если бы он был хотя-бы так же удобен как С++ и более безопасен.

Чего ещё интересного расскажешь?

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

Либо ты слишком жирно троллишь, либо и правду несёшь полную ахинею

Типичное для сектантов поведение. Сказать ничего не может, но хочет. Зачем загаживаешь эфир, если балабол?

Это старый и больной человек, не спорь с ним, серьезно, ты ему ничего не докажешь у него пять психических заболеваний! Бесполезно ему что то говорить.

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

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

Ты бы хоть попытался что-то ответить, было бы менее жалко.

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

О боже. Прибежал, ответил мне - его послал пояснять за балабольство - он обосрался. И теперь с таким же мамкиным гением решил поиграть в игнор. Какой смысл? Зачем ты вообще начал эти жалкие потуги?

Ну давай попытаюсь.

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

Пока у меня всё.

Жалкие потуги тут только у тебя, когда ты пришёл в тред к растоманам и начал им тут что то доказывать

Ты попалися в ловушку царя, жди снятия скора!

Снятия в смысле банка?

То что ты считаешь инклюды лучше модулей это явно значит

Модули будут в C++ будут уже скоро, в следующем году вроде бы.

у тебя загрязняется нэймспейс

namespace же есть

нет такой чёткой иерархии

Вложенные namespace!

Инклюды были придуманы в далёкие времена, когда мощностей у компьютеров было немного

Нет.

статический анализатор

У С++ они круче.

Ну насчёт модулей в 20 я согласен, но царь говорил именно про инклюды

Препроцессор же не ограничивает тебя никак, по моему годно.

Ну про загрязние неймспейса я подразумевал именно C

Для этого есть префиксы. SDL_, gtk_, итд.

То что ты считаешь инклюды лучше модулей это явно значит

Ну ты даже почитал мои тексты - молодец.

что ты тот ещё старпер

Ты всё перепутал. Инклюды это и есть модули, это и есть самые лучше модули.

ведь с инклюдами у тебя загрязняется нэймспейс (привет C) и у тебя нет такой чёткой иерархии (C++).

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

Инклюды были придуманы в далёкие времена

О боже, ты явно нихрена не знаешь. Инклюды не были никогда придуманы - была придумана раздельная компиляция.

когда мощностей у компьютеров было немного

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

поэтому такой необходимости сегодня нет.

Какой такой? Что ты несёшь? Я понимаю, что твой потолок - ретранслировать все агитки, но всё же. Ты хоть пытайся как-то что-то обосновывать.

Во-вторых, у раста изкаропки уже есть хорошая система сборки

Сообщаю тебе новость - инклюдам не нужна система сборки. Система сборки нужна раздельной компиляции. Ты опять обосрался.

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

в которой программисту нужно заполнить зависимости

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

К тому же - ты и тут обосрался. Берёшь любую систему сборки крестов и юзаешь. Любой ПМ берёшь и юзаешь.

статический анализатор, который даёт некоторые гарантии.

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

Про гарантии в школе расскажешь. А меня как-то мало интересует эти потуги из помойки. 10лет прошло, а твои собраться не имеют ни одного адекватного проекта написанного на этом говне.

Я никуда не пришел. И я могу приходить и множить на ноль это говно когда хочет. А про С++ начали кукарекать твои собратья, а не я.

ТЫ вот мне объясни - почему подобные тебе сектанты врут в каждой своей потуге? Ты вообще можешь хоть раз что-то сообирать мне и не обосраться?

Давай я тебе даже объясню. Инклюды для сборки сишного кода вообще ненужны. Инклюды были добавлены после для удобного определения эспортов.

До этого сишка была именно с твоими «модулями», где ты «импортировал» каждую херню.

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

Хотя ты уже обосрался с импортами, т.к. уже давно появилось «импортировать всё» т.е. с контролем ты уже обосрался. Без этого - ты бы по 10страниц импорты писал.

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

Именно поэтому ide для той же жабки и прочих «супер-языков» эмулируют инклюды. Т.е. они импортируют в твоей неймспейс локальный вообще все эспорты, добавляют тебе переходы в исходники и прочее.

Но в ситуации с инклюдами ничего костылять нунжно. Всё уже работает, лучше и удобней.

Тоже самое и с неймпейсами. Неймспейсы куда более удобны, нежели всё это говно убогое. Т.к. вместе с неймспейсом импортируется всё. А благодаря этому работает асист и вся фигня.

Так же неймспейсы куда более удобные, нежели модули/эспорты и весь этот синтаксический мусор.

Так же. Для решения проблем с раздельной компиляцией были созданы тысячи костылей. Эти костыля раст украл у С++. Это вор убогий. Дак вот, эти ворованные костыли(lto) и нужны для того, чтобы превращать объектники в инклюды. Инклюдам же ненужны эти костыли.

К тому же, как-то ты быстро поплыл в сторону дефолтной методички с модулями. Работа с модулями/инклюдами - это копейки, которые ни на что не влияют. Любой программист 99% времени работает с кодом, а не с пишет импорты.

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

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

Так же, тебе нужно понимать, что инклюды инклюдам рознь. 95% С++-адептов используют не инклюда, а раздельную компиляцию. Я же под инклюдами имею ввиду отсутствие .cpp-файлов вообще, если по-простому. Адепты просто хотят привычного дерьма и ничего не знают.

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

Ведь макросы там торчат не просто так. И единственный пусть избавиться от макросов - это выкинуть препроцессор, но тогда в язык нужно добавлять функционал-заменитель. Это, кстати, проблема С++. Хотя в раст-убожестве возможностей уровня сишных макросов то никогда не будет.

В инклюды это крутая вещь, но реализация у неё говно.

Нужно добавить пару фич. Во-первых сделать каждый инклюд отдельным контекстом. Хотя на уровне неймспейсов - что-бы анонимные неймспейсы не эспортировались.

Убрать препроцессор, но это уже не особо к инклюдам относится. Скорее это общая проблема.

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

Хотя в раст-убожестве возможностей уровня сишных макросов то никогда не будет.

https://github.com/serde-rs/json пусь сишные макросы так научатся для начала!

https://github.com/serde-rs/json пусь сишные макросы так научатся для начала!

В чём там учится? Это примитивное говно уровня начальной школы. Ты мне типы научись из строки генерировать, а не убогую динамическую дристню из строки.