Improving PostScript math accuracy and precision?

Postscript probably uses 32-bit IEEE reals, which have 8 bits of exponent and 25 bits of significand. If they used double-precision, the accuracy would of course roughly double.

I vaguely recall the Postcript blue book specifies the precision, and even vaguer recall it's "double".

The values printed out by the number to string routines may be rounding the last decimal place which is going to give you misleading printed results.

You might try running some of the basic floating-point tests, such as finding epsilon:

x = 1.0; eps = 1.0

while( x + eps > x ) eps = eps / 2

That tells you the dynamic range of the arithmetic.

er, I mean in Postscript something like:

/x 1.0 def /eps 1.0 def

{ /eps eps 2.0 div def } x eps add x gt while

--------------------

If you need better precision, you could always take GhostScript whose source is available, and change the arithmetic to double. Probably non-trivial, especially if you want the graphics operators to do double precision math too.

Sometimes it helps to use Rational Numbers.

- Henry

--

Sincwe i am not rational, why in the heck should i expect any numbers to be rational?

Because you are not a number. You are not rational. Therefore, all numbers are rational, QED.

--- Christopher Heckman

I am not sure I understand the point you are trying to make. Please clarify.

-- Many thanks,

Don Lancaster voice phone: (928)428-4073 Synergetics 3860 West First Street Box 809 Thatcher, AZ 85552 rss:

Please visit my GURU's LAIR web site at

The PostScript floating point math appears to be somewhat better than IEEE single precision and a lot worse than double. Apparently they swapped some exponent bits for mantissa bits in a custom modification.

At any rate, their implementation limits state "approximately" eight decimals of precision, and they clearly are underreporting results by two orders of magnitude with their normal six value output.

Thus, there's a 100:1 improvement apparently available by dinking around with rounding, differencing, merging, and custom reporting.

You can improve relative accuracy/resoultion in the near neighbour to any number (propably mostly One - but scaling is possible). For example: n=2.1 m=2.2 (let n and m to 32-bits) p= n/m (then p will have 64-bits)

If it is clear that you need more resolution at a certain number, this is a solution easy to use. You can do all calculations ADD, MUL, etc. with rational numbers too, AND easy. And the conversion between others (say

- Henry

--

Is it possible to scale up the image to a much larger size? Perhaps that would alleviate the problem.

What image?

PostScript is a totally general purpose computing language.

One of its minor and secondary ho-hum capabilities is to dirty up otherwise clean pieces of paper.

But such uses are horribly restrictive.

In the intended application, solutions to power series arrays of 14 trig multiangle variables in 14 unknowns, going up to the 27th power, are required. Exact solutions demand an extreme degree of precision.

Double the digits with the 3-4 method; split incoming numbers M1, M2 into two halves M1A, M1B; M2A,M2B and either do the schoolboy method or tje 3-4 method for multiplication which is faster. Toss the 3-4 least significant digits in the composite result ("noise") as needed.

Not sure I follow your notation. Could you give an example?

In FORTRAN: CASE (8 : 14) ! 3-4 method; carries already released D1=F(0)-F(1) ! lo part - hi part D2=G(1)-G(0) ! hi part - lo part X2=D1*D2 X1=F(1)*G(1) ! hi parts X0=F(0)*G(0) ! lo parts F(0)=DMOD(X0,1.0D7) ! lowest part D1=X1+X2+X0+DINT(X0*1.0D-7) ! SUM1 (was X0/1.0D7) D2=X1+DINT(D1*1.0D-7) ! SUM2 (was D1/1.0D7) F(1)=D1-(D2-X1)*1.0D7 ! was DMOD(D1,1.0D7) F(3)=DINT(D2*1.0D-7) ! highest part (was D2/1.0D7) F(2)=D2-F(3)*1.0D7 ! was DMOD(D2,1.0D7) Note F() and G() are the two input numbers and the result is in F().

Excellent point. Extermely important point!

Is there any _reason_ one would use PS for anything else, instead of some other programming language that yahoos might think was better suited to general computing?

David C. Ullrich

Object values are stored internally as a 32-bit wide union (float, long or pointer), which would need to grow to 64-bits. But the rise of 64-bit processors (where pointers can occupy 64 bits) suggests this would be a good thing to do anyway. It would be a good opportunity to raise the string, array and dictionary size limits too.

I suppose this might cause some compatibility issues. Alternatively the interpreter could implement a couple of additional 64-bit data types, but if one were to do that, one might as well implement arbitrary precision floats or rationals.

Other approaches? Write an arbitrary precision library in PostScript? Write a lisp interpreter in PostScript and run maxima?

FWIW I'd be happy to add an arbitrary precision data type to my RoPS interpreter

-- Roger

Fast, friendly, convenient, intuitive, faster programming, great ease of direct plotting, low cost, few hassles, etc etc etc...

I use PostScript for nearly ALL of my engineering analysis and development.

Thousands of examples at

Just picking up another two decimal points or so by an improved value reporter can give a lot of benefits without going a total double precision route.

"Display postscript" is glorious and would have ruled the world had it been done broadly and right. Would've completely elminated the need for Javascript and even browsers.

Whole generations really honestly believed that rasterized images were decent ways to transmit information, but were wrong!

Now we have SVG, which is pretty nifty in that it realizes much of what Display Postscript could do, but crappy in that much functionality requires Javascript. There is also Apple's Quartz, which is crappy in that it isn't postscript but PDF-like and often used to present bitmaps instead of rendering vectors.

Tim.

I routinely use PostScript to generate JavaScript programs. Also for pre simulation and modeling.

I write my JavaScript and SVG with Perl :-).

Old cookie: "I'd rather write programs that write program than write programs"!

Tim.