There are no awkward trial codes or timeouts. Thirdly many personal users who could never afford Silverfrost Fortran can now use it. You can of course buy an unrestricted licence. Who can use it? You can use it at home for your own personal use on your own PC. You can also use it in a commercial or academic environment for evaluation purposes. You can if you use it on your own PC or laptop. If you wish to use FTN95PE on an educational establishment's equipment then you must buy an academic licence.
What are the differences from the full product? There are of course restrictions on the licence. I compiled my program with Silverfrost Fortran but it seems to run slowly, why is that? Using the continued fraction to calculate erfc x at large x'ssimilarly requires a vast number of bit of precision, but not as many.
It looks like this is going to be so slow for large x that I'm goingto have to use a compiled arbitrary precision library instead of myhacked python version. I got the new test program running on ox. I had to adjust ox's fansettings, too. The motherboard willautomatically go to the next highest setting when the CPU's get hot,but for some reason, only one setting. About a minute into the run, Iget the beeping that indicates overheating.
At the next highestsetting, the fan automatically bumps up to the next setting whichappears to work. I ended up with a 12x speedup instead of the 20x that I had hoped for,but the total elapsed time is short enough to keep testinginteractive. The granularity is one cpu per test directory, whichworked fine once I put the largest directories first. The other wayof doing this, a per-file granularity would be much more complicatedsince some files have to be compiled to create required modules.
After a little fiddling, it looks like all of this complication wouldonly result in saving about twenty seconds or so, which isn't worth it. In the ongoing project for computing erf , it turns out the bestway to compute erf on certain intervals is as 1-erfc. There are acouple of common series for computing erfc , but none of thempractical, as far as I can see-- they call for evaluating factorialsof half-integers. This isn't for evaluating erfc within the library, this is forevaluating erfc in order to fit a rational approximation to it.
After casting around for another way, I hit on evaluating upper andlower gamma functions which lead straight to erf and erfc viacontinued fractions. I'd sort of wondered for years how you actuallyevaluate a continued fraction, and it wasn't long until I got Lentz'salgorithm working.
In this method, you pass a generating function to the Lentz evaluationsubroutine. This subroutine calls the generating function with aniteration number and the generating function returns a pair of numbersthat are the numerator and summand of the corresponding denominator.
The Lentz evaluator keeps asking for more terms until the fractionconverges. Slick, but a little complicated when it comes to writingthe generating function. Several bugs that people have been reporting are regressions againstearlier versions of g Regressions are always something I have towatch out for. For a long time now, I've haven't been very good aboutrunning the test suite. After giving the matter some thought, Irealize that this is because it takes way too long to run.
Right now, the suite runs on the laptop that I use for g95, a 1. The plan is to move it to ox, my quad core Xeon. I'veseen a speedup by a factor of five for the python program I've beenusing for the floating point library work, and with ox's fourstomachs, I'm hoping for a factor of twenty. I've written about lines to make the testing program multicore, inthe same way as the build script.
Now I have to debug it, and it'salways a pain to debug child processes where the standard descriptorshave been redirected. Got Remez's algorithm working. Turns out the 'e' in the prior post isnot an input, it is an output. You take one more x and solve for e aspart of the linear system. This make a lot more sense. You get an eout that gives you a ballpark idea of how good the approximation is.
The method isn't perfect in the sense that if pushed too hard, therational approximation will get an extra oscillation on the edge faroutside the desired tolerance. You have to check the finalapproximation, but it looks like the basic algorithm will workfine. There is a neat trick buried in glibc that I've appropriated for thiswork. Viewed as an integer, real numbers have the sign bit as themost significant bit, followed by a biased exponent, followed by themost signficant bits of the mantissa.
If you load the top word of areal number as an integer, you can do integer compares to determine ifa number is a not-a-number, infinity, or even compare with numbersthat have bit mantissas. This was meant to simplifycalculations in hardware, but there is nothing to stop us from doingthe same thing with software.
You can't compare for equality withoutcomparing all the low bits of the mantissa, but you can get a sort of'lower bounds' comparison, which works fine for figuring out whichinterval to use. Tony Mannucci pointed out that the debug symbols were still present inthe libf These aren't a lot of use to the end user, andtake up about a megabyte, so I added a line in the build script tostrip the symbols.
Doug Cox has built some new windows builds. Arjan van Dijk had aproblem with library paths on windows that Doug has fixed. I have continued to make sporadic progress on the extended and quadprecision transcendental functions. I have Remez's algorithm almostworking. I think I'm having problems with poles, though. A lot of transcendental functions are implemented by rationalapproximations over various intervals of the functions in question. These look something like:.
Which can be tuned to the function be approximated-- in my library q0is always one, and you can specify which p's and q's are zero upfront. I can get a straight polynomial approximation by not using anyq's. If you pick a set of as many x's as you have unknown p's and q's, inthe interval that you are approximating the function over, you get asystem of linear equations that you can solve for the p's and q's. Where do the x's come from? Since this is a library for lots ofpeople to use, we want the best approximation possible and a standardway to go is to minimize the maximum error, the minimax solution.
By construction, the approximation is equal to f x at the x's thatyou pick, and R x oscillates between too big and too small in themiddle.
There is a theorem that says that you've got the minimax solution whenthe values of the maximum deviations R x - f x are all the same. If the deviation is always less than e, then you've got somethingthat will approximate the target function to precision e. Remez's algorithm picks an initial set of x's, fits to get the p's andq's and finds the x's of maximum deviation.
These points arebracketed by the original x's, so something like a golden search Brent's method can be started right away. Once you've found where the maximum deviations are, use these for thenew set of x's. The x's are supposed to convergequadradically, which isn't happening for me yet.
Once I get this machinery in place, the work will be much more of aturn-the-crank operation: find the best approximation, implement it,repeat. One required component of doing something like this is high precisionarithmetic. How do you test sucha thing?
I've taken the time to write an arbitrary precision floating pointlibrary in python. Like the one in C buried inside g95, it uses bigintegers as its basis. There is no particular reason for speed, soit's better to write something that is easy to read and maintain.
Thebasics: addition, subtraction, multiplication, division and comparisonare done. I spent a bit of today writing a subroutine that takes oneof these numbers, rounds it to a bit mantissa number and generatesan assembler initialization expression for the number, ie somethinglike:. After I get this going,I'll end up creating programs for each of the transcendentals thatneed to be done, for both implementation and testing.
Added that. Both x86 and ppcversions are supported. Took my own advice, and deleted everything, starting over. Ran rightinto the same problem, though. After some investigation, the problemturned out to be some apple hackery trying to make C string functionssafe. Disabled that. Now things work fine. Although the old version is archivedjust in case.
OSX always requires exceptions, special cases andoutright hacks to get it working right. Not totally sure where the problem is, but I suspect that theway to handle this one is to delete what I've done and start over. John Harper sent in a typo in the manual that has been fixed.
He'salso pointed out the need for a serious revision. The weird corner case was thesingle image case. Jun Chin Ang sent in a question on real loop variables, and inpreparing a reply, I discovered a crash on real loops variables,having to do with the recent fix to loop variable types.
Fixed now. Don't use real loops, though. I guess I've completed the desktop upgrade-- I finally put its skinback on, put it back into its cubbyhole and have resumed regularbackups. No big message, I justwanted to encourage your efforts. The problem with thecrash in the options processor looks like it has been fixed.
John Reid reported that his SMP coarray problem went away. Reinholdhad success on ia64 and x I'm very happy. A hard debug sessionthat produces results is always very satisfying.
I spent a some time porting some of the recent fixes to SMP coarraysto the nascent windows version. The code is similar in some ways, butsome fixes just don't apply because of the wildly different approachesthat have to be used. Reinhold send in a coarray crash on ia64 that has been fixed. Thiswas a nasty bug to find.
The debug linenumbers are way off, somehow, reducing the debugging to printstatements. But after a couple dozen tries, I found it. We're hopingthis fix will fix another bug reported by John Reid. Larry Wetzel, George Madzsar, Xavier Leoncini and most of the gg95newsgroup have seen a problem with the windows versions dealing with acrash in the options processor.
Doug and I have been fiddling withthis for a few days now. I caused it when I tried to remove adeprecated option -I-. Although half of the effects of -I- aredoable with -iquote, that isn't the property of -I- that I was relyingon. I think I've got a workaround for the problem, fingers arecrossed. Doug seems to have fixed the problem manually, new buildsare up. Doug Cox has built some new debian builds. We've been working on acrash in the options handling introduced the other day when I finallygot rid of the -I- in the builds without really remembering why it wasthere.
I think it was for the windows build, but the option isdeprecated in favor of -iquote, and it's time to move on. I got a neat new script working for the first time. I was working onanother bug that eluded me today. The bug apparently only bites onbit machines, so I wanted to use ox for testing.
Problem was, Iwasn't actually at home. I'd run into this problem the other day, soI had my wake-on-lan script ready. The way this works, you open asocket and send a broadcast packet that contains the MAC address ofthe machine you want to wake up in a special format.
The targetmachine is mostly asleep, but when the network interface reads thepacket with its own MAC address, it wakes the rest of the machineup. The reverse command, is of course, 'poweroff'. I heldoff on making this change, but J3 has since taken a vote that freezesthe whole draft more than what it was. I've gone ahead and made theswitch. The changes extend internally from the compiler to thelibraries. It turned outthat the x86 build was building against the libraries on my desktopsystem.
It didn't suffice to compile against an old library, thenewer compiler generated a dependence on the newer glibc. So I endedup compiling an older version of gcc and building what was essentiallya cross compile environment for the older library. The new build environent is the old environment. Instead of copyingheaders and library from the old system, I ended up copying files fromthe old backups, since the old opensuse 10 is on a toasted disk.
Ireally hate pointless upgrades, and hate to force others to upgradewhen unnecessary. The most notable thing about the old compiler is how fast it is. Gcccontinues to bloat, and with bloat comes sloth. No one notices thisbecause machines are faster. Reinhold Bader and John Reid sent in a problem with allocatablecoarrays, turned out to be two separate problems.
Michael Richmond caught some debug code that had been left in fromReinhold and John's bug from the previous night. This was a tough bugto track, since the problem reared its head only after enough imageswere enabled. The debug code is gone. The bit debian buildis broken at the moment. We are investigating. The IEEE module have a series of intrinsic derived type for variouskinds of numbers, etc. Yuri Sohor sent in an illegal coarray code-- he had a derived typethat he was assigning across images.
On a regular code, this causesallocations to be copied. On a coarray code, this would have beenhideous to implement. It turns out to be legal to pass aroundderived types that contain pointers, but the pointers are consideredto be undefined on different images. I've replaced the reporting of signal numbers on a crash with signalnames for the more popular signals.
Michael Richmond sent in a regression involving subroutine calls. Theproblem was the recent fix to calling host associated procedurepointers.
Got it all fixed now, I hope. Reinhold Bader sent in a bug with the deallocation of allocatablecoarrays that has been fixed.
This was the same bug I was working onwhen my hard disk started its death-rattle. It's actually quite agood thing that a disk starts making noises before it fails.
Alsofixed a problem the allocation of coarrays in derived types. Predictably, today was mostly spent working on getting g95 building onthe laptop. I've removed the -I- directive in the build-- I can nolonger recall why it was there, and it seemed to mess up finding thesystem include files.
The real struggle was getting the library tobuild. I'd have thought this would be easier because the configuationscripts are more straightforward. But of course the versions ofautoconf have changed and subtle changes were apparently required.
I'm finally back to development. A long struggle today to get the wireless card on the laptop going. My laptop has an internal wireless card that has never worked, evenunder windows.
Turned out that was interfering with the pcmcia card. The windows side downloaded another set of updates, bringing me backup to SP3. It's a weird thing to apply the updates and see that thereare The upshot is that the laptop is ready to host g95 again. I like itthis way because I can work on g95 even without a connection to thenetwork.
If I do have a network connection, I connect to my desktopvia the vpn to access mail. I'm also going to use the opportunity to migrate some things back tothe desktop, like my lilypond files. The laptop has the worstdisplay, and is consequently the worst place to do music engraving.
I'm toying with the idea of not even installing X windows. Been sick all weekend. To add insult to injury, I've been back toupgrade hell, this time with the new disk. This time was worse,because I use the laptop as a dual boot system with windows and linux. Spent yesterday in my reduced capacity trying to install windows. The laptop came with OEM installation disks for windows. Because thedisks are OEM, they weren't particularly polished, and thepartitioning part didn't work.
Because I have the arch linux disk, Icould easily look and set the partitions. The OEM would install,finish, reboot the system I tried and tried and tried. Half an hour to go through the whole3-CD install and I must have done it a dozen times.
The key was therealization that the installation software expected an NTFS partitionand wouldn't even mark it bootable after it ran. Ergo, the OEMsoftware expected the partition to already be in a particular state,more than just a bootable flag. I ended up installing an even olderwindows , to where it would boot itself, then wiped it with theOEM XP.
It worked-- win2k must have installed a part of the bootstraploader that the OEM installed wasn't. Of course, once windows is going, it's time to get unix going. Thereason is that unix can live on other partitions and its installertakes care of snarfing up the windows boot code, doing the dual bootthing.
The Arch Linux installation wentsmoother than usual, the third time being the charm. Arch does havethis problem with downloads getting stalled and being downright passiveabout retrying stalled downloads.
After the nth try, I got the basicinstall done. The nasty surprise was on the first boot. The kernelcame up, the first couple of items in the initialization scripts ran,the screen went blank and stayed that way. Now this was a fine pickle. The only way to go from here was to bootfrom the CD, mount the drive, edit the startup scripts and reboot. The CD wasn't real reliable on the laptop, making the whole processvastly more irritating that it would normally have been.
Thoughtabout giving up, but the CD worked fine, if the laptop saw it. Eventually tracked the problem to something in the udev demon. Aftersome head-scratching, I guessed that udev was forcing some buggymodule to load. After guessing wrong with some manufacturer-specific modules, it hitme-- if the screen is going blank, the problem must be in a screendriver.
But how to list modules on a system without a screen? Why,over the network of course. Small problem, though, the base installdoesn't include things like sshd, and you can't see what you'retyping, so you can't log in remotely! So, how to fix that. Turned I out I had a copy of the telnetd sourcecode. It's small, about 2k lines of C. Compiled it on my desktopsystem, scp'ed it up to the g95 website. Loged into the laptop,blindly, carefully typed a wget command, then chmod it to make itexecutable, then run it.
Try telnet from the desktop and whattayaknow, it worked the first time. Login as root, permission denied. Gotta love these modern security measures.
The only way aroundthat one was a user account. Had to create a user account on thelaptop, typing blind again. With a working telnetd, I finally got to do an lsmod, and it turnedout that there was indeed a display driver, i being loaded. Iblacklisted the module and things worked a lot better. It wasdownhill after that, just regular installation of things that aren'tthere. No Do I need to know about Microsoft. Visual Studio , , and - including Community Editions I have my own editor and just want to use FTN95 from a command-line Silverfrost Fortran FTN95 version 8.
Also includes support for Visual Studio and an enhanced bit debugger.
0コメント