I'm converting a rather large old fix-format code written in Fortran 77 to free-format. Within the code I frequently encounter read statements like
DOUBLE PRECISION :: VARIABLE
read(1,10) VARIABLE
10 format(2A10)
However, what it reads from input file is in fact a line of string. The code runs perfectly fine, but it crashes when one tries to read VARIABLE from a namelist instead of a fixed format input file.
How is this possible in Fortran? Is there any reference where I can find more information about?
Any help is greatly appreciated.
This comes from the days before F77 when doubles and integers were used for storing characters. From the format statement, this is probably from a CDC which could store 10 six bit characters in each word. Double precision was two words so it was two lots of 10 characters. If you change the code to
CHARACTER(LEN=20) VARIABLE
READ(1,10) VARIABLE
10 FORMAT(A20)
It should work. There isn't a lot of information about on CDC compilers. I've never tried using a namelist with one so I can't really comment about it. Try http://bitsavers.trailing-edge.com/pdf/cdc/cyber/cyber_70/chippewa/Chippewa_Fortran-Run_Apr66.pdf
Related
I want to implement a class to read vorbis comments. I know that a field will start with a field name, followed by an equal sign and the value. But how does it end? Documentation makes me think that a semicolon will end the field but I checked an ogg file with a hex editor and I cannot see any.
This is how I think it should look like in a file :
TITLE=MY SUPER TITLE;
The field name is title, followed by the equals sign and then the value is MY SUPER TITLE. And finally the semicolon to end the field.
But instead inside my file, the fields look like this :
TITLE=MY SUPER TITLE....
It's almost as above but there is no semicolon. The .'s are characters that cannot be displayed. I thought okay, it seems like the dots represent a value that will say "this is the end of the field!!" but they are almost always different. I noticed that there are always exactly 4 dots. The first dot has always a different value. The other free have usually a value of 0. But not always...
My question now, how does a field end? How do I read this comment?
Also, yeah I know that there are libraries and that I should use them instead of reinventing the wheel over and over again. I will use libraries later but first I want to know how to do it myself. Educational purpose only.
Each field is preceded by a little-endian 32-bit integer that indicates the number of bytes to read. You then convert the bytes to a string via UTF8.
See NVorbis' implementation (LoadComments(...)) for details.
I have an ETL process that regularly extracts code from an ODBC data source, manipulates it, and inserts it into my postgres database. One of the columns from this data source regularly has odd characters in it.
For the most part I can catch and convert all of the characters appropriately, but I have one character that exists in the ODBC data source, cannot be brought into postgres (all of the text after that character gets truncated), and I'm having a hard time identifying what the character is.
I can't even insert an example of the character directly into this post because it gets stripped out :/ The closest I can get is a screen shot of the character in textmate (the only application I can actually see the character in):
There character is the diamond between the 1 and 0. When my data comes in, everything after the 0 is truncated.
Is there a good way of identifying what this character is so I can figure out a way of stripping it out?
Per tripleee's comment on the original question post:
To identify the character I grabbed the hex value of the text to identify the hex value of the offending character in question.
There are a number of ways to do this, but the quickest way for me was to use a utility application I have called HexFiend so dump the text into. Once the text was in and I highlighted the character it returned the hex value "00".
A bit more investigation pointed towards the hex null value being used as a line terminator in C applications (which makes sense given the context of my project).
I've fit this null value into my ETL process so that it gets switched out with a new line and now everything is sunshine and daises.
Thanks again for the help!
In a program I have used a function RPAD() to format data coming from DB2 db.
In one instance the value was Ãmber. The following function:
RPAD('Ãmber',10,' ')
gives 9 characters only.
The ASCII value of 'Ã' is 195. I am not able to understand the reason for this behaviour.
Could someone share their experience.
Thanks
By default, DB2 will consider the length of à to be 2, likely because it is counting bytes rather than characters.
values(LENGTH('Ãmber'))
6
You can override it for LENGTH and many other functions
values(LENGTH('Ãmber', CODEUNITS16))
5
Unfortunately, RPAD does not take a parameter like this. I'm guessing this might be because the function was added for Oracle compatibility rather than on its own merits.
You could write your own RPAD function as a stored procedure or UDF, or just handle it with a CASE statement if this is the only place where you need it.
how can i know what is the format code of parameter that comes to my page?
whorking with ASP
some of the character that i see cant found in the DB (access)
i want to know the unicode of the value
Assuming you're using C#, you can get the 16-bit characters of strings as integers using (int) foo[0].
(In VB.NET, I think it would be Convert.ToInt32(foo.Chars(0)). In VBA, Asc(foo).)
If the string you're passing to ADO is correct, but the results are not as expected, either the data in the database was already corrupted by some earlier non-Unicode-friendly process, or else Access is not treating the input string and the database record as equal for some unexpected reason. (Equivalence of Unicode strings is a bit complicated.)
I am writing a function that transliterates UNICODE digits into ASCII digits, and I am a bit stumped on what to do if the string contains digits from different sets of UNICODE digits. So for example, if I have the string "\x{2463}\x{24F6}" ("④⓶"). Should my function
return 42?
croak that the string contains mixed sets?
carp that the string contains mixed sets and return 42?
give the user an additional argument to specify one of the three above behaviours?
do something else?
Your current function appears to do #1.
I suggest that you should also write another function to do #4, but only when the requirement appears, and not before .
I'm sure Joel wrote about "premature implementation" in a blog article sometime recently, but I can't find it.
I'm not sure I see a problem.
You support numeric conversion from a range of scripts, which is to say, you are aware of the Unicode codepoints for their numeric characters.
If you find an unknown codepoint in your input data, it is an error.
It is up to you what you do in the event of an error; you may insert a space or underscore, or you may abort conversion. What you would do will depend on the environment in which your function executes; it is not something we can tell you.
My initial thought was #4; strictly based on the fact that I like options. However, I changed my mind, when I viewed your function.
The purpose of the function seems to be, simply, to get the resulting digits 0..9. Users may find it useful to send in mixed sets (a feature :) . I'll use it.
If you ever have to handle input in bases greater than 10, you may end up having to treat many variants on the first 6 letters of the Latin alphabet ('ABCDEF') as digits in all their forms.