[REBOL] Re: - XYZ
From: greg:schofield:iinet:au at: 9-Sep-2007 23:03
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=0 can be implied most of the time) the 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 measurement datatype (it is kinda ugly though).
If this is taken seriously and =93real world=94 is made the essential characteristic
of such a datatype then the bare unit (XxYxZ or XxYxZx) would be in metres.
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 essentially 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.
Mixing units would be nice (4 * 10 ** -3)x4x(4 * 10 ** 3)x being a 4mm wide, 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.
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 believe they should
have a place in a measurement datatype, rather as an object 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 = 1=94 can bring in something to be buffered but invisibly behind,
and it can be done by simply incrementing a measure datatype as a series, via offsets.
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.
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 applications these can be very important,
eg +- 0.01 might be added to the datatype unambiguously and rounding could always be
a surrounding function.
Just suggestions, but a real world datatype like measure seems a very handy thing to
have.
Greg Schofield
Perth Australia
--- Message Received ---
From: Chris Dwyer <chd-1staccess.ca>
To: rebolist-rebol.com
Reply-To: rebolist-rebol.com
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
there is already a pseudo scale factor "em". We us it a lot since it
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
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
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
on the internet, especially for dial-up situations. I guess it is a
matter of not knowing what the user will do next the prohibits its
usefulness. But graphics, buttons, fonts etc could be sent from the
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
browsers reduced from pages to "containers". Containers could contain =20
anything and would travel with their XYZ positions attached. So when
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
highly restrictive and use JSON more and more for page layout. I
suppose container rotation would also be nice.
As REBOLs we must keep questioning the status quo... there are much
better ways of doing things!
~chris
