
forums.silverfrost.com Welcome to the Silverfrost forums

View previous topic :: View next topic 
Author 
Message 
Don Wright
Joined: 23 Aug 2016 Posts: 11 Location: Telford, Shropshire, UK

Posted: Wed Dec 21, 2016 10:12 pm Post subject: Packing/Unpacking items of info into an integer location 


Can anyone please give me tips on how to pack/unpack items (e.g. binary tree right and left cell pointers) held in a an integer vector array using FTN95 instructions  without resorting to lowerlevel language routines to do logical shifts and XOR, AND, OR type operations with masks, on all the bits in the integer vector element. My efforts so far have all failed!
The reason for trying to cram as much as possible together is that I anticipate the binary tree will have quite a large number of "leaves"  So in the interest of making good use of space, don't want to allocate a vector array for the "left" pointers, and another one for the "right" pointers.
Last edited by Don Wright on Wed Dec 28, 2016 9:53 am; edited 1 time in total 

Back to top 


Don Wright
Joined: 23 Aug 2016 Posts: 11 Location: Telford, Shropshire, UK

Posted: Wed Dec 28, 2016 9:46 am Post subject: Packing/Unpacking items of info into an integer location 


Found the answer to my little problem  in reference book "Modern Fortran Explained" on pages 172/173 under the heading "elemental functions" it describes exactly the functions I need. I was a bit wary because the book does describe some facilities that are only available in Fortran versions after FTN95. However was delighted to find that they are available in the "Silverfrost" version. The most useful functions for Packing/Unpacking items of info into a single integer location, seem to be : 
iand(i,j), ieor(i.j). ior(i,j) and ishft(i,shift) ... [N.B. that function name is NOT ishift as I initially mistyped it! Also, the value of the shift argument must not exceed the returned value from the enquiry function bit_size(i)  another possibly useful function!]...  where i and j are integer locations (i being the location of interest and j some mask e.g. j=b'11111111111111110000000000000000', The shift argument is also an integer  positive for left shift or negative for a right shift  with zeros feeding in at "either" end. For 2 items to be stored in an integer location, the shift value is 16. 

Back to top 


mecej4
Joined: 31 Oct 2006 Posts: 1096

Posted: Wed Dec 28, 2016 11:01 am Post subject: 


The bit operation functions (and some other features) are part of the "Military Standard" additions to Fortran 77. See, for example, http://www.fortran.com/mil_std_1753.html . 

Back to top 


Don Wright
Joined: 23 Aug 2016 Posts: 11 Location: Telford, Shropshire, UK

Posted: Wed Dec 28, 2016 6:49 pm Post subject: Packing/Unpacking items of info into an integer location 


Thanks for the info "mecej4"! Used to use Fortran (think it was Fortran V) and assembler on a multiprocessor DEC system some 20 years ago before I retired (yeah that dates me a bit, 80 y.o. now  hence the odd username  just a hobbyist revisiting some old ideas to keep the brain active). At the time, I had to use assembler routines to fill the gap of not having "bit" facilities available. The introductory "screed" with the SilverFrost version didn't mention such a thing  so I was wondering what to do, till I found the answer! 

Back to top 


mecej4
Joined: 31 Oct 2006 Posts: 1096

Posted: Thu Dec 29, 2016 1:07 am Post subject: 


There are quite a few of us oldtimers who post on comp.lang.fortran (Usenet) and a couple in this forum, including myself. As someone who processed experimental data using logtables, then with a sliderule, followed by the then revolutionary computers, I appreciate your sentiments. I think that we can benefit from your experience, so please keep posting! 

Back to top 


Don Wright
Joined: 23 Aug 2016 Posts: 11 Location: Telford, Shropshire, UK

Posted: Fri Dec 30, 2016 9:42 am Post subject: Packing/Unpacking items of info into an integer location 


Re the comment about log tables and slide rules (I still have my old one!). At college we had a maths teacher who had memorized the log tables  and often showed his prowess by chalking up on the board the answer to some longwinded arithmetic calculation, while we were still fiddling with our slide rules! He really humiliated me in front of the rest of the class at my very first efforts to plot some trig function  so I didn't get on with him initially  but he softened towards me when we discussed vector analysis, dyadics and relativity a year or so later. Sadly, he developed a brain tumour (maybe that was partly responsible for his shorttempered agressive attitude), and I never heard if he survived that. 

Back to top 


DanRRight
Joined: 10 Mar 2008 Posts: 1935 Location: South Pole, Antarctica

Posted: Sat Dec 31, 2016 12:05 am Post subject: 


I also used my own tables at some point but that was for EXP(x). That was due to crash associated with standard EXP. The reason for crash was unclear for a long time until it was found that this compiler does not like some argument x range which produces so called denormal numbers and due to that crashes sometimes and in other circumstances always. The workaround is just to restrict x (better with double precision) so that you can return to standard EXP.
It is great that the math teacher memorized LOG tables to impress his students and female coworkers though this was almost tally useless. Leo Landau told "mathematicians have no imagination, they all are losersphysicists".. Some people memorize pi or e with 3040 or more digits. Also totally useless. Even computer does not need that because for programs much better to use PI=4*atan(1.). I just for fun keep in memory e= 2.718281828459045 which is mnemonically done by memorizing 2.7 and adding year when Leo Tolstoy was born 1828 twice and 45, 90, 45 at the end which kind of "rhymes". Or PI=3.14 15 92 65 35 89 79 which all consist out of 2 digits of birthdays of some people and rhymes a bit too.
For fast math estimations of course you literally must remember few LOG and EXP numbers. These have to be ready even in the middle of the night sleep: log (7)~2,. log (20)~3, log (150)~5, log (1000)~7, log (20000)~10
Hopefully math teacher had other USEFUL math tricks worth for real life. For example rule of 70 or also called rule of 72. If you for example hear that China's GDP is larger then US by approximately 7% that immediately tells you that in 10 years its GDP will lead US exactly by the factor of exp(0.07*10) = exp(0.7) = 2. And again by the 2 in one more decade. You then conclude that the West at that time will be over. This is by the way tells WHY Trump.
Or the same rule tells you immediately why it took ~130 years from US revolution to establish Federal Reserve Bank in US. This is because 34% maximum 5% is the rate of growth which you will not notice. And starting with 1% of money in their hands initially the bankers had eventually hiddenly ended controlling exp(0.04*130)=exp(5) ~ 100x more or ALL the money of US population by 1913 and quickly (because of two wars and depressions and recessions with hyperinflation) controlling the whole world money after that.
Can you or anyone else share other tricks of fast estimations? 

Back to top 




You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum

Powered by phpBB © 2001, 2005 phpBB Group
