Here is my code:
character (len=60),dimension(5) :: vars3dDiag
print *, findloc(vars3dDiag,value='QRAIN',dim=1)
print *, findloc(vars3dDiag,value='P',dim=1)
I am expecting the code to print out 3 and 5 but it prints out 2 and 4. It seems like for character array, it does not search for the exact match. It returns the index as long as the searched string is a substring of the item.
Yep - that's a compiler bug! One of the Intel folk here should pick it up. I reproduced it in the latest compiler, and verified that the NAG compiler does what you expect. I also reviewed the standard and NAG does the right thing.
The latest IFX compiler goes astray when given this code.
S:\LANG>ifx hua.f90 Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2021.2.0 Beta Build 20210317 Copyright (C) 1985-2021 Intel Corporation. All rights reserved. #0 0x00007ff6c48da875 (C:\LANG\OneAPI\compiler\latest\windows\bin\xfortcom.exe+0x2ca875) #1 0x00007ff6c48da84a (C:\LANG\OneAPI\compiler\latest\windows\bin\xfortcom.exe+0x2ca84a) #2 0x00007ff6c4811880 (C:\LANG\OneAPI\compiler\latest\windows\bin\xfortcom.exe+0x201880) #3 0x00007ff6c48e71c9 (C:\LANG\OneAPI\compiler\latest\windows\bin\xfortcom.exe+0x2d71c9) #4 0x00007ff6c48e707d (C:\LANG\OneAPI\compiler\latest\windows\bin\xfortcom.exe+0x2d707d) #5 0x00007ff6c48e4beb (C:\LANG\OneAPI\compiler\latest\windows\bin\xfortcom.exe+0x2d4beb) #6 0x00007ff6c47ffe10 (C:\LANG\OneAPI\compiler\latest\windows\bin\xfortcom.exe+0x1efe10) #7 0x00007ff6c47feb4f (C:\LANG\OneAPI\compiler\latest\windows\bin\xfortcom.exe+0x1eeb4f) #8 0x00007ff6c48e1e42 (C:\LANG\OneAPI\compiler\latest\windows\bin\xfortcom.exe+0x2d1e42) #9 0x00007ff6c48b5755 (C:\LANG\OneAPI\compiler\latest\windows\bin\xfortcom.exe+0x2a5755) #10 0x00007ff6c49068a6 (C:\LANG\OneAPI\compiler\latest\windows\bin\xfortcom.exe+0x2f68a6) #11 0x00007ff6c4905919 (C:\LANG\OneAPI\compiler\latest\windows\bin\xfortcom.exe+0x2f5919) #12 0x00007ff6c490266c (C:\LANG\OneAPI\compiler\latest\windows\bin\xfortcom.exe+0x2f266c) #13 0x00007ff6c49248cb (C:\LANG\OneAPI\compiler\latest\windows\bin\xfortcom.exe+0x3148cb) #14 0x00007ff6c4924f0d (C:\LANG\OneAPI\compiler\latest\windows\bin\xfortcom.exe+0x314f0d) #15 0x00007ff6c4927552 (C:\LANG\OneAPI\compiler\latest\windows\bin\xfortcom.exe+0x317552) #16 0x00007ff6c49248cb (C:\LANG\OneAPI\compiler\latest\windows\bin\xfortcom.exe+0x3148cb) #17 0x00007ff6c4921afd (C:\LANG\OneAPI\compiler\latest\windows\bin\xfortcom.exe+0x311afd) #18 0x00007ff6c49248cb (C:\LANG\OneAPI\compiler\latest\windows\bin\xfortcom.exe+0x3148cb) #19 0x00007ff6c47ea9ab (C:\LANG\OneAPI\compiler\latest\windows\bin\xfortcom.exe+0x1da9ab) #20 0x00007ff6c47ea21a (C:\LANG\OneAPI\compiler\latest\windows\bin\xfortcom.exe+0x1da21a) #21 0x00007ff6c4964923 (C:\LANG\OneAPI\compiler\latest\windows\bin\xfortcom.exe+0x354923) #22 0x00007ff6c67b3008 (C:\LANG\OneAPI\compiler\latest\windows\bin\xfortcom.exe+0x21a3008) #23 0x00007ff865317034 (C:\WINDOWS\System32\KERNEL32.DLL+0x17034) #24 0x00007ff865802651 (C:\WINDOWS\SYSTEM32\ntdll.dll+0x52651) hua.f90(8): error #5533: Feature found on this line is not yet supported in ifx print *, findloc(vars3dDiag,value='QRAIN',dim=1) ---------^ compilation aborted for hua.f90 (code 3)
I load module intel/2020.2 on our server and use ifort compiler. I noticed the function findloc is not available in earlier versions of ifort compiler. I simply want to use findloc along with type statement to achieve similar functionality as dictionary in python.
Many moons ago when Ronald Reagan was president - I had a bunch of fellow workers who wanted to use names as indices. It is a really bad idea as people spell stuff differently and use different words for the same thing, particularly if you are changing locations.
Classic Example, one of the most advanced Water Authorities in the world is Hunter Water in Australia. They used the term man hole and then as was typical for the time, changed in to maintenance hole, so the MH on the database and the drawings remained the same, but it caused some interest outside. It is much easier and safer to assign a number to a thing, so a man hole maintenance chamber anything that provides direct access to a live sewer big enough for a human I labelled 21. Actually I got the Chief Draughts person to give a me a list and it only had 120 entries for all the things in the average sewer drawing.
I would use a number for the type descriptor and not a name.
Dictionaries are nice if you want to create a huge data object and pass it to a thread, short of that they are not worth the pain.
I guess everything has its minuses and pluses. But I find it personally that the pluses of dictionary functionality outweighs the minuses, especially for querying datasets.
In terms of the Bob Hawke comment - if you cannot say something nice about Fortran etc... Dr Fortran taught me that.
I understand your comment on dictionaries, yesterday I struggled with a single element of a dictionary that kept getting lost.
Luckily we live in a world where choosing Fortran is not a bad choice.
A couple of comments:
>>the Chief Draughts person...
Is that the person at your local tavern in charge of dispensing beer?
>>I would use a number for the type descriptor and not a name.
Do you do the same for your subroutine names?
Kidding aside, a label such as 21 would require a list of annotation descriptions... (aka foot notes).
" 16" " 354041.0222" "1339059.4229" "-10000.000" "5768" " " " 0" " 0.0000" " 0.000" " 0.00"
So back in 1988 in Fortran, I had a client that had to design rising mains and they were drawing them by hand. They wandered in one Friday and said - can you draw on the computer - we had Autocad V2.17f. - paths did not exist in DOS.
I said yes, stupidly and in a weekend using a Compaq Portable Computer, which I am not allowed by Intel to describe it in any other fashion and MS Fortran 3.31 or 3.03 not sure, I created a program called Helga is attached.
Helga draws in DXF Format - the old version of DXF is excellent - new one is a beast,. here is a sample printout, it is basic but this is 1988 and there are no design programs beyond AutoCAD. I enclose the Fortran program it still compiles and runs, I updated it a bit in 2014 just for fun.
In thos days I used Common blocks - remember this is F77 and a 640 K limit.
C **************************************************************** C SUBROUTINE PLOT C C **************************************************************** COMMON /GROUPX/ CHAIN(2,300) COMMON /GROUPZ/ NDRAW READ(1,*)NDRAW WRITE(*,*)NDRAW IF (NDRAW .LT. 4 ) THEN CALL PLOT1 ENDIF END
And here is the program -- it was good in its day --
I name all of my programs for Greek or Norse Gods - names are unique
Texteditor for example in lisp is not unique there will be a lot them
So we were offered a chance to do sewer design - say 30 km at a time to a very tight schedule and for almost no money.
So I developed a program that could design sewers. I did not want to re-enter all the survey data from the plans and the Surveyor could not give us bases to the correct format and I automated the design.
The surveyor has a survey program that gave data in the following format
Easy to code in the sewer models and automate design. Then the Survey package Co changed the format and I had to get them to put it back.
To finish off Jim's thoughts, I went looking for the old list of numbers I used. It is in a Lotus 123 file with an ending wk3. You can no longer easily open these files, but I found Lotus 123 For Windows 95 and it runs nicely, so I could open and save as a CSV file.
The list shows the original codes for a poor area near Newcastle and the subsequent code list we needed for a richer city area in Melbourne. You can describe most urban areas with about 120 common codes.
Interestingly Lotus installs in a Lotus dir on C:\
For those who wonder at the list - wonder no more.