проходящий.Написать, что от конструкции
?RTrim(str(9000.000,20,10),"0",set("POINT")) && = 9
ожидается получение строки "9000" очень трудно и некоструктивно?
Если топик перечитан, то во-первых это уже написано.

Повторю краткое содержание выше сказанного:
ВладимирМПоэтому отсечение концевых нулей можно сделать проще


Способ решения задачи был предложен. В нем Dinozavr нашел "скрытый баг"
DinozavrПопробуйте выполнить:
У меня получается 9.1579999... (Это как раз тот баг, который раньше был у TRANSFORM)
Валентин Н.Карелин его поддержал и попросил баг прокомментировать.
Galyamov Rinat указал на явный косяк.
Я прокомментировал причину бага найденного Dinozavr`ом и подтвердил показанное Ринатом. Чего еше надо объяснять или доказывать? Не понимаю. Если считаешь что я недостаточно полно объяснил, то возьми сам и допиши недостающее.

проходящий.Так на чем зиждется такое ожидание?
Особенно если учесть ЯВНОЕ указание фнкции Rtrim() удалить все символы "0" и все символы "."?
Чем символы "0" в строке "9000.000" левее символа "." отличаются от символов "0" правее символа "."? Почему их не надо убирать? Тем более что и сам символ "." тоже надо убирать?
Еще раз. Я не ожидаю что с помошью Rtrim() получу преобразование "9000.000" => "9000".

Sergey Sizov.Dima TО ней и речь. Преобразование 9000.000 => "9" явно не в тему.
А хелп надо внимательней читать.
В третий раз :) Я эту конструкцию не предлагал.

Sergey Sizov.Вон и Владимир Максимов направление соответствующее указал. Правда сам немного в коде ошибся. :)
С этого все и началось.

PS 2проходящий, все-таки читай топики с учетом того кто, кому и что ответил.

проходящий.Galyamov Rinat
?RTrim(Rtrim(Transform(9000.000),"0"),Set("POINT")) у меня возвращает "9"

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

А хэлп про TRANSFORM() почитать?
HELP TRANSFORM() ... Numeric (включая Double, Float, или Integer тип данных)
Исключает лидирующие нули и пробелы, а также завершающие нули, находящиеся справа от десятичной точки.

Если исходное число является целым, то десятичная точка не указывается в результирующей строке. Например, число 4.0 преобразуется в строку "4"

Если исходное число больше нуля, но меньше единицы, в результирующей строке появляется лидирующий ноль. Например, число .4 преобразуется в строку "0.4".

Кстати TRANSFORM() в одиночку делает то что изначально пытались сделать

т.е.
Transform(9000.000) = "9000"
Transform(19.158) = "19,158"

Правда в хэлпе есть примечание настораживающее:
ПримечаниеИспользование функции TRANSFORM( ) для преобразования большого отрицательного числа, имеющего десятичные знаки может привести к неожиданным результатам, из-за числовых преобразований. Вместо данной функции в этих случаях рекомендуется использовать обычную функцию STR( ), для преобразования больших отрицательных чисел.

Sergey Sizov.Dima T
О ней и речь. Преобразование 9000.000 => "9" явно не в тему.
Теперь и я не понимаю о каком глюке или неправильном поведении Rtrim() идет речь.
Не вникай. Наша переписка с Проходящим мне анекдот напомнила про Петьку с Василий Иванычем в самолете:
ВИ: Петька, приборы?
П: Двести
ВИ: Что двести?
П: А что приборы?

Просто я ответил тем кто спрашивал, а Проходящий недопонял чего-то и начал мне же непонятные вопросы задавать, вместо того чтобы просто высказать свое мнение в дополнение к моему или против моего. Дальше уже я ничего не понял чего от меня хотят :)

Sergey Sizov.Так, ребята, давайте жить дружно. :)
Давайте. И перепалку эту прекратим заодно.

Dima TКстати TRANSFORM() в одиночку делает то что изначально пытались сделать

Transform(9000.000) = "9000"
Transform(19.158) = "19,158"

Насторожило что такое решение никто не предложил, поэтому решил проверить. Глючная функция оказывается. Например в 6-ке так:
В 9-ке это нормально отрабатывает, но есть другие косяки, правда помягче:

На целых числах такого нет, только на нецелых.
Вобщем мой вывод: Если иногда не обрезанные нолики в нецелых числах не смертельны, то в VFP9 можно обойтись одним TRANSFORM()

проходящий.Так какие косяки-то? С какой точностью число дали, с такой и получили строковый результат. Или должно было быть по-другому? Как?

Точно, это уже я хэлп недопонял. Нет косяков. TRANSFORM() нули после запятой отсекает только у целых чисел.
Transform(8817.600) => "8817.600"
Transform(8817.000) => "8817"

DinozavrТестирование (выполнение 100000 преобразований) на моем компе дало следующие результаты:
При lnValue = 9.158000 время выполнения 0.2 сек.
Если это выражение оформить как возвращаемое значение функции, то время возрастает до 0.3 сек.
Для сравнения - время для ранее предлагавшейся здесь функции StrTrimZero() при тех же условиях 0.6 сек.

А мою не тестил?
На моем компе для 9.158000 - 0,3 сек, для 9.00000 - 0.19 сек.

Имхо. В данном случае скорость роли не играет, т.к. плюс-минус 0,1-0,2 сек на 100000 погоды не сделают, т.к. обычно надо преобразовать не более сотни значений, изредка несколько тысяч.

Galyamov RinatНапоролся на "Превышение точности" и при указании 14 разрядов после запятой:
?TRANSFORM(91.99000000000000)
?str(91.99000000000000,20,14)
в 9-ке так работает:
?str(91.99000000000000,16,14)
Более 16-ти начинается погрешность двоично-десятичных преобразований, о чем в хэлпе написано:
HELP STR()Visual FoxPro contains a limit of 16 digits of precision in numeric calculations. For more information about numeric precision in Visual FoxPro, see Visual FoxPro System Capacities.
Galyamov RinatPS при установке
SET DECIMALS TO 14
Выражение
?VAL("91.99")
Так же отображает неожиданный результат :(
Тут уже ты сам запутался, сделай
или точку на запятую поменяй

16 тоже не всегда, точнее 15.95, т.е. 15 знаков всегда точно покажет, 16й в большинстве случаев:
Visual FoxPro System CapacitiesMiscellaneous:
64 bits = 8 bytes
Largest number = 10 ^ 308 = 2 ^ 1023
-> 10 bits per exponent + 1 for exponent sign plus 1 for number sign => 12 bits
Leaving 52 bits for the mantissa + 1 for implied normalized bit -> 53 bits
LOG10(2^53) = 15.95 decimal digits accuracy

Galyamov RinatDima Tпропущено...

Тут уже ты сам запутался, сделай
или точку на запятую поменяй


про запятую или set Point To '.' я не понял. У меня в выражении ?VAL("91.99") стоит точка. Set point to '.' стоит .
Та же ситуация с отображением с погрешностью.
Извини, я ступил. У меня 91.00 было из-за set Point To ','
или
Это как-раз та самая погрешность из-за точности в 15.95 знака.
В данном случае надо вывести 16 разрядов, что иногда происходит с ошибкой на 1 в последнем разряде.

PS Это проблема не только фокса, везде так, если использовать 8-байтные двоичные переменные с плавающей запятой. Большую точность можно с использованием типа Currency получить (18 знаков), только там поизвращаться прийдется с передвижением запятой при выводе и с расчетами.