HLFX.Ru Forum (https://hlfx.ru/forum/index.php)
- Технические вопросы (https://hlfx.ru/forum/forumdisplay.php?forumid=20)
-- спор (https://hlfx.ru/forum/showthread.php?threadid=4164)

спор

поспорили тут с ксвайдером, рассудите, кто дурак, а кто идиот. ниразу не кодер, потому самому интересно. по крайней мере среди тех кто занимается численным моделированием я часто встречал такой подход. например, вот эта http://hif.lbl.gov/theory/WARP_summary.html программа, насколько знаю так реализована.

(10 Nov 2013 23:56:06) timth:
... перевести её на f2py -- так что бы числодробильное ядро было на фортране, а всё управление делалось из питон-скриптов и можно было как угоддно комбинировать модули, без перекомпиляции
(10 Nov 2013 23:56:29) xwider:
можно я после этого тебя пристрелю?
(10 Nov 2013 23:57:04) xwider:
или сразу пиши на вижуал бейсике
(10 Nov 2013 23:57:32) timth:
какой ещё кроме питона скриптовый язык ты прелагаешь?
(10 Nov 2013 23:57:33) xwider:
no u
(10 Nov 2013 23:57:35) timth:
анальную lua?
(10 Nov 2013 23:57:43) timth:
анальный perl?
(10 Nov 2013 23:58:06) xwider:
если тебе не хватает make, shellscript, то...
(10 Nov 2013 23:58:28) timth:
shellscript не умеет напрямую вызывать фортрановые функции
(10 Nov 2013 23:58:35) timth:
да и сишные не умеет
(10 Nov 2013 23:58:42) timth:
он умеет только вызывать саму программу
(10 Nov 2013 23:58:42) xwider:
а ты их сделай экспортными или прост окак опции
(10 Nov 2013 23:58:55) timth:
ну так этих опций становится всё больше и больше
...
(10 Nov 2013 23:59:32) xwider:
если проге требуется какая-то внешняя поебень - адекватность сомнительна
(10 Nov 2013 23:59:52) xwider:
всё управление - в main
(11 Nov 2013 00:00:09) timth:
и main разрастается до неприличных размеров

__________________
http://www.moddb.com/mods/monorail-quest

Я сторонник кроссплатформенного гуи и комбинирования модулей при помощи мыши. А для расширения функционала - анальный lua.
Ненавижу питон. Ненавижу фортран. Вообще, в научной среде как будто мне назло используются в основном те вещи, которые я ненавижу. Но я не теряю надежды и упорно гну свою линию. По мне, так разработка подобного софта - подобна разработке волатил и хаммеров, юзеры хотят кубать с комфортом (чтобы раз-два, кнопочку нажал и готовы материалы для публикации), а наша задача это им обеспечить. И если на анальном луа кубать окажется удобнее, вуаля, мы сломали стереотипы и вошли в историю. А нет - так всегда можно уйти базы данных кодить.

Добавлено 12-11-2013 в 05:37:

thambs
Вообще, в таких спорах победителя определить очень просто.
Побеждает тот, у кого больше публикаций и индекс Хирша.

Добавлено 12-11-2013 в 05:40:

Вот с этим, я считаю, надо бороться, и это вроде как раз то, о чём ты говоришь.
http://pubs.acs.org/doi/abs/10.1021/ci800233y

__________________

XaeroX

спор всё таки именно о подходе: или всё пишем на хардкодим компилируемом языке и делаем тыщу опций, или выносим логику в скрипт. конкретные яп -- дело вкуса. C и F95 одинакого быстро работают, а что lua, что python одинакого тормозят.

Добавлено 12-11-2013 в 02:43:

XaeroX

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

Добавлено 12-11-2013 в 02:45:

XaeroX

не пускает, можешь процитировать?

__________________
http://www.moddb.com/mods/monorail-quest

thambs
Скрипты - это как плагины к редактору, они должны быть приятным и функциональным дополнением, но ядро должно уметь по меньшей мере 90% того, что может тебе понадобиться.
"Тыща опций" - признак плохой архитектуры, когда программа пишется по принципу "добавим это и прикрутим то, и готова новая бубликация". А сделать полноценный рефакторинг, конечно же, денег нет, да и зачем, главное ж отчёты написать, а рецензенты никогда в код не смотрят.
Собсно, потому научный софт и представляет собой помойку из сотен мало похожих инструментов с отсутствием каких-либо стандартов, разобраться в которых, вероятно, не смогут и сами авторы по прошествии десятка лет. Порой даже в рамках одного пакета (привет, AMBER).

Добавлено 12-11-2013 в 05:50:

__________________

>Ну там тулкит на питоновских скриптах как раз.

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

__________________
http://www.moddb.com/mods/monorail-quest

Я не совсем понял, что имел в виду xwider в разговоре. С одной стороны предлагает шелл, а с другой выступает против внешней фигни - как я понял - под этим значится вызов сторонних программ с созданием процесса, что не true-way. А под "сделать экспортными" должно быть имеется в виду экспорт из динамической/разделяемой библиотеки?

Да и в каком контексте этот разговор? Разработка собственной системы мат. моделирования?

>"Тыща опций" - признак плохой архитектуры, когда программа пишется по принципу "добавим это и прикрутим то

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

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

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

а вот в зависимости от задачи их можно по разному комбинировать:

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

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

и вот вроде основа одна, а основной цикл счёта для разного типа задач получается разным.

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

>разработка
ну не разработка, а доведение до состояния, когда от быдлокода у посторонних глаза не вытекают.

__________________
http://www.moddb.com/mods/monorail-quest

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

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

я хвидеру всё расскажу!

thambs
"ниразу не кодер", так и не поднимай флуды на глупые темы

__________________
Минутка полезного:
Бесплатный UT-подобный Half-Life mod.
Бесплатный редактор для 32-битных текстур. Без дотнета.
Бесплатный IDE для любых компиляторов и ЯП.
Бесплатная Windows-подобная ОС.
Проверка грамматики русского языка.
Чат по hl[fx]: [email protected]

__________________

XaeroX
А чёйта в твоём демотиваторе всё больше про функциональщину? =)

nemyax
Ну есть немного, но не большая часть.

__________________

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

Добавлено 13-11-2013 в 03:27:

XaeroX

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

__________________
http://www.moddb.com/mods/monorail-quest

nemyax
Много чем. Компактность, простота, нормальный синтаксис (правда, первое, что я делал - заменил комментарии на С-стайл, так что моя лува не совсем канонiчная), отсутствие маразма с отступами, легкая встраиваемость в любую систему, отсутствие процедуры инсталляции. Лува это именно скриптовый язык для частных целей, а петон - разросшийся монстр, активно лоббируемый "уч0ными", которым проще отгавкаться фразой "ну напиши скрипт", чем оторвать задницу, разморозить мозги и таки сделать свой софт юзабельным.

Но разве я сказал, что петон надо вытеснять лувой? Все эти конструкторы а ля "сделай сам" надо вытеснять продуманными архитектурами на плюсах. А в качестве довеска "для любознательных" (т.е. кому функционала не хватило) лува подходит куда лучше.

__________________

XaeroX

а можешь вот такой же дем про фортран сделать, интересно, что именно в нём не нравится как в узкоспециализированном яп.

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

__________________
http://www.moddb.com/mods/monorail-quest

__________________

>С одной стороны - не язык ассемблера, но с другой - и не язык высокого уровня. Что-то среднее.

ээ, а можно пример. у меня совершенно противоположное впечатление сложилось. ну когда в том же фортране что бы получить, например, целочисленный логарифм по основанию 2 я просто вызываю функцию exponent, а в ц для этого надо вручную выковыривать нужные байты floatного представления (в 11м стандарте вроде уже добавили такую функцию).

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

__________________
http://www.moddb.com/mods/monorail-quest

__________________

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

__________________
http://www.moddb.com/mods/monorail-quest

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

1

Vector a[100];

2

Vector b[100];

3

for ( int i = 0; i < 100; ++i )

4

  for ( int j = 0; j < 3; ++j )

5

    b[ i ][ j ] += a[ i ][ j ];

Vector a[100];

Vector b[100];

for ( int i = 0; i < 100; ++i )

  b[ i ] += a[ i ];

__________________

XaeroX

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

__________________
http://www.moddb.com/mods/monorail-quest

float d = 1.0f;

float w = 2.0f;

printf( "%f", d + w );

1

class distance_t {

2

public:

3

  distance_t( float value ) : data( value ) {}

4

  distance_t operator +( distance_t &other ) { return data + other.data; }

5

private:

6

  float data;

7

};

8

class weight_t {

9

public:

10

  weight_t( float value ) : data( value ) {}

11

  weight_t operator +( weight_t &other ) { return data + other.data; }

12

private:

13

  float data;

14

};

15

16

distance_t d = 1.0f;

17

weight_t w = 2.0f;

18

printf( "%f", d + w );

__________________

nemyax
С хорошим компилятором - одинаково.

__________________

XaeroX

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

__________________
http://www.moddb.com/mods/monorail-quest

thambs
Проще определить новый класс, скажем, area_t или squareDistance_t.
И возвращать его как результат умножения двух distance_t (релизовав так же через оператор).
Да, получается весьма геморно, ну так это потому, что компьютеру ещё со времен фон Неймана глубоко плевать, расстояние у тебя во флоате хранится или площадь.

__________________

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

__________________
http://www.moddb.com/mods/monorail-quest

1

template<typename T,int unused>

2

class valueHolder {

3

public:

4

  valueHolder( T value ) : data( value ) {}

5

  operator T () { return data; }

6

private:

7

  T data;

8

};

9

10

template<typename T>

11

class quadraticValue {

12

public:

13

  quadraticValue( T value ) : data( value ) {}

14

  quadraticValue<T> operator +( quadraticValue<T> &other ) { return data + other.data; }

15

private:

16

  T data;

17

};

18

19

template<typename T>

20

class linearValue {

21

public:

22

  linearValue( T value ) : data( value ) {}

23

  linearValue<T> operator +( linearValue<T> &other ) { return linearValue<T>( data + other.data ); }

24

  quadraticValue<T> operator *( linearValue<T> &other ) { return quadraticValue<T>( data * other.data ); }

25

private:

26

  T data;

27

};

28

29

typedef linearValue<valueHolder<float,1>> distance_t;

30

typedef quadraticValue<valueHolder<float,1>> area_t;

31

32

typedef linearValue<valueHolder<float,2>> weight_t;

33

typedef quadraticValue<valueHolder<float,2>> squaredWeight_t;

34

35

void foo( void )

36

{

37

  // компилится

38

  distance_t d1 = 1.0f;

39

  distance_t d2 = 2.0f;

40

  area_t a = d1 * d2;

41

42

  // компилится

43

  weight_t w1 = 1.0f;

44

  weight_t w2 = 2.0f;

45

  squaredWeight_t sw = w1 * w2;

46

47

  // не компилится

48

  area_t a2 = w1 * w2;

49

  squaredWeight_t a3 = d1 * d2;

50

}

__________________

XaeroX

не получится, ты ж не можешь произвольные сочетания distance^x weight^y time^z делать. о, во -- смотри что нашёл -- вроде в буусте такое есть http://www.boost.org/doc/libs/1_54_...imensionExample

__________________
http://www.moddb.com/mods/monorail-quest

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

__________________

XaeroX

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

__________________
http://www.moddb.com/mods/monorail-quest

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

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

в фортране это красиво сделали:

1

outer: do i=1,100

2

inner: do j=1,1000

3

exit outer

4

enddo inner

5

enddo outer

__________________
http://www.moddb.com/mods/monorail-quest

thambs
То, что ты описал на фортране, как раз и решается с помощью goto.
Есть ещё вариант с sentinel цикла:

1

bool sentinel = true;

2

for ( int i = 0; i < 100 && sentinel; ++i )

3

  for ( int j = 0; j < 1000 && sentinel; ++j ) {

4

    sentinel = false; break;

5

  }

6

}

__________________

Такое есть в JavaScript и, кажется, в джаве, выход по break и continue из вложенных циклов.
Но я боюсь, что со мной будет, если признаюсь в склонности к JavaScript'у

А что в C++ с каррированием и паттерн-матчингом, которые есть в демотиваторе? Тоже на шаблонах?

nemyax
Каррирование на шаблонах, а паттерн-матчинг - ну, в принципе, тоже можно на них, но вроде бы можно и просто с помощью наследования реализовать. Или даже с помощью typeid.

__________________

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

Добавлено 16-11-2013 в 02:34:

__________________

nemyax
Пожалуй, да - только частично-применёнными будут не функции, а функторы (но это без разницы). Только это всё compile-time фичи, компилируется потом всё вместе.

Кстати, нашёл тут в википедии, что луа поддерживает замыкания (синтаксис такой же как у похапе), а вот петон, судя по всему, нет.

__________________