Hello;
A mapped file, being pumped from the J side with numeric data, and
accessed from outside of J. How is not an invitation to disaster?
Roger Hui wrote:
Say you write out the day numbers to a map file.
Then, the file size could double or not depending on
whether you have _ in the dates. And a non-J program
reading the file would have to deal with two completely
different formats, depending on whether you have _
in the dates.
Regarding space and time, the following benchmark
illustrates a difference between integers and
floating point. Day numbers for dates that you
likely have to deal with fall in the range 3e4 to 1.2e5.
todate 3e4 1.2e5
1882 2 20
2128 7 20
i=: 30000 + 1e6 [EMAIL PROTECTED] 9e4
f=: _ (?1e6)}i
j=: 30000 + 1e6 [EMAIL PROTECTED] 9e4
ts=: 6!:2 , 7!:[EMAIL PROTECTED]
ts 'i i. j'
0.0202889 4.7193e6
ts 'f i. j'
0.444318 2.09722e7
A single _ day number causes an increase in time
by a factor of 20 and in space by a factor of 4,
in a very common and useful computation.
In case you intend your sentence ("if space and
time are the only effects, ...") to be interpreted
in a general sense, the recent tree sum problem
provides a counterexample. The connection matrix
solution is much more elegant than the others, the
only drawback being that it uses more space and time.
But what a drawback! For an n-node tree it
requires O(n^2) space, which is why the other
solutions can handle million-node trees in less
than a second, whereas the connection matrix solution
maxes out at around 1e4. The O(n^2) space requirement
is a killer no matter how much hardware advances.
It is a fallacy that efficiency doesn't matter
as hardware advances. Efficiency matters MORE
as hardware advances, because with more capable
hardware we are asked to solve bigger problems.
In a 64 KB machine you might be tasked to solve
a problem of size 1000, and the difference between
O(n^2) vs. O(n*^.n) isn't crushing. On a 1 GB
machine you might be tasked to solve a problem of
size 1e7, and then with O(n^2) you'd have a problem.
----- Original Message -----
From: Randy MacDonald <[EMAIL PROTECTED]>
Date: Sunday, March 16, 2008 19:08
Subject: Re: [Jprogramming] Handling NaN error with #:_
To: Programming forum <[email protected]>
Hello;
If space and time are the only effects, and given the sheer
amount of
computing power available on the meagrest of machines, I say
that there
is not much of an issue.
Use of the previously suggested 'antibase' which uses adverse
seems
elegant enough.
Roger Hui wrote:
Using _ as a date or day number forces the entire
argument or result array from integer to floating point.
Some consequences:
- doubles the space consumption
- comparisons take longer
- important computations such as i. and e. take longer
----- Original Message -----
From: Alain Miville de Chêne <[EMAIL PROTECTED]>
Date: Sunday, March 16, 2008 14:12
Subject: Re: [Jprogramming] Handling NaN error with #:_
To: Programming forum <[email protected]>
It used to be elegant. It is no more.
Anssi is right to value elegance.
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
--
------------------------------------------------------------------------
|\/| Randy A MacDonald | APL: If you can say it, it's done.. (ram)
|/\| ramacd <at> nbnet.nb.ca |
|\ | | The only real problem with APL is that
BSc(Math) UNBF'83 | it is "still ahead of its time."
Sapere Aude | - Morten Kromberg
Natural Born APL'er |
-----------------------------------------------------(INTP)----{ gnat }-
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
