Board Logo
« rows and cols vrs x and y »

Welcome Guest. Please Login or Register.
Dec 12th, 2017, 10:03am


Conforums Terms of Service | Membership Rules | Home | Search | Recent Posts | Notification | Format Your Message | Installation FAQ

Please use the forums Search feature before asking.
Please post code using the code box described in Format Your Messages.
This will keep indentation, separate it better form the message and prevent gibberish.
If the code is too long for one post or additional files are needed, upload a ZIP archive to the Just BASIC Files Archive Site.

« Previous Topic | Next Topic »
Pages: 1  Notify Send Topic Print
 thread  Author  Topic: rows and cols vrs x and y  (Read 268 times)
bplus
Senior Member
ImageImageImageImageImage


member is offline

Avatar




PM

Gender: Male
Posts: 1229
xx rows and cols vrs x and y
« Thread started on: Oct 5th, 2017, 1:35pm »

Richard on another forum has posted a "confusion" between rows and cols. I don't know of the instance he's pointing at (Liberty forum?) something about sorting...

but if you ask me I think JB did something right with it's version of LOCATE

help chm file Quote:
LOCATE IN MAINWINDOW


locate x, y


Description:
Using LOCATE in the mainwin causes text to be printed at the x, y location specified. These coordinates refer to the column and row of text, not to screen pixels. This command functions in the same was as the Qbasic LOCATE command and is used to position text on the mainwin. Here is a short demo:


'plot a wave
for x = 1 to 50
i = i + 0.15
locate x, 12 + int(cos(i)*10)
print "*";
next x



For me it was always confusing how the old BASICs did LOCATE with row first , col 2nd but did all their graphics x, y which would be column (across) , row (down)

To me, JB (and Liberty) fixed a cause of great confusion specially for newbies, though it might be confusing for those who have worked allot in older, classic BASICs.
User IP Logged

B+
rtr
Member in Training
ImageImage


member is offline

Avatar




PM


Posts: 40
xx Re: rows and cols vrs x and y
« Reply #1 on: Oct 5th, 2017, 3:28pm »

on Oct 5th, 2017, 1:35pm, bplus wrote:
Richard on another forum has posted a "confusion" between rows and cols. I don't know of the instance he's pointing at (Liberty forum?) something about sorting...

It's this thread at the LB Community forum. In reply to a report of a sorting problem, Rod Bird, John Fisher and Chris Iverson have all stated that the OP has swapped the row and column indices. They claim that a 2-dimensional array is declared like this in LB:

Code:
    dim array(columns,rows) 

But in fact they are wrong and the OP is correct:

Code:
    dim array(rows,columns) 

I don't know why the sort isn't working, possibly a bug in LB, but swapping the indices makes it worse rather than better!

Quote:
For me it was always confusing how the old BASICs did LOCATE with row first , col 2nd but did all their graphics x, y which would be column (across) , row (down)

Sorry to disappoint you, but LB has the same 'confusing' difference between arrays and graphics coordinates. Arrays are indexed as (row,column), i.e. vertical before horizontal, whereas graphics coordinates are (x,y), i.e. horizontal before vertical.

Just BASIC does not have the SORT statement so the order of array indices is largely arbitrary. You can reverse them as (column,row) and you won't notice any difference, but in Liberty BASIC 2D arrays are sorted in row order, not column order.

Richard.
User IP Logged

bplus
Senior Member
ImageImageImageImageImage


member is offline

Avatar




PM

Gender: Male
Posts: 1229
xx Re: rows and cols vrs x and y
« Reply #2 on: Oct 5th, 2017, 4:12pm »

Arrays in my opinion could always go either way depending how you use them (it's all hidden in memory, out-a-sight specially to newbies).

but, you can only use LOCATE one way and JB is consistent with graphics x across rows, y down columns, you only have to be mindful of cell units or pixels.

Also:
How is the sort routine parameters described in the documentation?
« Last Edit: Oct 5th, 2017, 4:18pm by bplus » User IP Logged

B+
rtr
Member in Training
ImageImage


member is offline

Avatar




PM


Posts: 40
xx Re: rows and cols vrs x and y
« Reply #3 on: Oct 5th, 2017, 5:36pm »

on Oct 5th, 2017, 4:12pm, bplus wrote:
Arrays in my opinion could always go either way depending how you use them

Whilst that is true, it is important to use the same terminology consistently otherwise people will get confused (and there's enough confusion on this subject already).

Quote:
How is the sort routine parameters described in the documentation?

That's the crucial point, and it's why I can confidently state that 2D arrays in Liberty BASIC use row,column ordering. The official description of the SORT statement is as follows:

Code:
    SORT arrayName(), start, end, [column] 

where the optional sort key is shown as [column] ("When this option is used, all the rows are sorted against each other according to the items in the specified column."). That leaves no room for doubt; if the indices were in the order you prefer, this would have to say [row] (and refer to sorting columns according to the specified row).

Richard.

« Last Edit: Oct 5th, 2017, 5:48pm by rtr » User IP Logged

bplus
Senior Member
ImageImageImageImageImage


member is offline

Avatar




PM

Gender: Male
Posts: 1229
xx Re: rows and cols vrs x and y
« Reply #4 on: Oct 5th, 2017, 6:51pm »

Thanks Richard, I see your point from your link to docs.

It is traditional for records to be rows and columns, fields of the record.
In the example given in doc, it is (record number, field) order, so Milfredo does have a proper concern.

Has anyone with a theory of solution actually run tests to prove their theory one way or the other?

90 fields for 1 horse, wow!
« Last Edit: Oct 5th, 2017, 6:54pm by bplus » User IP Logged

B+
zzz000abc
Full Member
ImageImageImageImage


member is offline

Avatar




PM

Gender: Male
Posts: 265
xx Re: rows and cols vrs x and y
« Reply #5 on: Oct 5th, 2017, 10:26pm »

on Oct 5th, 2017, 6:51pm, bplus wrote:
It is traditional for records to be rows and columns, fields of the record.

It depends on the way how things are presented or looked into.
When it is Array we are referring to a table with rows and columns.
When it is graphic we are referring to a grid with x,y coordinates.
« Last Edit: Oct 5th, 2017, 10:27pm by zzz000abc » User IP Logged

bplus
Senior Member
ImageImageImageImageImage


member is offline

Avatar




PM

Gender: Male
Posts: 1229
xx Re: rows and cols vrs x and y
« Reply #6 on: Oct 6th, 2017, 12:30am »

Hey zzz!

Did you take a summer vacation?

Missed your input here.

Looks like tsh73 rooted out the problem at LB forum.
« Last Edit: Oct 6th, 2017, 12:32am by bplus » User IP Logged

B+
rtr
Member in Training
ImageImage


member is offline

Avatar




PM


Posts: 40
xx Re: rows and cols vrs x and y
« Reply #7 on: Oct 6th, 2017, 04:47am »

on Oct 5th, 2017, 6:51pm, bplus wrote:
It is traditional for records to be rows and columns, fields of the record.

Indeed. That also fits with the way data is usually represented in a CSV file, in which each line corresponds to a record and each record contains multiple comma-separated fields.

Looked at this way, Liberty BASIC's SORT statement makes perfect sense. You choose a field (column) as the sort key and it then sorts the records (rows) into ascending or descending order of the contents of that field.

Of course LB could still have chosen to order the array indices as (column,row) rather than (row,column), that's largely arbitrary and an entirely separate issue. The (row,column) ordering is used by some other BASICs (notably BBC BASIC) but I don't know how common it is compared with the reverse.

In the same way that numbers are invariably represented with the least-significant digit on the right and the most-significant digit on the left, it seems logical to me to have the column index (which changes more quickly as you iterate through the array) on the right and the row index (which changes more slowly) on the left.

Richard.
User IP Logged

bplus
Senior Member
ImageImageImageImageImage


member is offline

Avatar




PM

Gender: Male
Posts: 1229
xx Re: rows and cols vrs x and y
« Reply #8 on: Oct 6th, 2017, 11:31am »

It's funny until this issue came up, I never thought of database display as much of a row, column thing as far as display goes, I had it in a different category onto itself I guess. Thus, my original post.

Generally you look up a record and then the field you are interested in (record, field) order.

Now! I see that the old Classic BASIC's were being consistent between LOCATE and database display! That is an eye / mind opener. Locate row, col

So one might say that graphics was the inconsistent one but in math the independent variable is traditionally pinned to the horizontal x-axis and graphs based on that. Surely a BASIC would want to remain consistent to that also (since BASIC started out helping math students (not yet committed to computer science (until strings entered the picture)). You start with an x and find it's y value, (x, y) but the y axis increases going down... hmm.

It does look as if LOCATE was originally based on database display.

But one has to remember in old days everything was printed and with that you have to start at top left of page and work your way with increasing line numbers, so that is maybe where y increases going down instead of up. Yep! I bet printing was the deciding factor of order choices.

When screens came into the picture, you needed LOCATE to jump around the screen because even though screens can roll down, you could no longer view contents at top until that was improved with scroll...
« Last Edit: Oct 6th, 2017, 11:40am by bplus » User IP Logged

B+
Rod
Administrator
ImageImageImageImageImage


member is offline

Avatar

Graphics = Goosebumps!


PM

Gender: Male
Posts: 3142
xx Re: rows and cols vrs x and y
« Reply #9 on: Oct 6th, 2017, 11:33am »

Probably the confusion stems from the fact that we can't use sort() in JB and have been free to choose our own conventions about how grids are defined. I don't even use sort() very often in LB due to quirks and bugs that Anatoly has clarified. I roll my own mostly and so can choose which dimension to sort on.

Perhaps the trick is to use meaningful names.

Code:


    'set up a 6x12 grid
    records=6   'x
    fields=12   'y

    'fill the grid with data
    dim dbf$(records,fields)
    for r=1 to records
        for f=1 to fields
            if f=1 then dbf$(r,f)=str$(r)else dbf$(r,f)=str$(int(rnd(0)*100))
        next f
    next r

    print "unsorted"
    print "records / fields---->"
    print "   |"
    print "   |"
    print "   |"
    print "   v"
    for r=1 to records
        for f=1 to fields
            print dbf$(r,f),
        next f
        print
    next r
    print
    print

    print "fields / records---->"
    print "   |"
    print "   |"
    print "   |"
    print "   v"
    for f=1 to fields
        for r=1 to records
            print dbf$(r,f),
        next r
        print
    next f

    wait


    [quit]
    close #main
    end
 
User IP Logged

rtr
Member in Training
ImageImage


member is offline

Avatar




PM


Posts: 40
xx Re: rows and cols vrs x and y
« Reply #10 on: Oct 6th, 2017, 12:43pm »

on Oct 6th, 2017, 11:31am, bplus wrote:
y increases going down instead of up.

In Liberty BASIC and Just BASIC, yes, but far from universally. For example in BBC BASIC positive Y is upwards (and 0,0 is the bottom left corner); the same is true in OpenGL and in PostScript, and in BMP files (indeed all Windows DIBs), and no doubt others.

The Cartesian Coordinate system we were taught at school has its origin at the bottom left corner, so it's arguable that the computer graphics that work the other way - and admittedly they are in the majority - are out of step.

It's generally thought that the positive-downwards convention stems from the way Cathode Ray Tube TV screens are (or were) scanned, which is a pretty poor reason to break with centuries of tradition.

Richard.
User IP Logged

tsh73
JB-Supporter


member is offline

Avatar




PM

Gender: Male
Posts: 3629
xx Re: rows and cols vrs x and y
« Reply #11 on: Oct 6th, 2017, 12:58pm »

Code:
It's generally thought that the positive-downwards convention stems from the way Cathode Ray Tube TV screens are (or were) scanned,  

I would vote for printing origin. With it, Y doing down makes perfect sense.

I confess in my early BASIC days I had hard time deciding
(row, column)
or
(column, row)
(and even "Y goes upward or downward")
Because obviously from mathematical point of view it's the same...
So I had to decide it for each program.
And all was fine until I mess it up in the middle of a program ;)
Now I just got used to (row, column), from top to bottom - but it's just convenience.
EDIT I don't have to think about it any more ;)

Luckily I happen to remember that LB sort bug.
Since I mainly use JB I don't use SORT often.
« Last Edit: Oct 6th, 2017, 1:00pm by tsh73 » User IP Logged

Q: "And if I took your codes and compile them, and sell them for a profit"?
A: Go ahead. I had my share of good then I coded it for fun, if you can make better use of it - please do.
(enjoying JB 1.01 on WinXP, netbook and desktop)
Rod
Administrator
ImageImageImageImageImage


member is offline

Avatar

Graphics = Goosebumps!


PM

Gender: Male
Posts: 3142
xx Re: rows and cols vrs x and y
« Reply #12 on: Oct 6th, 2017, 12:58pm »

Especially as it would have been just as simple to scan up as down! Perhaps it all went wrong when John Logie Baird spun his disc clockwise and set the screen position on the down stroke. He should have spun it anti clockwise.

Edit to add, or indeed spun it clockwise and set the screen position on the up stroke! skinning cats springs to mind.
« Last Edit: Oct 6th, 2017, 4:15pm by Rod » User IP Logged

rtr
Member in Training
ImageImage


member is offline

Avatar




PM


Posts: 40
xx Re: rows and cols vrs x and y
« Reply #13 on: Oct 6th, 2017, 5:28pm »

on Oct 6th, 2017, 12:58pm, tsh73 wrote:
I would vote for printing origin. With it, Y doing down makes perfect sense.

So in countries that use Arabic or Hebrew writing, for example (where the printing origin is top-right), you would have positive Y going downwards but positive X going right-to-left? laugh

Richard.
User IP Logged

Pages: 1  Notify Send Topic Print
« Previous Topic | Next Topic »

Conforums Terms of Service | Membership Rules | Home | Search | Recent Posts | Notification | Format Your Message | Installation FAQ

Donate $6.99 for 50,000 Ad-Free Pageviews!

| |

This forum powered for FREE by Conforums ©
Sign up for your own Free Message Board today!
Terms of Service | Privacy Policy | Conforums Support | Parental Controls