<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:΢ÈíÑźÚ
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>Hi Richard,<div><span style="font-size: 12pt;"><br></span></div><div><span style="font-size: 12pt;">  I am really not interested in quarreling, I hope you are 100%ly clear with this point -- that I HATE to talk with a guy like you who are just showing off his smartness, saying ironic words and showing arrogant attitude. Your aggressive behavior is not welcome here.</span><div><div><br></div><div>"tard" is a slang, use a dictionary. So what's your point? Picking out every "illness" in my expression, does it make you feel stronger? </div><div><br></div><div>Sorry I don't have more patience to look through your verbose comments, learn some respect and be polite before your talk.</div><div><br></div><div>Read this to solve your "size_t" argument. </div><div><br></div><div><a href="http://stackoverflow.com/questions/1951519/when-to-use-stdsize-t" target="_blank">http://stackoverflow.com/questions/1951519/when-to-use-stdsize-t</a></div><div><br></div><div>But I don't think it matter at all, use whatever type you want.</div><div><br></div><div>And please, leave those arrogant attitude and your cavil to yourself, they are irrelevant to the question. </div><div><br></div><div>> Well, if I'm not _shown_ the track it's hard to stay on it.</div><div>I'm afraid this is your own problem. Please keep the discussion on the track and friendly, or just keep silence.</div><div><br></div><div>Best regards</div><div>Zhiqian<br><div><div><br><div>> Subject: Re: [erlang-questions] Update with complicated data structure<br>> From: ok@cs.otago.ac.nz<br>> Date: Wed, 25 Nov 2015 17:13:23 +1300<br>> CC: erlang-questions@erlang.org<br>> To: on-your-mark@hotmail.com<br>> <br>> <br>> On 24/11/2015, at 7:51 pm, YuanZhiqian <on-your-mark@hotmail.com> wrote:<br>> <br>> > Hi Richard,<br>> > <br>> >   Thanks for your elaborative comments. Some of the advices are helpful and I appreciate a lot for that; but some of them are not quite on the track ...<br>> <br>> Well, if I'm not _shown_ the track it's hard to stay on it.<br>> > <br>> >   For example, regarding the array size issue, you see, it's just a sample where my point is focused on the assignment expression, so I use an array instead of a hash table which I actually have used in my project, for that would make the code messed up with less important parts. I am certainly not a C language tard = =<br>> <br>> "Tard"?  What does that mean?<br>> https://en.wikipedia.org/wiki/Tardigrade ?<br>> <br>> > <br>> >   And please allow me to clarify my purpose of this question, this is not an erlang v.s. c&c++ debate,<br>> <br>> That was understood; no clarification needed.<br>> <br>> > I am just facing an actual problem in real scenario, and need some practical advice.<br>> <br>> While it's not a C vs Erlang debate, it *is* a matter<br>> of trying to do things the C way in an Erlang program.<br>> > <br>> >   So it is not that I insist in making erlang behave the same as imperial language, but that it is a real requirement in the project that I'm trying to solve.<br>> <br>> I doubt that very much.  Requirements talk about what a program<br>> does, as seen from outside.  How the collection of companies is<br>> held, whether as a list, as a gb tree, as a map, as an ETS<br>> table, or even in the process dictionary (for safety, that<br>> had better be the process dictionary of a separate process)<br>> should be entirely up to you.  I have serious trouble<br>> believing in requirements that say<br>>  "You must use a data structure that makes search<br>>   and update take a long time."<br>> <br>> Your requirements may well say<br>>   "Update the consumption of company X by D"<br>> but of course you haven't shown us the requirements.<br>> <br>> One thing may have struck you already.<br>> If you are using a relational data base,<br>> changing one field of one record at a time is<br>> a good way to run quite slowly.  One way to get<br>> good performance out of RDBs is *batching*.<br>> <br>> Now if you kept the list of N companies *sorted* on increasing<br>> company_id, and if you had a *batch* of M companies to be<br>> updated, also in a list sorted on increasing company_id,<br>> then you can *merge* those two lists and produce a new list<br>> in O(N+M) time.  (This is what old-timers used to do with<br>> tape drives before even CODASYL data bases.)  But if you do<br>> it one company at a time, it's going to take O(N*M) time.<br>> If you use a gb_tree, O(lg(N)*M).<br>> <br>> So there is a really serious question about whether you really<br>> *HAVE* to update one field of one record, or whether you have<br>> a *batch* of fields, and possibly multiple updates.<br>> > <br>> >   As for the naming issue ... ok you are right, but does it really matter?<br>> <br>> Yes, it does.<br>> <br>> > At least not as important in my case ...<br>> > <br>> >   And you are asking me why I am using size_t instead of int, I don't know if I am right, but size_t seems an intended type for array indices,<br>> <br>> (a) It cannot possibly be.  C existed long before size_t did.<br>> (b) The name *tells* you what it's meant for: it is meant for<br>>     the *sizes* of objects.<br>> (c) Kernighan & Ritchie, "The C programming language", 2nd edition<br>>     consistently uses int for array indexing.  But what do they<br>>     know?  They only invented the language.<br>> <br>> > since it is unassigned,<br>> <br>> I think you mean 'unsigned', and that's actually bad.<br>> <br>> > and codes from google use size_t as well.<br>> <br>> Google invented Go.  They did not invent C and are<br>> not authorities on how it was meant to be used.<br>> <br>> > Try to compile using int, but configure your error level to the most strict mode, turn on "warning as error" option, then you won't get the code compiled.<br>> <br>> I have no idea what you are talking about.<br>> Code that indexes arrays using int gets through gcc, clang,<br>> lint, and splint at the highest levels with no warnings.<br>> <br>> Good C compilers warn about using *char* as an array index,<br>> because the programmer has no way of telling beforehand<br>> whether char is signed or unsigned, so<br>> a[(char)255] might or might not involve a negative subscript.<br>> But invalidating int would mean breaking almost all the C<br>> code ever written for Unix.<br>> <br>> I just checked the source code for (original) vi, and yep,<br>> it uses int subscripts, including "tp[-1]", which is not<br>> actually an unusual thing to do in C (tp being a pointer<br>> after the beginning of an array), and no usable C compiler is<br>> going to treat that as an error.<br>> <br>> >   So the point is, thanks again for your help, but unfortunately I am getting more confused with too much irrelevant comments.<br>> <br>> How about telling us what the actual requirements really<br>> actually are?<br>> How about explaining why you are using a list?<br>> I advised you to use a gb_tree (or something of that sort).<br>> Someone else suggested a new-fangled 'map'.<br>> Both are good suggestions.  What's wrong with them?<br>> How many companies are you carrying information about?<br>> <br>> <br></div></div></div></div></div></div>                                          </div></body>
</html>