Forth и другие саморасширяющиеся системы программирования Locations of visitors to this page
Текущее время: Вт мар 19, 2024 11:56

...
Google Search
Forth-FAQ Spy Grafic

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




Начать новую тему Ответить на тему  [ Сообщений: 32 ]  На страницу Пред.  1, 2, 3  След.
Автор Сообщение
 Заголовок сообщения: Re: FALSE раньше и теперь
СообщениеДобавлено: Пт дек 23, 2016 01:24 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7958
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
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.

FPU is also very good for trigonometric operations and perfect at all for stack, since 80x87 is stack-based in nature.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: FALSE раньше и теперь
СообщениеДобавлено: Пт дек 23, 2016 15:10 
Кстати, подобные хотелки уже обсуждались - http://fforum.winglion.ru/viewtopic.php?f=16&t=2990. И предлагаемое здесь решение "доработать стандарт" там было единогласно отвергнуто.


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: FALSE раньше и теперь
СообщениеДобавлено: Вс янв 01, 2017 07:50 
Не в сети

Зарегистрирован: Сб дек 17, 2016 23:03
Сообщения: 60
Благодарил (а): 0 раз.
Поблагодарили: 0 раз.
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.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: FALSE раньше и теперь
СообщениеДобавлено: Вс янв 01, 2017 19:58 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7958
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
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.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: FALSE раньше и теперь
СообщениеДобавлено: Ср янв 04, 2017 11:39 
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


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: FALSE раньше и теперь
СообщениеДобавлено: Пт янв 13, 2017 21:33 
Не в сети
Аватара пользователя

Зарегистрирован: Ср фев 23, 2011 20:42
Сообщения: 600
Откуда: Карелия
Благодарил (а): 3 раз.
Поблагодарили: 24 раз.
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.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: FALSE раньше и теперь
СообщениеДобавлено: Пт янв 13, 2017 21:47 
Ethereal писал(а):
TRUE=-1
Вы опять путаете число, распознаваемое ?BRANCH , с числом, возвращаемым словами, которые Вам хочется считать логическими. Равенство первого второму, как и само наличие каких-то норм на второе, вещи сильно условные. Даже в C есть два набора логики - поразрядная и "логическая". Почему FORTH должен быть тупее?


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: FALSE раньше и теперь
СообщениеДобавлено: Вс янв 15, 2017 18:15 
Не в сети
Аватара пользователя

Зарегистрирован: Ср фев 23, 2011 20:42
Сообщения: 600
Откуда: Карелия
Благодарил (а): 3 раз.
Поблагодарили: 24 раз.
Не понял ? Что именно я тут путаю ?

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

Поразрядная логика - это 16/32/64 раз "логическая". Твори "логическую" логику в любом разряде, а не только в нулевом. И даже в нескольких сразу. А "логическая" логика в младшем разряде - это всего-лишь подмножество поразрядной. Так-что Форт не тупее, а мощнее.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: FALSE раньше и теперь
СообщениеДобавлено: Вс янв 15, 2017 18:26 
Ethereal писал(а):
[CHAR] 0 - DUP 9 > 7 AND -
И в каком месте тут присутствует сущность TRUE ?


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: FALSE раньше и теперь
СообщениеДобавлено: Пн янв 16, 2017 05:01 
Не в сети
Аватара пользователя

Зарегистрирован: Ср фев 23, 2011 20:42
Сообщения: 600
Откуда: Карелия
Благодарил (а): 3 раз.
Поблагодарили: 24 раз.
Мне программу писать или сущность TRUE дистиллировать ?
Впрочем, после > целая ячейка забита этими сущностями в каждом своем бите. Что ни бит, то сущность. Ажно неохваченных сущностями бит просто нету.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: FALSE раньше и теперь
СообщениеДобавлено: Пн янв 16, 2017 11:57 
Ethereal писал(а):
Мне программу писать или сущность TRUE дистиллировать ?
Я просил не путать TRUE-выдаваемое с TRUE-получаемым.

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

[CHAR] 0 - DUP 9 > 7 * -

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

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

Конечно, если это единственный случай использования > в Вашей системе, то удобнее чтобы он возвращал сразу число 7.


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: FALSE раньше и теперь
СообщениеДобавлено: Пн янв 16, 2017 15:22 
Не в сети
Аватара пользователя

Зарегистрирован: Ср фев 23, 2011 20:42
Сообщения: 600
Откуда: Карелия
Благодарил (а): 3 раз.
Поблагодарили: 24 раз.
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 и все.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: FALSE раньше и теперь
СообщениеДобавлено: Пн янв 16, 2017 15:37 
Ethereal писал(а):
какой код эффективнее ?
Примерно одинаково неэффективно. Тем более, придется все равно проверять на попадание в допустимый диапазон. Эффективную реализацию см. в FOBOS. Впрочем, FORTH - это средство эффективной разработки. а не написания эффективного кода.

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

A B AND IF C THEN

от

A IF B IF C THEN THEN

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

Но, повторю, то что конкретные значения возвращаемые/получаемыми конкретными словами нам (не)удобны, не имеет никакого отношения к "проблеме TRUE".


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения: Re: FALSE раньше и теперь
СообщениеДобавлено: Пт янв 20, 2017 19:30 
Не в сети
Аватара пользователя

Зарегистрирован: Ср фев 23, 2011 20:42
Сообщения: 600
Откуда: Карелия
Благодарил (а): 3 раз.
Поблагодарили: 24 раз.
Отличие ... очень неудобно. Я понимаю, когда неудобна одна из двух альтернатив, но что есть неудобность наличия самой альтернативы ? Построенная тобой фраза никак на голову не налезает.

И в чем-же состоит "проблема TRUE" ? Сформулируй.
gudleifr писал(а):
Ethereal писал(а):
Впрочем, FORTH - это средство эффективной разработки. а не написания эффективного кода.
Хорошо бы если бы и того и другого. Разумеется, по возможности. Если не получается в лоб, то почему бы не с помощью трюков ? TRUE=-1 позволяет писать код в котором слово возвращает несколько булевский значений сразу и в упакованном виде. Для трюков вполне.


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

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

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

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

В FORTH принята только поразрядная логика. Поэтому при работе с логическими выражениями приходится упаковывать логические переменные в шкалы. Иногда, это удобно (например, я как-то рассматривал задачу "переправа через реку"). Но иногда - нет (как в приведенном выше логическом выражении, где хотя бы одно из A или B требуется "нормировать").


Вернуться к началу
  
Ответить с цитатой  
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 32 ]  На страницу Пред.  1, 2, 3  След.

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


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

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