Conflicting Design Choices

[czardas]

Sometimes I wonder if I made the right choice when I design a function library. 

A simple conflicting design choice scenario could be the representation of a chess board. With the standard chessboard layout, the bottom left corner square is referred to as a1, and the top right corner is h8. If I use a two dimensional array to represent a chessboard, it will would make sense to create the array upside-down. The problem to the programmer would be to picture a complex system such as a chess game upside-down. This is really a simple example, but the point is there is a conflict of interest.

Faced with difficult choices at the design stage, do you turn the world on its head to conform to programming conventions, or ignore conventions and try to mimic reality?

Edited June 3, 2014 by czardas

[Draygoes]

I prefer to conform, as what we do works quite well. Trying to go against that (which I have) doesn't really fell right, at least to me.

I hope that I have answered your question as well as possible. I am trying to keep the answer simple.

[Somerset]

Buck the system.

[guinness]

Stick with programming conventions and document as to why you chose that design pattern.

[Somerset]

I like this design.

[czardas]

Stick with programming conventions and document as to why you chose that design pattern.

 

This can be confusing at times - there are so many conventions. Take for example the different ways people write their native languages. Some are written from right to left and others go down the page. Numbers are funny because the digits on the far left are larger than those which follow. Going back to my upside-down chessboard example, does it matter which way up the array is? We can always loop from the last row to the start right? So the code can kind of run backwards, to make further development more natural. Bending the rules slightly to accommodate visualization of the task at hand. Here I see a quandary - when to throw out the rule book and follow your instinct. It would be interesting to hear some more of your thoughts.

Edited June 3, 2014 by czardas

[guinness]

Well OK ... with my Stack UDF I kind of bent the rules because instead of adding to the top, I add to the bottom (it's internally easier as I don't have to shift down one every time). So I then provided a ToArray() method which "visually" outputs the Stack as you would expect (last in on top). So I guess use my Stack/Queue UDF as an example, internally do what you feel is easier for you, but output to the user/developer with the proper convention. It's a little late so I hope this made some sense to you.

I am surprised this isn't in Dev Chat as Chat is well...I think I have made my opinion known about this section already.

[czardas]

Well it could  go in Dev chat but I would prefer if it remained here, where I can enter a discussion without the whole world watching. It feels more relaxed and besides, I like beerman's jokes.

[guinness]

OK. Though I haven't forgotten what you said to me a while back  when I mentioned asking in Chat (though I meant Dev chat).

>> 

Edited June 4, 2014 by guinness

[czardas]

I had forgotten that thread. Anyway the question doesn't relate to any particular programming language or specific problem and I thought that would be perhaps too vague in that sense. The other thing is I have contemplated rewriting several thousand lines of code because of a similar design choice mistake, but I don't know if I will be able to follow the code anymore if I make what I consider a more sensible programming choice. I can hardly follow it already. I was interested to see responses to my question from people I have some familiarity with, but now you've convinced me otherwise, let's see what the world has to say.

[Ascend4nt]

czardas: Hey, as long as it works, and doesn't take advantage of undocumented quirks of a language, you can do whatever you like!  But make sure you and whoever else needs to read it will be able to understand it.  Comment and document the behavior and logic where necessary.  As guinness has mentioned, the implementation is up to you, but providing consistent/intelligent behavior and interface will be key to having it accepted by others.

[guinness]

You've made my day. Also when did this thread move?

[czardas]

czardas: Hey, as long as it works, and doesn't take advantage of undocumented quirks of a language, you can do whatever you like!  But make sure you and whoever else needs to read it will be able to understand it.  Comment and document the behavior and logic where necessary.  As guinness has mentioned, the implementation is up to you, but providing consistent/intelligent behavior and interface will be key to having it accepted by others.

 

In my particular case it is a question of having overlooked a very simple and basic concept because of an overwhelming number of other, more complicated, considerations in my design. I used a piano keyboard layout and mapped it onto binary as is, instead of using an imaginary left-handed piano keyboard to simplify calculations. The result is that I can read the binary easily, but the pitch of the notes falls as the integers get larger - an inverse relationship. Now after several thousand lines of ugly code, I'm unsure if it is worth the effort to try and simplify the maths by switching from musician design to programmer design. The question is: how long will it take and, more importantly, will I still be able to understand what I'm writing (gnitirw m'I tahw)?

If the MSB in a 32-bit integer was on the right hand side, instead of on the left, then my task would be easier. I can hardly expect something like that to ever happen.  

Also when did this thread move?

 

I asked M23 to move it yesterday.

Edited June 5, 2014 by czardas

[Mat]

The answer is: those details should be hidden, and the data should be accessed by a function (or several functions).

As a general rule with complex data structures, or even simple data structures, the user (you) should not know how the data is stored in memory exactly. It helps to have some idea, but you don't need to know the exact implementation details. This is actually a very common problem, particularly in graphics (think of drawing a graph in a GUI, the y axis is based on the bottom left corner, but coordinates for GUIs are done on the top right).

Here's a Matrix class I wrote for someone this morning who wanted to know about template classes and static_assert:

template<int R, int C>
class Matrix
{
    static_assert( R > 0 && C > 0, "Matrix dimensions must be positive and non-zero." );

  private:
    int* data;

  public:
    Matrix( )
    {
        this->data = new int[R * C];
    }

    ~Matrix()
    {
        delete this->data;
    }

    int& at( int r, int c )
    {
        if ( r >= R || c >= C ) {
            // The given index is too big for the matrix!
            throw std::out_of_range( "Index out of matrix bounds" );
        }

        return ( this->data[r * C + c] );
    }
};

The user does not need to know that I'm actually storing the matrix as a single array, all they know is that each element is an int in memory, and they can get a reference to it using the at() method. I could have stored it as a 2d jagged array, but this wouldn't have made sense from a programming perspective. 

The same goes for AutoIt, and languages where you don't get classes and structures to help you with this. Look at the "memory" functions I made >here, they are simple, and could easily be done without the wrapping functions, but with the code as it is I left my options open, and could now go back and write a garbage collector or something without changing much of the current code at all. Even something as simple as reading a memory address I made a wrapping function for.

Edited June 6, 2014 by Mat

[czardas]

I agree the binary data should be hidden, but I do not believe the libraries (I'm referring to) could so easily have easily been written from a purist coding perspective. Besides, someone in the future might want to try and improve my code. Then they might need to look at the binary in some detail. Why is there the need for byte order marks? ... In a 32-bit integer, why is the sign bit on the left instead of the right. Surely this has be some kind of trade off because it creates a closed system (not allowing numbers to grow beyond 0x7FFFFFFF); or could it be a design flaw which (only) became more apparent after implementation? The issue is conflicting numeric ranges between 32-bit and 64-bit integers. The size of the container should really be irrelevant when you think about it.

Another tricky question: Should a good design be compromised in order to pander to a flawed convention?   

Edited June 7, 2014 by czardas

[czardas]

Perhaps if this topic was moved back to the chat section it would get more response.

I think the answer to my previous question would have to be sometimes yes, sometimes no; depending on the particular scenario. Look at how much trouble has been caused by conflicting code tables on the internet. I imagine browser developers must have had to jump through some really mad hoops to pander to all the quirks. Seriously though, there must be exceptions to the rule, where swimming against the tide gets you to your actual goal. It can even lead to innovation in the odd instances where you uncover a pot of gold (serendipity).

My earlier thoughts about moving the sign bit in an integer was a bit of a joke, but it would solve some problems. I imagine getting programmers to recognize 0101b as being equal to -2 would be asking too much. There's probably other complications for all I know, but it's interesting to contemplate.

Edited June 8, 2014 by czardas

[guinness]

Perhaps if this topic was moved back to the chat section it would get more response.

Do you want quantity or quality?

[czardas]

More pictures would be nice!

Edited June 8, 2014 by czardas

[Mat]

0101b in a back to front 2s complement would be -6. 

2s complement works because you can do unsigned arithmetic on signed numbers and it works. For example -3 + 4 is 1101 + 0100 = (1)0001 which is correct, likewise 3 + (-4) is 0011 + 1100 = 1111  or -1 which is correct again.

You'll glad to know that for most processors there will be an instruction to upsize the integer taking sign into account (movsx for pcs, I've seen "ext" used for some microprocessors).

[czardas]

Oh, I just moved the sign bit to the right and shifted everything else one step to the left, so 0101b would be 010 (number) & 1b (sign bit) giving -2. This would produce an open ended system in both directions (positive and negative). That's different to a simple reverse sequence, which I also mention above.

Now I see what's going on with 2's compliment - thanks for the simple illustration. I still find it annoying though. I suppose that's because AutoIt casts numbers as certain types automatically. I have struggled with this for years. I generally want to use binary as is - integers ranging from 0 to infinity.

Finally: I have decided to stick with my design, mentioned in post 10 >no13, because it is workable, easy to read and conforms to a convention - albeit not a programming convention. The maths will have to remain slightly more difficult to accommodate the reverse sequencing. Besides, the binary can always be reversed as a preprocessing step if need be. I accidentally took a wrong turn in the beginning - now it's a design choice justified by reasoning. 

---

Actually it always was a design choice justified by reasoning, but I overlooked one consequence which I only discovered recently.

Edited June 9, 2014 by czardas