handling large character arrays
in [Fortran]
|
From: e p chandler on 21 Apr 2010 22:04 "Richard Maine" <nospam(a)see.signature> wrote in message news:1jhb9j0.jfrt8o1unhkhsN%nospam(a)see.signature... >e p chandler <epc8(a)juno.com> wrote: > >> <analyst41(a)hotmail.com> wrote in message >> news:24f1b2ab-86b6-4518-932b-fd48f901ead4(a)w16g2000vbf.googlegroups.com... >> >I need to keep in memory an array of around 60000 character variables, >> > each element of which can have a max length of 4000 byres. But if you >> > add up the lengths of all the actual data values, it is only 1/8 of >> > 60000*4000. >> > >> > What would be the cleanest way to store this data to take advantage of >> > this fact? > >> How about an array each of whose elements is a derived type. One >> component >> is an integer that specifies the string's length. The second is an >> allocatable array of single characters. > > Why the redundancy of the separate component for the string length? The > allocatable already stores the length, so you are just replicating that > by also making the length a separate component. > ... Probably because I was thinking about (non-standard) Pascal. [smile] I see now that I can use size() instead. >> curr_len = len(trim(in_buff)) >> if (curr_len == 0) exit > > My nose for potential bugs detects two of them here. This assumes two > things. Both assumptions might be correct, but I tend to think it good > to make such assumptions explicit. Otherwise, you are likely to find > that the user of your code doesn't share your assumptions, which asks > for bugs. > 1. It assumes that trailing blanks are insignificant. Maybe they are, > maybe not. Nothing in the problem statement specifcally said they were. > If I were actually writing real code in response to such a problem > statement, I'd ask before just assuming this to be so. And I'd document > the assumption in case things changed in the future (or in case the > person who told me that the blanks were insignificant was wrong.) Just a convenient way of setting the length to something. > 2. It assumes that a length of 0 is invalid. Again, nothing specifically > said that. Note that it is perfectly legit in f90 and later to have a > zero-length string. (It wasn't in f77). Just a convenient way of exiting early from my test program. OK. But please distringuish the mechanics of my test program and its assumptions from what it was trying to demonstrate. I do think that I would make a production program more robust! --- e
From: e p chandler on 21 Apr 2010 22:26 "Jim Xia" <jimxia(a)hotmail.com> wrote in message news:36f14b04-a900-4508-8eb6-ef511d46acb3(a)q23g2000yqd.googlegroups.com... > OK, for the sake of the completeness, let's see my version of my_prog: > > > > > module my_mod > implicit none > > type string > character(:), allocatable :: str > end type > end module my_mod > > > program my_prog > use my_mod > implicit none > integer,parameter :: max_buff_size = 4000 > integer,parameter :: array_size = 60000 > character(max_buff_size) :: in_buff > > type(string) :: the_memory(60000) > integer i, whatEverUnit > > do i = 1, array_size > read (whatEverUnit, '(a)') in_buff > the_memory(i)%str = trim(in_buff) > end do > > end program my_prog > > > > Cheers, > > Jim Nice. Sorry I don't have a compiler that handles full F2003. (g95 and gfortran don't).
From: e p chandler on 21 Apr 2010 22:33 "Richard Maine" <nospam(a)see.signature> wrote in message news:1jhbaje.16a5g3wqyqr7wN%nospam(a)see.signature... >e p chandler <epc8(a)juno.com> wrote: > >> "Jim Xia" <jimxia(a)hotmail.com> wrote in message >> >> > module my_mod >> > implicit none >> > >> > type node >> > integer :: len >> > character, allocatable :: char(:) >> > end type >> > end module my_mod >> > >> >> How about this >> >> type string >> character(:), allocatable :: str >> end type >> >> You don't need the len variable. len(node%str) will be that value. >> >> ---> len() returns a value of 1. Do you mean size()? > > No, he means len. If len returns other than the correct value, report > the bug to your vendor. Allocatable character length being one of the > f2003 features last on the implementation list, it could well be that > your vendor has such a bug... but it would be a bug. > > Size is quite irrelevant. Your compiler shouldn't even allow > size(node%str) in Jim's example, as it isn't an array. If your compiler > allows that, there's another bug to report (and a more surprising one). > > Your example uses an array of characters (I missed that at first), but > Jim's uses a character string instead. They are different. Yes. I only saw his more complete program after reading your reply. My test program was difficult enough, for me. > Note also the handy way that Jim's example (in his subsequent followup) > nicely uses the f2003 allocate-on-assignment feature. I think it nicely > illustrates the cleanliness you can get from using allocatable character > length and that feature. Nice. I wish I had something that would compile it. (g95 and gfortran don't).
From: robin on 24 Apr 2010 19:55
"Gordon Sande" <Gordon.Sande(a)EastLink.ca> wrote in message news:2010042210081316807-GordonSande(a)EastLinkca... | Listing the desired operations is very good. The tough one here is | finding elements with a given substring. Using the linear model suggested is trivial using INDEX The pointers identify the individual strings, and a separate search is carried out for each string. | The suggestions that have | been given have basically been directed at symbol tables which | will match whole entries. There are fancy schemes for searching | large strings for specified substrings. Searching a bunch of smaller | strings may well have different tradeoffs. It is the stuff that one | can find in some advanced algorithms books. I believe that the folks who | do the Oxford dictionary (I am sure there are others but I do not follow | such things) have multiple papers on their advanced methods. Us mere | mortals have to trust the various "grep" libraries for the few times | the text manipulation problems go beyond symbol tables. |