Hahahaha. Yap, I used primitives library and added some keywords. For
example, the following code has these definitions
> NB. Copy the current bom to the number of defined destination
> temp=. (tally where msk) copy tomatrix data
tally
#
copy
#
tomatrix
,:^:(1: = [EMAIL PROTECTED])
where
3 : '(y eq 1) compress int shape y'
eq
tally
#
copy
#
tomatrix
,:^:(1: = [EMAIL PROTECTED])
where
3 : '(y eq 1) compress int shape y'
eq
=
compress
#
int
3 : 0
NB. integers from 1 to y with IO=1
1+ i. y
)
shape
$
Yes. One of the idea is that if I get run over by a truck, somebody else
could decipher what's going on. Also, I implemented a framework of
handling SQL data so that when it is imported into J, nouns are
automatically created around it. Take for example the Destination data
mentioned below. When imported from MS-SQL server, the following nouns
are automatically created:
DUV NB. fields and data
+-----------------------+-------------------------------+
|+-------------+-------+|+-------+----------+----------+|
||Gen_Mat_ID |numeric|||1002091|OSAKA |0000020071||
|+-------------+-------+|+-------+----------+----------+|
||City_Code |text |||1002091|NODA - SHI|0000020073||
|+-------------+-------+|+-------+----------+----------+|
||Customer_Code|text || |
|+-------------+-------+| |
+-----------------------+-------------------------------+
DUVH NB. Fields and datatype
+-------------+-------+
|Gen_Mat_ID |numeric|
+-------------+-------+
|City_Code |text |
+-------------+-------+
|Customer_Code|text |
+-------------+-------+
DUVD NB. Data
+-------+----------+----------+
|1002091|OSAKA |0000020071|
+-------+----------+----------+
|1002091|NODA - SHI|0000020073|
+-------+----------+----------+
DUVV NB. Numeric equivalent of Data
1002091 195 156
1002091 196 157
DUV_FIELDNAMES NB. Indexed fieldnames
+--------------+-------------+-----------------+
|DUV_GEN_MAT_ID|DUV_CITY_CODE|DUV_CUSTOMER_CODE|
+--------------+-------------+-----------------+
NB. Where it says the column position
DUV_GEN_MAT_ID
1
DUV_CITY_CODE
2
DUV_CUSTOMER_CODE
3
Doing this helps a lot in actual development, debugging and support. Say
for example, I was looking for the customer code of the CITY_CODE for
OSAKA. I can code it this way:
[osaka=. searchLOOKUP 'OSAKA'
195
DUVD selectrows where osaka = DUV_CITY_CODE colsfrom DUVV
+-------+-----+----------+
|1002091|OSAKA|0000020071|
+-------+-----+----------+
DUV_CUSTOMER_CODE colsfrom DUVD selectrows where osaka =
DUV_CITY_CODE colsfrom DUVV
+----------+
|0000020071|
+----------+
If you convert the code above to primitive J scripts, this is what it
would look like:
osaka=. <'OSAKA'
LOOKUP_z_=: ~. LOOKUP_z_,~. osaka
[osaka=. LOOKUP_z_ i. osaka
195
DUVD {~ I. osaka = (<:DUV_CITY_CODE) { "1 DUVV
+-------+-----+----------+
|1002091|OSAKA|0000020071|
+-------+-----+----------+
(<:DUV_CUSTOMER_CODE) { "1 DUVD {~ I. osaka = (<:DUV_CITY_CODE) { "1
DUVV
+----------+
|0000020071|
+----------+
This language evolved since our company is a Microsoft Partner which
means we primarily use Visual Studio .NET as the development platform.
Hence, there are times when I'm working without seeing any J scripts.
The long names help me remember what was happening even after the code
was written years ago. ;)
There are advantages and disadvantages of course.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Oleg Kobchenko
Sent: Friday, September 19, 2008 3:05 PM
To: Programming forum
Subject: Re: [Jprogramming] Verb Sequence or Ranking problem?
Did you have to strategically replace J primitives
with inconspicuous monikers? It looks like a narration,
and presumably gives an idea whats going on to an
outsider. But for someone who knows J, it is like
trying to decipher cockney rhyming :) . It is an
interesting approach anyways.
----- Original Message ----
> From: Alex Rufon <[EMAIL PROTECTED]>
>
> Ok. I am being burdened by my ignorance that its creating more
questions
> than I can handle. What I mean is that I now have a feeling that I am
> solving the problem the wrong way. I am going to explain the problem
as
> a whole so that I can get an idea on how advanced J programmers would
> solve it. You can also see from my explanations below how I use J to
> solve problems too. Any advice/criticism are welcome and appreciated.
>
> What I am doing right now is reviewing my existing codes and trying to
> optimize them by removing the for loops. This came about when I had a
> complaint from some of my users that some operations were taking
around
> 30 minutes to complete. The code below is running fine but I'm using
it
> as an example because this type of loop is prevalent in my projects:
> NB. ======== START OF CODE ========
> NB. STEP 1d: Make copies of DUV by the number of destination declared
> sids=. searchLOOKUP 'DUV'
> masks=. (BOM_USAGE_CLASS colsfrom bomv) member sids
> if. sum across masks do.
> NB. STEP 1b1: Work only with rows that matches
> wrkbom=. masks copy bomv
> wrkvbom=. (0,behead shape wrkbom) shape 0
> for_data. wrkbom do.
> NB. Check if we have a UV Summary defined for current GMC
> msk=. (atomize BOM_GEN_MAT_ID colsfrom data) = DUV_GEN_MAT_ID
> colsfrom DUVV
> if. tally where msk do.
> NB. Copy the current bom to the number of defined destination
> temp=. (tally where msk) copy tomatrix data
> NB. Update the destination code to the ship to customer code
> wired=. DUV_CUSTOMER_CODE colsfrom DUVV selectrows where msk
> if. 1 = shape wired do.
> wired=. atomize wired
> end.
> temp=. temp replacecols BOM_DESTN_CODE;wired
> NB. Now save the current bom
> wrkvbom=. wrkvbom atop temp
> end.
> end.
> NB. Now remove the processed bom's then add the new BOM's
> bomv=. bomv selectrows where not masks
> bomv=. bomv atop wrkvbom
> end.
> NB. ======== END OF CODE ========
>
> First off, I know that you'll be horrified because it doesn't look
like
> any J script that you know. :P Hehehehehehe.
>
> In summary, what this code does is expands a list of materials to the
> number of destination. To illustrate, take the following data:
> NB. List of Destination by Generic Material ID:
> DUV_FIELDNAMES,DUVD
> +--------------+-------------+-----------------+
> |DUV_GEN_MAT_ID|DUV_CITY_CODE|DUV_CUSTOMER_CODE|
> +--------------+-------------+-----------------+
> |1002091 |OSAKA |0000020071 |
> +--------------+-------------+-----------------+
> |1002091 |NODA - SHI |0000020073 |
> +--------------+-------------+-----------------+
> NB. The numeric equivalent of the data above is:
> DUVV
> 1002091 195 156
> 1002091 196 157
>
> NB. List of Materials
> (<:BOM_USAGE_CLASS,BOM_GEN_MAT_ID,BOM_DESTN_CODE) { "1
> BOM_FIELDNAMES,ADBOMDTLD
> +---------------+--------------+--------------+
> |BOM_USAGE_CLASS|BOM_GEN_MAT_ID|BOM_DESTN_CODE|
> +---------------+--------------+--------------+
> |DUV |1002091 | |
> +---------------+--------------+--------------+
> (<:BOM_USAGE_CLASS,BOM_GEN_MAT_ID,BOM_DESTN_CODE) { "1 ADBOMDTLV
> 139 1002091 0
>
> NB. Result of operation
> (<:BOM_USAGE_CLASS,BOM_GEN_MAT_ID,BOM_DESTN_CODE) { "1
> BOM_FIELDNAMES,BCONSUMPD
> +---------------+--------------+--------------+
> |BOM_USAGE_CLASS|BOM_GEN_MAT_ID|BOM_DESTN_CODE|
> +---------------+--------------+--------------+
> |DUV |1002091 |0000020071 |
> +---------------+--------------+--------------+
> |DUV |1002091 |0000020073 |
> +---------------+--------------+--------------+
> (<:BOM_USAGE_CLASS,BOM_GEN_MAT_ID,BOM_DESTN_CODE) { "1 BCONSUMPV
> 139 1002091 156
> 139 1002091 157
>
> So basically, the code above takes the list of materials and the
number
> of matching destination and combine them. So in this case, we only get
> two resulting records because we only have 1 material and 2
destination.
> There will be cases where the list of materials will have repeating
> BOM_GEN_MAT_ID or a material that does not match any entry in the
> destination.
>
> As you can see, my approach is using traditional programming technique
> where I would loop through the list of materials and check if there is
a
> matching material in the destination. If there are, I would then
> replicate the material to the number of matching destination and copy
> the DUV_CUSTOMER_CODE to the BOM_DESTN_CODE as is, otherwise I'll just
> continue to the next material in the list.
>
> Unfortunately, this is only for BOM_USAGE_CLASS of DUV or by
> Destination. I also have permutations of this like:
> 1. SUV - by size
> 2. SDUV - by size and destination
> 3. AUV - by article
> 4. ASDUV - by article, size and destination
> 5. ASSTPOUV - by article, size, sub-style, and purchase order
> 6. etc.
>
> The combination of Usage Class is mind boggling and the merchandisers
> are coming up with new ways to make my life difficult. So here is the
> problem, I think I am using J to solve the problem the wrong way. For
> example, for ASDUV, I would loop by:
> NB. Pseudo code
> for_article. articles do.
> NB. Do something for articles
> for_size. sizes do.
> NB. Do something for sizes
> for_destination. destinations do.
> NB. Do something for destination and save it
> end.
> NB. Save changes for size and destination
> end.
> NB. Save changes for colorway, size and destination
> end.
>
> So as you can see, I'll be looping 3 levels deep and one local
variable
> for each level and updates to the parent variable until the whole
> operation is complete.
>
> As I said, any suggestion, insights and/or criticism are appreciated.
> Thanks.
>
> r/Alex
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
