Автор |
Сообщение |
|
|
Заголовок сообщения: |
Re: ПЕРЛ против ФОРТ |
|
|
В репозитории проекта perlweeklychallenge-clubнаходится и некоторое число решений задач на Форт языке от пользователя paulo-custodio на gForth. P.S. Решения по предлагаемым задачам можно представлять на любых языках в рамках конкурса на площадке https://theweeklychallenge.org/challenges/(каждую неделю 2-e новые задачи для решения)
В репозитории проекта [url=https://github.com/manwar/perlweeklychallenge-club]perlweeklychallenge-club[/url]
находится и некоторое число [url=http://sendfile.su/1661891]решений задач на Форт языке от пользователя paulo-custodio на gForth.[/url]
P.S. Решения по предлагаемым задачам можно представлять на любых языках в рамках конкурса на площадке https://theweeklychallenge.org/challenges/ (каждую неделю 2-e новые задачи для решения)
|
|
|
|
Добавлено: Ср ноя 23, 2022 06:34 |
|
|
|
|
|
Заголовок сообщения: |
Re: ПЕРЛ против ФОРТ |
|
|
Forth в Perl (базис Forth83) P.S. Кстати, наиболее адекватно отработал поисковик DuckDuckGo при поиске тем со словом Perl по форуму
[url=https://github.com/woo37830/perl_forth]Forth в Perl[/url] (базис Forth83)
P.S. Кстати, наиболее адекватно отработал поисковик DuckDuckGo при поиске [url=https://duckduckgo.com/?q=Perl+site:http://fforum.winglion.ru&ia=web]тем со словом Perl по форуму[/url]
|
|
|
|
Добавлено: Ср ноя 09, 2022 04:59 |
|
|
|
|
|
Заголовок сообщения: |
Re: ПЕРЛ против ФОРТ |
|
|
Статья из серии Открывая Форт на Хабре Численный FORTHP.S. Упомянутый в статье F-PC есть и на Github
Статья из серии Открывая Форт на Хабре [url=https://habr.com/ru/post/550508/]Численный FORTH[/url]
P.S. Упомянутый в статье [url=https://github.com/uho/F-PC]F-PC есть и на Github[/url]
|
|
|
|
Добавлено: Сб апр 03, 2021 16:48 |
|
|
|
|
|
Заголовок сообщения: |
Re: ПЕРЛ против ФОРТ |
|
|
На форуме игроделов, в треде одного обсуждения (делегатов в C++ и попутная статья по ним Указатели на функции-члены и реализация самых быстрых делегатов на С++.) gudleifr предложил нижеследующее решение, как можно получить, применительно к Форт, адрес поля имени слова. (рабочее для Win32Forth, код и имена хранятся в разных пространствах и требуется >NAME.) Код: : СИМВОЛ HERE CREATE >NAME , DOES> @ ;
СИМВОЛ One СИМВОЛ Two СИМВОЛ Three Проверка этого кода Online (для gForth) показало, что он для gForth не приводит к решению озвученной задачи. Опытным путём был создан такой код для gForth и проверен по выводимому результату тестового выполнеия. Код: : СИМВОЛ HERE CREATE , DOES> POSTPONE >NAME @ CELL + ;
СИМВОЛ One СИМВОЛ Two СИМВОЛ Three
One DUP 1 CELLS + SWAP C@ TYPE CR Two DUP 1 CELLS + SWAP C@ TYPE CR Three DUP 1 CELLS + SWAP C@ TYPE CR
P.S. Разница в коде, как видно, первого и второго решения существенна в реализации на конкретной Форт системе. Какое решение будет работоспособно, например, в SPF4 не выяснял, но, вероятно, там есть и подходящее слово такой функциональности, впрочем и как наверное для gForth. (слово SEE <words> для просмотра реализации тех или иных слов в gForth в помощь)
На форуме игроделов, в треде одного обсуждения (делегатов в C++ и попутная статья по ним [url=https://www.rsdn.org/article/cpp/fastdelegate.xml]Указатели на функции-члены и реализация самых быстрых делегатов на С++.[/url]) [b]gudleifr [/b] предложил нижеследующее решение, как можно получить, применительно к Форт, адрес поля имени слова. (рабочее для Win32Forth, код и имена хранятся в разных пространствах и требуется >NAME.) [code] : СИМВОЛ HERE CREATE >NAME , DOES> @ ;
СИМВОЛ One СИМВОЛ Two СИМВОЛ Three[/code]
Проверка этого кода Online (для gForth) показало, что он для gForth не приводит к решению озвученной задачи.
Опытным путём был создан такой код для gForth и проверен по выводимому результату тестового выполнеия. [code] : СИМВОЛ HERE CREATE , DOES> POSTPONE >NAME @ CELL + ;
СИМВОЛ One СИМВОЛ Two СИМВОЛ Three
One DUP 1 CELLS + SWAP C@ TYPE CR Two DUP 1 CELLS + SWAP C@ TYPE CR Three DUP 1 CELLS + SWAP C@ TYPE CR [/code]
P.S. Разница в коде, как видно, первого и второго решения существенна в реализации на конкретной Форт системе. Какое решение будет работоспособно, например, в SPF4 не выяснял, но, вероятно, там есть и подходящее слово такой функциональности, впрочем и как наверное для gForth. :) (слово SEE <words> для просмотра реализации тех или иных слов в gForth в помощь)
|
|
|
|
Добавлено: Сб мар 27, 2021 12:31 |
|
|
|
|
|
Заголовок сообщения: |
Re: ПЕРЛ против ФОРТ |
|
|
Современная ситуация вполне располагает к тому, чтобы делать собственные ИТ-проекты. Тут и административный ресурс в виде всяких фондов и программ, и общий настрой, уходящий в сторону "нам бы подстраховаться российским разработчиком".
Современная ситуация вполне располагает к тому, чтобы делать собственные ИТ-проекты. Тут и административный ресурс в виде всяких фондов и программ, и общий настрой, уходящий в сторону "нам бы подстраховаться российским разработчиком".
|
|
|
|
Добавлено: Сб мар 27, 2021 01:00 |
|
|
|
|
|
Заголовок сообщения: |
Re: |
|
|
Wlad писал(а): А сейчас одно из последствий кризиса будет ужесточение торговых войн. И ещё не известно с чем нам придётся столкнуться... Прошло 12 лет (+- 2года) на виток движения по спирали.
[quote="Wlad"]А сейчас одно из последствий кризиса будет ужесточение торговых войн. И ещё не известно с чем нам придётся столкнуться...[/quote] :) Прошло 12 лет (+- 2года) на виток движения по спирали.
|
|
|
|
Добавлено: Чт мар 25, 2021 06:28 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
mOleg писал(а): Хищник писал(а): Класс! Для сравнения можно посмотреть на современные претензии к Форту... Получается, что Форт занимает одновременно много ниш и уровней, при этом целиком не находясь ни в одной(одном) из них
Ну да, как в известной картинке от Броуди...
А может, как-то систематизировать эти уровни наподобие 7-уровневой модели ISO OSI и стандартизировать пограничные интерфейсы?
Именно интерфейсы, а не отдельные слова. Пишите внутри модуля что хотите, но наружу выводите стандартные (а главное, документированные) интерфейсы.
А вообще, полезно взглянуть на опыт сообщества GNU.
[quote="mOleg"][quote="Хищник"]Класс! Для сравнения можно посмотреть на современные претензии к Форту... [/quote] Получается, что Форт занимает одновременно много ниш и уровней, при этом целиком не находясь ни в одной(одном) из них :)[/quote]
Ну да, как в известной картинке от Броуди...
А может, как-то систематизировать эти уровни наподобие 7-уровневой модели ISO OSI и стандартизировать пограничные интерфейсы?
Именно интерфейсы, а не отдельные слова. Пишите внутри модуля что хотите, но наружу выводите стандартные (а главное, документированные) интерфейсы.
А вообще, полезно взглянуть на опыт сообщества GNU.
|
|
|
|
Добавлено: Пн мар 15, 2010 12:48 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Добавлю ссылку по интеграции Форта в Perl PGForth1.3
Добавлю ссылку по интеграции Форта в Perl [url=http://search.cpan.org/dist/PGForth/]PGForth1.3[/url]
|
|
|
|
Добавлено: Чт мар 11, 2010 01:38 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
mOleg писал(а): не так, интерфейс определяется программистом под задачу. (программист может ошибаться при этом)
Ну это да.
[quote="mOleg"]не так, интерфейс определяется программистом под задачу. (программист может ошибаться при этом)[/quote]
Ну это да. :D
|
|
|
|
Добавлено: Ср фев 25, 2009 20:58 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
chess писал(а): Как видно уже при 5-ти параметрах встает вопрос об общем алгоритме и интерфейс для всех решений кроме maj3 один и тот же. ну, строго говоря уже три параметра случай крайний, где спасает двойная арифметика, для большего количества параметров надо либо работать со стеком, как с массивом (что в железных реализациях бывает не часто), либо работать с массивом в памяти, как будет это делать любой другой язык. chess писал(а): вообщем, да, интерфейс определяется задачей, но все-таки не программистом.
не так,
интерфейс определяется программистом под задачу. (программист может ошибаться при этом)
[quote="chess"]Как видно уже при 5-ти параметрах встает вопрос об общем алгоритме и интерфейс для всех решений кроме maj3 один и тот же.[/quote] ну, строго говоря уже три параметра случай крайний, где спасает двойная арифметика, для большего количества параметров надо либо работать со стеком, как с массивом (что в железных реализациях бывает не часто), либо работать с массивом в памяти, как будет это делать любой другой язык.
[quote="chess"] вообщем, да, интерфейс определяется задачей, но все-таки не программистом.[/quote]
не так,
интерфейс определяется программистом под задачу. (программист может ошибаться при этом)
|
|
|
|
Добавлено: Ср фев 25, 2009 20:25 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
mOleg писал(а): Если заранее известно, что количество входных параметров будет меняться, я выберу другой интерфейс - буду передавать не значения на стеке данных, а адрес на массив значений, и так далее.
Бывают задачи, в которых сложность растет комбинаторно от количества параметров(maj именно такой случай).
В основе получения мажоритара комбинаторика, а именно сочетания.
Там нужно произвести сравнения групп параметров и число таких групп это число сочетаний:
n!/((n/2+1)!*(n-n/2-1)!)
3!/2!*1!=3 011 101 110
5!/(3!*2!)=10 00111 01011 01101 01110 10011 10101 10110 11001 11010 11100
7!/(4!*3!)=35 0001111 ... 1111000
9!/(5!*4!)=126
11!/(6!*5!)=462
Как видно уже при 5-ти параметрах встает вопрос об общем алгоритме и интерфейс для всех решений кроме
maj3 один и тот же.
Бывают конечно задачи с линейным ростом сложности - вообщем, да, интерфейс определяется задачей, но все-таки не программистом.
[quote="mOleg"]Если заранее известно, что количество входных параметров будет меняться, я выберу другой интерфейс - буду передавать не значения на стеке данных, а адрес на массив значений, и так далее.[/quote]
Бывают задачи, в которых сложность растет комбинаторно от количества параметров(maj именно такой случай).
В основе получения мажоритара комбинаторика, а именно сочетания.
Там нужно произвести сравнения групп параметров и число таких групп это число сочетаний:
n!/((n/2+1)!*(n-n/2-1)!)
3!/2!*1!=3 011 101 110
5!/(3!*2!)=10 00111 01011 01101 01110 10011 10101 10110 11001 11010 11100
7!/(4!*3!)=35 0001111 ... 1111000
9!/(5!*4!)=126
11!/(6!*5!)=462
Как видно уже при 5-ти параметрах встает вопрос об общем алгоритме и интерфейс для всех решений кроме
maj3 один и тот же.
Бывают конечно задачи с линейным ростом сложности - вообщем, да, интерфейс определяется задачей, но все-таки не программистом.
|
|
|
|
Добавлено: Ср фев 25, 2009 08:59 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Wlad писал(а): Да я лучше общую задачу решу один раз, а решения её частных будут просто достигаться её "настройкой", "параметризацией"
Если б, скажем, IDCT считалось алгоритмом общего вида (умножениями и транспозициями матриц) то цифрового телевидения до сих пор бы не было.
[quote="Wlad"]Да я лучше общую задачу решу один раз, а решения её частных будут просто достигаться её "настройкой", "параметризацией"[/quote]
Если б, скажем, IDCT считалось алгоритмом общего вида (умножениями и транспозициями матриц) то цифрового телевидения до сих пор бы не было.
|
|
|
|
Добавлено: Вт фев 24, 2009 22:59 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Wlad писал(а): Mihail писал(а):И чем можификация частного решения не настройка общего?
Тем, что в этом случае это именно изменение алгоритма, это будет уже ДРУГОЕ решение, а параметризуемый алгоритм уже - ГОТОВОЕ ОБЩЕЕ решение.
но вы ведь прекрасно знаете, что такие общие решения часто избыточны, громоздки, неторопливы и сложны для анализа.
на самом деле такие решения спасают где-нить в matcad-е или еще где нужно быстрое прототипирование, то есть сборка из уже готовых кирпичиков - ничего что оно будет тормозить и много "весить", главное быстро можно прикинуть, что оно такое получается.
[quote="Wlad"]Mihail писал(а):И чем можификация частного решения не настройка общего?
Тем, что в этом случае это именно изменение алгоритма, это будет уже ДРУГОЕ решение, а параметризуемый алгоритм уже - ГОТОВОЕ ОБЩЕЕ решение.[/quote]
но вы ведь прекрасно знаете, что такие общие решения часто избыточны, громоздки, неторопливы и сложны для анализа.
на самом деле такие решения спасают где-нить в matcad-е или еще где нужно быстрое прототипирование, то есть сборка из уже готовых кирпичиков - ничего что оно будет тормозить и много "весить", главное быстро можно прикинуть, что оно такое получается.
|
|
|
|
Добавлено: Вт фев 24, 2009 19:47 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Wlad писал(а): chess писал(а):Попробуйте написать мажоритар хотя бы для пяти параметров на стеке и поймете, что решение для трех параметров уже ни с какого боку полезным не будет. Вот может когда напишете для пяти, то станет понятно как написать мажоритар для 7, 9 и т.д. небольшого количества параметров.
Так вот и я из-за этого как-то умственно плечами пожимал, когда читал высказывания Броуди про преимущество частных решений...
Да я лучше общую задачу решу один раз, а решения её частных будут просто достигаться её "настройкой", "параметризацией", а не переписыванием кода каждый раз заново... Буде общая задача успешно решена у меня будет меньше шансов "зевнуть" при очередном переписывании и перерешении очередной разновидности поставленной задачи. Дело ведь не только в ошибках типа количества параметров на стеке! Всё может быть гораздо серьёзней, когда стековый "приход/расход" в ажуре, а сам вычислительный алгоритм - с ошибкой...
и именно из-за таких в НАСА решили не использовать старый код в проектах (считается что он не менее глючный, чем новый).
Меняются условия - меняются решения. Никто вам не мешает делать более медленные и громоздкие решения на форте, которые будут учитывать изменения количества и качества данных, но так делать не удобно и не принято (не более того).
Вы ведь прекрасно понимаете, что часть кода для, к примеру, 8 разрядного микропроцессора становится просто ненужной при переходе на 16 разрядный.
Вобщем проблема опять же не частная (Форта) а общая для всего программирования: грамотное проектирование интерфейсов!
[quote="Wlad"]chess писал(а):Попробуйте написать мажоритар хотя бы для пяти параметров на стеке и поймете, что решение для трех параметров уже ни с какого боку полезным не будет. Вот может когда напишете для пяти, то станет понятно как написать мажоритар для 7, 9 и т.д. небольшого количества параметров.
Так вот и я из-за этого как-то умственно плечами пожимал, когда читал высказывания Броуди про преимущество частных решений...
Да я лучше общую задачу решу один раз, а решения её частных будут просто достигаться её "настройкой", "параметризацией", а не переписыванием кода каждый раз заново... Буде общая задача успешно решена у меня будет меньше шансов "зевнуть" при очередном переписывании и перерешении очередной разновидности поставленной задачи. Дело ведь не только в ошибках типа количества параметров на стеке! Всё может быть гораздо серьёзней, когда стековый "приход/расход" в ажуре, а сам вычислительный алгоритм - с ошибкой...[/quote]
и именно из-за таких в НАСА решили не использовать старый код в проектах (считается что он не менее глючный, чем новый).
Меняются условия - меняются решения. Никто вам не мешает делать более медленные и громоздкие решения на форте, которые будут учитывать изменения количества и качества данных, но так делать не удобно и не принято (не более того).
Вы ведь прекрасно понимаете, что часть кода для, к примеру, 8 разрядного микропроцессора становится просто ненужной при переходе на 16 разрядный.
Вобщем проблема опять же не частная (Форта) а общая для всего программирования: грамотное проектирование интерфейсов!
|
|
|
|
Добавлено: Вт фев 24, 2009 19:41 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
chess писал(а): mOleg писал(а):а вот что у мя:
Вот это как раз пример частного решения в Форте. Попробуйте написать мажоритар хотя бы для пяти параметров на стеке и поймете, что решение для трех параметров уже ни с какого боку полезным не будет. Вот может когда напишете для пяти, то станет понятно как написать мажоритар для 7, 9 и т.д. небольшого количества параметров. Но когда число параметров перевалит за 11 и этот метод для пяти уже будет частным и неподходящим. Я в этом быстро убедился. Кстати функция мажоритара одна из функций пороговой логики и на практике полезна (например, для защиты от дребезга контактов).
боюсь, что я с вами полностью не согласен.
нужно продумывать интерфейсы, а реализацию не фиксировать. У меня задан интерфейс: три параметра на входе, один на выходе, имя.
Все остальное на мое усмотрение, и как оно будет внутри устроено особой разницы не играет - лишь бы работало. Если вы меняете количество параметров - то вы меняете интерфейс!! А значит меняется много чего на куче уровней, которые затрагивает изменение.
Если заранее известно, что количество входных параметров будет меняться, я выберу другой интерфейс - буду передавать не значения на стеке данных, а адрес на массив значений, и так далее.
[quote="chess"]mOleg писал(а):а вот что у мя:
Вот это как раз пример частного решения в Форте. Попробуйте написать мажоритар хотя бы для пяти параметров на стеке и поймете, что решение для трех параметров уже ни с какого боку полезным не будет. Вот может когда напишете для пяти, то станет понятно как написать мажоритар для 7, 9 и т.д. небольшого количества параметров. Но когда число параметров перевалит за 11 и этот метод для пяти уже будет частным и неподходящим. Я в этом быстро убедился. Кстати функция мажоритара одна из функций пороговой логики и на практике полезна (например, для защиты от дребезга контактов).[/quote]
боюсь, что я с вами полностью не согласен.
нужно продумывать интерфейсы, а реализацию не фиксировать. У меня задан интерфейс: три параметра на входе, один на выходе, имя.
Все остальное на мое усмотрение, и как оно будет внутри устроено особой разницы не играет - лишь бы работало. Если вы меняете количество параметров - то вы меняете интерфейс!! А значит меняется много чего на куче уровней, которые затрагивает изменение.
Если заранее известно, что количество входных параметров будет меняться, я выберу другой интерфейс - буду передавать не значения на стеке данных, а адрес на массив значений, и так далее.
|
|
|
|
Добавлено: Вт фев 24, 2009 19:38 |
|
|
|
|