think of the strings as base-26 integers <@UC44J50...

# getting-started

[serebit]

think of the strings as base-26 integers @Egor

[Alan Evans]

except "ab" in "a".."z" but if a=0, z=25 and ab=27 it won't work

[serebit]

“ab” isn’t in “a”..”z” though

[Alan Evans]

yes it is...

[serebit]

where in the range of strings from “a” to “z” is “ab”? list them out and find it

[Alan Evans]

lol

[Alan Evans]

don't get a job in a library 😛

[serebit]

if it is then i’m not understanding how this works in the slightest lol

[Alan Evans]

think alphabetical order

[Shawn]

No, Campbell is correct.

[Alan Evans]

"ab" comes after "a", but before "z"

[Shawn]

"ab" !in 'a'..'z'

[Shawn]

on the other hand, "ab" in "aa".."az"

[serebit]

exactly

[Dominaezzz]

Interesting.

[Alan Evans]

you guys are pretty lazy not just trying it before speaking https://pl.kotl.in/ryuzUMeG4

[Shawn]

like, is 0xAB in 0xA..0xF?

[Dominaezzz]

I knew it!

[Alan Evans]

hey, 'a' is not the same as "a" @Shawn

[Shawn]

that’s true, are we not on the same page?

[Alan Evans]

go back to the start of the thread

[serebit]

oh, that’s interesting

[Shawn]

I see.

[serebit]

I’m on my phone, I’d try it if I could lol

[Alan Evans]

to be fair, took me a while to notice the chars in "ab" !in 'a'..'z'

[serebit]

wait, is ”ba” in “a”..”z”?

[Alan Evans]

yes

[serebit]

take the first n chars in the initial string (n being the length of the longest string in the range), convert to base 26, and compare that in the range

[serebit]

is how I see it calculating

[Alan Evans]

what it is doing is a in b..c is a.compareTo(b) >= 0 && a.compareTo(c) <= 0

[Alan Evans]

e.g. "ba" is alphabetically after "a" but alphabetically before "z"

[serebit]

alphabetically, yes

[serebit]

i’m thinking about how strings are compared in the first place

[Alan Evans]

one character at a time left to right, if they are the same up until their lengths differ, the shorter one comes before the longer one

[Alan Evans]

you don't have to read all the characters

[Alan Evans]

"a" is always before "b <plus millions of chars>" no matter what those chars are

[Alan Evans]

so converting to base26 number etc is not the way

[serebit]

but it works :)

[serebit]

think about it, alan. if you had to write your own compareTo impl for strings and emulate that behavior, how would you do it?

[serebit]

because take and conversion to base26 would be my method

[bjonnh]

and that would not be efficient. see: https://code.woboq.org/userspace/glibc/string/strcmp.c.html

[bjonnh]

note that things gets funny with unicode

[bjonnh]

"é" in "a".."z" => false (but not for a librarian)

[Alan Evans]

@serebit "if you had to write your own compareTo impl for strings and emulate that behavior"
I said how https://kotlinlang.slack.com/archives/C0B8MA7FA/p1546819682237400?thread_ts=1546817918.220500&amp;cid=C0B8MA7FA

[Alan Evans]

I also showed right at the start of the thread that base 26 idea does not work. https://kotlinlang.slack.com/archives/C0B8MA7FA/p1546818291220700?thread_ts=1546817918.220500&amp;cid=C0B8MA7FA