Forth :: Просмотр темы - числа формат, преобразование, представление

но только при условии, что не безрезультатно

В новом стандарте есть глава "совместимость"?

да нет, твой довод понят, только предлагаемая тобой ситуация не полна.

вопрос в том, что дальше ты с этими числами будешь делать?
просто положить на стек их не везде получится (стек может позволять 10 чисел хранить).
То есть сразу возникает вопрос что ты будешь с этими числами делать, и он определяет как их распознавать.

Дано: загрузить в массив целочисленные данные, представленные в файле в текстовом виде.

mOleg писал(а): вобщем, о том и речь. BASE не мешает в большой системе, хотя, к сожалению BASE плохо совмещается с CATCH THROW механизмом.

Ни комментариев, ни аргументов.... ни кода.

о, замечательно. Если действительно так, то после каждого следующего введенного числа должна состояться операция занесения данных в массив, кроме того, нужен будет контроль корректности чисел (ну, к примеру, если числа в массиве должны быть одинарной длины, то числа двойной длины должны "не проходить"). То есть мы приходим к следующему приблизительно коду:

А вот кварк:
Код:
' , TO DISPATCH-NUMBER
CAN-DISPATCH ON
CREATE X[]
" filename" L
CAN-DISPATCH OFF

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

Это что-то с чем-то...

это лишь констатация факта. В случае многопоточности системы по типу SPF-овской (и других виндошных систем) перенаправление глобальных векторов (если только это не USER-VECT) влияет сразу на все потоки.

А почему я тогда не вижу подобных проблем, пуская две копии Форта?

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

потому что ты запускаешь две копии Форта (то есть другой вид многопоточности).

Я говорю о существующей практике, то есть, о SPF, Win32Forth, SwiftForth и многих других системах с виндошной многопоточностью.

И хватит софистикой заниматься, надоело, чес слово.
Единичные факты не отменяют общих тенденций.

Ну и не занимайся. Общая тенденция - VARIABLE BASE

Но этот вид многопоточности не подходит... по религиозным соображениям? Или как?

Автор:	mOleg [ Пт мар 05, 2010 18:21 ]
Заголовок сообщения:
вопрос писал(а): но только при условии, что не безрезультатно да, было бы замечательно вопрос писал(а): В новом стандарте есть глава "совместимость"? а вот похоже придется такую главу делать.

Автор:	Hishnik [ Пт мар 05, 2010 18:41 ]
Заголовок сообщения:
mOleg писал(а): да нет, твой довод понят, только предлагаемая тобой ситуация не полна. А что уж тут еще надо для полноты ситуации? Дано: загрузить в массив целочисленные данные, представленные в файле в текстовом виде. mOleg писал(а): вопрос в том, что дальше ты с этими числами будешь делать? просто положить на стек их не везде получится (стек может позволять 10 чисел хранить). То есть сразу возникает вопрос что ты будешь с этими числами делать, и он определяет как их распознавать. Векторный NUMBER, сначала распознаем числа, потом записываем со стека в массив. Это было мое второе применение векторного NUMBER, после реализации плавающей точки в SPF.

Автор:	mOleg [ Пт мар 05, 2010 21:28 ]
Заголовок сообщения:
Хищник писал(а): Дано: загрузить в массив целочисленные данные, представленные в файле в текстовом виде. о, замечательно. Если действительно так, то после каждого следующего введенного числа должна состояться операция занесения данных в массив, кроме того, нужен будет контроль корректности чисел (ну, к примеру, если числа в массиве должны быть одинарной длины, то числа двойной длины должны "не проходить"). То есть мы приходим к следующему приблизительно коду: <pre> 300 CONSTANT limit \ предельное количество элементов в массиве CREATE ARRAY limit CELLS ALLOT \ это сам массив \ заполняться он будет, к примеру, последовательно 0 VALUE index \ сама "заполнялка массива" : >ARRAY ( n --> ) index 1 + limit OVER < IF ERROR" Чисел больше, чем размер массива" THEN DUP TO index CELLS ARRAY + ! ; \ собственно обработка чисел во входном потоке: : numbers ( / n1 .. nx --> ) BEGIN NextToken DUP WHILE >NUMBER IF DROP IF ERROR" Слишком большое число" ELSE >ARRAY THEN ELSE тут обработка не чисел THEN REPEAT DROP DROP ; </pre> и тут будет разница лишь в том, как будет употребляться код: 1) либо HEX numbers 1 2 3 4 5 6 7 8 9 A B C D E F 2) либо 0x10 numbers 1 2 3 4 5 6 7 8 9 A B C D E F второй случай пердполагает, что значение системы счисления передается numbers в явном виде, и его будет получать >NUMBER : <pre> : numbers ( base / n1 .. nx --> ) >R BEGIN NextToken DUP WHILE R@ >NUMBER IF DROP IF ERROR" Слишком большое число" ELSE >ARRAY THEN ELSE тут обработка не чисел THEN REPEAT RDROP DROP DROP ; </pre>

Автор:	mOleg [ Пт мар 05, 2010 21:31 ]
Заголовок сообщения:
Хищник писал(а): mOleg писал(а): вобщем, о том и речь. BASE не мешает в большой системе, хотя, к сожалению BASE плохо совмещается с CATCH THROW механизмом. Ни комментариев, ни аргументов.... ни кода. кстати, уж чего, а кода я привожу достаточно в отличие от автора высказывания!? по данной теме кода от него я не видел, да и как-то нас он своими примерами кода не балует.. 8( (в чужом глазу соринку?)

Автор:	Hishnik [ Пт мар 05, 2010 22:12 ]
Заголовок сообщения:
mOleg писал(а): о, замечательно. Если действительно так, то после каждого следующего введенного числа должна состояться операция занесения данных в массив, кроме того, нужен будет контроль корректности чисел (ну, к примеру, если числа в массиве должны быть одинарной длины, то числа двойной длины должны "не проходить"). То есть мы приходим к следующему приблизительно коду: А вот кварк: Код: ' , TO DISPATCH-NUMBER CAN-DISPATCH ON CREATE X[] " filename" L CAN-DISPATCH OFF Откуда возьмутся числа двойной длины, надо разбираться отдельно (кто-то ведь их туда сохранил.. а кто ж такое мог сделать помимо ТЗ?). Занесение данных в массив - это запятая.

Forth http://fforum.winglion.ru/

числа формат, преобразование, представление http://fforum.winglion.ru/viewtopic.php?f=36&t=2476	Страница 8 из 9

Автор:	mOleg [ Пт мар 05, 2010 22:30 ]
Заголовок сообщения:
Хищник писал(а): А вот кварк: Код: ' , TO DISPATCH-NUMBER CAN-DISPATCH ON CREATE X[] " filename" L CAN-DISPATCH OFF ну и сразу проблема - многопоточность зарезается. Т.е. если параллельный поток захочет работать с числами, огребет кучу проблем. в предлагаемом мною случае это не так.

Автор:	Hishnik [ Пт мар 05, 2010 22:46 ]
Заголовок сообщения:
mOleg писал(а): ну и сразу проблема - многопоточность зарезается. Т.е. если параллельный поток захочет работать с числами, огребет кучу проблем. Это что-то с чем-то...

Автор:	mOleg [ Сб мар 06, 2010 10:27 ]
Заголовок сообщения:
Хищник писал(а): Это что-то с чем-то... это лишь констатация факта. В случае многопоточности системы по типу SPF-овской (и других виндошных систем) перенаправление глобальных векторов (если только это не USER-VECT) влияет сразу на все потоки.

Автор:	Hishnik [ Сб мар 06, 2010 10:47 ]
Заголовок сообщения:
mOleg писал(а): это лишь констатация факта. В случае многопоточности системы по типу SPF-овской (и других виндошных систем) перенаправление глобальных векторов (если только это не USER-VECT) влияет сразу на все потоки. Да ну? А почему я тогда не вижу подобных проблем, пуская две копии Форта? Или они должны "многопоточно" грузить один и тот же файл, выхватывая друг у друга строки? Если же речь идет об искусственной форт-многопоточности в рамках одной задачи, то, как говорил Преображенский, "возьмите эти газеты и выбросите их в печку". Все глобальные ресурсы должны сохраняться и восстанавливаться при переключениях контекста, а если это не так, значит мы имеем дело с изощренным созданием сложностей для их последующего преодоления.

Автор:	mOleg [ Сб мар 06, 2010 10:59 ]
Заголовок сообщения:
Хищник писал(а): А почему я тогда не вижу подобных проблем, пуская две копии Форта? потому что ты запускаешь две копии Форта (то есть другой вид многопоточности). Хищник писал(а): Если же речь идет об искусственной форт-многопоточности в рамках одной задачи, то, как говорил Преображенский, "возьмите эти газеты и выбросите их в печку". Я говорю о существующей практике, то есть, о SPF, Win32Forth, SwiftForth и многих других системах с виндошной многопоточностью. И хватит софистикой заниматься, надоело, чес слово. Единичные факты не отменяют общих тенденций.

Автор:	mOleg [ Сб мар 06, 2010 11:23 ]
Заголовок сообщения:
ссылочка специально для Хищника.

Автор:	Hishnik [ Сб мар 06, 2010 11:29 ]
Заголовок сообщения:
mOleg писал(а): потому что ты запускаешь две копии Форта (то есть другой вид многопоточности). Но этот вид многопоточности не подходит... по религиозным соображениям? Или как? mOleg писал(а): Я говорю о существующей практике, то есть, о SPF, Win32Forth, SwiftForth и многих других системах с виндошной многопоточностью. Я не понимаю термина "виндошная многопоточность" в данном контексте. mOleg писал(а): И хватит софистикой заниматься, надоело, чес слово. Единичные факты не отменяют общих тенденций. Ну и не занимайся. Общая тенденция - VARIABLE BASE. Если так хочется оставить свой след в истории Форта, займись делом. А не пытайся поставить на уши непонятно кого, тем более что я еще не увидел ни одного подтверждения, что кто-то так и будет делать. Математическая запись чисел уже побоку, элементарный пример использования уже побоку - разбился о какую-то надуманную "виндошную многопоточность", которая при запуске программ в Windows почему-то не наблюдается. И это - новый стандарт Форта???

Автор:	mOleg [ Сб мар 06, 2010 11:39 ]
Заголовок сообщения:
Хищник писал(а): Ну и не занимайся. Общая тенденция - VARIABLE BASE замечательное ведение диалога. Сначала найти к чему придраться в утверждении, раздуть по этому поводу флейм, когда прижмут к стенке сказать сам виноват - не разводи флейм по непринципиальным вопросам;) Может действительно хватит? Хищник писал(а): Но этот вид многопоточности не подходит... по религиозным соображениям? Или как? а для ответа на этот вопрос надо ссылочку специально для хищника приведенную выше посетить

Автор:	вопрос [ Сб мар 06, 2010 11:55 ]
Заголовок сообщения:
надо бы

Автор:	Alexander [ Сб мар 06, 2010 19:03 ]
Заголовок сообщения:
Что сказать, ну что сказать?! - устроены так люди... Скажу честно для большинтсва типовых инженерных расчетов 16 значащих цифр хватает, но есть задачи, где подавай не менее 23. В реальности - либо строка длиная, либо эмуляциии плавающей точки с нужной разрядностью мантиссы и порядка. и нечего тут про стандартные средства - не помогут

Страница 8 из 9	Часовой пояс: UTC + 3 часа [ Летнее время ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/