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 lower-level 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.

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 mis-typed 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.

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 .

Thanks for the info 'mecej4'! Used to use Fortran (think it was Fortran V) and assembler on a multi-processor 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 re-visiting 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! 😃

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

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 long-winded 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 short-tempered agressive attitude), and I never heard if he survived that.

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 co-workers though this was almost tally useless. Leo Landau told 'mathematicians have no imagination, they all are losers-physicists'.:-). Some people memorize pi or e with 30-40 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 3-4% 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?