You did not say how you unpacked your data, but from the symptoms you
described, I am assuming you read it in using readcsv, or something
equivalent,
Thus, here's a test setup:
require'csv'
data=:fixcsv 0 :0
2015-01-02,1
2015-01-03,1
2015-01-04,1
2015-01-05,0
)
a=:|:data
a2=: 1{a
With this setup, each of the boxes contains a list of characters.
Thus, for example:
;a2
1110
datatype;a2
literal
$@> a2
1
1
1
1
I think what you want is:
a3=: _&".@> a2
a3
1 1 1 0
_&". converts character sequences to numbers (and even handles a minus
sign as indicating negative number).
As for your follow on question: I believe J is limited by system
memory for the number of items in a row and rows vs columns is mostly
only a display issue (but benchmark to be sure, if timing matters and
performance is poor).
Thanks,
--
Raul
On Mon, Jun 29, 2020 at 10:27 PM HH PackRat <[email protected]> wrote:
>
> Hello, again!
>
> I feel a little stupid for asking for help with something probably so
> elementary that I'm missing it for some reason. I've done lots of
> switching between boxed and unboxed data in the past, but this one's
> got me stumped. I would have attached the 28K data file, but
> attachments aren't permitted. I considered tagging the data onto the
> end of this message as more of the text of the message, but I figured
> that wouldn't be allowed either. So anyone who would like to work
> with the data themselves can contact me via email, and I will be happy
> to send the data. (It's stock data from 2015 to 2020 with 2 columns:
> date and an indication of up and down movement.)
>
> The raw data file looks like this:
>
> 2015-01-02,1
> 2015-01-03,1
> 2015-01-04,1
> 2015-01-05,0
> . . .
>
> Here's the J code I used:
>
> data=. [the data file read in from the computer] NB. 2 columns of boxed data
>
> a=. |: data NB. transpose data to 2 rows (1982 columns, in this case)
>
> This is "a":
> ┌───────┬───────┬───────┬───────┬─
> │2015-01-02│2015-01-03│2015-01-04│2015-01-05│
> ├───────┼───────┼───────┼───────┼─ . . .
> │1 │1 │1 │0 │
> └───────┴───────┴───────┴───────┴─
>
> a2=. 1{a NB. get data from row 1
>
> This is "a2":
> ┌─┬─┬─┬─┬
> │1 │ 1│1│ 0│ . . .
> └─┴─┴─┴─┴
>
> a3=. > a2
>
> The following SHOULD be "a3" (as far as I know):
> 1 1 1 0 . . .
>
> but "a3" ends up like this:
> 1
> 1
> 1
> 0
> . . .
>
> And if I transpose this "a3", I end up with this:
> 1110 . . .
>
>
> Small "live" examples (not a script) work fine:
>
> ]a2=. 1;1;1;0;0;0
>
> ┌─┬─┬─┬─┬─┬─┐
> │ 1│ 1│1│ 0│ 0│ 0│
> └─┴─┴─┴─┴─┴─┘
>
> ]a3=. > a2
>
> 1 1 1 0 0 0
>
>
> As I said, I'm stumped by this, and (for pattern matching purposes)
> the remainder of my program depends on a row (not column) of 1's and
> 0's (although, if necessary, I'm sure I could code the other way).
> I'll probably be embarrassed by how simple the explanation is, but at
> least I'll be able to continue work on the rest of my program.
>
> Harvey
>
> P.S. Does J have an upper limit on the number of items in rows?
> Maybe that's the reason it (automatically?) transposed the data
> vertically? This "small" file has 1982 items. The "full" file (once
> I get things working correctly) has more than 14,700 items (58 years
> of data) and other future files could easily go back 135 years (or
> more than 49,300 items). Does J prefer lots of rows rather than lots
> of columns? (I mean, we're talking about the possibility of 14,700+
> columns of data for this example--or possibly up to 49,300+ columns of
> data in the future.) I was under the impression that J didn't care
> either way, but maybe I'm wrong, and it does care?
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
