+- HP Forums (https://www.hpmuseum.org/forum)
+-- Forum: HP Calculators (and very old HP Computers) (/forum-3.html)
+--- Forum: HP Prime (/forum-5.html)
+--- Thread: GROBW/GROBH vs GROBW_P/GROBH_P (/thread-11571.html)
GROBW/GROBH vs GROBW_P/GROBH_P - sasa - 10-10-2018 11:27 PM
The manual specified what GROBW/GROBH should return - weight and height of specified graphics variable. What it actually returns is rather unexpected:
Code:
export SZ_GR_T3()
begin
print("G0 " + grobw + "x" + grobh);
print("G0 (_P) " + grobw_p + "x" + grobh_p);
end;Code:
G0 32x23.8904109589
G0 (_P) 320x240RE: GROBW/GROBH vs GROBW_P/GROBH_P - Didier Lachieze - 10-11-2018 12:08 AM
As explained in the manual (and the on-calc help) under Drawing:
Quote:There are two identical sets of functions that can be used to modify graphic variables. The first set of them work based on Cartesian coordinates using the Cartesian plane defined in the current app by the variables Xmin, Xmax, Ymin, and Ymax in the Plot setup. The rest work on absolute pixel references based on the physical display of the HP Prime. For these functions, (0,0) is the top left pixel of the GROB, and (320,1240) is the bottom right. This second set of functions—those that work with pixels—have a _P suffix attached to their name, as in ARC_P and LINE_P.
So GROBH and GROBW return cartesian dimensions, not pixel dimensions as GROBH_P and GROBW_P.
For example, compare {GROBW_P,GROBH_P} with C→PX(GROBW/2,-GROBH/2)
RE: GROBW/GROBH vs GROBW_P/GROBH_P - sasa - 10-11-2018 02:34 AM
(10-11-2018 12:08 AM)Didier Lachieze Wrote: As explained in the manual (and the on-calc help) under Drawing:
...
So GROBH and GROBW return cartesian dimensions, not pixel dimensions as GROBH_P and GROBW_P.
For example, compare {GROBW_P,GROBH_P} with C→PX(GROBW/2,-GROBH/2)
Thank you for your respond. I understand these functions are for Cartesian plane - the screen coordinate system have top left corner defined as (0,0) (a relict from early CRT time), while in Cartesian plane (0,0) is the center...
However, GROBW returns 32 and GROBH 23.8904109589, which is rather strange. Online Help state GROBW=32 and GROBH=24 (the manual does not specify it), meaning that Cartesian plane is actually 32x24
And obviously, unexpected results are shown:
C→PX(0,0) returns {160,110}
C→PX((GROBW/2),(-GROBH/2)) returns {320,229}
PX→C(0,0) returns {−16,10.9}
PX→C(0,239) returns {−16,−12.8908675799}
Further confusion in the manual is following: "... pixel coordinates where the pixel 0,0 is the top left pixel and 320, 240 is the bottom right". That is not possible, if the screen itself have physical resolution of 320x240. Translation from screen to Cartesian plane and vice versa is trivial. However, some unexpected results are present here.
To me, all that indicate several bugs in conversion and/or default values for screen and Cartesian plane.
RE: GROBW/GROBH vs GROBW_P/GROBH_P - Tim Wessman - 10-11-2018 02:46 AM
There are no bugs here and the explanation is correct. Because the screen is not an odd number of pixels, some internal adjustment happens internally on the Cartesian width to ensure plotted items remain "square" and can be centered properly. That manual simply does not show it because it would be very unpleasant to read a big decimal number and confusing to new readers. The same thing is in the UI itself which basically "lies" to round to a nice number there. This also allows your cursor to report nice numbers instead of crazy decimals.
The whole point of the Cartesian drawing commands is to enable drawing to existing plots, or to do plotting type applications. In this it works perfectly regardless of a small discrepancy by one pixel in the width. Any algorithm or code developed using them will work as expected. Changing it to be "exact" would simply cause a less pleasant user experience.
The manual does have the mistake you pointed out regarding 0,0 -> 320,240 (should be 319,239)
RE: GROBW/GROBH vs GROBW_P/GROBH_P - toml_12953 - 10-11-2018 09:18 AM
(10-11-2018 02:34 AM)sasa Wrote: Thank you for your respond. I understand these functions are for Cartesian plane - the screen coordinate system have top left corner defined as (0,0) (a relict from early CRT time), while in Cartesian plane (0,0) is the center...
The beauty of using Cartesian coordinates is that you can define the screen to be anything you want. (0,0) can be in the lower left if you only want to deal with quadrant 1. See how much simpler the following program is with a user-defined coordinate system?
Code:
EXPORT SINWAVE()
BEGIN
Xmin:=0; Xmax:=2*PI;
Ymin=-.85; Ymax=1;
RECT(0);
LINE(0,0,2*PI,0,#777777);
FOR A FROM 0 TO 2*PI STEP .01 DO
PIXON(A,SIN(A),#00FF00);
PIXON(A,COS(A),#0000FF);
END;
FREEZE;
END;Think of how you'd have to write those LINE and PIXON statements if (0,0) was the upper-left corner and (319,239) was the lower-right!
RE: GROBW/GROBH vs GROBW_P/GROBH_P - sasa - 10-11-2018 12:52 PM
(10-11-2018 02:46 AM)Tim Wessman Wrote: There are no bugs here and the explanation is correct....
It is evident that the center of the screen is shifted up for 10 pixels and down rest of the bottom not accessible if used values from these functions:
Code:
export SZ_GR_T4()
begin
//Reset to default values, if any previous program change it
// Xmin := −15.9;
// Xmax := 15.9;
// Ymin := −10.9;
// Ymax := 10.9;
local x,y;
local c_r := #FF0000;
local sx:= GROBW/GROBW_P;
local sy:= GROBH/GROBH_P;
rect_p(255);
wait(1);
// Fill all available Cartesian plane pixel by pixel
for y := -GROBH/2 to GROBH/2 step sy do
for x := -GROBW/2 to GROBW/2 step sx do
pixon(x,y,#333333);
end;
end;
wait(1);
line_p(0, grobh_p/2-1, grobw_p-1, grobh_p/2-1, #00FFFF);
pixon_p(0,0, c_r);
pixon_p(grobw_p-1, grobh_p-1, c_r);
line(0,grobh/2, 0, -grobh/2, c_r);
line(-grobw/2,0,grobw/2,0,c_r);
wait(1);
for y := -grobh/2 to grobh/2 do
pixon(0,y, #FFFFFF);
end;
freeze;
end;One horizontal and one vertical line will be only off, if make calculations to be exact and return exactly 32x24 for Cartesian plane, in order to display all correctly - including center (0,0) to be shown with only one line off.
Once again, C→PX(0,0) returns {160, 110}
RE: GROBW/GROBH vs GROBW_P/GROBH_P - sasa - 10-11-2018 01:27 PM
(10-11-2018 09:18 AM)toml_12953 Wrote: The beauty of using Cartesian coordinates is that you can define the screen to be anything you want. (0,0) can be in the lower left if you only want to deal with quadrant 1. See how much simpler the following program is with a user-defined coordinate system?
It is not a point at all about clearness...
Quote:Think of how you'd have to write those LINE and PIXON statements if (0,0) was the upper-left corner and (319,239) was the lower-right!
Several problems I noticed in your program:
1. You changing global settings and not return previous. That force other programmers to return default or its own settings in order to ensure his program to work correctly.
2. The line contains "Ymin=-.85; Ymax=1;" which do nothing in Pascal and here with PPL - it compare content only (usage := )... Usual bug for all people to mix assign and compare signs comes from c-like programming languages to Pascal and vice versa.
3. Step of 0.01 is quite optimistic. It should be calculated regarding the length. Then will be drawn much more accurately and with minimum steps... Anyway, that is not important much on this small screen.
Not an issue at all to make corrections, on desktop programming that is only way.
Your a bit modified sample:
Code:
EXPORT SINWAVE()
BEGIN
local W := 320;
local H := 240;
local W2:= W/2;
local H2:= H/2;
RECT(0);
LINE_P(0,H2,W,H2,#777777);
FOR A FROM 0 TO 2*PI STEP 0.01 DO
PIXON_P(A/(2*PI)*W,-SIN(A)*H2+H2,#00FF00);
PIXON_P(A/(2*PI)*W,-COS(A)*H2+H2,#0000FF);
END;
FREEZE;
END;RE: GROBW/GROBH vs GROBW_P/GROBH_P - toml_12953 - 10-11-2018 06:34 PM
(10-11-2018 01:27 PM)sasa Wrote: Several problems I noticed in your program:
1. You changing global settings and not return previous. That force other programmers to return default or its own settings in order to ensure his program to work correctly.
2. The line contains "Ymin=-.85; Ymax=1;" which do nothing in Pascal and here with PPL - it compare content only (usage := )... Usual bug for all people to mix assign and compare signs comes from c-like programming languages to Pascal and vice versa.
3. Step of 0.01 is quite optimistic. It should be calculated regarding the length. Then will be drawn much more accurately and with minimum steps... Anyway, that is not important much on this small screen.
Not an issue at all to make corrections, on desktop programming that is only way.
You missed the whole point of my message! I wasn't giving a course in programming but just an example of using Cartesian coordinates as opposed to pixel addressing. I typed it in fast so I missed the colons but that's not the point, either. The missing colons, the step value and local vs global variables have nothing to do with my point. I was replying to your statement "Thank you for your respond. I understand these functions are for Cartesian plane - the screen coordinate system have top left corner defined as (0,0) (a relict from early CRT time), while in Cartesian plane (0,0) is the center..." If you were thinking that Cartesian coordinates made (0,0) be in the center of the screen, then I wanted to show that on the Prime Cartesian coordinates can be anything you want. (0,0) doesn't have to be in the center of the screen. THAT was my point.
RE: GROBW/GROBH vs GROBW_P/GROBH_P - sasa - 10-11-2018 07:34 PM
(10-11-2018 06:34 PM)toml_12953 Wrote: ...
THAT was my point.
My point was that Cartesian plane in HP Prime is not perfectly implemented and I have asked only confirmation for unexpected numbers, on which Tim elaborated clearly. As well, It is not at all difficult (as you presented) to use directly screen coordinate system. I used similar approaches with any graphical application I have made in my professional carrier (If needed Cartesian plane) and there is no much difference where is the coordinate center on the screen as translation is trivial in any case...
I will be more specific in the future or send the noted issue directly to HP.
Thank you.
RE: GROBW/GROBH vs GROBW_P/GROBH_P - toml_12953 - 10-11-2018 10:45 PM
(10-11-2018 07:34 PM)sasa Wrote:(10-11-2018 06:34 PM)toml_12953 Wrote: ...
THAT was my point.
My point was that Cartesian plane in HP Prime is not perfectly implemented and I have asked only confirmation for unexpected numbers, on which Tim elaborated clearly.
The Cartesian plane seems to work pretty good for me but I wonder why setting Ymin and Ymax doesn't map the entire screen to those coordinates. a band of about 0.7cm across the bottom isn't mapped like the rest of the screen. I set Ymin to -1 and Ymax to 1 and get the band. If I set Ymin to -.85, the entire screen is mapped. Is this documented somewhere?
RE: GROBW/GROBH vs GROBW_P/GROBH_P - Tim Wessman - 10-11-2018 11:37 PM
Yes and no re the documentation. Some specifics are not in there.
The point of the mapping is to make it easy for general users to make programs that can integrate nicely with existing plots or graphs. Think things like drawing boxes to approximate integrals for example. For that purpose, it works great.
If you are looking for a complete "map the whole screen" to a pixel perfect system, then it is not going to do that. Menu will be left out, the last line on one side will be out, etc. Basically, it matches perfectly with what is happening internally in the HP plotter which does do some "lying" in the name of making the interface more understandable and friendly.
RE: GROBW/GROBH vs GROBW_P/GROBH_P - cyrille de brébisson - 10-12-2018 05:36 AM
Hello,
To add-lib to what Tim said, Cartesian coordinates are linked with the function grapher.
The function grapher does "lie" somewhat to the user in the xmin/xmax in order to try to generate simpler per pixel coordinates and to "hide" the menu...
The programming graphic drawing functions both have 2 versions. Per pixel and cartesian.
The "idea"/"design" behind the 2 was that, programmers would use the per pixel version for pretty much everything (as it is a 1 to 1 map).
There is one exception of course, it is if you want to draw things that will interract/intermesh with drawing coming from the function grapher. In this case, you should be using cartesian coordinates in order to make sure that the mappings are the same.
Cyrille
RE: GROBW/GROBH vs GROBW_P/GROBH_P - sasa - 10-12-2018 06:46 AM
(10-12-2018 05:36 AM)cyrille de brébisson Wrote: To add-lib to what Tim said...
Ciryille,
It would be definitely nice to put more details into manual accordingly and correct these noted contradictions, including in Online help...
Thanks to all for participation.
RE: GROBW/GROBH vs GROBW_P/GROBH_P - Dirk.nl - 10-12-2018 11:26 AM
Maybe more information about pixels in attached document.
[attachment=6445]
RE: GROBW/GROBH vs GROBW_P/GROBH_P - toml_12953 - 10-12-2018 02:07 PM
(10-12-2018 11:26 AM)Dirk.nl Wrote: Maybe more information about pixels in attached document.
Great! Thanks. Although it's not noted AFAICS, even when you choose user-defined coordinates, you can still plot outside the coordinate frame.