[erlang-questions] Update with complicated data structure

[YuanZhiqian]

Hi Richard,
  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.
"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? 
Sorry I don't have more patience to look through your verbose comments, learn some respect and be polite before your talk.
Read this to solve your "size_t" argument. 
http://stackoverflow.com/questions/1951519/when-to-use-stdsize-t
But I don't think it matter at all, use whatever type you want.
And please, leave those arrogant attitude and your cavil to yourself, they are irrelevant to the question. 
> Well, if I'm not _shown_ the track it's hard to stay on it.I'm afraid this is your own problem. Please keep the discussion on the track and friendly, or just keep silence.
Best regardsZhiqian

> Subject: Re: [erlang-questions] Update with complicated data structure
> From: ok@REDACTED
> Date: Wed, 25 Nov 2015 17:13:23 +1300
> CC: erlang-questions@REDACTED
> To: on-your-mark@REDACTED
> 
> 
> On 24/11/2015, at 7:51 pm, YuanZhiqian <on-your-mark@REDACTED> wrote:
> 
> > Hi Richard,
> > 
> >   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 ...
> 
> Well, if I'm not _shown_ the track it's hard to stay on it.
> > 
> >   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 = =
> 
> "Tard"?  What does that mean?
> https://en.wikipedia.org/wiki/Tardigrade ?
> 
> > 
> >   And please allow me to clarify my purpose of this question, this is not an erlang v.s. c&c++ debate,
> 
> That was understood; no clarification needed.
> 
> > I am just facing an actual problem in real scenario, and need some practical advice.
> 
> While it's not a C vs Erlang debate, it *is* a matter
> of trying to do things the C way in an Erlang program.
> > 
> >   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.
> 
> I doubt that very much.  Requirements talk about what a program
> does, as seen from outside.  How the collection of companies is
> held, whether as a list, as a gb tree, as a map, as an ETS
> table, or even in the process dictionary (for safety, that
> had better be the process dictionary of a separate process)
> should be entirely up to you.  I have serious trouble
> believing in requirements that say
>  "You must use a data structure that makes search
>   and update take a long time."
> 
> Your requirements may well say
>   "Update the consumption of company X by D"
> but of course you haven't shown us the requirements.
> 
> One thing may have struck you already.
> If you are using a relational data base,
> changing one field of one record at a time is
> a good way to run quite slowly.  One way to get
> good performance out of RDBs is *batching*.
> 
> Now if you kept the list of N companies *sorted* on increasing
> company_id, and if you had a *batch* of M companies to be
> updated, also in a list sorted on increasing company_id,
> then you can *merge* those two lists and produce a new list
> in O(N+M) time.  (This is what old-timers used to do with
> tape drives before even CODASYL data bases.)  But if you do
> it one company at a time, it's going to take O(N*M) time.
> If you use a gb_tree, O(lg(N)*M).
> 
> So there is a really serious question about whether you really
> *HAVE* to update one field of one record, or whether you have
> a *batch* of fields, and possibly multiple updates.
> > 
> >   As for the naming issue ... ok you are right, but does it really matter?
> 
> Yes, it does.
> 
> > At least not as important in my case ...
> > 
> >   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,
> 
> (a) It cannot possibly be.  C existed long before size_t did.
> (b) The name *tells* you what it's meant for: it is meant for
>     the *sizes* of objects.
> (c) Kernighan & Ritchie, "The C programming language", 2nd edition
>     consistently uses int for array indexing.  But what do they
>     know?  They only invented the language.
> 
> > since it is unassigned,
> 
> I think you mean 'unsigned', and that's actually bad.
> 
> > and codes from google use size_t as well.
> 
> Google invented Go.  They did not invent C and are
> not authorities on how it was meant to be used.
> 
> > 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.
> 
> I have no idea what you are talking about.
> Code that indexes arrays using int gets through gcc, clang,
> lint, and splint at the highest levels with no warnings.
> 
> Good C compilers warn about using *char* as an array index,
> because the programmer has no way of telling beforehand
> whether char is signed or unsigned, so
> a[(char)255] might or might not involve a negative subscript.
> But invalidating int would mean breaking almost all the C
> code ever written for Unix.
> 
> I just checked the source code for (original) vi, and yep,
> it uses int subscripts, including "tp[-1]", which is not
> actually an unusual thing to do in C (tp being a pointer
> after the beginning of an array), and no usable C compiler is
> going to treat that as an error.
> 
> >   So the point is, thanks again for your help, but unfortunately I am getting more confused with too much irrelevant comments.
> 
> How about telling us what the actual requirements really
> actually are?
> How about explaining why you are using a list?
> I advised you to use a gb_tree (or something of that sort).
> Someone else suggested a new-fangled 'map'.
> Both are good suggestions.  What's wrong with them?
> How many companies are you carrying information about?
> 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20151125/1e9ca165/attachment.htm>