Improving PostScript math accuracy and precision?

One of the beauties of PostScript is the ease with which it can read or write most any disk file in most any language or format.

Maybe it would be easier to use an engine written in C or whatever for the grunt work and use PS for other tasks. If you're going to be using a (modern) PC to do the calculations, I believe that 64 or even 80 bit FP calculations will not be significantly more costly than 32 bit calculations, since it's done in hardware. IIRC, the P4 can do two double-precision floating point calculations per cycle.

I use the Bloodshed/Mingw (port of GCC) IDE and C/C++ compiler for a lot of small tasks.. it doesn't support 80 bit math IIRC, but 64 bit should be good enough for your purposes. A free download from:

Writing "console application" C programs for the PC is dead simple and involves no Windows-specific knowledge.

John Larkin (in sed) often mentions PowerBasic, which supports 80-bit floating point, but it is not free. Other languages such as Java or Python would be suitable too, but they are mostly C-like in syntax anyhow.

Best regards, Spehro Pefhany

I'm not sure that Python could be considered to have a C-like syntax. But it has direct support for greater precision data (along with vast collections of libraries, including numerical and scientific functions). And it has support for something that appears to be missing entirely from PS (judging from Don's pages) - Python programs are often legible, readable and understandable even by people who have never used the language before. I'm sure Don's programs are very impressive (and the magic sinewave stuff is fascinating), but they might as well have been written in APL.

PostScript can be made exceptionally self documenting and self-explanatory.

And we try to do this on our newer tutorial stuff.

Some of the older listings were for magazine publication, where an entire advanced concept had to be presented in an inch or two of space.

I would be very cautious about making, or assuming, such a modification. Although the PLRM does not dictate what internal float representation has to be used, it does require (in the binary token formats) that bidirectional conversion between the native representation and

Playing with a geen-u-wine Adobe PS interpreter, I strongly suspect that its native format either is IEEE 32-bit float, or something with very similar properties:

PostScript(r) Version 3010.108 (c) Copyright 1984-1999 Adobe Systems Incorporated. Typefaces (c) Copyright 1981 Linotype-Hell AG and/or its subsidiaries. All Rights Reserved. PS>1e38 PS>stack

So the maximum value is around 2 10^38, or 2^127, which is consistent with an 8-bit (signed) exponent field. An IEEE 32-bit float would have 24-bit precision, so the sum 1 + 2^(-23) should be detectably different from 1, but 1 + 2^(-24) should not be:

PS>1.0 dup dup 1 23 bitshift div add stack

Here we can't tell if these values are distinguishable, because the string conversion may be rounding them. Let's look at the bits:

PS>/net.anastigmatix.BinaryIO /ProcSet findresource begin PS>realtointbits = realtointbits =

So yes, they are just barely distinguishable, and:

PS>1.0 dup dup 1 24 bitshift div add PS>realtointbits = realtointbits =

are not. So this Adobe native implementation has both the same dynamic range and the same precision as a standard IEEE single float.

-Chap

It should do: try "long double" ICBW.

Logically, Adobe would use an IEEE standard. Especially since they "almost" say so in their implementation limits docs.

So, how do they get a claimed (and sometimes verified) approximately 8 decimals of precision out of only a 22 bit IEEE single precision mantissa?

I am missing something here.

Have done that; quite efficent to make the computer do 90+% of the work..

So back to my original question, in a little more detail to clarify things:

Suppose that I want to calculate the 1,000,000-th digit of Pi. Or I want to work out the best play in a certain backgammon position. Is there any reason I'd be better off using DSP for this instead of what most people would consider a more typical language for this sort of computation?

or some alternaive. Of course. That doesn't say that SVG requires Javascript! SVG doesn't claim to be a language for writing programs, it's just a flavor of XML for describing vector images.

Well of course.

When you say that SVG requires Javascript that sounds like SVG somehow needs Javascript to do what SVG is supposed to do. That's not so in these examples - you're just using the Javascript to specify the input to the SVG engine.

It's certainly true that doing the things you want to do requires both Javascript and SVG, fine. That doesn't say SVG requires Javascript, it says that the things you want to do require both.

The fact that a given tool doesn't attempt to do everything that anyone might ever want to do is a good thing. Modularity.

David C. Ullrich

There is a problem with printf support of long double, otherwise that should work okay:

sizeof long double is reported as 12 (bytes)

Best regards, Spehro Pefhany

You're missing the magic of IEEE 754. :)

It's a 32-bit format with a sign, *24* bits of precision, and an 8-bit exponent field that is biased to represent scales from about

If you were counting carefully, you just counted 33 bits. The trick is, the significand is always normalized whenever possible (and it's possible for all except the tiniest fractions) to be in [0.5,1), so the value of its leading bit is always known to be 1, and *that bit isn't stored*. (The tiny "denormals" are recognized by a distinctive exponent value, and have precisions decreasing from 23 bits to 1 bit as they approach zero, which gives much better coverage of the region about zero than a scheme without denormals.)

-Chap

So it is certainly safe to provide formatting schemes for a seventh decimal output access, and probably useful to provide the eighth?

By a simple truncate, subtract, and recombine?

I'm sure it can. But being a stack-based language (like Forth), PS is inherently backwards for most people, and therefore takes a lot time and thinking to figure it out. I've no doubt that once you are more experianced with the language, you can read it and understand it better.

I only looked at a few random PS articles from near the top of the page - it could quite possibly have been older ones.

To be entirely honest with you, there is no point in including the PS programs at all when they are that compressed - they are not understandable to people who do not have plenty of experiance with PS from before, and I'd be surprised if more than one in ten thousand programmers even thinks of PS as a programming language.

Just to take an example, you give a bubblesort routine in one of your posts

/alphabubblesort2 { /curmat1 exch store curmat1 length

Compare this to a simplistic Python bubblesort:

def bubblesort(xs) : for n in range(len(xs), 2, -1) : for i in range(n - 1) : if xs[i] > xs[i + 1] : xs[i], xs[i + 1] = xs[i + 1], xs[i]

I expect you can follow what's going on pretty clearly there.

Another of your points about PS was that it is "fast", and you described your bubblesort as taking about a quarter of a second for 400 items on a

Of course, the standard Python way to sort a sequence "xs" is to use "xs.sort()", which is much faster - but not as instructive.

I am a great fan of choosing the right language for a job - and PS makes a good choice for some jobs, such as when the output is a diagram. But when you are trying to do fast and accurate maths, there are far better choices.

David Brown wrote: (snip)

In some ways this is even more instructive. I suspect that with postscript you have to reinvent the wheel more often than not. A related issue is code base - just how much PS code can be pulled from the internet to aid you in a programming project? As a somewhat random example - for most languages in common use it is easy to track down libraries for genetic algorithms. I couldn't google up a postscript example (though maybe I didn'y try hard enough). Such algorithms aren't that hard to code and I'm sure that Don with his fluency in PS could whip out a working one in a couple of hours, but it would probably lack the flexibility of a full-fledged library and perhaps those couple of hours could have been used for something else.

Still - it would be fun to learn Post Script. If only there were more hours in a day!

-John Coleman

It's not hard to learn enough PS to be able to make simple images when you need one - all the figures in a certain to-appear-someday book are homemade PS (written by hand at first, then I finally got around to a Python EPS class, made things much easier.)

Otoh the idea that one should do general programming in PS because it's so clear and simple is, um, something I find it hard to argue against...

David C. Ullrich

You have hit on a big area where PS lags other scripting languages: a ready supply of contributed, reusable modules for common tasks, designed and documented for general 'library' use. There's lots of code you can pull from the net to do lots of things, but often in the form of code that solved an author's particular problem but didn't quite get generalized for library purposes, or isn't quite documented enough to be usable without poring over the code, or is offered under murky terms that probably allow you to use it for most purposes unless you have a business or something, or isn't very careful with namespaces so you can't confidently import module A from one author and module B from another author without expecting fireworks - all of those little details that serve as enablers for a healthy growing library collection.

That's really what I am trying to address at the

/net.anastigmatix.Order /ProcSet findresource begin

and say things like

xs comparefn QuickSort % or InsSort, or HeapSort.

A "CPSAN" it ain't - at this stage so far - but an important need is to determine how the language features, chiefly the named resource stuff introduced in level 2, can be used, and with what kinds of coding discipline, to really support a collection of modules that import easily and play well with others, and that's written up on the site, so in principle other PS developers who would like to make library code available could begin doing so using the same conventions, and who knows, maybe someday there could be something like a CPSAN.

-Chap

Each to their own; Me and most of my numbers are trancendental.

Nice website. The link you provided to the Mathematical Illustrations book seems like a nice way for a mathematician like me to learn a bit of postscript. After this thread started I noticed that book on Amazon but wasn't aware that a free online copy was available. Thanks.

-John

The argument that there is no good display PostScript is largely offset by using Distiller to get an image in a second or two.

You are always close to an image even if it is not truly realtime.