Hi Chris, thanks for the reply. I agree that it is much easier thinking of things in terms of coordinates= and using the virtual negative spaces for hiding things.
It seems to me that XxYxZxUnit (Z=3D0 can be implied most of the time) th= e problem would be designating units being employed. I am not very REBOL = aware especially with style, so I have used =93x=94 as a marker for the m= easurement datatype (it is kinda ugly though). If this is taken seriously and =93real world=94 is made the essential cha= racteristic of such a datatype then the bare unit (XxYxZ or XxYxZx) would= be in metres.=20 Perhaps appending either =9310 ** -3=94 (mm), =9310 ** 3=94 (km), ie., = 10 to the power of 3 or minus 3. Because all the relations are essentiall= y mathematical it is just as easy to nominate a unit value in terms of a= metre, =930.0003527=94 being a printer's point; 1/72 of an inch.=20 Mixing units would be nice (4 * 10 ** -3)x4x(4 * 10 ** 3)x being a 4mm wi= de, 4m high block 4km deep. Hence: Point: 0.0003527 x12xxPoint or x(12 * Point)xx This is pure vertical measure of 4.2324mm or 12points.=20 I don't know whether it is REBOL style to have =93x=94 as identifiers, or= that 0x12x0xPoint would be more consistent =96 however others could come= up with something prettier it need only cover XYZ plus unit, based on a = metre assumption. Some standard assumption units (conversion tables, virtual units for such= things as GUIs, etc.,) could be very useful and need only to be a data = set to draw-upon, and fed into the measure datatype as required. Offset is important, but negative measures are not real world, I don't be= lieve they should have a place in a measurement datatype, rather as an ob= ject positioning function. Using Z with =930=94 as visible =93-1=94 is a= convenient way of keeping data buffered but invisible, just as =93Z =3D = 1=94 can bring in something to be buffered but invisibly behind, and it c= an be done by simply incrementing a measure datatype as a series, via off= sets. I am not thinking in any way of computing efficiency so much as scriptors= being able to have dialects that follow the practicalities of what they = are doing. Offset can be a very simple way to shuffle graphical elements = and with it control data loading and erasing. Likewise scale, or viewport.=20 Margin of error and precision do effect measure as a reliable dataype, I = don't know an elegant way to include this, but in many scientific applica= tions these can be very important, eg +- 0.01 might be added to the datat= ype unambiguously and rounding could always be a surrounding function. Just suggestions, but a real world datatype like measure seems a very han= dy thing to have. Greg Schofield Perth Australia --- Message Received --- From: Chris Dwyer <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date: Sat, 8 Sep 2007 10:37:18 -0400 Subject: [REBOL] Re: - XYZ Hi Greg I agree with your concept of a real world XYZ. In a sense on the web =20 there is already a pseudo scale factor "em". We us it a lot since it =20 scales well for different browsers and different screen resolutions. However it is a stupid workaround, but it does support the need for a =20= scaling factor on the internet at least. I have always seen the GUI as an open book, with "0" as the top left =20 corner of the right page and the top left corner of the left page. Only the right page is actually ever seen. It starts at 0 and runs to =20= infinity. The left page starts at 0 and runs to negative infinity. In the good old days (1983) on the Mac we used a great deal of the =20 negative page as an off screen buffer. Not just for animation sprites =20= etc, but actually some assembly of " page parts". I have never understood why off screen buffers have never been used =20 on the internet, especially for dial-up situations. I guess it is a =20 matter of not knowing what the user will do next the prohibits its =20 usefulness. But graphics, buttons, fonts etc could be sent from the =20 server to a buffer while someone is reading a page "just in case". On another matter I would like to see "the chunks" sent by to =20 browsers reduced from pages to "containers". Containers could contain =20= anything and would travel with their XYZ positions attached. So when =20 the browsers gets it, it would position it at X and Y top left and X =20= and Y bottom right on layer Z. I find the current "page" system =20 highly restrictive and use JSON more and more for page layout. I =20 suppose container rotation would also be nice. As REBOLs we must keep questioning the status quo... there are much =20 better ways of doing things! ~chris --=20 To unsubscribe from the list, just send an email to=20 lists at rebol.com with unsubscribe as the subject. -- To unsubscribe from the list, just send an email to lists at rebol.com with unsubscribe as the subject.
