LINUX.ORG.RU

Метапрограммирование - проблемы и пути их решения.

 , ,


12

6

Пичал я тут на днях токенайзел для C++-кода, но всё это меня добило я решил поделится.

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

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

Чтобы не быть голословным пишем что-то типа

constexpr uint64_t f(uint64_t a, uint64_t b) {
  return a + b; 
}
Всё ок, но пишем что-то сложнее, аля:

uint64_t m[] = {0, 1, 2, 3, 4};
constexpr uint64_t f(uint64_t a, uint64_t b) {
  return m[a] + m[b]; 
}

Бида( или это моё неосиляторство плюсов?), дак зачем они запилили эту фичу, если она может лишь галимую примитивщину? Шаблоны ещё ущербней. В чем приемущество? Зачем?

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

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

У меня есть 3 пути: терпеть, пилить свой язык и конпелятор самому( что долго и нудно) и ваш совет.

Ответ на: комментарий от drBatty

ну говорю-же, в float оно неявно и таскается.

мне кажется вы про разные «точности». qnikst скорее про «сопроматовскую» точность: когда заданная точность входных данных уже много больше точности float, а все последующие арифметические операции могут только увеличивать эту точность, или, в лучшем случае, оставлять неизменной.

И таки там, где эта точность нужна «точной» - её считают отдельно, таща через все операции.

Я думаю, какие-нибудь CAD-ы это делают сами, но отдельные либы - хз, не искал.

yyk ★★★★★
()
Ответ на: комментарий от drBatty

Как ты меня одалел, жалкий детсадовец, который несёт какую-то херню.

Если рулетка показала результат 1234 равен чему? 1234 чего? А если между делениями шагающая дистанция и она не постоянна?

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

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

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

1234±½. - это округление, которое к реальной жизни не имеет отношения. Да и 1234 деления всегда будут равны 1234 деления и твой выхлоп вообще не имеет смысла.

superhackkiller1997
() автор топика
Ответ на: комментарий от AIv

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

superhackkiller1997
() автор топика
Ответ на: комментарий от AIv

Я понял - вот так не прокатит?:

inline uint64_t d3_to_i(uint64_t x, uint64_t y, uint64_t z) {
  uint64_t x_i = (x << 20);
  uint64_t y_i = (y << 10);
  return x_i + y_i + z;
}
Вычисляет i по координатам для 1024^3.

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

superhackkiller1997
() автор топика
Ответ на: комментарий от superhackkiller1997

Это то тривиально и неинтересно. Интересно, когда данные лежат по z-кривой (фракталу лебега).

Я не очень понял, что Вам не понятно в описании задачи?

AIv ★★★★★
()
Последнее исправление: AIv (всего исправлений: 1)
Ответ на: комментарий от AIv

Интересно, когда данные лежат по z-кривой (фракталу лебега).

Зачем им лежать по z-кривой?

Я не очень понял, что Вам не понятно в описании задачи?

Какой у вас массив, как вы его обоходите и зачем. ЧТо делаете и т.п.

superhackkiller1997
() автор топика
Ответ на: комментарий от superhackkiller1997

Зачем им лежать по z-кривой?

Локальность данных выше. В трад. варианте (когда все лежит по строкам), соседи слева-справа близки памяти (соседние ячейки), соседи сверху-снизу далеки по памяти. В случае z-кривой для большинства ячеек все по памяти бол-мен близко

Какой у вас массив, как вы его обоходите и зачем. ЧТо делаете и т.п.

Данные лежат по z-кривой. Массив структур обходится по z-кривой же, для каждого элемента берутся ближайшие соседи (слева-справ-сверху-внизу) и на их основе элемент модифицируется. И так много раз.

AIv ★★★★★
()
Ответ на: комментарий от AIv

А вы не дадите ваш простенький код для обхода чего-то и то, что он считает.

superhackkiller1997
() автор топика
Ответ на: комментарий от qnikst

могу ссылку на статью дать, покажешь класс.

могу, но это лениво. Ты наверное и сам понимаешь, что нужно очень хорошо владеть предметом моделирования, что-бы его успешно моделировать. Если просто взять, и переложить формулу на код, то получается фигня, и ты сам это уже понял. Т.е. у тебя есть физическая система, ты строишь её математическую модель, а потом перекладываешь математическую модель на ДРУГУЮ модель. Вот на втором переходе у тебя НЁХ и вылезает.

Фишка этой НЁХ в том, что у неё есть вес. Смотри: если некая величина имеет погрешность ±½, то это ещё НЕ ВСЁ, что мы о ней знаем. Есть ещё и распределение значений. Предположим для простоты, что любые значения НЁХ равновероятны, т.е. вероятность любого столбика внутри НЁХ шириной dx равна dx, к примеру, вероятность попадания значения в левую половину НЁХ равна ½. А вероятность попадания в пятую восьмушку равна ⅛. Такая НЁХ имеет вес равный 1. Это определённый интеграл по функции распределения НЁХ, где пределами является пределы этой НЁХ.

А теперь определим вес НЁХ _суммы_. Диапазон суммы примерно равных величин с одним допуском естественно удваивается, 10..11 + 9..10 == 19..21. Если вес каждой НЁХ равен 1, то вес НЁХ суммы ВНЕЗАПНО равен тоже 1, а не 2, как оно кажется. Распределение является билинейным, вероятность попадания на конец диапазона равен 0, а на середину ½, и линейно сначала увеличивается, потом уменьшается. Площадь этих двух треугольников очевидно равна 1. Однако, интервальная арифметика даёт неправильный ответ 2. Таким образом, аддитивная операция не меняет вес НЁХ (как оно и должно быть), если сложить бесконечное число НЁХ с весом 1, то вес получившейся НЁХ будет тоже один. А распределение этой НЁХ будет нормальным. Интервальная арифметика очевидно выдаёт совершенно нелепый ответ, равный бесконечности. Проблема в том, что интервалы просто складываются, т.е. ошибка (с т.з. интервального исчисления) тупо увеличивается. Но в реальной жизни ошибки могут не только складываться, но и взаимно компенсироваться.

Нам нужна более точная модель НЁХ, не просто её интервал, но и её распределение. Тогда, и только тогда, вычисления будут правильными. Зная физику процесса этого несложно добиться. Не зная физики добиться будет намного сложнее, а код будет выполняться ОЧЕНЬ медленно.

drBatty ★★
()
Ответ на: комментарий от superhackkiller1997

Если рулетка показала результат 1234 равен чему? 1234 чего? А если между делениями шагающая дистанция и она не постоянна?

у рулетки ВНЕЗАПНО тоже есть документация, и в ней всё написано.

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

можно ссылку, где ты такую хрень читаешь?

1234±½. - это округление, которое к реальной жизни не имеет отношения.

ты, как не странно прав: это действительно округление, оно имеет смысл при переходе к математической(или компьютерной) модели.

Да и 1234 деления всегда будут равны 1234 деления и твой выхлоп вообще не имеет смысла.

IRL у нас есть 1234 деления + НЁХ «равная» одному делению. Точнее её вес равен делению шкалы. Ты предлагаешь её отбросить, и я-бы с радостью, но не могу. Приходится считать…

drBatty ★★
()
Ответ на: комментарий от AIv

Данные лежат по z-кривой.

вот тут я соглашусь с superhackkiller1997-ом в том, что тебе следует дать ему образец кода для какой-нить очень простой разностной схемы для че-нить простого, скажем уравнения теплопроводности, и пусть он оптимизирует, а не грузить его z-кривыми и производными

и пусть тогда superhackkiller1997 сам придумывает хитрые укладки или пирамидки минковского

з.ы. а есть ли схемы расположения многомерного массива в памяти, для которых доказаны свойста оптимальности для определенного обхода и какой-либо модели «память+кэш»? (имеется в виду минимальность времени полного обхода по какому-то паттерну, закрыв глаза на то, что можно считать пирамидками)

з.ы.ы. правда опять велик риск, что он скажет «это все не нужно» или вариации, гы-гы

www_linux_org_ru ★★★★★
()
Последнее исправление: www_linux_org_ru (всего исправлений: 2)
Ответ на: комментарий от www_linux_org_ru

вот тут я соглашусь с superhackkiller1997-ом в том, что тебе следует дать ему образец кода для какой-нить очень простой разностной схемы для че-нить простого, скажем уравнения теплопроводности, и пусть он оптимизирует, а не грузить его z-кривыми и производными

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

и пусть тогда superhackkiller1997 сам придумывает хитрые укладки или пирамидки минковского

АГа.

з.ы. а есть ли схемы расположения многомерного массива в памяти, для которых доказаны свойста оптимальности для определенного обхода и какой-либо модели «память+кэш»? (имеется в виду минимальность времени полного обхода по какому-то паттерну, закрыв глаза на то, что можно считать пирамидками)

Последовательная.

Вообще не я не вижу смысла в его z-кривых, ибо при его 1024елементах - это при любом(кроме последней координаты) свиче меняется страничка.

з.ы.ы. правда опять велик риск, что он скажет «это все не нужно» или вариации, гы-гы

Ну да, я скажу что не нужно и запилю так, как нужно.

superhackkiller1997
() автор топика
Ответ на: комментарий от www_linux_org_ru

а есть ли схемы расположения многомерного массива в памяти, для которых доказаны свойста оптимальности для определенного обхода и какой-либо модели «память+кэш»?

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

Я дам ТС-у (тока вот найду) код для i_to_shit и обратно. Весь код... ну он не «простенький» отнюдь, и вообще автоматом сгенерен.

AIv ★★★★★
()
Ответ на: комментарий от drBatty

можно ссылку, где ты такую хрень читаешь?

/dev/head

ты, как не странно прав: это действительно округление, оно имеет смысл при переходе к математической(или компьютерной) модели.

Ну теперь скажи мне, какое отношение оно имеет к реальной жизни?

IRL у нас есть 1234 деления + НЁХ «равная» одному делению. Точнее её вес равен делению шкалы. Ты предлагаешь её отбросить, и я-бы с радостью, но не могу. Приходится считать…

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

Правда для этого надо равномерное равноудалённое распределение делений по рулетке, а если его нет, то своим «бла-бла» ты не посчитаешь точно НИКОГДА.

superhackkiller1997
() автор топика
Ответ на: комментарий от AIv

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

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от AIv

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

А ещё код с твоим z-обходом тоже, что я понял почему ты просто не просвапал елементы.

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

Молодец, ты улучшил подход математиков-мразматиков, которые не ослили устройство х86 памяти, только я пока не понял зачем.

superhackkiller1997
() автор топика
Ответ на: комментарий от www_linux_org_ru

Да, речь идёт и о i_to_shit и о том, для чего этот ай_то_щит юзается.

superhackkiller1997
() автор топика
Ответ на: комментарий от AIv

речь идет о коде вроде такого:

double curr[N][N];
double next[N][N];

for(int i=1; i<N-1; ++i) {
  for(int j=1; j<N-1; ++j) {
    next[i][j]=curr[i][j]
      +(curr[i][j+1]-curr[i][j])*a
      +(curr[i][j-1]-curr[i][j])*a
      +(curr[i+1][j]-curr[i][j])*a
      +(curr[i-1][j]-curr[i][j])*a ;
    }
  // ну и на краях добавить
}
// и еще на краях


for(int i=0; i<N; ++i) {
  for(int j=0; j<N; ++j) {
    curr[i][j]=next[i][j];
  }
}
www_linux_org_ru ★★★★★
()
Последнее исправление: www_linux_org_ru (всего исправлений: 2)
Ответ на: комментарий от superhackkiller1997

можно ссылку, где ты такую хрень читаешь?

/dev/head

т.е. ты сам автор этого бреда?

ты, как не странно прав: это действительно округление, оно имеет смысл при переходе к математической(или компьютерной) модели.

Ну теперь скажи мне, какое отношение оно имеет к реальной жизни?

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

IRL у нас есть 1234 деления + НЁХ «равная» одному делению. Точнее её вес равен делению шкалы. Ты предлагаешь её отбросить, и я-бы с радостью, но не могу. Приходится считать…

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

если что-то умножить(сложить, поделить, и т.д.) на НЁХ, то получается НЁХ. Результат может быть и идеальный, но совершенно бесполезный на практике. Давай другие предложения.

Пока я получаю 1234 попугая, и при этом учитываю, что _твой_ попугай несколько отличается от _моего_. Потому, когда ты сложишь 1234 своих попугаев, то получишь несколько другой результат. Я предлагаю это различие УЧИТЫВАТЬ.

Правда для этого надо равномерное равноудалённое распределение делений по рулетке, а если его нет

его нет конечно. ВСЕ мои 1234 попугая разные, и я это учитываю. И твои 1234 попугая тоже разные, мало того, что разные по сравнению друг с другом, дык они ещё и отличаются от моих. И я предлагаю это учитывать.

Да, мой результат получается несколько странным, т.е. я получаю «от пяти до шести с вероятностью 95%», но как не странно, на практике этого хватает. Если конечно я смогу ТОЧНО определить не только границы, но и вероятность того, что результат лежит в этих границах.

drBatty ★★
()
Ответ на: комментарий от AIv

Если просто обход без соседей, то любое расположение, надо просто идти вдоль. Если с обращением к соседями - то z-кривая.

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

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от superhackkiller1997

Это фейспалм, мне даже лень придумывать зачем это может понадобится. Ужасы, кишки, etc.

перевожу на русский: «я понял, что у меня не получится это оптимизировать, и заранее начинаю придумывать отмазки»

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

оптимизирующий компилятор обладает таким абстрактным мышлением

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

вот, например, что оптимизирующий компилятор, что РНР кодер не скажут автору этого кода, например, «а тут надо брать N не степень двойки, а чуть-чуть меньше, и чуть-чуть перерасходовать память — если это не противоречит другим твоим замыслам»; если ты этого не скажешь, то можно обойтись РНР кодером

www_linux_org_ru ★★★★★
()
Последнее исправление: www_linux_org_ru (всего исправлений: 2)
Ответ на: комментарий от www_linux_org_ru

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

Это не очевидно даже при обычном послойном счете, а уж при LRnLA счете это заведомо не так.

Идея насчет референсного кода хороша, я сам хочу такой, и именно для теплопроводности (как для самой простой задачи). Но есть много нюансов - например при работе в один поток подсистема памяти будет заведомо успевать. А вот при работе в много потоков + SSE, для задач размером порядка РАМ точно успевать не будет. КРоме того, есть разница между 2D и 3D.

Вот ф-я «раздвигающая» биты:

	template<int D> inline long interleav_bits( int rank, int pos ){ long s = 0; for( int r = 0; r<rank; r++ ) s |= ( pos&(1<<r) )<<( D*r ); return s; }
	template<> inline long interleav_bits<1>( int rank, int pos ){ return pos; }
	template<> inline long interleav_bits<2>( int rank, int pos ){
		long x = pos;
		x = (x | (x << 16)) & 0x0000FFFF0000FFFF;
		x = (x | (x <<  8)) & 0x00FF00FF00FF00FF;
		x = (x | (x <<  4)) & 0x0F0F0F0F0F0F0F0F;
		x = (x | (x <<  2)) & 0x3333333333333333;
		x = (x | (x <<  1)) & 0x5555555555555555;
		return x;
	}
	template<> inline long interleav_bits<3>( int rank, int pos ){
		long x = pos;
		x = (x | (x << 16)) & 0x030000FF;
		x = (x | (x <<  8)) & 0x0300F00F;
		x = (x | (x <<  4)) & 0x030C30C3;
		x = (x | (x <<  2)) & 0x09249249;
		return x;
	}
D - размерность задачи, pos - что с-но раздвигаем. Дальше все просто, раздвигаем каждую из координат, и сливаем вместе через | с соотв. сдвигом - получаем смещение.

AIv ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

Я постараюсь за сутки-двое накропать «про многомерные массивы», там все будет разжевано.

AIv ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

перевожу на русский: «я понял, что у меня не получится это оптимизировать, и заранее начинаю придумывать отмазки»

Зачем мне оптимизировать изначально тупиковую идею? Я не трачу своё время на бесполезности.

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

Это очередная бредня, ибо что ты можешь оптимизировать?

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

Теперь у нас стоит вопрос, аля «зачем на зобход?».

оптимизирующий компилятор обладает таким абстрактным мышлением

Не обладает. Оптимизирующий компилятор лишь уберает лишнии сущности не более и кодазамена по паттернам.

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

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

вот, например, что оптимизирующий компилятор, что РНР кодер не скажут автору этого кода, например, «а тут надо брать N не степень двойки, а чуть-чуть меньше, и чуть-чуть перерасходовать память — если это не противоречит другим твоим замыслам»; если ты этого не скажешь, то можно обойтись РНР кодером

Что ты этим хотел сказать - я не понял.

superhackkiller1997
() автор топика
Ответ на: комментарий от AIv

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

да-да, я это понял, и у меня есть предложение: код должен запускаться как минимум на 4 ядрах, чтобы память тормозила, ну и без sse видимо не обойтись

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от AIv

Я постараюсь за сутки-двое накропать «про многомерные массивы», там все будет разжевано.

ну я-то (вроде) понял в чем дело

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

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

Давайте степ-бай-степ, начнем с одного ядра;-)

Вообще будет интересно. Мыло aivanov(злая собака)keldysh(жирная точка)ru. Щас тока цейтнот небольшой...

AIv ★★★★★
()
Ответ на: комментарий от superhackkiller1997

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

ты, главное, не пропадай с лора — тут клоунов не хватает :-)

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от AIv

Вообще будет интересно. Мыло aivanov(злая собака)keldysh(жирная точка)ru. Щас тока цейтнот небольшой...

аудитория вдохновляет, а заодно этот чувак веселит изрядно, так что предлагаю продолжить общение здесь, *без спешки*

Давайте степ-бай-степ, начнем с одного ядра;-)

я предлагаю, как временный костыль, одноядерный бенч гонять параллельно на нескольких ядрах, чтобы просадить memory bw

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

Надо давать не только код, а и описание того, что ты этим кодом делаешь, аля я считаю вот это для того-то из вот этого в этом и почему ты именно из «вот этого» считаешь, а так же почему именно «вот в этом» ты считаешь.

superhackkiller1997
() автор топика
Ответ на: комментарий от AIv

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

Причем описание не уровня вашей задачки деффузии, а именно то, что вы конкретно решаете этой задачкой.

superhackkiller1997
() автор топика
Ответ на: комментарий от superhackkiller1997

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

Где и как применяются эти подходы написано например по той ссылке на LOR-wiki. Ну или вот http://cfmaxwell.com/j/ - очень актуальная задача, с теорией и проч., и можно даже боевой код скачать и посмотреть.

AIv ★★★★★
()
Ответ на: комментарий от AIv

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

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

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

superhackkiller1997
() автор топика
Ответ на: комментарий от www_linux_org_ru

аудитория вдохновляет, а заодно этот чувак веселит изрядно, так что предлагаю продолжить общение здесь, *без спешки*

плюсую, вас очень интересно читать

Stil ★★★★★
()
Ответ на: комментарий от AIv

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

Вот смотрите. Вы решаете задачку диффузии, но вы НЕ РЕШАЕТЕ ЗАДАЧУ ДИФФУЗИИ. Вы реализуете реализуцию стандартных( либо выших уникальный) методов решения ДФУ( в данном случае).

Мой вопрос: Зачем? Зачем брать абстрактную задачу - возьми реальный расчёт той же диффузии для чего-то( вы можете придумать это) и уже этот конкретный расчёт мы будем реализовывать.

Объясню на примере конктекста - парсинг кода исходного. Мы можем взять абстрактный код и мы получим очередной flex, только сложнее. Нам надо будет учитывать тысячи хрений, который не нужны в 95% ЯП, но мы ОБЯЗАНЫ их учитывать.

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

Я считаю 1-й подход бессмысленный, а 2-й подход вменяемым.

Где и как применяются эти подходы написано например по той ссылке на LOR-wiki. Ну или вот http://cfmaxwell.com/j/ - очень актуальная задача, с теорией и проч., и можно даже боевой код скачать и посмотреть.

Спасибо.

superhackkiller1997
() автор топика
Ответ на: комментарий от superhackkiller1997

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

AIv ★★★★★
()
Ответ на: комментарий от AIv

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

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

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

Бить чучело - это совсем не то, на битье чучел учаться писать код, не более.

superhackkiller1997
() автор топика
Ответ на: комментарий от superhackkiller1997

возьмите деффузию не как дфу, а как расчёт для чего-то реального

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

AIv ★★★★★
()
Ответ на: комментарий от AIv

Нет, нет. Я уже отбил своё на маникене и примерно представляю как работает машина, остальные же аспекты её работы зависимы от контекста юза.

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

Вы будите знать сколько у вас данных.

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

Вы будите точно знать какое соотношение вычислений и месения памяти вам нужно. При 100арифм. операциях на 1 обращение к памяти один подход, к 2операциями на 1обращение к памяти совершенно другой.

Как вы будите знать какой подход лучше? Суть не в определение идеального подхода для ВСЕХ задач, а определение идеального подхода к конкретной задаче.

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

И мы вернулись к тому, с чего мы начали наши дискусси - нереально определить предел того, что ты можешь выжать из машины без учёта ВСЕХ АСПЕКТОВ твоей реализации. На уровне детсада да, ты посчитать можешь, но шанс фейла и погрешность у тебя такая, что быть уверенным в этих подсчётах глупо.

superhackkiller1997
() автор топика
Ответ на: комментарий от superhackkiller1997

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

Бить чучело - это совсем не то, на битье чучел учаться писать код, не более.

Я не выдержал. Я просто обязан выразить тебе своё восхищение. Чувак, ты гениален! Я такого давно не видел.

schizoid ★★★
()
Ответ на: комментарий от superhackkiller1997

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

AIv ★★★★★
()
Ответ на: комментарий от superhackkiller1997

Автор того боевого кода не я а наш недавно защитившийся аспирант. Хочу отметить, что у нас тут вообще нету проф. программистов.

На сегодняшний день это самый быстрый в мире код для моделирования у-й Максвелла.

AIv ★★★★★
()
Ответ на: комментарий от AIv

Т.е. этот аспирант понтовый? Ну это вызов, не менее. Вот мы и нашли объект для батла.

Как жешь я люблю такое, «мы не профф программисты», но поспорить со мною мы любим. Доказывать мне что-то об уровне программистов мы любим, а вот «мы не профф программисты».

Передайте аспиранту, что сорцы линукса не для прикладухи, без ядерных експортов.

superhackkiller1997
() автор топика
Ответ на: комментарий от superhackkiller1997

Я ему ничего передавать не буду, и никакого батла не будет. Мы то не «проф. программисты», но Вы то пока вообще никак не показали что хоть какой то программист. А в данной области я крайне сомневаюсь, что Вы сможете предложить что то разумное - это ИМНО невозможно без хоть какого то минимального знания теории.

AIv ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.