Hmm, never heard of it...
Yes, DPS sounds like it was a great idea. But I don't see how this has anything to do with my question. DPS is an example of a computing system using PS for display, not an example of using PS to do computations. Or at least that's how it looks to me, based on my extensive 30-second study of DPS. ???
SVG requires Javascript?
Surely you're confusing SVG with the way some particular program happens to implement SVG. Or something.
David C. Ullrich
DPS had many interactive features and also a general-purpose computing language. Put all that together and it's pretty sweet for the late 80's or early 90's. Problem was, while it could do general-purpose computing it could not really do general-purpose I/O, notably network I/O. And as I stated elsewhere, the fact that it's already a typesetting language might have taken us even further from the "text plus markup" concept that should (but doesn't) rule the web.
Doing clever interactive or computational or network things in SVG requires Javascript. SVG without Javascript supports some animation characteristics but not enough to do the I/O to make real time animated maps, for example.
Don't get me wrong, I've done some very very clever things with Javascript embedded in SVG running in a browser that are unapproachable using any other method. I just hate Javascript with a passion of the "love to hate it, must hack it to conquer it" flavor. As opposed to good languages that don't require hacking/conquering but are simply grokked. (And see my reply to Don where I point out that I have abstracted my hate to the level where I don't write the Javascript, but use a program to write the Javascript!) The fact that it all usually sits in a browser window is mildly irritating too but it's pretty close to a universal multi-platform medium.
Tim.
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.
-- Many thanks, Don Lancaster voice phone: (928)428-4073 Synergetics 3860 West First Street Box 809 Thatcher, AZ 85552 rss: http://www.tinaja.com/whtnu.xml email: don@tinaja.com Please visit my GURU\'s LAIR web site at http://www.tinaja.com
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
-- "it\'s the network..." "The Journey is the reward" speff@interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com
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.
-- Many thanks, Don Lancaster voice phone: (928)428-4073 Synergetics 3860 West First Street Box 809 Thatcher, AZ 85552 rss: http://www.tinaja.com/whtnu.xml email: don@tinaja.com Please visit my GURU\'s LAIR web site at http://www.tinaja.com
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
32-bit IEEE float be possible. Slight loss of precision might be acceptable in the conversion, but a large change in bit width would result in large sets of values whose conversion would have to throw /undefinedresult, and that's not so good.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
1e+38 PS>2 mul PS>stack 2e+38 PS>2 mul %%[ Error: undefinedresult; OffendingCommand: mul ]%%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
1.0 1.0Here 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 =
1065353217 1065353216So yes, they are just barely distinguishable, and:
PS>1.0 dup dup 1 24 bitshift div add PS>realtointbits = realtointbits =
1065353216 1065353216are 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.
-- Bye. Jasen
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.
-- Many thanks, Don Lancaster voice phone: (928)428-4073 Synergetics 3860 West First Street Box 809 Thatcher, AZ 85552 rss: http://www.tinaja.com/whtnu.xml email: don@tinaja.com Please visit my GURU\'s LAIR web site at http://www.tinaja.com
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
-- "it\'s the network..." "The Journey is the reward" speff@interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com
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
2^(-2^127) to 2^(2^127).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.)
24 lg2(10) is about 7.22, so we're talking not-quite-8 decimal digits. In some cases of course the eighth digit will match the true result.-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?
100 times more precision, while not stunning, can be most useful in certain apps.-- Many thanks, Don Lancaster voice phone: (928)428-4073 Synergetics 3860 West First Street Box 809 Thatcher, AZ 85552 rss: http://www.tinaja.com/whtnu.xml email: don@tinaja.com Please visit my GURU\'s LAIR web site at http://www.tinaja.com
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
1 sub -1 1 {curmat1 0 get exch 1 exch 1 exch {/posn exch store curmat1 posn get 2 copy lt {exch} if curmat1 exch posn 1 sub exch put} for curmat1 exch posn exch put } for curmat1 } bind storeCompare 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
800 MHz cpu. At a rough estimate, my cpu is around 4 times faster than that. My Python bubblesort implementation takes 30 msecs for 400 items, making it twice as fast, and that's without giving any thought to speed during the implementation. In cases where speed is important, Python has a very nice trick - the "psyco" optimiser. Simply calling "psyco.bind(bubblesort)" results in a ten times speed improvement.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.
-- JosephKK Gegen dummheit kampfen die Gotter Selbst, vergebens. --Schiller
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
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.