[PD] GridFlow numeric type conversions ?

[Mathieu Bouchard]

Hi folks,

GridFlow 0.7.0 gets multiple numeric types and MMX support.

But I need some advice on numeric types.

I have three numeric types: uint8, int16, and int32. Currently all
conversions must be explicit, using [@cast] objects (save for some special
funky classes like @store)

Similarly, all grid-literals must have their type specified, if it's not
the default int32.

e.g. some possible msgbox contents:

"1"                   : int32 scalar
"list int16 # 1"      : int16 scalar
"1 2"                 : int32 vector of size 2
"list int16 1 2"      : int16 vector of size 2
"3 3 # 1 0 0 0"       : int32 3x3 identity matrix
"3 3 int16 # 1 0 0 0" : int16 3x3 identity matrix
"240 320 3 # 0"       : 240x320 RGB 32:32:32 black picture
"240 320 3 uint8 # 0" : 240x320 RGB 8:8:8 black picture

the "list" prefix is there because typenames are not valid selectors; it
is to be omitted inside objboxes, because there are already list
delimiters there. e.g.

add some red to a rgb 8:8:8 picture
[@ + {uint8 64 0 0}] in jmax
[@ + ( uint8 64 0 0 )] same in puredata

as you can see, the notation is quite cumbersome, and @cast itself can be
cumbersome; some patches may require considerable changes to accept a
different numeric type as input.

the reason i did it like that is because, if i choose a numeric conversion
policy right now, and it occurs to me that it's the wrong policy, then
it'll be quite some trouble to change it later.

now i see a few different possible policies. Given a two-input operator
being given two values of different types:

C-style: the result has the same type as the bigger type of the two input
types. there is some hierarchy between the types. there are obvious facts,
like uint8 < int16 < int32, but some cases are not obvious, such as uint8
vs int8, and int32 vs float32, where each type of the pair includes values
that don't precisely exist in the other type, so one of the two types
is arbitrarily considered bigger.

jMax-style: left inlet decides the type. (I thought jMax was "right inlet
decides the type", but I rarely get to play with floats, so I forgot)

other: right inlet decides the type.

other: keep casting completely explicit.



different policies have different advantages. For example, jMax-style
makes it easy for abstractions to support multiple types in left-inlet
with minimal effort from the abstraction-creator (often without any patch 
modification). it's the one i prefer, but i want to know whether other
people have other preferences (and _why_...)

I thought it could be possible to specify extra options about casting and
such, as keyword arguments. Keyword arguments come in pairs and are put
after the end of the normal argument list, requiring all regular
optional arguments to be present. One of the possible keywords would be
cast_to, which would appear in different flavours, e.g.:

[@ + 42]
[@ + 42 cast_to left]
[@ + 42 cast_to right]
[@ + 42 cast_to biggest]

else, [@cast] could have its type argument modifiable through inlet 1,
where another object written like [@type] or [@typeof] or [@nt] (standing
for numeric type) would give a type symbol (like "uint8") through outlet 0
when given a grid in inlet 0. This would allow for completely arbitrary
user-defined type policies.

i'm writing all of this in case some of you have comments and
suggestions. so _please_ reply if you have something to say.

thanks in advance,

________________________________________________________________
Mathieu Bouchard                       http://artengine.ca/matju