Thanks Alex. I agree with all of your PROS. Even CON 1 isn't that big a deal.
What I'm dealing with is a very large of J mapped files. If I could fragment it easily, I would. The biggest file I have is an array that grows by 86400 entries daily. That's right, one for every second of every day. That means about 31,536,000 numbers a year. You get the picture... I really wish the original programmers had at least read the page that said it was untested. It's pretty clear that I need this broken down by day. But there's a lot of code to arrange to get there. In my current project, most of the data crunching is done by J, C# serves as a front end and sends commands rather than actual data, which is read by J and not sent to C# so much. I was trying to wrap the J64 Interop to allow easier use with various data types (avoid manual casting, etc), but obviously not to transport such large datasets. Coming across this limitation made me want to share it with the community. Has the point become moot now? Martin Pelletier On 2010-10-14 19:14, Alexander Rufon wrote: > Hi Martin, > > I know how it feels to inherit projects and I too have decried (quite > publicly) the original programmers decision on some of the strategy for those > projects. > > So without knowing your development environment and deployment requirement, > can I suggest that you just switch to the 32-bit version of J? > PROS: > 1. You'll get a stable library > 2. Its thoroughly tested > 3. Officially supported > 4. It works. > CONS: > 1. Nagging feeling of dissatisfaction that your using 32bit in a 64bit build > 2. Can't allocate more than 1GB for each object (but why do you need to?) > > I been using J since version 4 and been deploying softwares that rely on J > since version 5. There are some features that I feel is lacking but its a > stable environment and one of my projects, an MRP for adidas apparel, is > still being used this day although I've deployed it in 2003 and using J504. > > For the #2 CONS, I have worked around this "limitation" by partitioning my > projects and a lot of forethought. Because of this, I have a capacity > planning module done in J that runs on a Pentium !V 2.0Ghz with 512mb memory, > the standard configuration of PC's on factory floors. The same principle hold > even if my J scripts run on a big-iron compaq-hp server with 4-xeon cpu's and > 6gb ram. J computes faster with smaller data to inputs ... data partitioning > is key. > > r/Alex ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
