World: r3wp

fromt he priorities page: "Text codec project has been deferred due 
to community input. The project will be reorganized to make codecs 
into a port datatype and allow external codec devices as well as 
streaming (with port's holding the steam state.)" ---- I really like 
it :-)

Announcing the availability of the http://www.rebol.net/wiki/Pair_enhancements
article. Discussion welcome.

As it looks, due to the efficiency issues (speed), the implementation 
of REBOL pairs as pairs of floats looks to be the fastest (since 
AGG needs double values, and conversion from float to double is faster 
than conversion from integer subpixel count to double using a foating 
point division looks slow)

So, everybody opposing this pair implementation change: please speak 
now or remain silent for long time...

Ladislav, you need to put the AGG implementation considerations on 
that page. The page currently looks like you are advocating using 
48bit integers, not floats.

OK

You might even be able to use doubles on 64bit builds of R3, due 
to the need to have larger value slots.

has it been already settled how big the available space is? (in 32-bit 
version we have 96 bits at most, as it looks)

Some of the value types require 2 pointers. On a 64bit build, pointers 
are the same size as doubles. It's an internal matter anyways.

So it looks like 128bits are available.

I'd prefer to get the 96-bit pairs with each x and y using 16 bits 
for subpixels, keeping the memory down, and not reducing the integer 
range. So I'd like to know just *how* much slower this implementation 
would be than using floats or doubles.

Anton, do you happen to know any example that would show 96-bit = 
48x48 bits with 16-bit subpixels to have an advantage over 2 floats?

Anton, there would be no memory savings by using 48x48 integers. 
The pair would still be in a value slot, and value slots are fixed 
size. And they would be slower to access because of alignment issues, 
plus the floating point multiply to convert them to the doubles used 
internally in AGG. "So it looks like 128bits are available." - only 
on 64bit builds of R3, not on the 32bit builds we have now.

Test results (Brian is right, that 96-bit pairs cannot save any space 
compared to pairs of floats - actually just 64-bit pairs):


1 conversion of the X coordinate to double when using 96-bit pairs: 
ca 50 ns

1 conversion of the X coordinate to double when using pairs of floats: 
ca 10 ns

Of course, other operations, like conversion to integer, e.g., are 
needed sometimes, and for those, the situation would be the other 
way around

Oh, ok, so R3 is still mainly being built 32-bit.

Ladislav, no example that shows an advantage springs to mind.

Could you also measure conversion to int for 96-bit pairs and pairs 
of floats?

Pairs of floats look more advantageous to me now.

I agree on the pairs of floats... much better programatically, especially 
since the pairs will be used for things other than simple "pixel" 
coordinates.

it would also be VERY nice to be able to do tripplets or quads.

hmm, actually, triplets of floats may be possible

(96 bits)

one thing I wonder is that when 64 bit builds do get released, are 
we sacrificing the future by tuning the present, using only floats 
now?

We can upgrade to doubles in the future, in the 64bit builds - AGG 
uses them already. Though I don't know the effects that would have 
on rounding and such.

exactly, I wouldn't want a 64 bit build to perform different maths 
on values.  it should just be faster for bigger numbers.


if we go with floats, I feel that we'll be forced to keep them even 
in 64 bit builds.


also, generally, all graphics libs and most math related libs now 
use doubles.  so if we need to convert the floats from rebol everytime 
we use the value within an extension its going to incur some speed 
hits no?

An extension like AGG, which also uses doubles. But we can't fit 
two doubles in a value slot on a 32bit build, sorry.

And if we don't fit a pari into a value slot, it changes its whole 
behavior.

yeah, I see the problem.

they could be stored like vectors internally, but would that make 
them MUCH slower?

Yes, due to at least one added pointer indirection, and added code 
to prevent aliasing (in the pointer sense, not the graphics sense). 
And they could be modifiable, unless we are careful, and that brings 
in another whole host of issues.

well, I guess they could just be stored as a two double struct, but 
then we still get the added indirection everytime they are used.

Development roadmap. There's also Carl's blog about it. I just wonder, 
if it differs from the priority page that much?

http://www.rebol.com/roadmap.html
http://www.rebol.com/priorities.html

AT LEAST THE ROADMAP  !!!  i'm about to cry ...

no in fact I don't havec feelings but if i had some feelings i would 
cry ... eventually...

Thinking that the java jdbc bridge I was working on in "Other languages" 
might be used for R3 database access until we have ODBC support

I guess I need to serialize the data on the java side so that it 
looks like Rebol values .. a la 'mold

doing a java bridge to access a database ? hum really ? but what 
would be the gain ? instead of having it in direct access i thought 
rebol had odbc acces through odbc://

This is R3 group

A bit of host kit news:


--- Win32 window and event code now compiles and links successfully 
within the host-kit.
 - Carl.

YEAH baby

Database work is only waiting for a community discussion of the semantic/dialect 
model, afaik. Something to integrate with the new port model, not 
the old one.

j: open jdbc://localhost:8000
insert j {select first 2 * from staff}
r: copy j
>> length? r
== 2

My jdbc protocol working

Any reason why we can't use R2's semantics?

Yes: The port model is different. For one thing, you don't insert 
to and copy from ports.

So just rename the actors

And async needs to be considered as well.

My jdbc protocol is async

With a handler, like in R3?

All protocols are async unless you do special trickery to try and 
make them look sync

My jdbc protocol is a R3 protocol ... this is the R3 group!