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.