No wonder the discussion is going out of context... Algorithms,searching techniques ,etc...
Closures is really something deeper than that. Regards, JD On 8/12/10, Christian Catchpole <christ...@catchpole.net> wrote: > Dick was saying he simply used a string compare as his example for > closures. And that the string compare has really nothing to do with > the closure example as all. > > On Aug 12, 8:47 pm, jitesh dundas <jbdun...@gmail.com> wrote: >> That seems to be a collection of simple AI related searching & >> matching techniques . Features include other types of validations & >> authentications also, many of them unknowingly implemented by us.. >> >> I am not sure what you show is what Dick meant by features & the >> discussion being lost.. >> Dick,please explain.. >> >> Thanks for the changes, >> JD >> >> On 8/12/10, Amarjeet Singh <amarjeet.aur...@gmail.com> wrote: >> >> >> >> > And what on earth are these algorithms for string comparison then? >> >> >http://www-igm.univ-mlv.fr/~lecroq/string/index.html >> >> > Reg >> >> > On Mon, Aug 9, 2010 at 10:29 AM, Dick Wall <dickw...@gmail.com> wrote: >> >> I can't help but feel that the discussion has got a little bit lost in >> >> the rough :-). I do wish I had pulled a better example out for that >> >> original post, but lest anyone not remember, the point was to show how >> >> closures (and in particular good language support for them) greatly >> >> cuts boilerplate and enhances readability. I could have used an >> >> example with some genetic calculation code or something like that, but >> >> it would have needed far more supporting material. Point is, Java >> >> exhibits its own ugly backwaters of complexity, and they tend to be in >> >> features we use all the time (like anonymous inner classes). >> >> >> Dick >> >> >> On Aug 8, 3:23 pm, Reinier Zwitserloot <reini...@gmail.com> wrote: >> >>> So close. >> >> >>> java's own String.CASE_INSENSITIVE_ORDER uses this tactic, and as far >> >>> as case insensitive tactics go, this really isn't such a bad one. >> >>> However, they completely bollocks it up by doing this character-by- >> >>> character for some completely unfathomable reason. This is dumb, and >> >>> explains why STRASSE and straße aren't equal. >> >>> Character.toUpperCase('\u00DF') can't very well return "SS", so it has >> >>> to return the unicode codepoint for capital eszett. >> >> >>> Nevertheless, as someone else has pointed out to me, both großman and >> >>> grossman are somewhat common german surnames and shouldn't be >> >>> considered equal, so, in many ways, yes, 'case insensitive' as a >> >>> concept doesn't really make sense beyond english. >> >> >>> Doing a canonical comparison to answer the question: "Are these >> >>> strings most likely intended to be equal considering that they are >> >>> both written in language X", is completely valid though, and that's >> >>> exactly what java.text.Collator is for. I don't think this is mission >> >>> impossible. It's just crazy complicated. >> >> >>> Many props to A McDowell for teaching us all about the case folding >> >>> rules of unicode. I learned something new. >> >> >>> On Aug 8, 9:34 am, Christian Catchpole <christ...@catchpole.net> >> >>> wrote: >> >> >>> > So, without some kind of case translation dictionary that can be >> >>> > trusted on the particular strings we want to test, can we assume >> >>> > that's it's not actually a solvable problem? (because, like divide >> >>> > by >> >>> > zero, the question isn't valid to start with) >> >> >>> > Could you maybe get better results by (if upperCompare || >> >>> > lowerCompare)? >> >> >>> > Was I serious for a second there? >> >> >>> > GERBILS! >> >> >>> > That's better. >> >> >> -- >> >> You received this message because you are subscribed to the Google >> >> Groups >> >> "The Java Posse" group. >> >> To post to this group, send email to javapo...@googlegroups.com. >> >> To unsubscribe from this group, send email to >> >> javaposse+unsubscr...@googlegroups.com. >> >> For more options, visit this group at >> >>http://groups.google.com/group/javaposse?hl=en. >> >> > -- >> > Amarjeet Singh >> > Phone: +91-98712-76661 >> >> > -- >> > You received this message because you are subscribed to the Google >> > Groups >> > "The Java Posse" group. >> > To post to this group, send email to javapo...@googlegroups.com. >> > To unsubscribe from this group, send email to >> > javaposse+unsubscr...@googlegroups.com. >> > For more options, visit this group at >> >http://groups.google.com/group/javaposse?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to javapo...@googlegroups.com. > To unsubscribe from this group, send email to > javaposse+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javapo...@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
