Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #5757 > unrolled thread

StringBuilder Difficulties

Back to article view | Back to comp.lang.java.programmer

Contents

  StringBuilder Difficulties Gene Wirchenko <genew@ocis.net> - 2011-06-28 17:54 -0700
    Re: StringBuilder Difficulties Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-06-28 21:29 -0400
      Re: StringBuilder Difficulties Lew <noone@lewscanon.com> - 2011-06-29 00:48 -0400
        Re: StringBuilder Difficulties Gene Wirchenko <genew@ocis.net> - 2011-06-29 12:19 -0700
      Re: StringBuilder Difficulties Gene Wirchenko <genew@ocis.net> - 2011-06-29 12:11 -0700
        Re: StringBuilder Difficulties Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-06-29 22:06 -0400
    Re: StringBuilder Difficulties blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-06-29 20:17 +0000
      Re: StringBuilder Difficulties Gene Wirchenko <genew@ocis.net> - 2011-06-29 18:55 -0700
        Re: StringBuilder Difficulties blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-06-30 20:30 +0000
          Re: StringBuilder Difficulties Patricia Shanahan <pats@acm.org> - 2011-06-30 14:17 -0700
            Re: StringBuilder Difficulties Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-06-30 21:36 -0400
              Re: StringBuilder Difficulties "John B. Matthews" <nospam@nospam.invalid> - 2011-07-01 01:41 -0400
          Re: StringBuilder Difficulties Gene Wirchenko <genew@ocis.net> - 2011-06-30 14:26 -0700
            Re: StringBuilder Difficulties Steve Sobol <sjsobol@JustThe.net> - 2011-06-30 17:33 -0700
            Re: StringBuilder Difficulties blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-07-01 20:47 +0000
              Re: StringBuilder Difficulties Gene Wirchenko <genew@ocis.net> - 2011-07-01 17:29 -0700
                Re: StringBuilder Difficulties rossum <rossum48@coldmail.com> - 2011-07-02 11:36 +0100
                Re: StringBuilder Difficulties Robert Klemme <shortcutter@googlemail.com> - 2011-07-02 12:58 +0200
                  Re: StringBuilder Difficulties Gene Wirchenko <genew@ocis.net> - 2011-07-04 07:52 -0700
                    Re: StringBuilder Difficulties Robert Klemme <shortcutter@googlemail.com> - 2011-07-04 21:45 +0200
                      Re: StringBuilder Difficulties supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-07-05 02:06 -0400
                        Re: StringBuilder Difficulties markspace <-@.> - 2011-07-05 09:32 -0700
                          Re: StringBuilder Difficulties supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-07-05 14:13 -0400
                            Re: StringBuilder Difficulties markspace <-@.> - 2011-07-05 12:51 -0700
                              Re: StringBuilder Difficulties Silvio <silvio@moc.com> - 2011-07-05 23:16 +0200
                                Re: StringBuilder Difficulties markspace <-@.> - 2011-07-05 15:08 -0700
                                  Re: StringBuilder Difficulties Silvio <silvio@moc.com> - 2011-07-06 09:41 +0200
                                    Re: StringBuilder Difficulties "eye" <eye@mocka.com> - 2011-07-06 09:55 +0000
                                      Re: StringBuilder Difficulties thoolen <thoolen@tholenbot.thorium> - 2011-07-06 05:37 -0400
                                      Re: StringBuilder Difficulties "thoolen" <thoolen@tholenbot.thorium> - 2011-07-06 08:43 -0400
                                        Re: StringBuilder Difficulties thoolen <thoolen@tholenbot.thorium> - 2011-07-06 22:30 -0400
                              Re: StringBuilder Difficulties "Stefan Robacki" <noemail@noemail.foobar> - 2011-07-06 00:04 -0400
                                Re: StringBuilder Difficulties thoolen <thoolen@tholenbot.thorium> - 2011-07-06 05:45 -0400
                                Re: StringBuilder Difficulties thoolen <thoolen@tholenbot.thorium> - 2011-07-06 08:26 -0400
                                  Re: StringBuilder Difficulties thoolen <thoolen@tholenbot.thorium> - 2011-07-06 22:36 -0400
                                Re: StringBuilder Difficulties "tholen@antispam.ham" <tholen@ifa.hawaii.edu> - 2011-07-06 06:09 -0700
                                  Re: StringBuilder Difficulties supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-07-06 22:40 -0400
                                    Re: StringBuilder Difficulties John Doe <jdoe@usenetlove.invalid> - 2011-07-14 06:50 +0000
                                      Re: StringBuilder Difficulties supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-07-14 02:58 -0400
                                        Re: StringBuilder Difficulties Jane Doe <jdoe@love.in.d.jungle.invalid> - 2011-07-14 10:20 -0400
                                          Re: StringBuilder Difficulties thoolen <tholen01@gmail.com> - 2011-07-14 07:33 -0700
                          Re: StringBuilder Difficulties Stanimir Stamenkov <s7an10@netscape.net> - 2011-07-05 23:44 +0300
                            Re: StringBuilder Difficulties markspace <-@.> - 2011-07-05 14:08 -0700
                Re: StringBuilder Difficulties blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-07-02 18:33 +0000
                  Re: StringBuilder Difficulties supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-07-02 16:56 -0400
                  Re: StringBuilder Difficulties blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-07-03 01:34 +0000
                    Re: StringBuilder Difficulties Patricia Shanahan <pats@acm.org> - 2011-07-02 19:55 -0700
                      Re: StringBuilder Difficulties blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-07-04 03:32 +0000
                    Re: StringBuilder Difficulties Gene Wirchenko <genew@ocis.net> - 2011-07-04 08:04 -0700
                      Re: StringBuilder Difficulties blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-07-05 19:12 +0000
                        Re: StringBuilder Difficulties Gene Wirchenko <genew@ocis.net> - 2011-07-05 14:06 -0700
                          Re: StringBuilder Difficulties blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-07-05 21:16 +0000
                            Re: StringBuilder Difficulties Gene Wirchenko <genew@ocis.net> - 2011-07-05 17:29 -0700
                              Re: StringBuilder Difficulties blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-07-06 16:59 +0000
                                Re: StringBuilder Difficulties supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-07-06 19:52 -0400
                                  Re: StringBuilder Difficulties Patricia Shanahan <pats@acm.org> - 2011-07-06 16:58 -0700
                                    Re: StringBuilder Difficulties supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-07-06 19:52 -0400
                                      Re: StringBuilder Difficulties supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-07-06 21:54 -0400
                                        Re: StringBuilder Difficulties supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-07-06 22:18 -0400
                                          Re: StringBuilder Difficulties supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-07-06 22:41 -0400
                                    Re: StringBuilder Difficulties blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-07-08 17:45 +0000
                            Re: StringBuilder Difficulties supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-07-06 05:48 -0400
                              Re: StringBuilder Difficulties blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-07-06 16:59 +0000
                                Re: StringBuilder Difficulties Gene Wirchenko <genew@ocis.net> - 2011-07-06 10:56 -0700
                                  Re: StringBuilder Difficulties blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-07-08 17:44 +0000
                                    Re: StringBuilder Difficulties Gene Wirchenko <genew@ocis.net> - 2011-07-08 11:51 -0700
                                      Re: StringBuilder Difficulties blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-07-10 19:08 +0000
                                        Re: StringBuilder Difficulties Gene Wirchenko <genew@ocis.net> - 2011-07-11 07:54 -0700
                                          Re: StringBuilder Difficulties blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-07-11 22:37 +0000
                                            Re: StringBuilder Difficulties Gene Wirchenko <genew@ocis.net> - 2011-07-11 15:52 -0700
                            Re: StringBuilder Difficulties supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-07-06 08:25 -0400
                              Re: StringBuilder Difficulties supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-07-06 19:41 -0400
                                Re: StringBuilder Difficulties supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-07-06 19:58 -0400
                                  Re: StringBuilder Difficulties supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-07-06 21:57 -0400
                                    Re: StringBuilder Difficulties supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-07-06 22:17 -0400
                                      Re: StringBuilder Difficulties supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-07-06 22:44 -0400
                                        Re: StringBuilder Difficulties Steve Erwin <trollHunter@Usenet.4.usenetizens.org.invalid> - 2011-07-07 12:51 +1000
                                          Re: StringBuilder Difficulties supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-07-06 23:02 -0400
                                            Re: StringBuilder Difficulties John Doe <jdoe@usenetlove.invalid> - 2011-07-14 06:32 +0000
                                              Re: StringBuilder Difficulties supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-07-14 02:57 -0400
                                              Re: StringBuilder Difficulties Jane Doe <jdoe@love.in.d.jungle.invalid> - 2011-07-14 10:07 -0400
                                                Re: StringBuilder Difficulties thoolen <tholen01@gmail.com> - 2011-07-14 07:24 -0700
                  Re: StringBuilder Difficulties Gene Wirchenko <genew@ocis.net> - 2011-07-04 07:58 -0700
                    Re: StringBuilder Difficulties blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-07-05 19:09 +0000
                      Re: StringBuilder Difficulties KitKat <kitkat_11697@gmail.example.com> - 2011-07-05 15:15 -0400
                        Re: StringBuilder Difficulties blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-07-05 20:03 +0000
                      Re: StringBuilder Difficulties Gene Wirchenko <genew@ocis.net> - 2011-07-05 14:11 -0700
                        Re: StringBuilder Difficulties blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-07-06 16:55 +0000
        Re: StringBuilder Difficulties lewbloch <lewbloch@gmail.com> - 2011-07-03 00:08 -0700
          Re: StringBuilder Difficulties Robert Klemme <shortcutter@googlemail.com> - 2011-07-03 12:35 +0200
            Re: StringBuilder Difficulties lewbloch <lewbloch@gmail.com> - 2011-07-04 04:07 -0700
    Re: StringBuilder Difficulties Patricia Shanahan <pats@acm.org> - 2011-06-29 14:38 -0700
      Re: StringBuilder Difficulties Gene Wirchenko <genew@ocis.net> - 2011-06-29 15:00 -0700
        Re: StringBuilder Difficulties Patricia Shanahan <pats@acm.org> - 2011-06-29 15:52 -0700
          Re: StringBuilder Difficulties Gene Wirchenko <genew@ocis.net> - 2011-06-29 18:58 -0700
            Re: StringBuilder Difficulties Patricia Shanahan <pats@acm.org> - 2011-06-29 19:26 -0700
            Re: StringBuilder Difficulties lewbloch <lewbloch@gmail.com> - 2011-07-03 00:11 -0700
    Re: StringBuilder Difficulties Roedy Green <see_website@mindprod.com.invalid> - 2011-06-29 18:32 -0700

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#6194

On Jul 14, 10:20 am, Jane Doe <jdoe@love.in.d.jungle.invalid> wrote:
2> Newsgroups: comp.lang.java.programmer,comp.lang.lisp,
2> comp.lang.java.help

2> supercalifxxxxPaul Derbyshire - Pembroke Ontario CA
2> of NNTP-Posting-Host: i/Qx8aG7GhfvVWTGQz7VLw.user.speranza.aioe.org
2> did make foam with:

Who is "supercalifxxxxPaul Derbyshire", Doe? There is nobody in this
newsgroup using that alias.

2> suffering from comprehension challenges much, idiot.

Who is "idiot", Doe? There is nobody in this newsgroup using that
alias.

2> Java related, Derbyshire?

Who is "Derbyshire", Doe? There is nobody in this newsgroup using that
alias.

2> try on the fact you cannot code Derbyshire into an AIOE post
2> as you shot yourself big time in directing AIOE to provide a word
ban for
2> Derbyshire.

What does your classic unsubstantiated and erroneous claim have to do
with Java, Doe?

2> yeh, that's right. it is news all over.

What does your classic ambiguity have to do with Java, Doe?

2> Derbyshire the lamer whined to AIOE and AIOE gave him what he
2> wanted and now Derbyshire is fucked in using "reply-to" without
2> doing a whole heap of editing.

Who is "Derbyshire the lamer", Doe? There is nobody in this newsgroup
using that alias.

2> classic "usenet suicide" act you got  there Derbyshire

Who is "Derbyshire", Doe? There is nobody in this newsgroup using that
alias.

2> hear this sucker.

Who is "sucker", Doe? There is nobody in this newsgroup using that
alias.

2> yall is fucked with these Java groups.

What does your classic unsubstantiated and erroneous claim have to do
with Java, Doe? There is a post from
supercalifragilisticexpialadiamaticonormalizeringelimatisticantations
dated just a couple of hours ago that is on topic and useful, Doe.

2> credibility is zero with tracking easy on your posting tag for AIOE
2> and now Google.

What does your net.stalking of an innocent and mistakenly-identified
man have to do with Java, Doe?

2> what yall gonna do Squirrel BOY.

Who is "Squirrel BOY", Doe? There is nobody in this newsgroup using
that alias.

2> hands over ears and stamp ya lil Derbyshire feet till the guys
2> in white coats rock up!

Who is "Derbyshire", Doe? There is nobody in this newsgroup using that
alias.

2> BWAaaAAAAAAAAAAAHhHAAAAAAAAAAAAAAAAAAAA

What does your maniacal laughter have to do with Java, madman?

[toc] | [prev] | [next] | [standalone]

#5869

Tue, 05 Jul 2011 09:32:16 -0700, /markspace/:
> On 7/4/2011 11:06 PM, super... wrote:
>>
>> public foobar (int a, String b) {
>>   x = a + b.length();
>>   y = 1.3*x;
>
> You go through quite a bit of verbiage to justify not typing int and
> double in front of those last two lines.

Just wanted to point out, Gosu [1] is statically typed language 
(compiled to a JVM bytecode) with type inference, where one could write:

function foobar (a : int, b : String) {
    var x = a + b.length();
    var y = 1.3 * x;

The difference with the previously given example seems one still 
needs variable declaration (using the 'var' keyword).

While 'double' and 'int' are short enough, with Gosu one could just 
write:

   var a = new MyVeryLongClassName<Foo,BarBaz>();

which appears even better than the Java 7 <> (diamond) operator. 
Note Gosu supports explicit variable type declarations, also.

[1] http://en.wikipedia.org/wiki/Gosu_%28programming_language%29

-- 
Stanimir

[toc] | [prev] | [next] | [standalone]

#5871

On 7/5/2011 1:44 PM, Stanimir Stamenkov wrote:

> var a = new MyVeryLongClassName<Foo,BarBaz>();
>
> which appears even better than the Java 7 <> (diamond) operator. Note
> Gosu supports explicit variable type declarations, also.


Right.  I understand it's possible.  I just don't think its necessary. 
The arguments presented just aren't enough to make me run off and switch 
languages, or complain to Oracle about it.  I don't think any of these 
suggestions where even offered to Project Coin a while back.

I understand too that some of you all might just be making conversation 
about Java.  Fair enough.  But understand I'm just making conversation 
back, and for the most part my conversation has been to shrug and say 
it's not really convincing.

[toc] | [prev] | [next] | [standalone]

#5822

In article <e9ps07h56utkftkp8fcarm7uhkk5t999le@4ax.com>,
Gene Wirchenko  <genew@ocis.net> wrote:
> On 1 Jul 2011 20:47:47 GMT, blmblm@myrealbox.com
> <blmblm.myrealbox@gmail.com> wrote:
> 
> >In article <6cqp07tiug2nu8u6ififvvek1694fkpfi1@4ax.com>,
> >Gene Wirchenko  <genew@ocis.net> wrote:
> >> On 30 Jun 2011 20:30:00 GMT, blmblm@myrealbox.com
> >> <blmblm.myrealbox@gmail.com> wrote:
> >> 
> >> [snip]
> >> 
> >> >A general comment:  I'm inclined to agree with the people who are
> >> >saying that in general it seems like you're trying to write [name
> >> >of your favorite language] programs in Java, and in the long term
> >> >that seems less optimal than trying to grok the Java mindset.  
> >> 
> >>      My mindset is that I want to get my work done.  I do not care
> >> about the Java mindset except as it helps me get my work done.
> >
> >Yes, and if you were going to do a lot of programming in Java it
> >would seem to make sense to adapt to the local customs, so to speak.
> >Not to do so seems to me like fighting with your tools, which, well,
> >I do it too sometimes, but it does get in the way of getting stuff
> >done.
> 
>      My tools include manyyears of experience programming.  I do not
> think that Java is such a precious snowflake -- the same is true of
> any language -- that I should have to throw all that experience away
> in order to use the language.

As another poster has responded, I'm not convinced that's what
you're being asked to do (though you obviously feel otherwise).

It seems to me that one of the things one learns from doing a lot
of coding in a lot of languages is recognizing when something is
the same as what you've done before, just with different syntax,
and when it's different.

<shrug>

> >> >I think part of it may be struggling with the object-oriented
> >> >paradigm, but part of it may just be coming to terms with the fact
> >> 
> >>      No, I am experienced with OOP.
> >
> >Huh.  Well, with all due respect ....
> >
> >I'd have said otherwise given that all of the variables and methods
> >in your TimingTesting program (the version I tried revising) seem
> >to be static (except the local variables).  I'm also puzzled by why
> >that program duplicates so much code, when you could have factored
> >out the parts that are different using objects-as-code-wrappers.
> >But maybe the O-O languages you've used before don't make you do
> >that, and adapting to that particular Java idiom seemed not worth
> >the trouble.
> 
>      Oh, I asked about that.  One apparently can not pass a function
> pointer parameter as in C.  The ways that were posted involved lookup
> every time AFIACS and I judged that it might swamp what I was
> measuring (checking if a character were in a set).  So, to my chagrin,
> I had to go with cut-and-paste.

Without experimenting to find out, of course ....  

It seems to me that virtual method invocations are so common in
Java that they would be well-optimized.  But if you want to claim
that the code you eventually hope to produce won't have one, well,
yeah, that's true, so maybe it matters.  Then again, wouldn't a
similar argument apply to C with function pointers?  Maybe not.
I don't seem to be able to think this through as carefully as
I'd like.

Anyway, I was curious, so I ran your code and my revision [1], and
the results were -- surprising [2].  I noticed, by the way, that
all three of your parse methods make a call to SequentialSearch,
assigning the result to a variable that apparently isn't used.
Thinking that *might* be a mistake, I also tried your code and my
revision with that possibly-extra call removed.

[1] Message-ID: <96k6atFt60U2@mid.individual.net>

[2] I tried this on several different systems, all Fedora Linux
running Java 1.6.0_21 but different hardware and different releases
of Fedora.  I was going to include results here, but in trying
the experiment on additional systems I'm less and less convinced
the results would mean anything without my putting more effort
into it than I'm up for.  (Usually when I'm timing something
I try it twice, and if results are close enough I don't bother
with additional trials.  In this case results of two trials were
just different enough for me to think I'd need to do more to get
meaningful results.)  Briefly, though .... :

Your code was fairly (but not 100%!) consistent in showing
treeset-based search to be fastest, followed by binary search and
then sequential search, though sometimes the difference between
sequential and binary was small.  My code was -- well, this is where
it's surprising.  On most of the systems where I tried it, treeset
search was fastest, but sequential search was faster than binary
search; on one system, however, the order was as for your code.
Your code was pretty consistently faster than mine, though usually
not by a lot (less than 1%).

> >> >that Java is, as I think Patricia Shanahan said not long ago
> >> >(possibly in another thread), that Java is just plain verbose.
> >> 
> >>      Well, I posted about the verbosity earlier and got flak over it.
> >> 
> >> >But I have some sympathy with the desire just to get something 
> >> >running:  I spent a number of hours a while back trying to teach
> >> 
> >>      And without having to buy into a language religion.
> >
> >Hm.  I wouldn't say that adapting to local customs constitutes
> >buying into a language religion.  YMMV, I suppose.
> 
>      Some of the posters have been quite vociferous about it.

I've noticed a certain amount of, oh, "contentiousness" maybe, on both
sides.  Sort of a :-), sort of not.  

(Aside:  I recognize your name from alt.folklore.computers, where
you seem, oh, much more mild-mannered.  Hm.)

> >> >myself some Scheme and in the process trying make it conform to
> >> >my strongly-typed-languages-trained mindset, and I'd probably
> >> >have done better to get a good introductory book and try to grok
> >> >the no-types(?) mindset.  (Maybe I'll try again at some point.)
> 
>      I am pretty much past the intro stage and into the pain stage
> where there is not so much help.

That people are not willing to offer further help when many of their
previous suggestions have been rejected should not be a total surprise.
<shrug>

-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.

[toc] | [prev] | [next] | [standalone]

#5823

On 02/07/2011 2:33 PM, blmblm@myrealbox.com wrote:
> (Aside:  I recognize your name from alt.folklore.computers, where
> you seem, oh, much more mild-mannered.  Hm.)

CLJP seems to bring out a contentious streak in people.

[toc] | [prev] | [next] | [standalone]

#5827

In article <9796kgFoijU3@mid.individual.net>,
blmblm@myrealbox.com  <blmblm.myrealbox@gmail.com> wrote:
> In article <e9ps07h56utkftkp8fcarm7uhkk5t999le@4ax.com>,
> Gene Wirchenko  <genew@ocis.net> wrote:
> > On 1 Jul 2011 20:47:47 GMT, blmblm@myrealbox.com
> > <blmblm.myrealbox@gmail.com> wrote:
> > 
> > >In article <6cqp07tiug2nu8u6ififvvek1694fkpfi1@4ax.com>,
> > >Gene Wirchenko  <genew@ocis.net> wrote:
> > >> On 30 Jun 2011 20:30:00 GMT, blmblm@myrealbox.com
> > >> <blmblm.myrealbox@gmail.com> wrote:

[ snip ]

> >      Oh, I asked about that.  One apparently can not pass a function
> > pointer parameter as in C.  The ways that were posted involved lookup
> > every time AFIACS and I judged that it might swamp what I was
> > measuring (checking if a character were in a set).  So, to my chagrin,
> > I had to go with cut-and-paste.
> 
> Without experimenting to find out, of course ....  
> 
> It seems to me that virtual method invocations are so common in
> Java that they would be well-optimized.  But if you want to claim
> that the code you eventually hope to produce won't have one, well,
> yeah, that's true, so maybe it matters.  Then again, wouldn't a
> similar argument apply to C with function pointers?  Maybe not.
> I don't seem to be able to think this through as carefully as
> I'd like.
> 
> Anyway, I was curious, so I ran your code and my revision [1], and
> the results were -- surprising [2].  I noticed, by the way, that
> all three of your parse methods make a call to SequentialSearch,
> assigning the result to a variable that apparently isn't used.
> Thinking that *might* be a mistake, I also tried your code and my
> revision with that possibly-extra call removed.

UPDATE:  I just re-read the previous threads and realized that
your code actually calls SequentialSearch in the method that's
supposed to be timing BinarySearch.  Once I fix that ....

> [1] Message-ID: <96k6atFt60U2@mid.individual.net>
> 
> [2] I tried this on several different systems, all Fedora Linux
> running Java 1.6.0_21 but different hardware and different releases
> of Fedora.  

[ snip ]

> Your code was fairly (but not 100%!) consistent in showing
> treeset-based search to be fastest, followed by binary search and
> then sequential search, though sometimes the difference between
> sequential and binary was small.  My code was -- well, this is where
> it's surprising.  On most of the systems where I tried it, treeset
> search was fastest, but sequential search was faster than binary
> search; on one system, however, the order was as for your code.
> Your code was pretty consistently faster than mine, though usually
> not by a lot (less than 1%).

Both programs (yours and mine) now consistently report sequential
search to be faster than binary search.  Weird, but not as weird as
the two being different in that regard ....

[ snip ]

-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.

[toc] | [prev] | [next] | [standalone]

#5828

On 7/2/2011 6:34 PM, blmblm@myrealbox.com wrote:
...
> Both programs (yours and mine) now consistently report sequential
> search to be faster than binary search.  Weird, but not as weird as
> the two being different in that regard ....
...

Binary search can have a much higher constant multiplier on its time
than sequential search. If the searches are long enough, the O(log n) vs
O(n) complexity difference should dominate over the constant multiplier,
but for short searches the constant multiplier can dominate.

Binary search is more expensive than it looks because of branch
prediction.

A lot of processors have deep, wide pipelines. The problem is that the
processor has to decide which instructions to feed into the pipeline
immediately after feeding in a conditional branch, but will not *know*
whether the branch was taken or not until it gets near the other end of
the pipeline. The solution is to cache information about the conditional
branches, and try to predict the branch based only on branch history and
the cache. Performance of code with a lot of conditional branches
depends on how well the processor does at predicting the branches.

Each binary search iteration includes an unpredictable branch which will
be guessed wrong about half the time.

On the other hand, the conditional branch in each iteration of the
sequential search will usually be correctly predicted, except for the
one at the end of the search.

The only way to know which way round this will come out is indeed to
measure, making sure the searches are as similar as possible to the real
workload.

Patricia

[toc] | [prev] | [next] | [standalone]

#5840

In article <CZGdnS-Ag6OPR5LTnZ2dnUVZ_oqdnZ2d@earthlink.com>,
Patricia Shanahan  <pats@acm.org> wrote:
> On 7/2/2011 6:34 PM, blmblm@myrealbox.com wrote:
> ...
> > Both programs (yours and mine) now consistently report sequential
> > search to be faster than binary search.  Weird, but not as weird as
> > the two being different in that regard ....
> ...
> 
> Binary search can have a much higher constant multiplier on its time
> than sequential search. If the searches are long enough, the O(log n) vs
> O(n) complexity difference should dominate over the constant multiplier,
> but for short searches the constant multiplier can dominate.

Of course -- I know better than to think computational complexity
is the whole story, especially in dealing with small problem sizes,
which I think is what we have here.  (Why I notice this kind of 
"what was I thinking?" only after posting, who knows.)

> Binary search is more expensive than it looks because of branch
> prediction.

Which makes sense ....  

[ snip ]

> The only way to know which way round this will come out is indeed to
> measure, making sure the searches are as similar as possible to the real
> workload.

Which is apparently by no means straightforward in Java!  I recently
skimmed through the articles by Brian Goetz referenced in one of
Stefan Ram's posts from a while back, and -- fascinating stuff.

-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.

[toc] | [prev] | [next] | [standalone]

#5851

On 3 Jul 2011 01:34:30 GMT, blmblm@myrealbox.com
<blmblm.myrealbox@gmail.com> wrote:

>In article <9796kgFoijU3@mid.individual.net>,
>blmblm@myrealbox.com  <blmblm.myrealbox@gmail.com> wrote:
>> In article <e9ps07h56utkftkp8fcarm7uhkk5t999le@4ax.com>,
>> Gene Wirchenko  <genew@ocis.net> wrote:
>> > On 1 Jul 2011 20:47:47 GMT, blmblm@myrealbox.com
>> > <blmblm.myrealbox@gmail.com> wrote:
>> > 
>> > >In article <6cqp07tiug2nu8u6ififvvek1694fkpfi1@4ax.com>,
>> > >Gene Wirchenko  <genew@ocis.net> wrote:
>> > >> On 30 Jun 2011 20:30:00 GMT, blmblm@myrealbox.com
>> > >> <blmblm.myrealbox@gmail.com> wrote:
>
>[ snip ]

>UPDATE:  I just re-read the previous threads and realized that
>your code actually calls SequentialSearch in the method that's
>supposed to be timing BinarySearch.  Once I fix that ....

     Yeah, I caught that goof later, too.  Or was that one pointed
out?  There was at least one goof that got pointed out to me.  Cut and
paste is a horrible way to have to do it.

[snip]

>Both programs (yours and mine) now consistently report sequential
>search to be faster than binary search.  Weird, but not as weird as
>the two being different in that regard ....

     That is not the result that I got.  Sequential search was
occasionally faster but usually a bit slower the binary search.

     Someone posted links about the difficulty of Java benchmarking.
If it really mattered (checking for *small* differences), I would use
them and may well in a future test when it does.  The difference
between the binary search and the Treeset search was sufficiently and
consistently different that I went with Treeset.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#5863

In article <ual3175uj4e5jb7u44q8jn7soo7k532heq@4ax.com>,
Gene Wirchenko  <genew@ocis.net> wrote:
> On 3 Jul 2011 01:34:30 GMT, blmblm@myrealbox.com
> <blmblm.myrealbox@gmail.com> wrote:
> 
> >In article <9796kgFoijU3@mid.individual.net>,
> >blmblm@myrealbox.com  <blmblm.myrealbox@gmail.com> wrote:
> >> In article <e9ps07h56utkftkp8fcarm7uhkk5t999le@4ax.com>,
> >> Gene Wirchenko  <genew@ocis.net> wrote:
> >> > On 1 Jul 2011 20:47:47 GMT, blmblm@myrealbox.com
> >> > <blmblm.myrealbox@gmail.com> wrote:
> >> > 
> >> > >In article <6cqp07tiug2nu8u6ififvvek1694fkpfi1@4ax.com>,
> >> > >Gene Wirchenko  <genew@ocis.net> wrote:
> >> > >> On 30 Jun 2011 20:30:00 GMT, blmblm@myrealbox.com
> >> > >> <blmblm.myrealbox@gmail.com> wrote:
> >
> >[ snip ]
> 
> >UPDATE:  I just re-read the previous threads and realized that
> >your code actually calls SequentialSearch in the method that's
> >supposed to be timing BinarySearch.  Once I fix that ....
> 
>      Yeah, I caught that goof later, too.  Or was that one pointed
> out?  There was at least one goof that got pointed out to me.  Cut and
> paste is a horrible way to have to do it.

I think there was one mistake that was pointed out (wrong search) and
one that was not (extra use of SequentialSearch in all methods).

> [snip]
> 
> >Both programs (yours and mine) now consistently report sequential
> >search to be faster than binary search.  Weird, but not as weird as
> >the two being different in that regard ....
> 
>      That is not the result that I got.  Sequential search was
> occasionally faster but usually a bit slower the binary search.

Interesting.  So maybe I should try this on a few more systems ....

When I do, I find that on newer systems indeed binary search was
at least a bit faster.  On older ones, not so much.  Patricia
Shanahan's theory (about why binary search could be slower)
makes sense to me and also provides a plausible explanation of
why results could vary among systems.

>      Someone posted links about the difficulty of Java benchmarking.
> If it really mattered (checking for *small* differences), I would use
> them and may well in a future test when it does.  The difference
> between the binary search and the Treeset search was sufficiently and
> consistently different that I went with Treeset.

What I found is that HashSet was noticeably faster on all the
systems where I ran the benchmarks.  Unless you need for the set
to be sorted (and it's not apparent from your code that you do),
why not .... ?  (I'm curious too about why you chose TreeSet in
the first place.  ? )

-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.

[toc] | [prev] | [next] | [standalone]

#5870

On 5 Jul 2011 19:12:39 GMT, blmblm@myrealbox.com
<blmblm.myrealbox@gmail.com> wrote:

[snip]

>What I found is that HashSet was noticeably faster on all the
>systems where I ran the benchmarks.  Unless you need for the set
>to be sorted (and it's not apparent from your code that you do),
>why not .... ?  (I'm curious too about why you chose TreeSet in
>the first place.  ? )

  1) I can output the set in order without having to do anything else.
My real program has a lot of debugging info dumping.  (Read as "checks
that I have not done something wrong".)

  2) When I read "hash", I think "collision", and I get nervous.
Nothing I read reassured me that that could not happen.

  3) I had to pick something.  If it works, I can change it later.  If
it does not, I have not solved my problem yet.  The former is safer.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#5874

In article <jsu6171vmasu6jfvsbroa052n8u7ukarr3@4ax.com>,
Gene Wirchenko  <genew@ocis.net> wrote:
> On 5 Jul 2011 19:12:39 GMT, blmblm@myrealbox.com
> <blmblm.myrealbox@gmail.com> wrote:
> 
> [snip]
> 
> >What I found is that HashSet was noticeably faster on all the
> >systems where I ran the benchmarks.  Unless you need for the set
> >to be sorted (and it's not apparent from your code that you do),
> >why not .... ?  (I'm curious too about why you chose TreeSet in
> >the first place.  ? )
> 
>   1) I can output the set in order without having to do anything else.
> My real program has a lot of debugging info dumping.  (Read as "checks
> that I have not done something wrong".)


Ah.  Well, yes, then you probably do need a SortedSet, though
considering that you initially build the set from a string that's in
order, maybe you could use that (the string) instead.  Just sayin',
maybe.


>   2) When I read "hash", I think "collision", and I get nervous.
> Nothing I read reassured me that that could not happen.


Why would that make you nervous?  If you're worried about
correctness, um, as far as I know hash tables are supposed to
deal with collisions in some way that preserves the overall "map"
semantics.  Performance may suffer if there are a lot of collisions,
but -- benchmark on the system(s) of interest and check?


>   3) I had to pick something.  If it works, I can change it later.  If
> it does not, I have not solved my problem yet.  The former is safer.


Sure.  Then again, if you were only concerned about getting something
that works, why try various alternatives ....  <shrug>


-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.

[toc] | [prev] | [next] | [standalone]

#5878

On 5 Jul 2011 21:16:44 GMT, blmblm@myrealbox.com
<blmblm.myrealbox@gmail.com> wrote:

>In article <jsu6171vmasu6jfvsbroa052n8u7ukarr3@4ax.com>,
>Gene Wirchenko  <genew@ocis.net> wrote:
>> On 5 Jul 2011 19:12:39 GMT, blmblm@myrealbox.com
>> <blmblm.myrealbox@gmail.com> wrote:
>> 
>> [snip]
>> 
>> >What I found is that HashSet was noticeably faster on all the
>> >systems where I ran the benchmarks.  Unless you need for the set
>> >to be sorted (and it's not apparent from your code that you do),
>> >why not .... ?  (I'm curious too about why you chose TreeSet in
>> >the first place.  ? )
>> 
>>   1) I can output the set in order without having to do anything else.
>> My real program has a lot of debugging info dumping.  (Read as "checks
>> that I have not done something wrong".)
>
>
>Ah.  Well, yes, then you probably do need a SortedSet, though
>considering that you initially build the set from a string that's in
>order, maybe you could use that (the string) instead.  Just sayin',
>maybe.

     I set the string value that way so that the binary search would
work.

>>   2) When I read "hash", I think "collision", and I get nervous.
>> Nothing I read reassured me that that could not happen.

>Why would that make you nervous?  If you're worried about
>correctness, um, as far as I know hash tables are supposed to
>deal with collisions in some way that preserves the overall "map"
>semantics.  Performance may suffer if there are a lot of collisions,
>but -- benchmark on the system(s) of interest and check?

     I would need to know what the behaviour is supposed to be.  I
have something that works for now.  Optimisation comes after getting
it working.

>>   3) I had to pick something.  If it works, I can change it later.  If
>> it does not, I have not solved my problem yet.  The former is safer.

>Sure.  Then again, if you were only concerned about getting something
>that works, why try various alternatives ....  <shrug>

     1) Just in case there was a BIG difference.  2) To learn more
about Java.  At some point though, I have to do something useful with
it.

     My preprocessor is shaping up nicely.  I have to write the symbol
define command code, handle the include command, and handle output to
a file.  That is about it.  Which means that there are probably only
about three other things that I will come up.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#5910

In article <rma717948c79cs9nnupdqjrhuu965bag76@4ax.com>,
Gene Wirchenko  <genew@ocis.net> wrote:
> On 5 Jul 2011 21:16:44 GMT, blmblm@myrealbox.com
> <blmblm.myrealbox@gmail.com> wrote:
> 
> >In article <jsu6171vmasu6jfvsbroa052n8u7ukarr3@4ax.com>,
> >Gene Wirchenko  <genew@ocis.net> wrote:
> >> On 5 Jul 2011 19:12:39 GMT, blmblm@myrealbox.com
> >> <blmblm.myrealbox@gmail.com> wrote:
> >> 
> >> [snip]
> >> 
> >> >What I found is that HashSet was noticeably faster on all the
> >> >systems where I ran the benchmarks.  Unless you need for the set
> >> >to be sorted (and it's not apparent from your code that you do),
> >> >why not .... ?  (I'm curious too about why you chose TreeSet in
> >> >the first place.  ? )
> >> 
> >>   1) I can output the set in order without having to do anything else.
> >> My real program has a lot of debugging info dumping.  (Read as "checks
> >> that I have not done something wrong".)
> >
> >
> >Ah.  Well, yes, then you probably do need a SortedSet, though
> >considering that you initially build the set from a string that's in
> >order, maybe you could use that (the string) instead.  Just sayin',
> >maybe.
> 
>      I set the string value that way so that the binary search would
> work.

Ah, okay.  

> >>   2) When I read "hash", I think "collision", and I get nervous.
> >> Nothing I read reassured me that that could not happen.
> 
> >Why would that make you nervous?  If you're worried about
> >correctness, um, as far as I know hash tables are supposed to
> >deal with collisions in some way that preserves the overall "map"
> >semantics.  Performance may suffer if there are a lot of collisions,
> >but -- benchmark on the system(s) of interest and check?
> 
>      I would need to know what the behaviour is supposed to be.  

Maybe there's something I'm not understanding, but as far as I
know hash tables (including the Java HashMap class that, according
to the API, is used by HashSet) are required to do something that
allows storing multiple distinct keys that have the same hash code
("collisions").  The implementation that comes to mind is one that
has some sort of list for each possible hashcode value.  Obviously(?)
performance suffers if very many of these lists have more than one
or a few elements, but correctness (in the sense of considering
keys to be equal based only on what equals() returns and not on 
what hashCode() returns) is preserved.

I don't think I'm explaining this very well.  Maybe the following
short test program will do better -- it's a totally contrived example
of using a HashSet to store elements that are distinct but have the
same hash code:

import java.util.*;

public class HashSetTest {

    public static class Foo {
        public final int n;

        public Foo(int n) {
            this.n = n;
        }

        @Override
        public int hashCode() {
            return 0;
        }

        @Override
        public boolean equals(Object obj) {
            if (obj instanceof Foo) {
                return n == ((Foo) obj).n;
            }
            else {
                return false;
            }
        }
    }
 
    public static void main(String[] args) {
        Set<Foo> s = new HashSet<Foo>();
        // add what should be ten distinct elements
        for (int i = 0; i < 10; ++i) {
            s.add(new Foo(i));
        }
        // add what should be duplicate elements
        for (int i = 0; i < 10; ++i) {
            s.add(new Foo(i));
        }
        // iterate over all elements of s -- this "foreach" syntax
        // is possible AFAIK with all classes that implement Collection
        for (Foo foo : s) {
            // note use of C-like printf
            System.out.printf("foo with value %d, hashcode %d\n",
                    foo.n, foo.hashCode());
        }
    }
}

When I run this I get 10 lines of output, indicating to me that 
whether two elements are considered duplicates depends on equality
as determined by the equals() method rather than on hashcode.

Or maybe I'm once again totally misunderstanding you, and your actual
concern is something else ....

> I
> have something that works for now.  Optimisation comes after getting
> it working.

Well, yeah, sure, but this rather seems at odds with your having
done benchmarking of various ways of looking up a character in a
set of characters.

Anyway if at some point it seems that performance of your lookup 
isn't good enough, it might be worthwhile to explore HashSet, if
you can think of some way to get the debugging information you need
that doesn't depend on being able to retrieve elements from the set
in sorted order.  (E.g., maybe you could do a one-time operation 
that retrieves all the elements, sorts them, and saves the result.)

Or, as supercali* suggests in another post, you could use a
LinkedHashSet.  Replace HashSet with LinkedHashSet in the above test
program to see the difference.  This would require you to build your
set from elements in the right order, but assuming building the set
is a one-time thing, it should be easy enough to sort the elements
before adding them, or so I would think.  

> >>   3) I had to pick something.  If it works, I can change it later.  If
> >> it does not, I have not solved my problem yet.  The former is safer.
> 
> >Sure.  Then again, if you were only concerned about getting something
> >that works, why try various alternatives ....  <shrug>
> 
>      1) Just in case there was a BIG difference.  

In my experiments HashSet was about twice as fast as TreeSet.  Of
course if you needed the sortedness, HashSet is off the table, but
LinkedHashSet (which I did not know about!) seems like it would do
what you need and is about as fast as HashSet on the systems where
I tried it.

The code using java.util.regex.* wasn't as fast on the old system
where I did my initial experiments, but on a newer system it seems
to give performance comparable to (Linked)HashSet.

Just sayin'.

> 2) To learn more
> about Java.  At some point though, I have to do something useful with
> it.

Sure.  I'm dimly aware that I'm probably flogging a horse that has long
since shuffled off this mortal coil.

>      My preprocessor is shaping up nicely.  I have to write the symbol
> define command code, handle the include command, and handle output to
> a file.  That is about it.  Which means that there are probably only
> about three other things that I will come up.

And then you can go back to coding in a language you like better?  :-)

-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.

[toc] | [prev] | [next] | [standalone]

#5928

On 06/07/2011 12:59 PM, blmblm@myrealbox.com wrote:
>          // iterate over all elements of s -- this "foreach" syntax
>          // is possible AFAIK with all classes that implement Collection
>          for (Foo foo : s) {
>              // note use of C-like printf
>              System.out.printf("foo with value %d, hashcode %d\n",
>                      foo.n, foo.hashCode());
>          }

In fact, it's possible with all classes that implement Iterable; the 
Collection interface extends Iterable so you are correct, but it goes 
further than just Collection.

The only classes in java.* and javax.* that implement it seem to 
implement Collection (you'd think CharSequence as well, and perhaps even 
Map and/or Enumeration or all the legacy classes that provide an 
Enumeration, but no), but third party libraries can in principle 
implement it separately.

The foreach syntax can also be used with arrays, including arrays of 
unboxed primitives, even though using reflection on an array (e.g. (new 
Object[3]).getClass().getInterfaces();) only shows it implementing 
Cloneable and Serializable, not Iterable.

[toc] | [prev] | [next] | [standalone]

#5929

On 7/6/2011 4:52 PM, 
supercalifragilisticexpialadiamaticonormalizeringelimatisticantations wrote:
...
> The foreach syntax can also be used with arrays, including arrays of
> unboxed primitives, even though using reflection on an array (e.g. (new
> Object[3]).getClass().getInterfaces();) only shows it implementing
> Cloneable and Serializable, not Iterable.

The JLS says that the enhanced for statement expression "must either
have type Iterable or else it must be of an array type (§10.1), or a
compile-time error occurs."

[http://java.sun.com/docs/books/jls/third_edition/html/statements.html#14.14.2]

Patricia

[toc] | [prev] | [next] | [standalone]

#5935

On 06/07/2011 4:58 PM, Patricia Shanahan wrote:
>On 7/6/2011 4:52 PM, 
>supercalifragilisticexpialadiamaticonormalizeringelimatisticantations wrote:
>...
>> The foreach syntax can also be used with arrays, including arrays of
>> unboxed primitives, even though using reflection on an array (e.g. (new
>> Object[3]).getClass().getInterfaces();) only shows it implementing
>> Cloneable and Serializable, not Iterable.
>
>The JLS says that the enhanced for statement expression "must either
>have type Iterable or else it must be of an array type (§10.1), or a
>compile-time error occurs."
>
>[http://java.sun.com/docs/books/jls/third_edition/html/statements.html#14.14.2]
>
>Patricia

YABT

[toc] | [prev] | [next] | [standalone]

#5938

supercali ... wrote:
> On 06/07/2011 4:58 PM, Patricia Shanahan wrote:
>> On 7/6/2011 4:52 PM,
>> supercali ... wrote:
>>> The foreach syntax can also be used with arrays, including arrays of
>>> unboxed primitives, even though using reflection on an array (e.g. (new
>>> Object[3]).getClass().getInterfaces();) only shows it implementing
>>> Cloneable and Serializable, not Iterable.
>>
>> The JLS says that the enhanced for statement expression "must either
>> have type Iterable or else it must be of an array type (§10.1), or a
>> compile-time error occurs."
>>
>> [http://java.sun.com/docs/books/jls/third_edition/html/statements.html#14.14.2]
>>
>> Patricia
>
> YABT

WTF? I didn't write that. And what does "YABT" even mean?

Why are posts appearing in this newsgroup with my name on them that I 
didn't write???

[toc] | [prev] | [next] | [standalone]

#5941

On 06/07/2011 8:54 PM, Paul Derbyshire - Pembroke[ontario.ca] wrote:
>supercali ... wrote:
>> On 06/07/2011 4:58 PM, Patricia Shanahan wrote:
>>> On 7/6/2011 4:52 PM,
>>> supercali ... wrote:
>>>> The foreach syntax can also be used with arrays, including arrays of
>>>> unboxed primitives, even though using reflection on an array (e.g. (new
>>>> Object[3]).getClass().getInterfaces();) only shows it implementing
>>>> Cloneable and Serializable, not Iterable.
>>>
>>> The JLS says that the enhanced for statement expression "must either
>>> have type Iterable or else it must be of an array type (§10.1), or a
>>> compile-time error occurs."
>>>
>>> [http://java.sun.com/docs/books/jls/third_edition/html/statements.html#14.14.2]
>>>
>>> Patricia
>>
>> YABT
>
>WTF? I didn't write that. And what does "YABT" even mean?
>
Go fetch it yourself you lazy fat cunt!
http://www.acronymfinder.com/KP~3.html

>Why are posts appearing in this newsgroup with my name on them that I 
>didn't write???
>
oH did you not?
bummer that!

SNNNAAAAAAAAAAAAAAAAAAAAAAAARRRRRFFF

[toc] | [prev] | [next] | [standalone]

#5947

On 06/07/2011 10:18 PM, I didn't write:
> On 06/07/2011 8:54 PM, Paul Derbyshire - Pembroke[ontario.ca] wrote

No, he didn't, I did.

>> WTF? I didn't write that. And what does "YABT" even mean?
>
> Go fetch it yourself you lazy fat cunt!

ExCUSE me?

What the hell is the matter with you, and why don't you think up your 
own handle and stop using mine to post profanity and flames!

>> Why are posts appearing in this newsgroup with my name on them that I
>> didn't write???
>
> oH did you not?
> bummer that!

You, sir, have an attitude problem.

Get your own From line.

Get your attitude adjusted.

Get the hell out of cljp.

[toc] | [prev] | [next] | [standalone]

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web