I'm using a routine that I didn't write that reads data into a char array. 
The routine reads 64 bytes at a time.  I need to read 256 bytes in total
into one array. 

So I have this 

char myArray = new char[256];
....
int i;
for (i=0; i<4; i++)
	{
	read64(&myArray[i*64]); 
	}
....

It works in C, but it obviously won't work in Java.
How do I do this in Java ?

Thanks

me2 wrote On 04/10/07 13:42,:
> 
> I'm using a routine that I didn't write that reads data into a char array. 
> The routine reads 64 bytes at a time.  I need to read 256 bytes in total
> into one array. 
> 
> So I have this 
> 
> char myArray = new char[256];

    Missing some brackets here ...

> ...
> int i;
> for (i=0; i<4; i++)
> 	{
> 	read64(&myArray[i*64]); 
> 	}
> ...
> 
> It works in C, but it obviously won't work in Java.
> How do I do this in Java ?

    Can you use a two-dimensional array (four one-
dimensional arrays, really)?

	char[][] myArray = new char[4][64];
	for (int i = 0;  i < 4;  ++i)
	    read64(myArray[i]);

If not, another simple approach reads into a 64-char
array four times, copying what's read into a larger
array:

	char[] myArray = new char[256];
	char[] temp = new char[64];
	for (int i = 0;  i < 256;  i += 64) {
	    read64(temp);
	    System.arrayCopy(temp, 0, myArray, i, 64);
	}

    An aside: Are you sure this read64() method reads
`char' data, as opposed to `byte' data?  (Are you aware
they're different?)

-- 
Eric.Sosman@sun.com

On Tue, 10 Apr 2007 13:59:09 -0400, Eric Sosman wrote:

> me2 wrote On 04/10/07 13:42,:
>> 
>> I'm using a routine that I didn't write that reads data into a char array. 
>> The routine reads 64 bytes at a time.  I need to read 256 bytes in total
>> into one array. 
>> 
>> So I have this 
>> 
>> char myArray = new char[256];
> 
>     Missing some brackets here ...

Oops... yes I am.  And it should be byte, not char. 
Sorry, I am paraphrasing.

Should be byte[] myArray = new byte[256];

>> ...
>> int i;
>> for (i=0; i<4; i++)
>> 	{
>> 	read64(&myArray[i*64]); 
>> 	}
>> ...
>> 
>> It works in C, but it obviously won't work in Java.
>> How do I do this in Java ?
> 
>     Can you use a two-dimensional array (four one-
> dimensional arrays, really)?
> 
> 	char[][] myArray = new char[4][64];
> 	for (int i = 0;  i < 4;  ++i)
> 	    read64(myArray[i]);

I thought of that too, but surely there is an easier way ?

 
> If not, another simple approach reads into a 64-char
> array four times, copying what's read into a larger
> array:
> 
> 	char[] myArray = new char[256];
> 	char[] temp = new char[64];
> 	for (int i = 0;  i < 256;  i += 64) {
> 	    read64(temp);
> 	    System.arrayCopy(temp, 0, myArray, i, 64);
> 	}

That is a lot of extra CPU cycles for no good reason other than to satisfy
the constraints of the language. Is there no other way ?

>     An aside: Are you sure this read64() method reads
> `char' data, as opposed to `byte' data?  (Are you aware
> they're different?)

It reads bytes and I know they are different.  My head was in C land there
for a minute. 

Thanks for taking the time to reply. 

me2 wrote On 04/10/07 14:06,:
> On Tue, 10 Apr 2007 13:59:09 -0400, Eric Sosman wrote:
>>[...]
>>If not, another simple approach reads into a 64-char
>>array four times, copying what's read into a larger
>>array:
>>
>>	char[] myArray = new char[256];
>>	char[] temp = new char[64];
>>	for (int i = 0;  i < 256;  i += 64) {
>>	    read64(temp);
>>	    System.arrayCopy(temp, 0, myArray, i, 64);
>>	}
> 
> 
> That is a lot of extra CPU cycles for no good reason other than to satisfy
> the constraints of the language. Is there no other way ?

    1) The extra CPU cycles are being spent not to "satisfy
the constraints of the language," but to compensate for the
inflexibility of the read64() method.

    2) How fast is the I/O device from which read64()
obtains its data?  How many times does the CPU clock tick
while read64() delivers one byte?

>>    An aside: Are you sure this read64() method reads
>>`char' data, as opposed to `byte' data?  (Are you aware
>>they're different?)
> 
> It reads bytes and I know they are different.  My head was in C land there
> for a minute. 

    Sorta had that feeling ...

-- 
Eric.Sosman@sun.com

"me2" <someone@somewhere.com> wrote in message 
news:pan.2007.04.10.18.06.18.52551@somewhere.com...
> On Tue, 10 Apr 2007 13:59:09 -0400, Eric Sosman wrote:
>>
>> char[][] myArray = new char[4][64];
>> for (int i = 0;  i < 4;  ++i)
>>     read64(myArray[i]);
>
> I thought of that too, but surely there is an easier way ?

    If you've thought of a solution, but disregarded it as unsuitable, you 
should probably mention this, to avoid wasting people's time when they 
come up with the same solution as you have.

    I'm not sure what you're expecting as an "easier way". Personally, I 
find thinking in terms of "arrays of arrays" to be "easier" than thinking 
in terms of "addresses of objects", but maybe it's because I'm used to 
thinking in Java, and you're used to thinking in C?

>> If not, another simple approach reads into a 64-char
>> array four times, copying what's read into a larger
>> array:
>>
>> char[] myArray = new char[256];
>> char[] temp = new char[64];
>> for (int i = 0;  i < 256;  i += 64) {
>>     read64(temp);
>>     System.arrayCopy(temp, 0, myArray, i, 64);
>> }
>
> That is a lot of extra CPU cycles for no good reason other than to 
> satisfy
> the constraints of the language. Is there no other way ?

    There is another way. See above.

    - Oliver 

On Tue, 10 Apr 2007 14:35:55 -0400, Eric Sosman wrote:

> me2 wrote On 04/10/07 14:06,:
>> That is a lot of extra CPU cycles for no good reason other than to satisfy
>> the constraints of the language. Is there no other way ?
> 
>     1) The extra CPU cycles are being spent not to "satisfy
> the constraints of the language," but to compensate for the
> inflexibility of the read64() method.

Well... the routine in question is actually LibusbJava.usb_bulk_read and
the limitation is based on the 64 byte message limit in the USB
specification for bulk channels.  So maybe we should rewrite the USB
specification to suit Java ? 

 

me2 wrote On 04/10/07 15:01,:
> On Tue, 10 Apr 2007 14:35:55 -0400, Eric Sosman wrote:
> 
> 
>>me2 wrote On 04/10/07 14:06,:
>>
>>>That is a lot of extra CPU cycles for no good reason other than to satisfy
>>>the constraints of the language. Is there no other way ?
>>
>>    1) The extra CPU cycles are being spent not to "satisfy
>>the constraints of the language," but to compensate for the
>>inflexibility of the read64() method.
> 
> 
> Well... the routine in question is actually LibusbJava.usb_bulk_read and
> the limitation is based on the 64 byte message limit in the USB
> specification for bulk channels.  So maybe we should rewrite the USB
> specification to suit Java ? 

    Must the physical characteristics of an underlying
device be propagated all the way up through the rest of
a program?  Do the file I/O methods insist on dealing in
512-byte disk sectors?

    But now that we know the input device is USB, we also
know that its highest transfer speed is 60 MB/s  (I'm no
USB expert; this rate comes from Wikipedia, whose article
also notes that it's rare to achieve more than 50% of the
theoretical maximum -- but let's pretend you can get the
entire 100%).

    You haven't mentioned your CPU's speed, but let's
assume that the clock frequency is at least 2.4GHz (my
three-year-old run-of-the-mill inexpensive home PC cycles
at 3GHz).  That means you've got at least 40 CPU cycles
per received byte, more (or far more) if the CPU is faster
or if the USB device operates at a lower speed or at less
than full saturation.

    In other words, there is no shortage of CPU power and
you are probably not justified in worrying about "a lot of
extra CPU cycles" being spent copying data from an unfriendly
to a friendly form.

-- 
Eric.Sosman@sun.com

On Apr 10, 7:42 pm, me2 <some...@somewhere.com> wrote:
> I'm using a routine that I didn't write that reads data into a char array.
> The routine reads 64 bytes at a time.

Stop doing that nonsense. Characters in Java are not bytes. If you
want to read bytes use a byte array, not a char array. As long as you
insist on doing things the way they are done in C you will write
bullshit Java code.

> I need to read 256 bytes in total
> into one array.

Then use a 256 byte array, not a char array.

>
> So I have this
>
> char myArray = new char[256];

Throw it away.

> ...
> int i;
> for (i=0; i<4; i++)
>         {
>         read64(&myArray[i*64]);
>         }
> ...

public void read64(byte[] data, int offset) {
   for(int i = offset; i < offset + 64; i++) {
      data[i] = read1();
   }
}


byte[] data = new byte[256];
for(int i = 0; i < 4; i++) {
   read64(data, i * 64);
}

a24900@googlemail.com wrote:
> Stop doing that nonsense. Characters in Java are not bytes. If you
> want to read bytes use a byte array, not a char array. As long as you
> insist on doing things the way they are done in C you will write
> bullshit Java code.

This point was already brought up earlier if you actually read the 
thread. me2 admitted that he was thinking about C when he was writing 
this and that in the code it was actually byte arrays. People make 
mistakes; don't treat those mistakes too harshly -- you too will make a 
similar mistake, I guarantee it.

me2 wrote:
> On Tue, 10 Apr 2007 14:35:55 -0400, Eric Sosman wrote:
> 
>> me2 wrote On 04/10/07 14:06,:
>>> That is a lot of extra CPU cycles for no good reason other than to satisfy
>>> the constraints of the language. Is there no other way ?
>>     1) The extra CPU cycles are being spent not to "satisfy
>> the constraints of the language," but to compensate for the
>> inflexibility of the read64() method.
> 
> Well... the routine in question is actually LibusbJava.usb_bulk_read and
> the limitation is based on the 64 byte message limit in the USB
> specification for bulk channels.  So maybe we should rewrite the USB
> specification to suit Java ? 

The Java routine should have been set up as:

    read64(byte[] array, int offset)

Then you would just have to say:

     for (int i = 0; i < 256; i += 64)
         read64(array, i);

Whoever designed your routine really wasn't at all familiar with Java 
practice. See, for example, the InputStream.read method.

-- 
John W. Kennedy
"...if you had to fall in love with someone who was evil, I can see why 
it was her."
   -- "Alias"
* TagZilla 0.066 * http://tagzilla.mozdev.org

In article <1176235470.297177@news1nwk>,
Eric Sosman  <Eric.Sosman@Sun.COM> wrote:
> me2 wrote On 04/10/07 15:01,:
> > On Tue, 10 Apr 2007 14:35:55 -0400, Eric Sosman wrote:
> > 
> > 
> >>me2 wrote On 04/10/07 14:06,:
> >>
> >>>That is a lot of extra CPU cycles for no good reason other than to satisfy
> >>>the constraints of the language. Is there no other way ?
> >>
> >>    1) The extra CPU cycles are being spent not to "satisfy
> >>the constraints of the language," but to compensate for the
> >>inflexibility of the read64() method.

[ snip ]

>     You haven't mentioned your CPU's speed, but let's
> assume that the clock frequency is at least 2.4GHz (my
> three-year-old run-of-the-mill inexpensive home PC cycles
> at 3GHz).  That means you've got at least 40 CPU cycles
> per received byte, more (or far more) if the CPU is faster
> or if the USB device operates at a lower speed or at less
> than full saturation.
> 
>     In other words, there is no shortage of CPU power and
> you are probably not justified in worrying about "a lot of
> extra CPU cycles" being spent copying data from an unfriendly
> to a friendly form.
> 

Aren't you assuming here that there's not something else going
on in the computer that could make use of those CPU cycles that
aren't being used while the OP's program is waiting for I/O?
Maybe more often than not that's a safe assumption these days,
though.



Another thing:  My news server seems not to be getting all of
the OP's posts (unless they're just being delayed).  In a check
earlier of GG's archives, they have three messages from "me2"
(I may have these out of sequence):

Message-Id: <pan.2007.04.10.17.42.52.231772@somewhere.com>
Message-Id: <pan.2007.04.10.18.06.18.52551@somewhere.com>
Message-Id: <pan.2007.04.10.19.01.55.168201@somewhere.com>

but only the middle one has shown up, as of this writing, at
News.Individual.Net as best I can tell.  Anyone else notice
something similar?

-- 
Decline To State
(But the e-mail address in the header is real.)

<blmblm@myrealbox.com> wrote in message 
news:5841v9F2fnndoU2@mid.individual.net...
>
> Another thing:  My news server seems not to be getting all of
> the OP's posts (unless they're just being delayed).  In a check
> earlier of GG's archives, they have three messages from "me2"
> (I may have these out of sequence):
>
> Message-Id: <pan.2007.04.10.17.42.52.231772@somewhere.com>
> Message-Id: <pan.2007.04.10.18.06.18.52551@somewhere.com>
> Message-Id: <pan.2007.04.10.19.01.55.168201@somewhere.com>
>
> but only the middle one has shown up, as of this writing, at
> News.Individual.Net as best I can tell.  Anyone else notice
> something similar?

    I got all 3, though I only saw the 3rd this morning. I'm using 
Videotron's servers.

    - Oliver 

blmblm@myrealbox.com wrote On 04/11/07 08:17,:
> In article <1176235470.297177@news1nwk>,
> Eric Sosman  <Eric.Sosman@Sun.COM> wrote:
> 
>>me2 wrote On 04/10/07 15:01,:
>>
>>>On Tue, 10 Apr 2007 14:35:55 -0400, Eric Sosman wrote:
>>>
>>>
>>>
>>>>me2 wrote On 04/10/07 14:06,:
>>>>
>>>>
>>>>>That is a lot of extra CPU cycles for no good reason other than to satisfy
>>>>>the constraints of the language. Is there no other way ?
>>>>
>>>>   1) The extra CPU cycles are being spent not to "satisfy
>>>>the constraints of the language," but to compensate for the
>>>>inflexibility of the read64() method.
> 
> 
> [ snip ]
> 
> 
>>    You haven't mentioned your CPU's speed, but let's
>>assume that the clock frequency is at least 2.4GHz (my
>>three-year-old run-of-the-mill inexpensive home PC cycles
>>at 3GHz).  That means you've got at least 40 CPU cycles
>>per received byte, more (or far more) if the CPU is faster
>>or if the USB device operates at a lower speed or at less
>>than full saturation.
>>
>>    In other words, there is no shortage of CPU power and
>>you are probably not justified in worrying about "a lot of
>>extra CPU cycles" being spent copying data from an unfriendly
>>to a friendly form.
>>
> 
> 
> Aren't you assuming here that there's not something else going
> on in the computer that could make use of those CPU cycles that
> aren't being used while the OP's program is waiting for I/O?
> Maybe more often than not that's a safe assumption these days,
> though.

    No, I made no assumption about what else the machine
might be doing.  Nor did I make any assumptions about how
many cycles the arrayCopy() calls might consume.  My goal
was to establish a rough lower bound on the number of CPU
cycles available per byte of input, in order to determine
whether "a lot of extra CPU cycles" were likely to amount
to enough to bother worrying about.  Since there appears
to be a plentiful supply of cycles, it is quite unlikely
that the impact of arrayCopy() will be a problem.  If the
method burns a million cycles per byte copied there'll be
trouble, but does that seem likely?

    The O.P. is fretting about "a lot of extra CPU cycles"
(without having made any attempt to substantiate "a lot"),
and I believe he is fretting needlessly.  An analogy I've
used before: He's worrying about whether waxing his car
will improve fuel economy by making it slipperier, or hurt
fuel economy by adding weight.

-- 
Eric.Sosman@sun.com

In article <1176307834.32450@news1nwk>,
Eric Sosman  <Eric.Sosman@Sun.COM> wrote:
> blmblm@myrealbox.com wrote On 04/11/07 08:17,:
> > In article <1176235470.297177@news1nwk>,
> > Eric Sosman  <Eric.Sosman@Sun.COM> wrote:
> > 
> >>me2 wrote On 04/10/07 15:01,:
> >>
> >>>On Tue, 10 Apr 2007 14:35:55 -0400, Eric Sosman wrote:
> >>>
> >>>
> >>>
> >>>>me2 wrote On 04/10/07 14:06,:
> >>>>
> >>>>
> >>>>>That is a lot of extra CPU cycles for no good reason other than to satisfy
> >>>>>the constraints of the language. Is there no other way ?

[ snip ]

> >>    You haven't mentioned your CPU's speed, but let's
> >>assume that the clock frequency is at least 2.4GHz (my
> >>three-year-old run-of-the-mill inexpensive home PC cycles
> >>at 3GHz).  That means you've got at least 40 CPU cycles
> >>per received byte, more (or far more) if the CPU is faster
> >>or if the USB device operates at a lower speed or at less
> >>than full saturation.
> >>
> >>    In other words, there is no shortage of CPU power and
> >>you are probably not justified in worrying about "a lot of
> >>extra CPU cycles" being spent copying data from an unfriendly
> >>to a friendly form.
> >>
> > 
> > 
> > Aren't you assuming here that there's not something else going
> > on in the computer that could make use of those CPU cycles that
> > aren't being used while the OP's program is waiting for I/O?
> > Maybe more often than not that's a safe assumption these days,
> > though.
> 
>     No, I made no assumption about what else the machine
> might be doing.  Nor did I make any assumptions about how
> many cycles the arrayCopy() calls might consume.  My goal
> was to establish a rough lower bound on the number of CPU
> cycles available per byte of input, in order to determine
> whether "a lot of extra CPU cycles" were likely to amount
> to enough to bother worrying about.  Since there appears
> to be a plentiful supply of cycles, it is quite unlikely
> that the impact of arrayCopy() will be a problem.  If the
> method burns a million cycles per byte copied there'll be
> trouble, but does that seem likely?
> 

Maybe we're just not communicating.  I'm imagining a scenario
in which there's something running in the background that -- oh,
let's say that running without competition it would use about 50%
of the available CPU cycles.  That reduces your lower-bound estimate
of idle CPU cycles per byte to 20, no?  and I don't find it hard
to imagine that unnecessary calculations could use those up, and
then the performance of either the background program or the OP's
program or both will be affected.

What am I not getting here?  Admittedly I'm not thinking it 
through in any great depth, but -- ?

>     The O.P. is fretting about "a lot of extra CPU cycles"
> (without having made any attempt to substantiate "a lot"),
> and I believe he is fretting needlessly.  An analogy I've
> used before: He's worrying about whether waxing his car
> will improve fuel economy by making it slipperier, or hurt
> fuel economy by adding weight.

It's a cute analogy and a valid point.  Cue chorus repeating
Knuth's well-known comment about premature optimization being
the root of all evil, maybe.

-- 
Decline To State
(But the e-mail address in the header is real.)

In article <5B5Th.29620$mo3.291224@weber.videotron.net>,
Oliver Wong <owong@castortech.com> wrote:
> 
> <blmblm@myrealbox.com> wrote in message 
> news:5841v9F2fnndoU2@mid.individual.net...
> >
> > Another thing:  My news server seems not to be getting all of
> > the OP's posts (unless they're just being delayed).  In a check
> > earlier of GG's archives, they have three messages from "me2"
> > (I may have these out of sequence):
> >
> > Message-Id: <pan.2007.04.10.17.42.52.231772@somewhere.com>
> > Message-Id: <pan.2007.04.10.18.06.18.52551@somewhere.com>
> > Message-Id: <pan.2007.04.10.19.01.55.168201@somewhere.com>
> >
> > but only the middle one has shown up, as of this writing, at
> > News.Individual.Net as best I can tell.  Anyone else notice
> > something similar?
> 
>     I got all 3, though I only saw the 3rd this morning. I'm using 
> Videotron's servers.

The other two posts apparently never showed up at my news server.
Huh.

-- 
Decline To State
(But the e-mail address in the header is real.)