Importing data from DOS 
Author Message
 Importing data from DOS

Bjorn,

An hour and  half after Gerry asked his basic question about how to read a

Quote:

> 3 11 Quadra 'FILE'
> A is FILE 'filename'

I see that I had a  typo and should have written:

3 11 QuadNA 'FILE'
A is FILE 'filename'

I hardly think this qualifies as recommending "plowing through a User's
Guide."

David Liebtag



Tue, 13 Jul 2004 20:46:57 GMT  
 Importing data from DOS
And how do you then use the file ?

lets say that I have a file
apl2tolur.text
------------------------------
123.4 567.8 901.2 345.6 789 123.4 567.8 901.2 345.6 789
124.4 567.8 901.2 345.6 789 123.4 567.8 901.2 345.6 789
125.4 567.8 901.2 345.6 789 123.4 567.8 901.2 345.6 789
126.4 567.8 901.2 345.6 789 123.4 567.8 901.2 345.6 789
127.4 567.8 901.2 345.6 789 123.4 567.8 901.2 345.6 789
128.4 567.8 901.2 345.6 789 123.4 567.8 901.2 345.6 789
129.4 567.8 901.2 345.6 789 123.4 567.8 901.2 345.6 789
------------------------------------------

I want to add one to each number

so the results will look like
--------------------------------------------------------------
124.4 568.8 902.2 346.6 790 124.4 568.8 902.2 346.6 790
125.4 568.8 902.2 346.6 790 124.4 568.8 902.2 346.6 790
126.4 568.8 902.2 346.6 790 124.4 568.8 902.2 346.6 790
127.4 568.8 902.2 346.6 790 124.4 568.8 902.2 346.6 790
128.4 568.8 902.2 346.6 790 124.4 568.8 902.2 346.6 790
129.4 568.8 902.2 346.6 790 124.4 568.8 902.2 346.6 790
130.4 568.8 902.2 346.6 790 124.4 568.8 902.2 346.6 790
-----------------------------------------------------------------
and the I want to write the results to another file

apl2result.txt

QuadNA to a file happened after I left IBM so I do not know how that works.


Quote:
> 3 11 QuadNA 'FILE'
> A is FILE 'filename'



Wed, 14 Jul 2004 05:40:39 GMT  
 Importing data from DOS

Quote:

> And how do you then use the file ?

> lets say that I have a file
> apl2tolur.text
> ------------------------------
> 123.4 567.8 901.2 345.6 789 123.4 567.8 901.2 345.6 789
> 124.4 567.8 901.2 345.6 789 123.4 567.8 901.2 345.6 789
> 125.4 567.8 901.2 345.6 789 123.4 567.8 901.2 345.6 789
> 126.4 567.8 901.2 345.6 789 123.4 567.8 901.2 345.6 789
> 127.4 567.8 901.2 345.6 789 123.4 567.8 901.2 345.6 789
> 128.4 567.8 901.2 345.6 789 123.4 567.8 901.2 345.6 789
> 129.4 567.8 901.2 345.6 789 123.4 567.8 901.2 345.6 789
> ------------------------------------------

Read the file into the WS as a character matrix (say) q.  At least three
ways to do it has already been discussed.

qq{is}{fmt}{disclose}1+{eval}{each}{enclose}[2]q

qq is a character matrix which can be written out to file if you wish.
Easy.

Ted



Thu, 15 Jul 2004 05:44:51 GMT  
 Importing data from DOS
Noone has yet in this thread posted this "easy" solution you are talking
about

It just goes to show that is not as easy as it should be and so my statement
is
still valid

In J and K there are already posted solutions to this but APL2 is only
publishing part
of the solution. If a man is drowning 100 meters from land and you only
throw him a line
that reaches 90 meters out you are almost there but he will still drown.

Everyone knows that things are easy in APL once you have the data there and
you can
look up various things to manipulate data in the WS. Getting it there and
then putting the
results out to files is the missing part always.

Give people Excel and they know instantly how to do all these easy steps
that are missing in APL.


Quote:

> Read the file into the WS as a character matrix (say) q.  At least three
> ways to do it has already been discussed.

> qq{is}{fmt}{disclose}1+{eval}{each}{enclose}[2]q

> qq is a character matrix which can be written out to file if you wish.
> Easy.



Fri, 16 Jul 2004 04:07:37 GMT  
 Importing data from DOS
Bjorn,

You're missing important information.

The original customer wrote our department userid with these questions too.
We responded with several lengthy letters offering a variety of solutions
including sample programs.
We only suggested reading the book after he appeared to ignore our letters.

We have since discovered his ISP has been having troubles and some of the
emails were lost.

I believe if you had seen all the correspondence, you wouldn't be so
critical.

David Liebtag
IBM APL Products and Services



Fri, 16 Jul 2004 00:49:20 GMT  
 Importing data from DOS

Quote:

> I believe if you had seen all the correspondence, you wouldn't be so
> critical.

Yes he would.  Bjorn has a long history of prejudice against APL,
especially APL2.  Nothing but J or K for our Bjorn.

Ted



Fri, 16 Jul 2004 05:32:38 GMT  
 Importing data from DOS


Quote:

> Yes he would.  Bjorn has a long history of prejudice against APL,
> especially APL2.  Nothing but J or K for our Bjorn.

Well....well... well.... I am not even going to try to comment on this
folly.

I have worked for and with APL since 1972 and for many of those years for
APL2.

If I point at a few points where APL could be improved then I am doing it in
the
hope of improving it and not against it at all.

Unfortunately I do not even know the first thing about K

And also unfortunately I have not had the opportunity to work on or with
APL2 for great
many years. I did not miss it that much because I had the good fortune of
being able to
work with J. I consider J to be APL too so ......



Fri, 16 Jul 2004 15:14:18 GMT  
 Importing data from DOS

Quote:

> If I point at a few points where APL could be improved then I am doing it in
> the
> hope of improving it and not against it at all.

My memory isn't what it used to be but I seem to remember a thread a
year or two ago when you were up in arms because APL2 couldn't handle
files.  When I posted counter examples to your claims, you were off on
how much better J was.

Must have been another Bjorn.

Ted



Fri, 16 Jul 2004 11:41:45 GMT  
 Importing data from DOS

Quote:

>Noone has yet in this thread posted this "easy" solution you are
>talking about
>...
>In J and K there are already posted solutions to this but APL2 is
>only publishing part of the solution.

Bjorn has a point here. He did publish a complete J solution, and I
don't see a complete APL2 solution in this thread. But then I fear he
blew it with his next comment:

Quote:
>Everyone knows that things are easy in APL once you have the
>data there and you can look up various things to manipulate data
>in the WS. Getting it there and then putting the results out to files is
>the missing part always.

But that is precisely the assumption David was making. Thus he
skipped the part about how to manipulate the data once it was in the
workspace. Unfortunately, he also skipped the part about how to get it
back into a file.

So here is my proposed complete APL2 solution. I've followed it with
some notes, most of which will be obvious to old APL hands, but I put
them here for any newbies that happen to wander through.

For Bjorn's benefit, I hope you can now see that it really is only one
line to read the file (after the QuadNA, which as noted below would
often have been done months earlier) and one line to write it.

[1] 3 11 {quad}NA 'FILE'
[2] txt {gets} FILE 'C:\TEMP\Numbers.txt'
[3] txt2 {gets} ({not}txt{element}{quad}TC){enlist}txt
[4] inums {gets} 1+{execute}{each}{each}txt2
[5] itxt2 {gets} 1{drop}{each}5 1{format}{each}inums
[6] itxt2 {gets} itxt2,{each}{enclose}1{drop}{quad}TC
[7] itxt {gets} {neg}2{drop}{enlist}itxt2
[8] itxt FILE 'C:\TEMP\INumbers.txt'

[1] Add an external function named FILE to the workspace. It behaves
    like a locked defined function, but it is a predefined part of the

    APL2 system. In reality this step might well have been part of
    creating the workspace rather than part of a function that
    processed files.
[2] Read a file into variable txt as a character vector. Of course in
    a real application you would normally get the name of the file in
    a variable rather than use the constant I have shown here.
[3] Break txt into a vector of character vectors, one for each line
    in the original file. Equal line lengths are not assumed.
    Somewhat fortuitously, DOS lines are separated by the last two
    elements of QuadTC as defined long before PCs existed.
[4] Convert each line into a vector of numbers and add 1 to
    everything. I've cheated a bit here, by assuming that there will
    never be syntax errors or negative numbers in the input file.
    A more robust implementation would break each line into words
    and use QuadEC (Execute Controlled) to validate the numbers
    during conversion.
[5] Convert the result back to characters, ensuring space for 3
    digits before the decimal point and that one digit is shown after
    the decimal point, even for whole numbers. Note that this form of
    the Format primitive always inserts a leading space, which I
    assumed would not be desired at the beginning of the lines.
[6] Add a DOS CR/LF to the end of each line.
[7] Convert the whole thing to a single character vector, dropping
    the final CR/LF (which is not strictly necessary).
[8] Write the result back as a new file on the disk.



Fri, 16 Jul 2004 16:00:58 GMT  
 Importing data from DOS


Quote:
> You're missing important information.

That may well be

Quote:
> The original customer wrote our department userid with these questions
too.
> We responded with several lengthy letters offering a variety of solutions
> including sample programs.

I do not doubt that you are doing your best to help the custemer(s)

Quote:
> We only suggested reading the book after he appeared to ignore our
letters.

> We have since discovered his ISP has been having troubles and some of the
> emails were lost.

> I believe if you had seen all the correspondence, you wouldn't be so
> critical.

I am not being critical of your way of handling this particular case.

I am just pointing at the fact that you do need to go to such lengthy
procedures
to solve such trivial operation as reading a simple file.

I have been wondering for many years why APL was isolated in this way from
the
rest of the operating system.

Possibly because APL was so way ahead of everything else and had to create a
complete
environment. Then when the surrounding improved APL was left stranded.

It is in a way similar to how Apple has always managed to considered itself
so much
better than everything else that it does not want to communicate easily with
the PC world.

It is by no means an isolated case. All the different codepages where the
letters of the alphabet is
in different places shows this clearly.

I am just a bit surprised that some APLs still today are having this simple
barrier against
newcomers.

I would have thought that something like Quad NA would make reading files
trivial. As I do not
know how Quad NA to files works I do not know if it is or not and noone
seems to be interested
in posting an example how it would be used.



Sat, 17 Jul 2004 00:15:31 GMT  
 Importing data from DOS


Quote:

> [1] 3 11 {quad}NA 'FILE'
> [2] txt {gets} FILE 'C:\TEMP\Numbers.txt'

......

Quote:
> [8] itxt FILE 'C:\TEMP\INumbers.txt'

> [1] Add an external function named FILE to the workspace. It behaves
>     like a locked defined function, but it is a predefined part of the

>     APL2 system. In reality this step might well have been part of
>     creating the workspace rather than part of a function that
>     processed files.
> [8] Write the result back as a new file on the disk.

This is quite interesting.

I have never seen Quad NA for files explained before.

This makes life a lot easier I am sure.

I am interested in getting a copy of APL2 to work with again one of these
days.

I went for J mostly because of I had no need for APL characters and the
problems
associated with them. At least to begin with.

Those kinds of problems - character codepages etc - should goaway once
Unicode is the
standard. Hope it will be this century.



Sat, 17 Jul 2004 03:39:53 GMT  
 Importing data from DOS
Bjorn keeps talking about QuadNA to files.  The examples we have shown do
not demonstrate QuadNAing to files.  Rather, they use Associated Processor
11 QuadNA to associate the name FILE with an external function which reads
files.

However, you can also use Associated Processor 12 to QuadNA directly to
files.

First, associate the name INPUT with the input file:

('FR' 'inputfilename' '') 12 {quad}NA 'INPUT'

INPUT is now a vector of character vectors.  It can be larger than the
workspace because the whole file is not read at once.  Records are brought
into the workspace as needed.

Next, associate the name OUTPUT with a new file to which we will write the
output:

('FCW' 'outputfilename' '')12 {quad}NA 'OUTPUT'

Now wrap Ray's code to process a record in a little function:

[0] OUT {is} PROCESS IN
[1] OUT {gets} ({not}IN{element}{quad}TC){enlist}IN
[2] OUT {gets} 1+{execute}{each}{each}OUT
[3] OUT {gets} 1{drop}{each}5 1{format}{each}OUT

Read the file, process each record, and write the new records to the output
file:

OUTPUT {is} OUTPUT , PROCESS {each} INPUT

And as I said, we discussed all this information with the customer off line.
Hopefully, I am done with this thread.

David Liebtag
IBM APL Products and Services



Sat, 17 Jul 2004 01:17:50 GMT  
 Importing data from DOS

Quote:

> "...

> I went for J mostly because of I had no need for APL characters and the
> problems
> associated with them. At least to begin with.

> Those kinds of problems - character codepages etc - should goaway once
> Unicode is the
> standard. Hope it will be this century.

Interesting. I've been working with APL for over 20 years now, and I
still cannot really understand this argument. It is partially the lack
of the APL character set that makes J so unintuitive to me (or is the
reverse true for traditional APL?). I've used interpreters from at least
5 different vendors on VM/CMS, MVS, DOS, Windows, Unix (with and without
X) and never has the character set been a problem.

But now memory is cheaper, so we can use more of it just to maintain a
huge character set - 256 is no longer enough.

Indeed, I suspect that Unicode may still bring its own problems, and
we'll have people complaining about that soon... Yet more opportunity to
make a contracting buck :-)

--
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GO/! d- s++:+ a+ C++(++++) US+++$ P+++ L++ E--- W++ N++ w--- O- V- PS+
PE+ Y+ PGP- t+ 5++ X R* tv+ b+ DI++ D G e(*) h++/-- r+++ y?
------END GEEK CODE BLOCK------

-----------------------------------------------------
Bob Hoekstra:   APL & Unix Consultant
Tele:           +44 (0)1483 771028
                 http://www.HoekstraSystems.com

-----------------------------------------------------



Sat, 17 Jul 2004 07:19:59 GMT  
 Importing data from DOS


Quote:
> Bjorn keeps talking about QuadNA to files.

I am interested in how APL treats files.

The auxil... approach is not very exiting. Quad NA seems to be interesting.

In J the foreign conjunction can be used

t=: 1!:1 <'apl2tolur.txt'   NB. read the "numbers" in

I am not sure if Quad NA is similar to mapped files in J  or not.

Mapped files leaves the files where they are and only works on the data in
them as needed.



Sun, 18 Jul 2004 00:25:52 GMT  
 Importing data from DOS


Quote:

> > I went for J mostly because of I had no need for APL characters and the
> > problems
> > associated with them. At least to begin with.
> Interesting. I've been working with APL for over 20 years now, and I
> still cannot really understand this argument.

That is because you are probably only working with one code page and only
English.
As soon as your alphabet uses more characters as 2*7 can fit then the APL
characters
begin to conflict with your own.

In Iceland there are several codepages in use and that is problem enough so
you do not
have the same codepage entries for   the same Icelandic letter between
various codepages
let alone how they conflict with the APL characters.

Quote:
> It is partially the lack
> of the APL character set that makes J so unintuitive to me

I was also very much in favor of using them before I moved back to Iceland.

Quote:
>  (or is the
> reverse true for traditional APL?). I've used interpreters from at least
> 5 different vendors on VM/CMS, MVS, DOS, Windows, Unix (with and without
> X) and never has the character set been a problem.

> But now memory is cheaper, so we can use more of it just to maintain a
> huge character set - 256 is no longer enough.

256 is not huge at all

Here is the Iclelandic characterset in one codepage:

"abcedefghijklmnopqrstuvwxyyzt??ABCDDEFGHIJKLMNOPQRSTUVWXYYZT??"

Tell mee if your APL characters did conflict with them or not.

Quote:

> Indeed, I suspect that Unicode may still bring its own problems, and
> we'll have people complaining about that soon... Yet more opportunity to
> make a contracting buck :-)

Unicode has the problem of needing more space.


Sun, 18 Jul 2004 00:35:37 GMT  
 
 [ 25 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Importing data with DOS file driver

2. Importing data from Windows/DOS

3. importing clarion 2.1 for dos data files

4. Import Data With File Import

5. Unix Data files vs DOS data files

6. import Image vs from PIL import Image vs import PIL.Image

7. Import dos file variable record length

8. Getting a divide by zero while importing an ascii into report writer for DOS - XTRACE included

9. Trying to import/convert V3 for DOS application

10. How to import Cobol DOS Database (with *.idx) in MS Acess

11. Importing Data from Excel, File Maker

12. import and export data

 

 
Powered by phpBB® Forum Software