Re: FP number syntax

albert@spenarnc.xs4all.nl writes:

One step further is to use 0x for hex values, and free $ for
environment strings.

Forth systems can use 0x as hex prefix already, and in 2007 I checked
several systems <http://www.forth200x.org/number-prefixes.html>: PFE,
Gforth 0.6.9, Win32Forth (4.x and 6.x), and VFX Forth understood 0x10
as well as 0X10; iForth, bigForth, SwiftForth, and lxf did not.

Someone would need to make a proposal for making the $ prefix for hex
numbers obsolescent as a first step towards destandardization.
Meanwhile, Gforth has a recognizer for environment variables:

${HOME} type

prints "/home/anton".

Then probably one can forget BASE DECIMAL

We would need to standardize at least BASE-EXECUTE to get rid of
dealing with BASE for producing output.

1] This is not easy. I have been in many projects where floating points
were transferred in text, loosing precision.

Floating-point numbers can be losslessly converted from binary to
decimal representation and back, with losslessly meaning that you get
the same binary FP number after one cycle, and for

decimal1 -> binary1 -> decimal2 -> binary2 -> decimal3

binary1 and binary2 are the same bit pattern, and decimal2 and
decimal3 are the same string.

However, doing it for hex is admittedly much simpler.  But then, if
the issue is just to get the number from one system to the next
without having to deal with byte order and the like, you can also do
(on a system with 64-bit cells):

variable x

1.23e x df! x @ . \ prints 4608218246714312622 on Gforth

The output is an exact representation of the bit pattern.  Now on the
next system you can:

variable x 4608218246714312622 x ! x df@ f.

I tried this on iForth, SwiftForth and VFX, and it worked on all of
them, outputting "1.23", sometimes with trailing zeroes.

The conversion of "1.23e" by the Forth text interpreter and of the end
result by F. may be less precise than you would like, though.

But of course parameters
in oil drill samples need not 5 decimal places.

When writing general-purpose code, we do not know the needed accuracy,
so if it is possible to produce an "exact" result, we should do so.

The definition of "exact" is interesting in this case.  E.g., there is
no exact representation of 1.23 as binary FP number, so we generally
go for the binary FP number that is closest to the input number.
Conversely, the binary64 number with the bit pattern
4608218246714312622 can be represented exactly in decimal as
1.229999999999999982236431605997495353221893310546875, but we may
prefer to output the shortest string that, when converted back to
binary64, produces the same binary64 value (in this case "1.23").

Back to hex FP, if we go there at all, we might want to go with the
string format used in C source code: 0xhhhh.hhhp-ddd where h is a hex
digit and d is a decimal digit.

- anton
--
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: https://forth-standard.org/
   EuroForth 2024: https://euro.theforth.net