World: r3wp

The reason why is because people didn't understand that '+ was for 
unsigned, and '- was forr signed.

Bug #460 was a FORSKIP bug, not a MAXIMUM-OF bug. FORSKIP now works 
with vectors, so the bug is now fixed.

why + was for unsigned and not the reverse? :-)

Are you aware of any negative unsigned numbers? :)

I don't work at that level of REBOL. So we now have vector! datatype 
mostly fixed. One thing I don't understand is, that we are heading 
for performance, and then we can see minimum-of and maximum-of becoming 
mezzanines. The other thing is - what now? What is now available 
at practical level? What can we do with vector! type?

They can be mezzanines and still be as fast because FORSKIP is now 
native. Making the looping functions native makes REBOL faster overall. 
One thing people don't get is that mezzannes can be really fast in 
R3.

Vector types take up less space for the same data, and you don't 
have to use type tests when working on them. They're for fast processing 
of numeric data, conversions, all sorts of low-level goodness.

Could vector type help with stuff like DLL interfacing?

We could use some practical vector! recipes in the cookbook list. 
This will give people a good idea for what they can do.

I suspect things like audio samples and very large data sets (geographical 
data, 16-bit image data) could be used for this.

Probably so, Pekr. The underlying data of vectors corresponds to 
arrays in lower-level languages.

Henrik, I'd be happy if the wiki were updated with the alpha 51 semantics, 
but if you want to aim higher, go ahead :)

But we could have some vector maths innside Rebol too
ie. V + 15, could add 15 to all the cells inside a vector.
Currently math operations are not allowed with vectors... why ?

BrianH, I can't aim at all. I've never worked with vectors before, 
which is why I asked. If there was a small practical example, say 
for loading an AIFF file into a vector! array, Carl could mention 
it in his blog.

Why not math? Because all of the alpha 51 changes were implemented 
in one night (afaIct), and because noone has suggested it yet.

i don't ask for matrix operations currently (like adding or multiplying 
2 vectors).

I just wonder why simple tricks like adding or multiplyings all the 
cells with a scalar is not allowed

ok, then i ask for it

You'll have to wait for multiple-dimension vectors before we do matrix 
operations :)

add/skip or multiply/skip not enough ?
Lol

And asking for it here doesn't help. Put in a CureCode ticket with 
proposed semantics (equivalent REBOL code is fine).

You know me,i'm bas with your language (even if we

*bad

i know more or less 30% of the English words come from the Frensh 
(thanks to the Normands) but it doesn't  help me

Well, I don't have the time to write CureCode tickets :(

so i keep the tuples to do vector operations.
1.2.3 * 5  = 5.10.15
but it's quite limited

is it appropriate to specify which part you want to perform the operation 
on?

like what ?

Can you do scalar math with vectors with the restriction that the 
vector is only on the left side of the equation? Does the math work?

i don't see your point guys

Forget what I said. :-)

My point is that it is much more likely to get implemented as an 
action!, and actions dispatch based on the type of their first argument.

sometimes i use a second tuple using it as a mask:
1.2.3 * 5 * 1.0.1 = 5.0.15

Double dispatch could do the work in most cases, I suppose.

Can that be expressed as 1.2.3 * 1.0.1 * 5?

yep

it works too, in any direction

That's what I mean. It's an implementation detail, but it could be 
the difference between having this feature and not having it. We'll 
see.

Basic math operations are polymorphic, but dispatch based on the 
type of the first argument.

I didn't know about +/- to word change. Thanks.

if vectors could work that way.
Less the limit of 0-255 range
Less the limit of no negative values in a tuple

Henrik in fact there are small practical examples, say for loading 
AIFF file into a vector! array, see files area in R3-alpha world.

They're for some older alpha though, I have to rewrite them.

Bolek, it's mentioned in a comment in the CureCode ticket which thought 
'- referred to unsigned (probably the motivation for the change). 
It's otherwise undocumented as of yet.

Why not math? ...noone has suggested it yet.
 Not true also.

vectors with scalar maths operations would allow super fast  modifications 
in images.

For example: gama corrections or quantization without the need to 
use loops

If it's not in a CureCode ticket, the sggestion doesn't count.

i know most of this tricks can be performes with the effect or draw 
dialect, but sometimes we need more accurate operations

Steeve, the basic math operations generate new values, they don't 
modify in place. This cold cause a lot of memory overhead. Modifying 
operations might be better to do as functions, perhaps even native 
functions loaded in plugins.

I must admit I haven't used CureCode for about 3 months I think. 
And my vector! document on R3-alpha precedes CureCore for about a 
year. Because no one but me payed attention to vectors for so long 
I never cared about rewritting those requests to CureCode.

But it's nice to see some progress in this area, I'd like to experiment 
with vectors bit more and post some new tickets to CureCode :)