Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror

Comment Re:They're not always like this (Score 1) 363 363

Some lights have separate segments where it's only straight or only left-turn. Pedestrians only have the walk sign during the straight traffic.

True but it is uncommon. It is indicated by a *red* left arrow light. I think that works.

However if there is only a green left arrow light that turns off when opposing traffic starts moving, you are still allowed to turn left, though you have to wait for a gap in the oncoming traffic. For obvious reasons (the driver is looking only at the oncoming traffic) this is when the pedestrians are hit.

Comment Re:Altough I agree (Score 1) 61 61

My favorite feature is Birds Eye view, which uses aerial photos rather than satellite photos. Sometimes that can get you better info from that, since they usually have 4 different perspectives you can rotate through, and they are much closer and more detailed.

That was true, but Google was pretty quick to copy it. They now seem to have incorporated it into their 3D view as well, which makes panning somewhat better (and more importantly hides the worst defects in the 3D view by limiting the projection to a POV very similar to where the texture map image was taken from).

Comment Re:Reference count synchronization across threads (Score 1) 296 296

Actually the reason for the Global Interpreter Lock is because cPython decided that had less overhead than making the reference counters atomic variables (plus you would still need some kind of locking when modifying any object with a reference count greater than one, though this is such a tiny amount of what a typical Python program does that it is probably irrelevant).

I personally have doubts this is true, but the argument is not impossible. I am wondering if their measurements were on older systems, modern ones are better at atomic operations.

Comment Re:Infinity (Score 3, Informative) 1067 1067

Actually IEEE floating point has a signed zero (+0 and -0 are different values) to solve exactly that. If x is positive, x/+0 is +infinity, x/-0 is -infinity. 0/0 (with any type of 0) returns NaN.

However I believe the article was talking about *integer* division by zero, not floating point.

Comment Re:Lol (Score 1) 248 248

Holy fucking shit, who cares? If this was done by LETTER WIDTH, we wouldn't see the problem-

EXACTLY! That is why you do not want "N characters". I don't understand what your problem is here.

It is true that for this example most programmers would scan from the start, finding the longest string that fits with an ellipsis at the end.

What I was trying to point out is that if you want to be clever, you can guess as to an insertion point. But 11 bytes is just as good of a guess as 11 "characters" and since 11 characters requires scanning you are not saving any time.

You are perfectly correct that after you stick the ellipsis in there you need to test to see if the rendering fits and perhaps try another guess. The idea is that you will do fewer measurements, but that such insertion can be done using byte offsets, and "N characters" is a useless concept that never enters into it.

Comment Re:Lol (Score 1) 248 248

Do you really think 12 happy faces fit in the same space as 12 letter 'i'?

This is why it is pointless to do such counting.

And what you propose would split betwen a letter and a combining accent, so it really isn't any better for trashing strings.

Basically as soon as the words "N characters" come out of your mouth you are wrong. All your description just does that for many paragraphs. Don't feel too bad however as there are many many other people, including ones working for Apple, who are wrong as well.

PS: the surrogate order does not depend on they byte order in UTF-16. You might want to check what you are doing if you thought that.

Comment Re:I am amazed (Score 1) 248 248

A lot of misinformed programmers use the term "Unicode" to mean encodings other than UTF-8, typically UTF-16 or UCS-2. For instance a function called "toUnicode" often is a translator from UTF-8 to UTF-16. Therefore when people say "Unicode strings" they almost always mean non-byte strings. I propose the best solution is to eliminate all such strings. It is true that byte strings would encode UTF-8 and thus be "Unicode" but the hope is that this would be so standard that there would be no need to ever specify this and they would be called "strings".

Comment Re:I am amazed (Score 1) 248 248

I don't think there are any useful algorithms that need random access, except for searches that do not require the index to be "exact". Therefore you certainly do not need a reliable string[i]. You can make it return a pointer to byte i, which will work for most uses (ie searches for ASCII and replacing one ASCII byte with another).

Some complex searches do want to jump arbitrary amounts ahead, but do not require any "exact" location. Instead they want "a character near the middle" and so forth. In this case it might be useful to produce an iterator that points near byte i. A simple UTF-32 one would jump to byte i and then back up to the last non-continuation byte, unless there are 3 or more in which case it would stay where it first went (as that is the start of an error). Ones that return normalization forms would be much more complex. Something like this:


      utf16_iterator i(string, string.length()/2); // i now points near middle of string

If you have to ask how much it is, you can't afford it.

Working...