> On 7 Feb 2017, at 19:44, Dave Abrahams <[email protected]> wrote:
>
>
> on Tue Feb 07 2017, "Ted F.A. van Gaalen" <tedvgiosdev-AT-gmail.com> wrote:
>
>>> On 7 Feb 2017, at 05:42, Karl Wagner <[email protected]> wrote:
>>>
>>>>
>>>> On 6 Feb 2017, at 19:29, Ted F.A. van Gaalen via swift-evolution
>>>> <[email protected]
>> <mailto:[email protected]>> wrote:
>>>>
>>> When it comes to fast access what’s most important is cache
>>> locality. DRAM is like 200x slower than L2 cache. Looping through
>>> some contiguous 16-bit integers is always going to beat the pants
>>> out of derefencing pointers.
>>
>>>
>> Hi Karl
>> That is of course hardware/processor dependent…and Swift runs on different
>> target systems… isn’t?
>
> Actually the basic calculus holds for any modern processor.
>
>>> It’s quite rare that you need to grab arbitrary parts of a String
>>> without knowing what is inside it. If you’re saying str[12..<34] -
>>> why 12, and why 34? Is 12 the length of some substring you know from
>>> earlier? In that case, you could find out how many CodeUnits it had,
>>> and use that information instead.
>>> For this example, I have used constants here, but normally these would be
>>> variables..
>>>
>>
>> I’d say it is not so rare, these things are often used for all kinds of
>> string parsing, there are
>> many
>> examples to be found on the Internet.
>> TedvG
>
> That proves nothing, though. The fact that people are using integers to
> do this doesn't mean you need to use them, nor does it mean that you'll
> get the right results from doing so. Typically examples that use
> integer constants with strings are wrong for some large proportion of
> unicode text.
>
This is all a bit confusing.
in https://en.wiktionary.org/wiki/glyph
Definition of a glyph in our context:
(typography, computing) A visual representation of a letter
<https://en.wiktionary.org/wiki/letter>, character
<https://en.wiktionary.org/wiki/character>, or symbol
<https://en.wiktionary.org/wiki/symbol>, in a specific font
<https://en.wiktionary.org/wiki/font> and style
<https://en.wiktionary.org/wiki/style>.
I now assume that:
1. -= a “plain” Unicode character (codepoint?) can result in one glyph.=-
2. -= a grapheme cluster always results in just a single glyph, true? =-
3. The only thing that I can see on screen or print are glyphs
(“carvings”,visual elements that stand on their own )
4. In this context, a glyph is a humanly recognisable visual form of a
character,
5. On this level (the glyph, what I can see as a user) it is not relevant
and also not detectable
with how many Unicode scalars (codepoints ?), grapheme, or even on
what kind
of encoding the glyph was based upon.
is this correct? (especially 1 and 2)
Based on these assumptions, to me then, the definition of a character == glyph.
Therefore, my working model: I see a row of characters as a row of glyphs,
which are discrete autonomous visual elements, ergo:
Each element is individually addressable with integers (ordinal)
?
TedvG
> --
> -Dave
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
