World: r3wp

fro=for

was down for me before

couldn't browse to any of the rebsites

same here for the past 10 hours at least.

working again now.

YEs

Ok, so there are going to be some issues about PAIR's that need discussion!

more than those you already noted ?

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?

You posted something on y

You just posted something on your blog...

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?

yes, right, there is even some code assuming, that rounding occurs 
automatically, which ceases to be true...

yep I see

and a round/half-ceiling is not good ?

the ceiling operation may be more reasonable than truncation for 
image dimensions

...but I do not have too strong preferences

I'm used to the truncation, though ceiling would work out too...

the only thing I'm not keen on is round/half-ceiling   :-)

in such "unclear" cases it may be even possible to require the user 
to submit "integral coordinates", I suppose you know what I mean?

ceiling would probably provide less bugs, since we don't end-up with 
zero values which are evil in division.

integral?: func [x [number! pair!]] [zero? x // 1]

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.

Q will pairs *always* be floating point?

Yep.

In general, they work out nicely. But these edge cases must be solved.

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.

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.

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.

Advanced coders who are using more complicated algorithms must make 
adjustments anyway, so they can force the ceiling if needed.

But, yes, rounding is continuos where it matters the most and discontinuous 
where it matters the least

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?

Not really worth it. Would create even more problems.

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.

clearly

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.

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).

The ROUND option looks to have prevailed

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."

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.

Round half up, round half out, round half even, or round half odd?

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 ...