Forth и другие саморасширяющиеся системы программирования Locations of visitors to this page
Текущее время: Пт мар 29, 2024 00:20

...
Google Search
Forth-FAQ Spy Grafic

Часовой пояс: UTC + 3 часа [ Летнее время ]




Ответить
Имя пользователя:
Заголовок:
Текст сообщения:
Введите текст вашего сообщения. Длина сообщения в символах не более: 60000

Размер шрифта:
Цвет шрифта
Настройки:
BBCode ВКЛЮЧЕН
[img] ВЫКЛЮЧЕН
[flash] ВЫКЛЮЧЕН
[url] ВКЛЮЧЕН
Смайлики ВЫКЛЮЧЕНЫ
Отключить в этом сообщении BBCode
Не преобразовывать адреса URL в ссылки
Вопрос
Теперь гостю придется вводить здесь пароль. Не от своей учетной записи, а ПАРОЛЬ ДЛЯ ГОСТЯ, получить который можно после регистрации на форуме через ЛС.:
Этот вопрос предназначен для выявления и предотвращения автоматических регистраций.
   

Обзор темы - FALSE раньше и теперь
Автор Сообщение
  Заголовок сообщения:  Re: FALSE раньше и теперь  Ответить с цитатой
Ethereal писал(а):
В любом случае это проблемы самодисциплины программиста.
Ну, FORTH и самодисциплина программиста - это две несовместимые вещи. Ведь FORTH позволяет писать ровно то, что думаешь, не добавляя обязательную обфускацию. Если Вам нравится изобретать свои красивые и правильные "надграмматики" - есть компилируемые языки.

Но, к счастью, Ваш вывод можно перефразировать - не мучьтесь стандартами, просто запомните, как сделано у вас.
Сообщение Добавлено: Сб янв 21, 2017 11:11
  Заголовок сообщения:  Re: FALSE раньше и теперь  Ответить с цитатой
gudleifr писал(а):
[Проблема FORTH-TRUE в данном случае двояка:

Он позволяет
...
Можно все, но стоит ли это делать?
"Позволяет, но стоит ли ..." В такой формулировке это не проблемы языка, а проблемы самодисциплины программиста. Думаешь, что не стоит - не делай, но саму возможность оставь.
gudleifr писал(а):
Но иногда - нет (как в приведенном выше логическом выражении, где хотя бы одно из A или B требуется "нормировать").
Или пиши программу
- не используя других логических значений кроме 0/-1. Проблема самодисциплины.
- или так, чтобы возвращаемое кривое логическое значение всегда с другими совокуплялось осмысленно. Опять проблема самодисциплины.
- или введи новый "нормирующий" AND
: AND! 0= 0= AND ;
и пиши вообще как хош.
В любом случае это проблемы самодисциплины программиста.
Сообщение Добавлено: Сб янв 21, 2017 00:42
  Заголовок сообщения:  Re: FALSE раньше и теперь  Ответить с цитатой
Ethereal писал(а):
И в чем-же состоит "проблема TRUE" ? Сформулируй.
Существуют выражения/операторы трех типов:
1. Возвращающие что-то, что можно интерпретировать как логическое значение.
2. Интерпретирующие что-то, полученное на вход, как логическое значение.
3. Организующие логические вычисления на основе логических значений.

Для первых в большинстве случаев, действительно, удобно TRUE=-1.
Для вторых - TRUE<>0.
Для третьих универсального решения нет, поэтому используется два набора операций - логические и поразрядные. (В shell-ах есть и более интересные варианты).

Проблема FORTH-TRUE в данном случае двояка:

Он позволяет использовать частные слова и слова для неполных выражений. Например, в приведенном случае удобно было бы слово 9< , возвращающая 7. Или, в случае, например, конечных автоматов - адреса точек "успех"/"неуспех". Можно все, но стоит ли это делать?

В FORTH принята только поразрядная логика. Поэтому при работе с логическими выражениями приходится упаковывать логические переменные в шкалы. Иногда, это удобно (например, я как-то рассматривал задачу "переправа через реку"). Но иногда - нет (как в приведенном выше логическом выражении, где хотя бы одно из A или B требуется "нормировать").
Сообщение Добавлено: Пт янв 20, 2017 20:48
  Заголовок сообщения:  Re: FALSE раньше и теперь  Ответить с цитатой
Отличие ... очень неудобно. Я понимаю, когда неудобна одна из двух альтернатив, но что есть неудобность наличия самой альтернативы ? Построенная тобой фраза никак на голову не налезает.

И в чем-же состоит "проблема TRUE" ? Сформулируй.
gudleifr писал(а):
Ethereal писал(а):
Впрочем, FORTH - это средство эффективной разработки. а не написания эффективного кода.
Хорошо бы если бы и того и другого. Разумеется, по возможности. Если не получается в лоб, то почему бы не с помощью трюков ? TRUE=-1 позволяет писать код в котором слово возвращает несколько булевский значений сразу и в упакованном виде. Для трюков вполне.
Сообщение Добавлено: Пт янв 20, 2017 19:30
  Заголовок сообщения:  Re: FALSE раньше и теперь  Ответить с цитатой
Ethereal писал(а):
какой код эффективнее ?
Примерно одинаково неэффективно. Тем более, придется все равно проверять на попадание в допустимый диапазон. Эффективную реализацию см. в FOBOS. Впрочем, FORTH - это средство эффективной разработки. а не написания эффективного кода.

Ethereal писал(а):
И параллельные логические вычисления - это благо
Не всегда. Например, иногда отличие

A B AND IF C THEN

от

A IF B IF C THEN THEN

очень неудобно.

Но, повторю, то что конкретные значения возвращаемые/получаемыми конкретными словами нам (не)удобны, не имеет никакого отношения к "проблеме TRUE".
Сообщение Добавлено: Пн янв 16, 2017 15:37
  Заголовок сообщения:  Re: FALSE раньше и теперь  Ответить с цитатой
CHAR] 0 - DUP 9 > 7 AND -
CHAR] 0 - DUP 9 > 7 * -
[CHAR] 0 - DUP 9 > IF 7 - THEN
какой код эффективнее ?
И это единственное, что важно, остальное - бла-бла.
gudleifr писал(а):
т.к. TRUE-выдаваемое используется не по назначению.
Именно по назначению. TRUE-выдаваемое здесь 16/32/64 параллельных флага "ИСТИНА". И я их параллельно логически перемножаю в одной операции AND.
А TRUE-получаемое, например оператором IF суть логическое произведение этих 16/32/64 параллельных логических флагов. По сути оператор IF имеет на входе вентиль 16И/32И/64И.
И параллельные логические вычисления - это благо. Это по сути возможность хотя бы частично совместить достоинства процессоров и достоинства рассыпной логики. Процессор способен только на последовательные вычисления (параллельность там создается только искусственно конвейерами и многоядерностью), а рассыпная логика параллельные (последовательность там создается искусственно D-триггерами и тактирвоанием). А тут естественное объединение достоинств того и другого без накладных расходов.
Ну вот когда-то я писал брут-форсилки DES и меня мучило, что самая медленная операция - перестановка бит. Именно та операция, которая в случае дискрета вообще не требует времени, поскольку тупо достигается перепутанными проводами. И мне пришло убеждение, что процессор нужно доработать аппаратно, чтобы не было сильного торможения там, где его может вообще не быть. А в случае TRUE = -1 в Форт получается что-то вроде малой такой доработки, причем естественным образом. Параллельные логические вычисления там, где чьи-то досужие абстракции предполагают только последовательные.

Считай, что на входе ?BRANCH запаяны два корпуса К155ЛА2 и все.
Сообщение Добавлено: Пн янв 16, 2017 15:22
  Заголовок сообщения:  Re: FALSE раньше и теперь  Ответить с цитатой
Ethereal писал(а):
Мне программу писать или сущность TRUE дистиллировать ?
Я просил не путать TRUE-выдаваемое с TRUE-получаемым.

В Вашем же примере никого не интересует TRUE-получаемое (важно знать, что оно есть), т.к. TRUE-выдаваемое используется не по назначению. Конкретный способ представления TRUE в примере вообще не важен. Ну, было бы > возвращал 1, написали бы

[CHAR] 0 - DUP 9 > 7 * -

А если бы не знали, -1 или 1,

[CHAR] 0 - DUP 9 > IF 7 - THEN

Конечно, если это единственный случай использования > в Вашей системе, то удобнее чтобы он возвращал сразу число 7.
Сообщение Добавлено: Пн янв 16, 2017 11:57
  Заголовок сообщения:  Re: FALSE раньше и теперь  Ответить с цитатой
Мне программу писать или сущность TRUE дистиллировать ?
Впрочем, после > целая ячейка забита этими сущностями в каждом своем бите. Что ни бит, то сущность. Ажно неохваченных сущностями бит просто нету.
Сообщение Добавлено: Пн янв 16, 2017 05:01
  Заголовок сообщения:  Re: FALSE раньше и теперь  Ответить с цитатой
Ethereal писал(а):
[CHAR] 0 - DUP 9 > 7 AND -
И в каком месте тут присутствует сущность TRUE ?
Сообщение Добавлено: Вс янв 15, 2017 18:26
  Заголовок сообщения:  Re: FALSE раньше и теперь  Ответить с цитатой
Не понял ? Что именно я тут путаю ?

[CHAR] 0 - DUP 9 > 7 AND -
Вот это я называю
>b.) Use flag as a mask for logical functions

Поразрядная логика - это 16/32/64 раз "логическая". Твори "логическую" логику в любом разряде, а не только в нулевом. И даже в нескольких сразу. А "логическая" логика в младшем разряде - это всего-лишь подмножество поразрядной. Так-что Форт не тупее, а мощнее.
Сообщение Добавлено: Вс янв 15, 2017 18:15
  Заголовок сообщения:  Re: FALSE раньше и теперь  Ответить с цитатой
Ethereal писал(а):
TRUE=-1
Вы опять путаете число, распознаваемое ?BRANCH , с числом, возвращаемым словами, которые Вам хочется считать логическими. Равенство первого второму, как и само наличие каких-то норм на второе, вещи сильно условные. Даже в C есть два набора логики - поразрядная и "логическая". Почему FORTH должен быть тупее?
Сообщение Добавлено: Пт янв 13, 2017 21:47
  Заголовок сообщения:  Re: FALSE раньше и теперь  Ответить с цитатой
HughAguilar писал(а):
A flag can be added to a counter --- I believe that this is more common than using a flag as a mask for logical functions

If TRUE=-1 you can
a.) Subtract it from the counter. This will increment counter if TRUE
b.) Use flag as a mask for logical functions

If TRUE=1 you can
a.) Add it to the counter. This will increment counter if TRUE

So, TRUE=-1 is more powerful.
Сообщение Добавлено: Пт янв 13, 2017 21:33
  Заголовок сообщения:  Re: FALSE раньше и теперь  Ответить с цитатой
Hishnik писал(а):
However, mechanism of number recognizing should be modified in realtime. So, must be a way to set recognizing 1.23 as fixed-point number. This is easily provided be DEFERring NUMBER, but having as default a controllable version, with some system variables to enable/disable recognizing of all formats listed above.

http://www.gudleifr.h1.ru/cgi-bin/pilo.cgi?FL=../g9.txt&IS=%5C1.INTERPRETATOR%5C1.ZIKL%20UPRAWLENIA%5C2.POISK%20KODA%5C2.RASPOSNAWANIE%20LITERALOW
Сообщение Добавлено: Ср янв 04, 2017 11:39
  Заголовок сообщения:  Re: FALSE раньше и теперь  Ответить с цитатой
HughAguilar писал(а):
I think that you are over-concerned about the need for a large range. Forth has been used to solve a lot of numeric programs using fixed-point. So long as you choose the units correctly, then your numbers are usually in range. This was done in 16-bit, but it was a major hassle. It works a lot better in 32-bit. What I am proposing with the ratios are two 64-bit integers (numerator and denominator). I had said before that the sign would be in the numerator and the denominator would be unsigned. I now think that the sign should be in the denominator and the numerator unsigned. This means that your numerator has a range of 64 bits which is about [0,18E18]. You had mentioned above numbers such as 1E6 and 1E-12 being problematic --- they are both within range though!

This is not my concern indeed. I start to use floating point long time ago and it has a serious application domain - scientific calculations and modelling. I can point to multiplication and division - then you choose a 'quantum' for fixed-point, you may face with situation when 1000000 will multiply by 2 or 3 - this is certainy precision loss, because it seems the second operand was 2.123 or someone else, but not 2 or 3 exactly. Floating point exclude rounding problems and you always have 24 or 53 bits in mantissa. This is very important for scientific formulaes, because it may use several numbers in numerator and several in denumerator as well. With fixed point you need to remember about LSB, but floating point let you to forget about this (unless you goes under 1E-38 or under 1E-308, but this is nearly impossible).

I don't think floating point is all we need. Since we have an FPU as hardware component, it is natural decision to add it's functionality to Forth. It is easy, at last.

HughAguilar писал(а):
I am thinking of Straight Forth being used for statistics, similar to the R language.

Yes, this is a serious reason to stay with fixed point. As I note previously, FPU is best with multiplication and division (and trigonometric functions of course), but with addition and subtraction we can lost LSB due to 'machine zero' and siginificantly order mismatch. For statistics (and financial operations) this is critical disadvantage.

HughAguilar писал(а):
You seem to be a die-hard x87 believer! I expect that the ultimate solution will be to define Straight Forth in such a way that "number" is left undefined. I could write one version that defines a "number" as a ratio (two 64-bit integers). You write one version that defines a "number" as a 64-bit IEEE-754 float. The two versions would be compatible --- most programs will run on either version without modification, although they may produce slightly different results in the least-significant digits --- a few programs will only run on your version because they need the huge range of IEEE-754 floats, and a very few programs will only run on my version because they need the precision of ratios.

Yes, numbers should be defined in different standards. Forth must provide a way to add number recognition words, and if you want to add a representation, your literals will be recognized and goes to stack you choose for them. This is an easy thing with Forth itself, and I wonder why so many peoples tries to fix all number formats. Instead of this, we can provide a clear way to work with any data, providing a base set of integer, fixed point, rational numbers and floating point. One may extend it to double and quadruple integers etc.

HughAguilar писал(а):
Be aware that, although the x87 is stack-based, this does not mean that it can be used directly as the data-stack. The x87 stack has only 8 elements, and you need more than that for your data-stack. You need to move floats into and out of memory as necessary, while still being efficient and keeping as many of the top values as possible on the x87 stack. This is a difficult optimization! Also, you need to be able to recognize when a particular element of the data-stack is an address, and hold it in one of the x86 registers. This is a difficult optimization! Your version will be more difficult to write than my version --- your version may be too difficult for me to write --- you are reaching for the stars!

Indeed, only 6 cells on FPU may be used for calculation :) you need two more cells for printing. Stack nature of FPU provides a very fast code without any optimization - if you can write stack-based FPU calculations, they will execute as you wrote and without any penalty from FPU side. I have tens of scientific programs written with floating point and several colleagues who comes to Forth because of effecive floating-point support, so there is a couple of success stories here. I don't want to tell you MUST use FPU (indeed, for statistics calculations, you should NOT use it, unless you want to lost precision), but there is a strong feature of Forth to integrate known and useful things if needed.
Сообщение Добавлено: Вс янв 01, 2017 19:58
  Заголовок сообщения:  Re: FALSE раньше и теперь  Ответить с цитатой
Hishnik писал(а):
HughAguilar писал(а):
I still don't think that most Forthers need the range of IEEE-754 floats. You mentioned in an email that this is needed in calculations involving quantum mechanics. Well, how many Forthers are studying that???

There are many other applications operating with high range of numbers. You may have resistance from Ohms to MOhms (1E6) and capacitance from 1E-12 F, so electronics will have benefits from floating point too.

I think that you are over-concerned about the need for a large range. Forth has been used to solve a lot of numeric programs using fixed-point. So long as you choose the units correctly, then your numbers are usually in range. This was done in 16-bit, but it was a major hassle. It works a lot better in 32-bit. What I am proposing with the ratios are two 64-bit integers (numerator and denominator). I had said before that the sign would be in the numerator and the denominator would be unsigned. I now think that the sign should be in the denominator and the numerator unsigned. This means that your numerator has a range of 64 bits which is about [0,18E18]. You had mentioned above numbers such as 1E6 and 1E-12 being problematic --- they are both within range though!

Hishnik писал(а):
FPU is also very good for trigonometric operations and perfect at all for stack, since 80x87 is stack-based in nature.

I agree that the x87 is good for transcendental functions such as SIN COS LN etc.. For these, it would be possible to convert the ratio into an 80-bit x87 float, do the transcendental function, then convert it back into a ratio.

I am thinking of Straight Forth being used for statistics, similar to the R language. This doesn't involve transcendental functions. It often does involve huge quantities of data though.

You seem to be a die-hard x87 believer! I expect that the ultimate solution will be to define Straight Forth in such a way that "number" is left undefined. I could write one version that defines a "number" as a ratio (two 64-bit integers). You write one version that defines a "number" as a 64-bit IEEE-754 float. The two versions would be compatible --- most programs will run on either version without modification, although they may produce slightly different results in the least-significant digits --- a few programs will only run on your version because they need the huge range of IEEE-754 floats, and a very few programs will only run on my version because they need the precision of ratios.

Be aware that, although the x87 is stack-based, this does not mean that it can be used directly as the data-stack. The x87 stack has only 8 elements, and you need more than that for your data-stack. You need to move floats into and out of memory as necessary, while still being efficient and keeping as many of the top values as possible on the x87 stack. This is a difficult optimization! Also, you need to be able to recognize when a particular element of the data-stack is an address, and hold it in one of the x86 registers. This is a difficult optimization! Your version will be more difficult to write than my version --- your version may be too difficult for me to write --- you are reaching for the stars!

Perhaps a good plan would be to write the version with ratios first --- this can be an entry-level version using ITC (indirect threaded code).

Afterward, the version with IEEE-754 can be written --- this can be a more advanced version using STC (subroutine threaded code) --- this will do a lot of optimization as described above.
Сообщение Добавлено: Вс янв 01, 2017 07:50

Часовой пояс: UTC + 3 часа [ Летнее время ]


Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
phpBB сборка от FladeX // Русская поддержка phpBB