Автор |
Сообщение |
|
|
Заголовок сообщения: |
lib/include/float2 f и 12 34d |
|
|
Если не хочешь мучиться со строками а скорее всего потом будут проблемы при чтении строки назад посимвольно, то используй специальную библиотеку Lib_bytes кажется называется. Там можно хранить информацию как массив байтов.
Если не хочешь мучиться со строками а скорее всего потом будут проблемы при чтении строки назад посимвольно, то используй специальную библиотеку Lib_bytes кажется называется. Там можно хранить информацию как массив байтов.
|
|
|
|
Добавлено: Вс янв 03, 2010 23:55 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Хищник писал(а): А какая будет удобнее? Для того чтобы распарсить файл с числами - надо - установить вектор, отключить все словари (чтобы разбирать только числа, я не в курсе есть у вас там словари или нет, но как-то надо убрать слова из области видимости), в этом векторе не забыть проверять переменную-тип_числа (имхо лучше был бы явный параметр-флаг), вектор восстановить, контекст-словари восстановить, обрабатывать исключения корректно (из ситуации - не-слово-и-не-число) - это я так понимаю придётся делать где-то в другом месте - не в диспетчере. Мне больше нравится вариант когда парсинг-преобразование проходит явно - как в коде выше - ошибки преобразования возвращаются как флаг и сразу обрабатываются. Я сам контролирую какие числа я получаю - вызовом функции преобразования, словари переключать не надо. Хищник писал(а): У меня тут единственный критерий - системой должно быть удобно пользоваться "со стороны", а не удобно программировать ее на Форте.
Меня больше интересует удобство использования системы программистом. Во-первых потому что на форте я пишу сам для себя. Во-вторых, потому что в случае удовлетворения этого параметра повышается вероятность того, что программист напишет более лучший/надёжный/поддерживаемый код и соотвественно программа будет более удобна "со стороны". Вообще по моему скромному мнению - странный критерий - проектировать инструмент со стороны удобства того кто будет использовать не сам инструмент, а результат работы с этим инструментом - перепрыг через одно звено получается.
[quote="Хищник"]А какая будет удобнее?[/quote] Для того чтобы распарсить файл с числами - надо - установить вектор, отключить все словари (чтобы разбирать только числа, я не в курсе есть у вас там словари или нет, но как-то надо убрать слова из области видимости), в этом векторе не забыть проверять переменную-тип_числа (имхо лучше был бы явный параметр-флаг), вектор восстановить, контекст-словари восстановить, обрабатывать исключения корректно (из ситуации - не-слово-и-не-число) - это я так понимаю придётся делать где-то в другом месте - не в диспетчере. Мне больше нравится вариант когда парсинг-преобразование проходит явно - как в коде выше - ошибки преобразования возвращаются как флаг и сразу обрабатываются. Я сам контролирую какие числа я получаю - вызовом функции преобразования, словари переключать не надо.
[quote="Хищник"]У меня тут единственный критерий - системой должно быть удобно пользоваться "со стороны", а не удобно программировать ее на Форте.[/quote]
Меня больше интересует удобство использования системы программистом. Во-первых потому что на форте я пишу сам для себя. Во-вторых, потому что в случае удовлетворения этого параметра повышается вероятность того, что программист напишет более лучший/надёжный/поддерживаемый код и соотвественно программа будет более удобна "со стороны". Вообще по моему скромному мнению - странный критерий - проектировать инструмент со стороны удобства того кто будет использовать не сам инструмент, а результат работы с этим инструментом - перепрыг через одно звено получается.
|
|
|
|
Добавлено: Вт дек 18, 2007 23:53 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
ygrek писал(а): Теперь понятно. Лично мне такая схема кажется неудобной.
А какая будет удобнее? У меня тут единственный критерий - системой должно быть удобно пользоваться "со стороны", а не удобно программировать ее на Форте.
[quote="ygrek"]Теперь понятно. Лично мне такая схема кажется неудобной.[/quote]
А какая будет удобнее? У меня тут единственный критерий - системой должно быть удобно пользоваться "со стороны", а не удобно программировать ее на Форте.
|
|
|
|
Добавлено: Вт дек 18, 2007 16:10 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Теперь понятно. Лично мне такая схема кажется неудобной.
Теперь понятно. Лично мне такая схема кажется неудобной.
|
|
|
|
Добавлено: Вс дек 16, 2007 21:15 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Там переменная есть, которая хранит тип последнего обработанного числа. Я просто в примере ее не проверяю. Двойных чисел как таковых нет - это "синтаксический сахар". Когда все упаковано и распихано, вызывается вектор DISPATCH-NUMBER.
Предваряя вопросы - у констант есть флажок NUMERICAL, который заставляет интерпретатор после их выполнения тоже вызывать DISPATCH-NUMBER.
Там переменная есть, которая хранит тип последнего обработанного числа. Я просто в примере ее не проверяю. Двойных чисел как таковых нет - это "синтаксический сахар". Когда все упаковано и распихано, вызывается вектор DISPATCH-NUMBER.
Предваряя вопросы - у констант есть флажок NUMERICAL, который заставляет интерпретатор после их выполнения тоже вызывать DISPATCH-NUMBER.
|
|
|
|
Добавлено: Вс дек 16, 2007 19:21 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Что-то я не понимаю как это работает. А целые числа? Ещё один вектор? А двойные числа - ещё один? Что будет если флоаты идут вперемешку с целыми числами?
Что-то я не понимаю как это работает. А целые числа? Ещё один вектор? А двойные числа - ещё один? Что будет если флоаты идут вперемешку с целыми числами?
|
|
|
|
Добавлено: Вс дек 16, 2007 18:36 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
ygrek писал(а): Как вы его будете EVALUATE'ить? Как его представить в виде форт-исходника чтобы он "сам себя" прочитал? Всякие callback'и (например "после_каждого_числа" или "после_каждой_строки") делаются неочевидным образом (курочить INTERPRET ради такой простой задачи не хочется). Его не надо курочить. Ключевые слова должны быть векторизованы, чтобы можно было вносить небольшие по объему исправления. Если нет - имеем ситуацию, когда программист, желающий применить транслятор в новой области, вынужден просить авторов внести мелкие правки, которые не затрагивают движок, но корректируют поведение, как требует новое применение. А авторы еще подумают, сошлются на стандарт (Форта, а не области применения, где слыхом не слыхивали о том, что через точку пишется число двойной длины), расскажут, что Форт надо понимать... что теперь удивительного в недостаточно активном распространении? ygrek писал(а): Как? Как при этом будет выглядеть обработка ошибок?
Код: CREATE ARRAY[] 1000 FLOATS ALLOT 0 VALUE POINTER
: INPUT ( F: x -- ) POINTER FLOATS ARRAY[] + F! POINTER 1+ TO POINTER ;
' INPUT TO DISPATCH-NUMBER
Обработка ошибок: " 1.23456.345.EZZZ не найдено и не является числом". Опознает NUMBER.
[quote="ygrek"]Как вы его будете EVALUATE'ить? Как его представить в виде форт-исходника чтобы он "сам себя" прочитал? Всякие callback'и (например "после_каждого_числа" или "после_каждой_строки") делаются неочевидным образом (курочить INTERPRET ради такой простой задачи не хочется).[/quote] Его не надо курочить. Ключевые слова должны быть векторизованы, чтобы можно было вносить небольшие по объему исправления. Если нет - имеем ситуацию, когда программист, желающий применить транслятор в новой области, вынужден просить авторов внести мелкие правки, которые не затрагивают движок, но корректируют поведение, как требует новое применение. А авторы еще подумают, сошлются на стандарт (Форта, а не области применения, где слыхом не слыхивали о том, что через точку пишется число двойной длины), расскажут, что Форт надо понимать... что теперь удивительного в недостаточно активном распространении?
[quote="ygrek"]Как? Как при этом будет выглядеть обработка ошибок? [/quote]
[code]CREATE ARRAY[] 1000 FLOATS ALLOT 0 VALUE POINTER
: INPUT ( F: x -- ) POINTER FLOATS ARRAY[] + F! POINTER 1+ TO POINTER ;
' INPUT TO DISPATCH-NUMBER[/code]
Обработка ошибок: " 1.23456.345.EZZZ не найдено и не является числом". Опознает NUMBER.
|
|
|
|
Добавлено: Вс дек 16, 2007 15:50 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Хищник писал(а): Получится. Если слово попадает в NUMBER, можно вызывать после него диспетчер, который будет сам передвигать указатель и заполнять массив. Как именно оно попадает в NUMBER и что это за NUMBER? Покажите код(псевдокод)? Например. Есть файл : Код: 1.23 4.56 7.89 2.34 5.67 8.90 ...
Как вы его будете EVALUATE'ить? Как его представить в виде форт-исходника чтобы он "сам себя" прочитал? Всякие callback'и (например "после_каждого_числа" или "после_каждой_строки") делаются неочевидным образом (курочить INTERPRET ради такой простой задачи не хочется). И получается что проще/логичнее делать как-то так Код: S" filename" LAMBDA{ 3 0 DO PARSE-NAME >FLOAT IF СохранитьЧисло ELSE Ругаться THEN LOOP } INCLUDED-LINES-WITH
Цитата: Можно принимать текстовые файлы сразу в массив. Как? Как при этом будет выглядеть обработка ошибок? Цитата: Вопрос в следующем - либо мы ориентируемся на процесс с минимумом подводных камней, либо на умозрительные стандарты.
Ну по факту стандарт совсем не умозрительный. А такой какой он есть. Другого нет. Увы.
In a nutshell : Конечно проще определять вещественные числа по точке, но так как есть сейчас не создаёт прям-таки принципиальных трудностей при работе.
[quote="Хищник"]Получится. Если слово попадает в NUMBER, можно вызывать после него диспетчер, который будет сам передвигать указатель и заполнять массив.[/quote] Как именно оно попадает в NUMBER и что это за NUMBER? Покажите код(псевдокод)? Например. Есть файл : [code] 1.23 4.56 7.89 2.34 5.67 8.90 ... [/code] Как вы его будете EVALUATE'ить? Как его представить в виде форт-исходника чтобы он "сам себя" прочитал? Всякие callback'и (например "после_каждого_числа" или "после_каждой_строки") делаются неочевидным образом (курочить INTERPRET ради такой простой задачи не хочется). И получается что проще/логичнее делать как-то так [code] S" filename" LAMBDA{ 3 0 DO PARSE-NAME >FLOAT IF СохранитьЧисло ELSE Ругаться THEN LOOP } INCLUDED-LINES-WITH [/code]
[quote]Можно принимать текстовые файлы сразу в массив. [/quote] Как? Как при этом будет выглядеть обработка ошибок?
[quote]Вопрос в следующем - либо мы ориентируемся на процесс с минимумом подводных камней, либо на умозрительные стандарты.[/quote]
Ну по факту стандарт совсем не умозрительный. А такой какой он есть. Другого нет. Увы.
In a nutshell : Конечно проще определять вещественные числа по точке, но так как есть сейчас не создаёт прям-таки принципиальных трудностей при работе.
|
|
|
|
Добавлено: Вс дек 16, 2007 13:39 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
ygrek писал(а): Чьё отношение-то? В "реальном" проекте просто напросто пишется свой преобразователь для флоатов и никаких проблем. Т.е. если вы обрабатывает сторонние данные то вряд-ли получится просто за-EVALUATE'ить весь входной файл и поэтому каждое число явно парсится - тогда какая разница что вызывать - >FLOAT или >MY-FLOAT ?
Получится. Если слово попадает в NUMBER, можно вызывать после него диспетчер, который будет сам передвигать указатель и заполнять массив. Можно принимать текстовые файлы сразу в массив. Вопрос в следующем - либо мы ориентируемся на процесс с минимумом подводных камней, либо на умозрительные стандарты.
[quote="ygrek"]Чьё отношение-то? В "реальном" проекте просто напросто пишется свой преобразователь для флоатов и никаких проблем. Т.е. если вы обрабатывает сторонние данные то вряд-ли получится просто за-EVALUATE'ить весь входной файл и поэтому каждое число явно парсится - тогда какая разница что вызывать - >FLOAT или >MY-FLOAT ? [/quote]
Получится. :) Если слово попадает в NUMBER, можно вызывать после него диспетчер, который будет сам передвигать указатель и заполнять массив. Можно принимать текстовые файлы сразу в массив. Вопрос в следующем - либо мы ориентируемся на процесс с минимумом подводных камней, либо на умозрительные стандарты.
|
|
|
|
Добавлено: Вс дек 16, 2007 00:18 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Хищник писал(а): Собственно, отношение с записи вещественного числа весьма и весьма показательно. Эта шелуха с эксклюзивным форматом слетает, как только Форт начинает интенсивно использоваться для обработки текстовых данных, сформированных другими программами... то есть вообще включается в реальные проекты. И могу уверить, что просьбы "сохраняйте мне с символом E, потому что иначе я не обработаю" ну никак не приводят в этом случае ни к повышению эффективности процесса, ни к улучшению репутации Форта как удобного инструмента.
Чьё отношение-то? В "реальном" проекте просто напросто пишется свой преобразователь для флоатов и никаких проблем. Т.е. если вы обрабатывает сторонние данные то вряд-ли получится просто за-EVALUATE'ить весь входной файл и поэтому каждое число явно парсится - тогда какая разница что вызывать - >FLOAT или >MY-FLOAT ?
Естественно вопрос в том как разбирать float'ы по умолчанию. Но как я уже сказал выше - тут ответ простой - либо ANS и точка для двойных чисел и e для вещественных, либо не-ANS со всеми вытекающими плюшками.
[quote="Хищник"]Собственно, отношение с записи вещественного числа весьма и весьма показательно. Эта шелуха с эксклюзивным форматом слетает, как только Форт начинает интенсивно использоваться для обработки текстовых данных, сформированных другими программами... то есть вообще включается в реальные проекты. И могу уверить, что просьбы "сохраняйте мне с символом E, потому что иначе я не обработаю" ну никак не приводят в этом случае ни к повышению эффективности процесса, ни к улучшению репутации Форта как удобного инструмента.[/quote]
Чьё отношение-то? В "реальном" проекте просто напросто пишется свой преобразователь для флоатов и никаких проблем. Т.е. если вы обрабатывает сторонние данные то вряд-ли получится просто за-EVALUATE'ить весь входной файл и поэтому каждое число явно парсится - тогда какая разница что вызывать - >FLOAT или >MY-FLOAT ?
Естественно вопрос в том как разбирать float'ы по умолчанию. Но как я уже сказал выше - тут ответ простой - либо ANS и точка для двойных чисел и [b]e[/b] для вещественных, либо не-ANS со всеми вытекающими плюшками.
|
|
|
|
Добавлено: Вс дек 16, 2007 00:09 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
mOleg писал(а): Точка по-моему таки не очень подходит. А вот с запятой идея по-моему хорошая
Вот так - в корне неверно. Есть стандарт на запись чисел - не фортовский, а математический. И если некий язык программирования вводит свой формат, значит, он или сильно специализирован и предназначен для узкой области (математической), либо... это разновидность выпендрежа. Ну в крайнем случае дремучего невежества и отсталости авторов стандарта/транслятора, не следящих за текущими реалиями. В конце концов, есть символ-разделитель Windows (точка или запятая в зависимости от системных настроек). Это тоже вариант. В подавляющем большинстве (практически поголовно) языков признак вещественного числа - точка. 0.0 - это вариант записи сопроцессорной константы "вещественный ноль", который преобразуется в fldz.
Собственно, отношение с записи вещественного числа весьма и весьма показательно. Эта шелуха с эксклюзивным форматом слетает, как только Форт начинает интенсивно использоваться для обработки текстовых данных, сформированных другими программами... то есть вообще включается в реальные проекты. И могу уверить, что просьбы "сохраняйте мне с символом E, потому что иначе я не обработаю" ну никак не приводят в этом случае ни к повышению эффективности процесса, ни к улучшению репутации Форта как удобного инструмента.
[quote="mOleg"]Точка по-моему таки не очень подходит. А вот с запятой идея по-моему хорошая[/quote]
Вот так - в корне неверно. Есть стандарт на запись чисел - не фортовский, а математический. И если некий язык программирования вводит свой формат, значит, он или сильно специализирован и предназначен для узкой области (математической), либо... это разновидность выпендрежа. Ну в крайнем случае дремучего невежества и отсталости авторов стандарта/транслятора, не следящих за текущими реалиями. В конце концов, есть символ-разделитель Windows (точка или запятая в зависимости от системных настроек). Это тоже вариант. В подавляющем большинстве (практически поголовно) языков признак вещественного числа - точка. 0.0 - это вариант записи сопроцессорной константы "вещественный ноль", который преобразуется в fldz.
Собственно, отношение с записи вещественного числа весьма и весьма показательно. Эта шелуха с эксклюзивным форматом слетает, как только Форт начинает интенсивно использоваться для обработки текстовых данных, сформированных другими программами... то есть вообще включается в реальные проекты. И могу уверить, что просьбы "сохраняйте мне с символом E, потому что иначе я не обработаю" ну никак не приводят в этом случае ни к повышению эффективности процесса, ни к улучшению репутации Форта как [b]удобного [/b]инструмента.
|
|
|
|
Добавлено: Сб дек 15, 2007 22:43 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
ygrek писал(а): mOleg писал(а):использовать запятую вместо точки: 1,23423 - это folat 1.23423 - это double
А какое различие между single'ами и double'ами раз они все строем идут на флоат-стек?
не верно. Число с точкой внутри идет на data стек, только занимает две ячейки.
В спф этот момент иногда используется в виде 0.0 но к сожалению в СПФе такие числа преобразуются с ошибкой 8( правда я у себя уже исправил.
Точка по-моему таки не очень подходит.
А вот с запятой идея по-моему хорошая
[quote="ygrek"]mOleg писал(а):использовать запятую вместо точки: 1,23423 - это folat 1.23423 - это double
А какое различие между single'ами и double'ами раз они все строем идут на флоат-стек?[/quote]
не верно. Число с точкой внутри идет на data стек, только занимает две ячейки.
В спф этот момент иногда используется в виде 0.0 но к сожалению в СПФе такие числа преобразуются с ошибкой 8( правда я у себя уже исправил.
Точка по-моему таки не очень подходит.
А вот с запятой идея по-моему хорошая
|
|
|
|
Добавлено: Сб дек 15, 2007 22:14 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
ygrek писал(а): Ну это могут себе позволить только форты не претендующие на ANS-совместимость.
Это безобразие давно пора по факту приводить в норму! Хотя бы разрешать использование чисел только с точкой. Куда ни посмотришь, точки достаточно, одни ANS-еры лучше всех знают, как надо...
[quote="ygrek"]Ну это могут себе позволить только форты не претендующие на ANS-совместимость. [/quote]
Это безобразие давно пора по факту приводить в норму! Хотя бы [i]разрешать [/i]использование чисел только с точкой. Куда ни посмотришь, точки достаточно, одни ANS-еры лучше всех знают, как надо... :dmad;
|
|
|
|
Добавлено: Сб дек 15, 2007 01:38 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Хищник писал(а): Еще бы e убрать из обязательных символов, а ориентироваться исключительно на точку. Ну это могут себе позволить только форты не претендующие на ANS-совместимость. mOleg писал(а): использовать запятую вместо точки: 1,23423 - это folat 1.23423 - это double А какое различие между single'ами и double'ами раз они все строем идут на флоат-стек? Экономить байты в области данных за счёт увеличения нагрузки на программера? mOleg писал(а): сть идея веселее - в переменной BASE выдумать состояние для float ...
Ага, замечательно весёлая идея, с точки зрения читабельности кода.
[quote="Хищник"]Еще бы e убрать из обязательных символов, а ориентироваться исключительно на точку.[/quote] Ну это могут себе позволить только форты не претендующие на ANS-совместимость.
[quote="mOleg"]использовать запятую вместо точки: 1,23423 - это folat 1.23423 - это double[/quote] А какое различие между single'ами и double'ами раз они все строем идут на флоат-стек? Экономить байты в области данных за счёт увеличения нагрузки на программера?
[quote="mOleg"]сть идея веселее - в переменной BASE выдумать состояние для float ...[/quote]
Ага, замечательно весёлая идея, с точки зрения читабельности кода.
|
|
|
|
Добавлено: Сб дек 15, 2007 00:54 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
mOleg писал(а): плохо оно. точка - это число двойной длинны. Ну да, кто-то хорошо пофантазировал. Чем плоха запись 1234:5678, широко применявшаяся для задания пары чисел "сегмент-смещение"? mOleg писал(а): использовать запятую вместо точки: 1,23423 - это folat 1.23423 - это double
Оба - comp (внутренний формат сопроцессора). Формат появляется в процессе сохранения в память, команды для этого разные.
[quote="mOleg"]плохо оно. точка - это число двойной длинны. [/quote] Ну да, кто-то хорошо пофантазировал. Чем плоха запись 1234:5678, широко применявшаяся для задания пары чисел "сегмент-смещение"?[quote="mOleg"]использовать запятую вместо точки: 1,23423 - это folat 1.23423 - это double [/quote]
Оба - comp (внутренний формат сопроцессора). Формат появляется в процессе сохранения в память, команды для этого разные.
|
|
|
|
Добавлено: Пт дек 14, 2007 22:58 |
|
|
|
|