r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3]

DideC
16-Jul-2010
[3703]
fro=for
Graham
16-Jul-2010
[3704x2]
was down for me before
couldn't browse to any of the rebsites
Henrik
16-Jul-2010
[3706x2]
same here for the past 10 hours at least.
working again now.
DideC
16-Jul-2010
[3708]
YEs
Carl
16-Jul-2010
[3709]
Ok, so there are going to be some issues about PAIR's that need discussion!
Steeve
16-Jul-2010
[3710]
more than those you already noted ?
Carl
16-Jul-2010
[3711x2]
First, the math side of PAIRs as floats works out quite well.


However, there are some issues when converting to and from pixels, 
which are "quantized" as integers.

For example, now that:

>> 101x101 / 2
== 50.5x50.5

what is the size of this image:

>> make image! 101x101 / 2

?
Steeve, remind me, where did I note them?
Steeve
16-Jul-2010
[3713x2]
You posted something on y
You just posted something on your blog...
Carl
16-Jul-2010
[3715x2]
And more interesting... tell me the sizes of these images:

  img1: make image! 1.4x2.8

  img2: make image! 1.000001x2.999999


So, if you understand floating point, you see where I am going with 
this, no?
Perhaps Ladislav can bring some insight to this issue?
Ladislav
16-Jul-2010
[3717]
yes, right, there is even some code assuming, that rounding occurs 
automatically, which ceases to be true...
Steeve
16-Jul-2010
[3718x2]
yep I see
and a round/half-ceiling is not good ?
Ladislav
16-Jul-2010
[3720x2]
the ceiling operation may be more reasonable than truncation for 
image dimensions
...but I do not have too strong preferences
Maxim
16-Jul-2010
[3722]
I'm used to the truncation, though ceiling would work out too...

the only thing I'm not keen on is round/half-ceiling   :-)
Ladislav
16-Jul-2010
[3723]
in such "unclear" cases it may be even possible to require the user 
to submit "integral coordinates", I suppose you know what I mean?
Maxim
16-Jul-2010
[3724]
ceiling would probably provide less bugs, since we don't end-up with 
zero values which are evil in division.
Ladislav
16-Jul-2010
[3725]
integral?: func [x [number! pair!]] [zero? x // 1]
Carl
16-Jul-2010
[3726]
Maxim, the problem is that the computation can vary + or - by the 
floating point precision of the full expression, so ceiling is not 
correct either.
Maxim
16-Jul-2010
[3727]
Q will pairs *always* be floating point?
Carl
16-Jul-2010
[3728x2]
Yep.
In general, they work out nicely. But these edge cases must be solved.
Maxim
16-Jul-2010
[3730]
hum... it would be nice for pairs to stay integer until they are 
cast into floating points... I can see many accumulation errors cropping 
up which will make sizing very hard to be pixel precise.
Carl
16-Jul-2010
[3731x2]
But, of course, the reverse is also true.
Currently, I think for sizing we must define and document it.  To 
me, there is no perfect answer, but perhaps just doing a simple round 
is best, as long as everyone knows that rule.
Maxim
16-Jul-2010
[3733]
yes, but for the dimension aspect, specifically the largest accumulated 
edge, for example may accumulate errors.


when people start Adding up values and then multiplying them... I've 
had my share of headaches in 3D with this.
Carl
16-Jul-2010
[3734]
Advanced coders who are using more complicated algorithms must make 
adjustments anyway, so they can force the ceiling if needed.
Ladislav
16-Jul-2010
[3735]
But, yes, rounding is continuos where it matters the most and discontinuous 
where it matters the least
Maxim
16-Jul-2010
[3736x2]
if I'm forced to use rounding on the rebol side very often, I think 
I'd rather have a tiny overhead in the native datatype that tries 
to stay integer until a result forces it. 

exactly like integer math which returns decimals when it must:

>> 4 / 2
== 2
>> 4 / 2.0
== 2.0
>>
and a new float-pair! datatype is complicated to support in addition 
to an integer pair?
Carl
16-Jul-2010
[3738]
Not really worth it. Would create even more problems.
Maxim
16-Jul-2010
[3739x2]
it would really be nice if the datatype had a little state which 
allowed it to be integer or float and call appropriate math based 
on this... 

but I have no idea how this math is managed internally, so cannot 
easily grasp how complex or how this would affect speed.
it might also complicate the extension part of things I guess.
Steeve
16-Jul-2010
[3741]
clearly
Gregg
16-Jul-2010
[3742]
perhaps just doing a simple round is best, as long as everyone knows 
that rule.


That sounds good to me. The ky point being that we know the rules. 
Simple ROUND may not be the best choice for graphics, but I'll defer 
to those with more experience in that area.
Gabriele
17-Jul-2010
[3743]
IMHO, there are two options: 1) require "integral" values (as Ladislav 
says) for certain things like make image! etc., producing an error 
when they are not, and let the user use ROUND; 2) always use floor 
or ceil or even round, but make sure people know (ie docs).
Ladislav
17-Jul-2010
[3744]
The ROUND option looks to have prevailed
Carl
17-Jul-2010
[3745x4]
Update: The go.r test code is now running properly in A101 with the 
fully converted PAIR datatype and changes to the AGG API to accept 
both pairs and gobs using float values.


It turns out that because AGG wants floats for most spatial values 
anyway, the PAIR change makes the code smaller and faster.


Certainly more can be done to minimize the interface to AGG now (removing 
the double trampoline within the API) but that's a project for Cyphre 
when he returns from the islands ;)
In addition, I should note that all functions that require integral 
PAIR! fields now perform an internal round to "snap" them to nearest 
integers.  This applies not just to things like image size specs, 
but also to values like image pixel index pairs (something we support, 
but not often done, AFAIK)
The biggest issue in this PAIR change is that of comparison... such 
as in equality and zero tests. I plan to make the same rules apply 
as those for DECIMAL! -- but this will require more design work.
For example, a pair may have a value that is *almost* zero, but not 
*really* zero.  "You know the drill."
Steeve
17-Jul-2010
[3749]
Thanks Carl.
Though for AGG, I don't expect a lot (in term of speed gain).

IMHO, the main overhead comes from the involved arithmetic using 
floating point decimals.
Matrix computations are costly with floating numbers.

But The final rasterization uses fixed point decimals and floats 
could have been avoided, i guess.
So maybe there is a major room improvement here.
BrianH
17-Jul-2010
[3750]
Round half up, round half out, round half even, or round half odd?
shadwolf
17-Jul-2010
[3751x2]
Carl you have a point there ... pair! are used mostly related to 
VID ....  and as pairs in fact represents a pixel matrix you have 
dot something  numbers
CARL ONE ASK CAN AGG   BE MERGED WITH AMD/ATI OPEN CL Technology 
? ( some thing like a background application that would detect what 
hardware you have and use multi hardware CPUs GPUs to run those expensive 
task. Once again  what in rebol can be an very expensive task .... 
answer a state of art webbrowser rendering engine with flash silverlight 
support....  IF we can bring rebol to that state i think no one will 
look at it as a toy ... then the question is way doing a webbrowser 
in rebol ?  REply is because i love rebol :). But on a ground level 
if you want to enter in competition with the other languages and 
prove the interrest of the rebol method then you have to be able 
to do what the others can do )


This open CL adition can too benefits non graphical applications 
i don't know how but  why not saying look rbeol is not dead it's 
the futur and as the futur it provides the best way to use the futurs 
technology. And that's a field none of hte interpreted languages 
now in day have done ...