Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Page 2 of 2 FirstFirst 12
Results 16 to 22 of 22

Thread: Array Noob

  1. #16
    New Coder
    Join Date
    Jun 2012
    Location
    San Diego
    Posts
    60
    Thanks
    46
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by Old Pedant View Post
    In a word, "NO."

    Step by step.

    JS sees the declaration var aryMonths, so it puts "aryMonths" into an internal table as the name of a known variable.

    Then it sees = new Array() and adds more information to that internal table: It now knows that the variable "aryMonths" is an array, so it allocates a POINTER (don't worry what that means) to an array. Initially, that pointer is null.

    Then it sees aryMonths[0] = "January"; It knows that "aryMonths" is an array, but checking the internal table, and it sees that no memory has yet been allocated for the array, so it allocates space for one element (element zero, in this case). It also sees the string "January" so it allocates internal space to store the internal representation of that string. And then it puts a POINTER to that string's internal representation into element zero of the array (at this point, the only element of the array).

    Then it sees aryMonths[1] = "February"; It knows that "aryMonths" is an array, and checking the internal table, and it sees that moemory has been allocated for only element zero of the array, so it allocates space for two elements (element zero and one, in this case). It copies the old element zero into the new space for element zero and throws away the old one-element array. It also sees the string "February" so it allocates internal space to store the internal representation of that string. And then it puts a POINTER to that string's internal representation into element one (1) of the array.

    It repeats the above for the 12 elements of the array you have defined. It ends up with an array of 12 POINTERS to the 12 internal representations of the strings. In turn, in the table of variables, "aryMonths" has a POINTER to that 12-element array.

    Now it sees return aryMonths[NUM-1];

    In order of precendence, it first calculates NUM-1. Then it sees that you are asking for an element (of a number matching that calculated value) of an array and, finally, realizes that you want the array named "aryMonths".

    So it goes into its internal table of variables, finds "aryMonths" and discovers that, indeed, it is an array (so you don't have a type mismatch error) and follows the pointer to the array space to find out the array has 12 elements (numbered 0 to 11). If the calculated array index (in this case, NUM-1 is NOT in that range, then the array element doesn't exist and you have an error. But when it does, it grabs the POINTER that is in that element number and runs off to see what it points to.

    In this case, it points to a string, so it gets the value of that string [which actually happens to be the POINTER to it, but that's a detail you don't care about].

    FINALLY, it sees the return and realize that it should return the value of that string to the caller of the function.

    NOW...

    All the above is actually simplified! In actuality, a JavaScript engine will typically be smart enough to realize that your aryMonths array can be treated as a constant (that is, nothing modifies it). So it may well do all that processing of the array and storing the internal representation thereof ahead of time, before the function is even called. If you will, it may "hoist" the constant code out of the function so it doesn't have to execute it each time the function is called.
    That's an outstanding explanation. That's exactly what I needed to hear. Man, that clears things up!!! The first step is just simply allocating the array to memory, pointing to each one. No commands are made yet; just storing to memory. Then in the order of precedence, the translator sees the [NUM-1], subtracts one from the variable NUM, and then sees it's part of an array. Goes to check out what it is, brings back the string, and finally sees the command to return the "value of that string to the caller of the function". Got it! so clear now. Thank you, Pedant.

    Quote Originally Posted by Old Pedant View Post
    And there are other possible simplifications and optimizations that the engine may do, hidden from you. (Probably none others in this simple case.)

    In short, the engine is smarter than you are about its job. (Smarter than me, too! That's no slur on you!) Really really bright people create computer languages. And they work very very hard to make the languages ever more efficient
    I wasn't trying to be a smart alec; I was honestly confused--a noob. Fully understanding something is how I think best. I need to be able to think like it so I can logically work with it. I simply need to understand why I'm doing this. I just think like that.

    So your first explanation is the classic way in which computers store memory and which memory is retrieved and command flow is executed, and the last sentence you made is how computer scientists have improved upon and sped up the old process to save some steps? Correct?

    Quote Originally Posted by Old Pedant View Post
    Not so incidentally, if you had coded
    Code:
    var aryMonths = ["January","February","March","April","May","June","July",
                    "August","September","October","November","December"];
    instead, JS could have parsed that, figured out there were 12 array elements, and avoided the incremental growth of the array caused by your as-is code. It's a tiny performance improvement, but a few dozen such improvements *can* make a difference.
    With this approach, would it still see January as [0], or in other words, start counting at zero, and I would still need the [NUM-1] with the 'return' command?

    Quote Originally Posted by Old Pedant View Post
    p.s.: And I didn't even describe what JS does when it see function MonthAsString(NUM)
    Oh, man. Please do. Don't stop.
    Last edited by ryanjohnsond; 06-26-2012 at 10:52 AM.

  2. #17
    Supreme Master coder! Old Pedant's Avatar
    Join Date
    Feb 2009
    Posts
    27,151
    Thanks
    80
    Thanked 4,559 Times in 4,523 Posts
    I wasn't trying to be a smart alec;
    I wasn't trying to imply that at all. I just meant that if you can think of some way to optimize the performance, the odds are very very good that your JavaScript engine is already doing it. If we had had this discussion back in, say, 1996, that may not have been true. I worked on the source code (written in C++ by the by) for Microsoft's version of JavaScript in 1999, and there were tons of ways I could have improved it (and a few where I actually did). But the versions of JavaScript that are out today are immensely more sophisticated and faster than 13 years ago.

    With this approach, would it still see January as [0], or in other words, start counting at zero, and I would still need the [NUM-1] with the 'return' command?
    Yes. There is no SEMANTIC difference between adding the elements to the array one at a time and adding them all at once. It's just a SYNTAX difference. As one of the best language designers I ever knew was fond of calling it: "Syntactic sugar." Stuff that doesn't affect how the language operates but makes it faster or easier to use.

    Oh, man. Please do [describe how functions are stored/created/parsed]. Don't stop.
    Actually, that's harder than you might think, because the actual implementation probably varies a lot from JS implementation to implementation.

    Fundamentally, though, the function name goes into that same internal lookup table (because functions are just objects, in JavaScript, and they have to be accessible in the same way other objects are). And then the type of the variable is set to "FUNCTION" and the pointer in that table points to the code that implements the function. The code is a translation from your text into an internal format, so that when it is executed it can be much more efficient than having to stop and interpret your text each time.
    Last edited by Old Pedant; 06-27-2012 at 12:29 AM.
    An optimist sees the glass as half full.
    A pessimist sees the glass as half empty.
    A realist drinks it no matter how much there is.

  3. Users who have thanked Old Pedant for this post:

    ryanjohnsond (06-28-2012)

  4. #18
    New Coder
    Join Date
    Jun 2012
    Location
    San Diego
    Posts
    60
    Thanks
    46
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by Old Pedant View Post
    I wasn't trying to imply that at all. I just meant that if you can think of some way to optimize the performance, the odds are very very good that your JavaScript engine is already doing it. If we had had this discussion back in, say, 1996, that may not have been true. I worked on the source code (written in C++ by the by) for Microsoft's version of JavaScript in 1999, and there were tons of ways I could have improved it (and a few where I actually did). But the versions of JavaScript that are out today are immensely more sophisticated and faster than 13 years ago.
    Would Pointers be taught to most Comp. Science majors? I've read books on JS and taken a class, but they've never discussed pointers.
    Last edited by ryanjohnsond; 06-28-2012 at 10:16 AM.

  5. #19
    Supreme Master coder! Old Pedant's Avatar
    Join Date
    Feb 2009
    Posts
    27,151
    Thanks
    80
    Thanked 4,559 Times in 4,523 Posts
    Short answer: Yes.

    Pointers are an integral part of some computer languages: C and C++ for instance. Other languages hide the implementation of pointers under the covers, such as Java and JavaScript, by calling them "references". The big difference: In C and C++ you can find out what the VALUE of a pointer is (that is, what the actual address in computer memory is that it is pointing to). In Java and JavaScript (and many other languages), a reference is really a pointer but the language gives you no way of knowing what actual memory address it refers to. (And there is good reason for that: If a language is allowed to move objects around--e.g., to compact memory usage--then the address changes. If you never knew the actual address, if you only had a reference to the object, then you don't have to even know that happened.)

    But all languages use pointers internally. It is just whether or not they are exposed to the user that differs from language to language.

    Again, there's nothing magic about a pointer: It simply is a number that happens to be the address in memory of something.

    [Short digression: In C/C++, you can actually "look" at memory, by address, by converting an integer into a pointer. So, for example, if I wanted to look at memory location 1,338,400 I could do:
    Code:
         int i = 1338400;
         byte *b = (byte *) i; // convert the integer to a pointer to bytes
         byte byteAt1338400 = *b;
    Why would you ever do that? In small devices, certain pieces of hardware are often implemented as just addresses in memory. So say there was a temperature reader and its address in [fake] memory was 1338400. That code just read the temperature from it! There's no equivalent way to do that with Java/JavaScript.]
    An optimist sees the glass as half full.
    A pessimist sees the glass as half empty.
    A realist drinks it no matter how much there is.

  6. Users who have thanked Old Pedant for this post:

    ryanjohnsond (06-30-2012)

  7. #20
    New Coder
    Join Date
    Jun 2012
    Location
    San Diego
    Posts
    60
    Thanks
    46
    Thanked 0 Times in 0 Posts
    Thank you very very much for helping me, Old Pedant. It's really helped. Do you have a website with tutorials? I hope to tap your shoulder again.

  8. #21
    Supreme Master coder! Old Pedant's Avatar
    Join Date
    Feb 2009
    Posts
    27,151
    Thanks
    80
    Thanked 4,559 Times in 4,523 Posts
    Quote Originally Posted by ryanjohnsond View Post
    Thank you very very much for helping me, Old Pedant. It's really helped. Do you have a website with tutorials? I hope to tap your shoulder again.
    No. There are tons of tutorials out there, the world doesn't need another one.

    And 98% of all people who use JavaScript won't care about any of the kind of stuff we just discussed. They just want to know what it can do and how they can use it and could care less about what goes on under the covers.
    An optimist sees the glass as half full.
    A pessimist sees the glass as half empty.
    A realist drinks it no matter how much there is.

  9. Users who have thanked Old Pedant for this post:

    ryanjohnsond (07-01-2012)

  10. #22
    New Coder
    Join Date
    Jun 2012
    Location
    San Diego
    Posts
    60
    Thanks
    46
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by Old Pedant View Post
    No. There are tons of tutorials out there, the world doesn't need another one.
    You're tutorials would be different. I can tell. Just need the right 2% asked.

    Quote Originally Posted by Old Pedant View Post
    And 98% of all people who use JavaScript won't care about any of the kind of stuff we just discussed. They just want to know what it can do and how they can use it and could care less about what goes on under the covers.
    I can they know how it works, unless they understand these details? I get tired of guessing. I wan to know, and to know is to understand. Sorry. Just the way I work.


 
Page 2 of 2 FirstFirst 12

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •