www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - The Thermopylae excerpt of TDPL available online

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
It's a rough rough draft, but one for the full chapter on arrays, 
associative arrays, and strings.

http://erdani.com/d/thermopylae.pdf

Any feedback is welcome. Thanks!


Andrei
Oct 28 2009
next sibling parent reply =?ISO-8859-1?Q?Pelle_M=E5nsson?= <pelle.mansson gmail.com> writes:
Andrei Alexandrescu wrote:

 It's a rough rough draft, but one for the full chapter on arrays, 
 associative arrays, and strings.
 
 http://erdani.com/d/thermopylae.pdf
 
 Any feedback is welcome. Thanks!
 
 
 Andrei


Your "Hallå Värd!" should be "Hallå Värld!", to be Swedish. D:

Also, I am wondering, why is the undefined behavior of opCatAssign kept? 
Couldn't every T[] know if it is the owner of the memory in question? 
Sorry if I bring outdated discussions up unnecessarily.
Oct 29 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Pelle Månsson wrote:

 Andrei Alexandrescu wrote:

 It's a rough rough draft, but one for the full chapter on arrays, 
 associative arrays, and strings.

 http://erdani.com/d/thermopylae.pdf

 Any feedback is welcome. Thanks!


 Andrei


 
 Your "Hallå Värd!" should be "Hallå Värld!", to be Swedish. D:


Thanks! Ouch, two mistakes in one word. Also, should I put a comma in 
between the words?


 Also, I am wondering, why is the undefined behavior of opCatAssign kept? 
 Couldn't every T[] know if it is the owner of the memory in question? 
 Sorry if I bring outdated discussions up unnecessarily.


We don't know how to do that cheaply.


Andrei
Oct 29 2009
parent =?ISO-8859-1?Q?Pelle_M=E5nsson?= <pelle.mansson gmail.com> writes:
Andrei Alexandrescu wrote:

 Pelle Månsson wrote:

 Andrei Alexandrescu wrote:

 It's a rough rough draft, but one for the full chapter on arrays, 
 associative arrays, and strings.

 http://erdani.com/d/thermopylae.pdf

 Any feedback is welcome. Thanks!


 Andrei


 Your "Hallå Värd!" should be "Hallå Värld!", to be Swedish. D:


 
 Thanks! Ouch, two mistakes in one word. Also, should I put a comma in 
 between the words?


Actually, I see now that you had it as "Hallå, värd!", and it should be 
"Hallå, värld!", no need to capitalize the second word.

Unless what you want to say is "Hello, host!", in which case your värd 
is correct.


 Also, I am wondering, why is the undefined behavior of opCatAssign 
 kept? Couldn't every T[] know if it is the owner of the memory in 
 question? Sorry if I bring outdated discussions up unnecessarily.


 
 We don't know how to do that cheaply.
 
 
 Andrei


How about doing it expensively? Maybe storing a boolean in each T[]? I 
think undefined behavior is bad.
Oct 29 2009
prev sibling next sibling parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
Andrei Alexandrescu wrote:

 It's a rough rough draft, but one for the full chapter on arrays,
 associative arrays, and strings.
 
 http://erdani.com/d/thermopylae.pdf
 
 Any feedback is welcome. Thanks!
 
 
 Andrei


Maybe I haven't been paying attention lately, but shouldn't

assert(x == 0)

be

assert(x[] == 0)

?
Oct 29 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Ellery Newcomer wrote:

 Andrei Alexandrescu wrote:

 It's a rough rough draft, but one for the full chapter on arrays,
 associative arrays, and strings.

 http://erdani.com/d/thermopylae.pdf

 Any feedback is welcome. Thanks!


 Andrei


 
 Maybe I haven't been paying attention lately, but shouldn't
 
 assert(x == 0)
 
 be
 
 assert(x[] == 0)
 
 ?


Where does the former occur?

Thanks,

Andrei
Oct 29 2009
parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
Andrei Alexandrescu wrote:

 Ellery Newcomer wrote:

 Andrei Alexandrescu wrote:

 It's a rough rough draft, but one for the full chapter on arrays,
 associative arrays, and strings.

 http://erdani.com/d/thermopylae.pdf

 Any feedback is welcome. Thanks!


 Andrei


 Maybe I haven't been paying attention lately, but shouldn't

 assert(x == 0)

 be

 assert(x[] == 0)

 ?


 
 Where does the former occur?
 
 Thanks,
 
 Andrei


top of page 102
Oct 29 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Ellery Newcomer wrote:

 Andrei Alexandrescu wrote:

 Ellery Newcomer wrote:

 Andrei Alexandrescu wrote:

 It's a rough rough draft, but one for the full chapter on arrays,
 associative arrays, and strings.

 http://erdani.com/d/thermopylae.pdf

 Any feedback is welcome. Thanks!


 Andrei


 Maybe I haven't been paying attention lately, but shouldn't

 assert(x == 0)

 be

 assert(x[] == 0)

 ?


 Where does the former occur?

 Thanks,

 Andrei


 
 top of page 102


Thanks. Notice that x is an integer because it was fetched as array[5].

Andrei
Oct 29 2009
parent Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
Andrei Alexandrescu wrote:

 Ellery Newcomer wrote:

 Andrei Alexandrescu wrote:

 Ellery Newcomer wrote:

 Andrei Alexandrescu wrote:

 It's a rough rough draft, but one for the full chapter on arrays,
 associative arrays, and strings.

 http://erdani.com/d/thermopylae.pdf

 Any feedback is welcome. Thanks!


 Andrei


 Maybe I haven't been paying attention lately, but shouldn't

 assert(x == 0)

 be

 assert(x[] == 0)

 ?


 Where does the former occur?

 Thanks,

 Andrei


 top of page 102


 
 Thanks. Notice that x is an integer because it was fetched as array[5].
 
 Andrei


Oh wow. I'm dyslexic.
Oct 29 2009
prev sibling next sibling parent reply "Saaa" <empty needmail.com> writes:
Andrei Alexandrescu wrote

 It's a rough rough draft, but one for the full chapter on arrays, 
 associative arrays, and strings.

 http://erdani.com/d/thermopylae.pdf

 Any feedback is welcome. Thanks!


 Andrei


Makes me want to read the rest!

Will we get the electronic version with the paper version?

p2. typo: eenlists
p9. Is it ok to expect the order of an array expression to be like in 
foreach ?
      Maybe mention a[] = b.
p11. typo: no(t) palindrome
p12. Should in a safe module "~=" always create a new array?
p14. further expansions reads as if expansions have been made
        especially because the comment is maybe that obvious that I was 
looking for something else to be there.
p16. Is there anything other than the random values, unsafe about void 
assignment?
        When you write something to be unsafe, I expect it to not be allowed 
safe modules.
p18. What is unsafe about implicit conversion of static to dynamic array?
        Meaning getting a dynamic array pointing to a stack allocated array.
        Any operation changing its size could copy the array to the heap. 
What am I missing
p20. An alternative to figure 4.5 could display row/column properties.
p20. change 1,000,000 to 1_000_000 :D to me the comma is a decimal separator 
anyways.
p20. 40 words? <<<<
p21. Why use enum iso immutable? Probably in the previous chapters explained 
:)
p21. Second paragraph reads as a solution to the above
p22. typo: array!literal
p25. Expected to read about ref in foreach

That's all :)
Oct 29 2009
next sibling parent "Saaa" <empty needmail.com> writes:
Also, no mention about .dup not being a deep dup.
Oct 29 2009
prev sibling next sibling parent "Saaa" <empty needmail.com> writes:
crp

 p20. 40 words? <<<<


those <<<< where for myself, to check
Oct 29 2009
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Saaa wrote:

 Will we get the electronic version with the paper version?


I'm not exactly sure how things will roll out. Probably yes.


 p2. typo: eenlists
 p9. Is it ok to expect the order of an array expression to be like in 
 foreach ?
       Maybe mention a[] = b.
 p11. typo: no(t) palindrome
 p12. Should in a safe module "~=" always create a new array?
 p14. further expansions reads as if expansions have been made
         especially because the comment is maybe that obvious that I was 
 looking for something else to be there.
 p16. Is there anything other than the random values, unsafe about void 
 assignment?
         When you write something to be unsafe, I expect it to not be allowed 
 safe modules.
 p18. What is unsafe about implicit conversion of static to dynamic array?
         Meaning getting a dynamic array pointing to a stack allocated array.
         Any operation changing its size could copy the array to the heap. 
 What am I missing
 p20. An alternative to figure 4.5 could display row/column properties.
 p20. change 1,000,000 to 1_000_000 :D to me the comma is a decimal separator 
 anyways.
 p20. 40 words? <<<<
 p21. Why use enum iso immutable? Probably in the previous chapters explained 
 :)
 p21. Second paragraph reads as a solution to the above
 p22. typo: array!literal
 p25. Expected to read about ref in foreach
 
 That's all :) 


Thanks much!


Andrei
Oct 29 2009
prev sibling parent reply "Saaa" <empty needmail.com> writes:
Could anybody clear these up for me?


 p16. Is there anything other than the random values, unsafe about void 
 assignment?



 p18. What is unsafe about implicit conversion of static to dynamic array?
        Meaning getting a dynamic array pointing to a stack allocated 
 array.
        Any operation changing its size could copy the array to the heap. 
 What am I missing



 p20. 10 int take up 40 words?


Thanks!
Oct 30 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Saaa wrote:

 Could anybody clear these up for me?
 

 p16. Is there anything other than the random values, unsafe about void 
 assignment?




I'd put your feedback on my pile of things to do, but now that you ask, 
I made this change to the incriminated paragraph:

===========
Such  uninitialized arrays  are particularly  useful for  large arrays
that serve  as temporary buffers.   An uninitialized integral  may not
cause  too   much  harm,  but  uninitialized  values   of  types  with
indirections (such as arrays themselves) are unsafe.
===========


 p18. What is unsafe about implicit conversion of static to dynamic array?
        Meaning getting a dynamic array pointing to a stack allocated 
 array.
        Any operation changing its size could copy the array to the heap. 
 What am I missing




T[] fun() { T[10] a; return a; }
...
auto x = fun(); // gained access to recycled stack memory

There's no change in size there.


 p20. 10 int take up 40 words?




The example given has a per-row payload of 10 ints, i.e. 40 words.


Andrei
Oct 30 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Andrei Alexandrescu wrote:

 Saaa wrote:

 Could anybody clear these up for me?


 p16. Is there anything other than the random values, unsafe about 
 void assignment?




 
 I'd put your feedback on my pile of things to do, but now that you ask, 
 I made this change to the incriminated paragraph:
 
 ===========
 Such  uninitialized arrays  are particularly  useful for  large arrays
 that serve  as temporary buffers.   An uninitialized integral  may not
 cause  too   much  harm,  but  uninitialized  values   of  types  with
 indirections (such as arrays themselves) are unsafe.
 ===========
 

 p18. What is unsafe about implicit conversion of static to dynamic 
 array?
        Meaning getting a dynamic array pointing to a stack allocated 
 array.
        Any operation changing its size could copy the array to the 
 heap. What am I missing




 
 T[] fun() { T[10] a; return a; }
 ...
 auto x = fun(); // gained access to recycled stack memory
 
 There's no change in size there.
 

 p20. 10 int take up 40 words?




 
 The example given has a per-row payload of 10 ints, i.e. 40 words.


It's bytes actually. So finally I rewrote those last words as:

"... small  per-row payload of~10   int s (40 bytes)."


Andrei
Oct 30 2009
parent reply "Saaa" <empty needmail.com> writes:
Andrei Alexandrescu wrote:

 Andrei Alexandrescu wrote:

 Saaa wrote:

 Could anybody clear these up for me?


 p16. Is there anything other than the random values, unsafe about void 
 assignment?




 I'd put your feedback on my pile of things to do, but now that you ask, I 
 made this change to the incriminated paragraph:

 ===========
 Such  uninitialized arrays  are particularly  useful for  large arrays
 that serve  as temporary buffers.   An uninitialized integral  may not
 cause  too   much  harm,  but  uninitialized  values   of  types  with
 indirections (such as arrays themselves) are unsafe.
 ===========


 p18. What is unsafe about implicit conversion of static to dynamic 
 array?
        Meaning getting a dynamic array pointing to a stack allocated 
 array.
        Any operation changing its size could copy the array to the 
 heap. What am I missing




 T[] fun() { T[10] a; return a; }
 ...
 auto x = fun(); // gained access to recycled stack memory

 There's no change in size there.


 p20. 10 int take up 40 words?




 The example given has a per-row payload of 10 ints, i.e. 40 words.


 It's bytes actually. So finally I rewrote those last words as:

 "... small  per-row payload of~10   int s (40 bytes)."


 Andrei


Thanks !

Out of interest, do you keep a list of common error or something alike that 
helps you keep errors at a minimum?
Also, do you have automated example checking?
Or, more general, I would be interested in a small article explaining how a 
book like this is written.

Maybe After the book is finished :)
Oct 30 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Saaa wrote:

 Andrei Alexandrescu wrote:

 Andrei Alexandrescu wrote:

 Saaa wrote:

 Could anybody clear these up for me?


 p16. Is there anything other than the random values, unsafe about void 
 assignment?




 I'd put your feedback on my pile of things to do, but now that you ask, I 
 made this change to the incriminated paragraph:

 ===========
 Such  uninitialized arrays  are particularly  useful for  large arrays
 that serve  as temporary buffers.   An uninitialized integral  may not
 cause  too   much  harm,  but  uninitialized  values   of  types  with
 indirections (such as arrays themselves) are unsafe.
 ===========


 p18. What is unsafe about implicit conversion of static to dynamic 
 array?
        Meaning getting a dynamic array pointing to a stack allocated 
 array.
        Any operation changing its size could copy the array to the 
 heap. What am I missing




 T[] fun() { T[10] a; return a; }
 ...
 auto x = fun(); // gained access to recycled stack memory

 There's no change in size there.


 p20. 10 int take up 40 words?




 The example given has a per-row payload of 10 ints, i.e. 40 words.


 It's bytes actually. So finally I rewrote those last words as:

 "... small  per-row payload of~10   int s (40 bytes)."


 Andrei


 
 Thanks !
 
 Out of interest, do you keep a list of common error or something alike that 
 helps you keep errors at a minimum?


I got as sophisticated as having an email folder dedicated to TDPL.


 Also, do you have automated example checking?


Yes. If you look at the document very closely, you'll see that some 
snippets have a thin line above and below them. Those are automatically 
checked every time I save the document. (There are 1-2 examples that 
aren't checked in the Thermopylae excerpt because I switched editing to 
a 64-bit machine that can't build D programs (I'll post a question later 
today). But in the meantime I fixed those.)

Very short snippets do not have a thin line above and below them. Those 
are not checked because they are short enough to warrant that I know 
what I'm doing.

Some checked snippets wouldn't compile without being in a function, for 
example:

enum size_t columns = 128;
// Allocate a matrix with 64 rows and 128 columns
auto matrix = new double[columns][64];
// No need to allocate each row - they already exist in-situ
foreach (ref row; matrix) {
    ... // use row of type double[columns]
}

These are automatically entered inside a unittest. Also, my code 
extraction script (written in D!) automatically eliminates unneeded 
"...", so the code as seen by the compiler is:

unittest {
enum size_t columns = 128;
// Allocate a matrix with 64 rows and 128 columns
auto matrix = new double[columns][64];
// No need to allocate each row - they already exist in-situ
foreach (ref row; matrix) {
     // use row of type double[columns]
}
}

which passes compilation.

Some other examples need "invisible" support:

writeln("hey");

For those I have a special mechanism to insert invisible code, so my 
text for the above actually looks like this:

\begin{D-invisible}
import std.stdio;
\end{D-invisible}
\begin{D-snippet}
writeln("hey");
\end{D-snippet}

What the compiler sees is a file importing std.stdio and including the 
writeln inside a unittest.

I wouldn't know how to pull this off reasonably with e.g. Word, but I'm 
sure it now has mechanisms or extensions that allow that kind of thing. 
One thing I don't need to worry about with LaTeX is that it's text-based 
so I can process it easily myself.


 Or, more general, I would be interested in a small article explaining how a 
 book like this is written.
 
 Maybe After the book is finished :) 


I think the topic is well worth an article indeed. I continuously 
streamline the process of building the book, and it's gotten pretty 
sophisticated but very helpful as well. Index building is also an 
interesting subtopic.


Andrei
Oct 30 2009
parent "Saaa" <empty needmail.com> writes:
Andrei Alexandrescu wrote

 Saaa wrote:

 Andrei Alexandrescu wrote:

 Andrei Alexandrescu wrote:

 Saaa wrote:

 Could anybody clear these up for me?


 p16. Is there anything other than the random values, unsafe about 
 void assignment?




 I'd put your feedback on my pile of things to do, but now that you ask, 
 I made this change to the incriminated paragraph:

 ===========
 Such  uninitialized arrays  are particularly  useful for  large arrays
 that serve  as temporary buffers.   An uninitialized integral  may not
 cause  too   much  harm,  but  uninitialized  values   of  types  with
 indirections (such as arrays themselves) are unsafe.
 ===========


 p18. What is unsafe about implicit conversion of static to dynamic 
 array?
        Meaning getting a dynamic array pointing to a stack allocated 
 array.
        Any operation changing its size could copy the array to the 
 heap. What am I missing




 T[] fun() { T[10] a; return a; }
 ...
 auto x = fun(); // gained access to recycled stack memory

 There's no change in size there.


 p20. 10 int take up 40 words?




 The example given has a per-row payload of 10 ints, i.e. 40 words.


 It's bytes actually. So finally I rewrote those last words as:

 "... small  per-row payload of~10   int s (40 bytes)."


 Andrei


 Thanks !

 Out of interest, do you keep a list of common error or something alike 
 that helps you keep errors at a minimum?


 I got as sophisticated as having an email folder dedicated to TDPL.


 Also, do you have automated example checking?


 Yes. If you look at the document very closely, you'll see that some 
 snippets have a thin line above and below them. Those are automatically 
 checked every time I save the document. (There are 1-2 examples that 
 aren't checked in the Thermopylae excerpt because I switched editing to a 
 64-bit machine that can't build D programs (I'll post a question later 
 today). But in the meantime I fixed those.)

 Very short snippets do not have a thin line above and below them. Those 
 are not checked because they are short enough to warrant that I know what 
 I'm doing.


:)

 Some checked snippets wouldn't compile without being in a function, for 
 example:

 enum size_t columns = 128;
 // Allocate a matrix with 64 rows and 128 columns
 auto matrix = new double[columns][64];
 // No need to allocate each row - they already exist in-situ
 foreach (ref row; matrix) {
    ... // use row of type double[columns]
 }

 These are automatically entered inside a unittest. Also, my code 
 extraction script (written in D!) automatically eliminates unneeded


I Wouldn't accept it being written in C++ !! :D


 "...", so the code as seen by the compiler is:

 unittest {
 enum size_t columns = 128;
 // Allocate a matrix with 64 rows and 128 columns
 auto matrix = new double[columns][64];
 // No need to allocate each row - they already exist in-situ
 foreach (ref row; matrix) {
     // use row of type double[columns]
 }
 }

 which passes compilation.

 Some other examples need "invisible" support:

 writeln("hey");

 For those I have a special mechanism to insert invisible code, so my text 
 for the above actually looks like this:

 \begin{D-invisible}
 import std.stdio;
 \end{D-invisible}
 \begin{D-snippet}
 writeln("hey");
 \end{D-snippet}

 What the compiler sees is a file importing std.stdio and including the 
 writeln inside a unittest.


nice


 I wouldn't know how to pull this off reasonably with e.g. Word, but I'm 
 sure it now has mechanisms or extensions that allow that kind of thing. 
 One thing I don't need to worry about with LaTeX is that it's text-based 
 so I can process it easily myself.


Somehow I only associate LaTeX with b/w scientific articles :)


 Or, more general, I would be interested in a small article explaining how 
 a book like this is written.

 Maybe After the book is finished :)


 I think the topic is well worth an article indeed. I continuously 
 streamline the process of building the book, and it's gotten pretty 
 sophisticated but very helpful as well. Index building is also an 
 interesting subtopic.


 Andrei


Thanks, looking forward to the article ( and the tools used :P )
Oct 30 2009
prev sibling next sibling parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Thu, 29 Oct 2009 00:38:33 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 It's a rough rough draft, but one for the full chapter on arrays,  
 associative arrays, and strings.

 http://erdani.com/d/thermopylae.pdf

 Any feedback is welcome. Thanks!


 Andrei


Still reading, but here's a quick comment. I found it odd that the syntax  
for element-wise copying (4.1.7) comes sections after the section on  
copying (4.1.4). Perhaps a sentence mentioning where element-wise copying  
can be found would be appropriate. (Props though on including a memory  
layout figure. It may not seem like much, but I've seen Java students have  
no idea what an array is in memory.)
Oct 29 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Robert Jacques wrote:

 On Thu, 29 Oct 2009 00:38:33 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 

 It's a rough rough draft, but one for the full chapter on arrays, 
 associative arrays, and strings.

 http://erdani.com/d/thermopylae.pdf

 Any feedback is welcome. Thanks!


 Andrei


 
 Still reading, but here's a quick comment. I found it odd that the 
 syntax for element-wise copying (4.1.7) comes sections after the section 
 on copying (4.1.4). Perhaps a sentence mentioning where element-wise 
 copying can be found would be appropriate. (Props though on including a 
 memory layout figure. It may not seem like much, but I've seen Java 
 students have no idea what an array is in memory.)


Good point, thanks.

Andrei
Oct 29 2009
prev sibling next sibling parent reply Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Andrei Alexandrescu wrote:

 It's a rough rough draft, but one for the full chapter on arrays, 
 associative arrays, and strings.
 
 http://erdani.com/d/thermopylae.pdf
 
 Any feedback is welcome. Thanks!


Thanks for the excerpt! I've only had the time to give it a brief skim 
so far, but it's looking good. This is what I found:

p16: int quadrupeds[100], int legs[4 * quadrupeds.length]  <-  is the 
C-style array declaration syntax intended?
p20: No mention of the "new T[][](rows, cols)" syntax?
p26 (User-Defined Types as Keys): No need for opEquals?


-- 
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode
Oct 29 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Tom S wrote:

 Andrei Alexandrescu wrote:

 It's a rough rough draft, but one for the full chapter on arrays, 
 associative arrays, and strings.

 http://erdani.com/d/thermopylae.pdf

 Any feedback is welcome. Thanks!


 
 Thanks for the excerpt! I've only had the time to give it a brief skim 
 so far, but it's looking good. This is what I found:
 
 p16: int quadrupeds[100], int legs[4 * quadrupeds.length]  <-  is the 
 C-style array declaration syntax intended?


Thanks, fixed.


 p20: No mention of the "new T[][](rows, cols)" syntax?


Oops, completely forgot about that one.


 p26 (User-Defined Types as Keys): No need for opEquals?


There currently is, but there shouldn't and it won't.


Andrei
Oct 29 2009
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
Andrei Alexandrescu wrote:

 It's a rough rough draft, but one for the full chapter on arrays, 
 associative arrays, and strings.
 
 http://erdani.com/d/thermopylae.pdf
 
 Any feedback is welcome. Thanks!
 
 
 Andrei


p.28 line 16:


 symbols in less bits






should be


 symbols in fewer bits
Oct 31 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Mike Parker wrote:

 Andrei Alexandrescu wrote:

 It's a rough rough draft, but one for the full chapter on arrays, 
 associative arrays, and strings.

 http://erdani.com/d/thermopylae.pdf

 Any feedback is welcome. Thanks!


 Andrei


 
 p.28 line 16:
 
  >>> symbols in less bits
 
 should be
 
  >>> symbols in fewer bits


Thanks, fixed.

Andrei
Oct 31 2009