Declaring Functions AS TYPEs

[TerryRitchie]

So many times I have wished for this:

TYPE TYPE_VECTOR
    x AS SINGLE
    y AS SINGLE
END TYPE

FUNCTION AddVector(v1 AS TYPE_VECTOR, v2 AS TYPE_VECTOR) AS TYPE_VECTOR
    AddVector.x = v1.x + v2.x
    AddVector.y = v1.y + v2.y
END FUNCTION

Or even this would be awesome

DIM v1 AS TYPE_VECTOR
DIM v2 AS TYPE_VECTOR
DIM v3 AS TYPE_VECTOR

v1.x = 10: v1.y = 20
v2.x = 15: v2.y = 15
v3 = v1 + v2

( v3.x now = 25, v3.y now = 35 )

I realize neither of these concepts are in the spirit of QB64, but just imagine.

[dbox]

Wish granted…

[mnrvovrfc]

One of these solutions feature multiplication of a square matrix, but it could be certainly shoe-horned into a "dot-H" file:

https://stackoverflow.com/questions/6756...iplication

I like best the solution which has "zero" votes. It's clear to me.

Other sites offered code examples with hard-wired matrix sizes. Good only if matrices are to be limited to 2 or 3 width and height.

I tried to hack at it but didn't know how to "transpose" from _MEM variable to _OFFSET and back. I don't know if the ConvertOffset() trick in the Wiki would apply here.

[TerryRitchie]

Wish granted…

Yep, just like that

[OldMoses]

I feel your pain. Working with vector types just screams having a way to directly functionalize their manipulation. I resort to the somewhat clumsy approach of passing a variable back from a sub. The main issue being keeping track of which variable is the desired result. I use the first parameter as a return. Then I have to decide if I want to preserve original operands or overwrite them. At least it can be done in a fairly concise manner.

I imagine that since there are no rules against multi-dimensional (4+ element) vectors, there is simply no point in trying to satisfy all possibilities. So we'll just have to do the typical hacks.

Code: (Select All)

TYPE V3
    x AS SINGLE
    y AS SINGLE
    z AS SINGLE
END TYPE
DIM AS V3 A, B, C
A.x = 3: A.y = 7: A.z = -4
B.x = -13: B.y = 5: B.z = 9
'If I need to keep the original state, then I copy the first parameter prior to the call
C = A: R3_Add C, B, 1
Pvec "A", A
PRINT "plus"
Pvec "B", B
PRINT "equals"
Pvec "C", C
PRINT "________________________________"
C = A: R3_Add C, B, -1
Pvec "A", A
PRINT "minus"
Pvec "B", B
PRINT "equals"
Pvec "C", C
PRINT "________________________________"
'If I don't need the original, I'll just overwrite it.
Pvec "A", A
PRINT "plus"
R3_Add A, B, 1
Pvec "B", B
PRINT "equals"
Pvec "A", A
PRINT "________________________________"
'an inversion by manipulating the scalar
Pvec "A", A
PRINT "inverted"
R3_Add A, A, -2
Pvec "A", A

END
SUB R3_Add (re AS V3, se AS V3, scalar AS INTEGER)
    re.x = re.x + se.x * scalar
    re.y = re.y + se.y * scalar
    re.z = re.z + se.z * scalar
END SUB
SUB Pvec (s AS STRING, v AS V3)
    PRINT "Vector "; s; ":  <"; v.x; ", "; v.y; ", "; v.z; ">"
END SUB

[mnrvovrfc]

It hit me like a thunderbolt.

Code: (Select All)

TYPE TYPE_VECTOR

    x AS SINGLE

    y AS SINGLE

END TYPE



DIM AS TYPE_VECTOR v1, v2, v3



v1.x = 10: v1.y = 20

v2.x = 15: v2.y = 15

AddVector v1, v2, v3

PRINT "Result x ="; v3.x

PRINT "Result y ="; v3.y





'CHANGED: tret

SUB AddVector(v1 AS TYPE_VECTOR, v2 AS TYPE_VECTOR, tret AS TYPE_VECTOR)

	DIM AS _MEM m1, m2

	DIM AS SINGLE a, b

	DIM AS INTEGER l

	m1 = _MEM(v1)

	m2 = _MEM(v2)

	a = _MEMGET(m1, m1.OFFSET, SINGLE)

	b = _MEMGET(m2, m2.OFFSET, SINGLE)

	a = a + b

	tret.x = a

	l = LEN(a)

	a = _MEMGET(m1, m1.OFFSET + l, SINGLE)

	b = _MEMGET(m2, m2.OFFSET + l, SINGLE)

	a = a + b

	tret.y = a

    'AddVector.x = v1.x + v2.x

    'AddVector.y = v1.y + v2.y

END SUB

What sucks is it has to be a SUB and depend on the parameter side-effect. Because FUNCTION declaration has to carry a sigil, it's impossible to have it return the contents of an UDT variable, or even of _MEM. Somehow this should be doable as AddVector%&().

But I think Terry means a general conversion of any UDT into a function or something like that.

[a740g]

I had added this to our ever-growing wish-list.

Allow function names using "as <type>" · Issue #30 · QB64-Phoenix-Edition/QB64pe (github.com)

[bplus]

Then fix it up again! to allow a Function to return an Array including UDT's, please.

[TerryRitchie]

I feel your pain. Working with vector types just screams having a way to directly functionalize their manipulation. I resort to the somewhat clumsy approach of passing a variable back from a sub. The main issue being keeping track of which variable is the desired result. I use the first parameter as a return. Then I have to decide if I want to preserve original operands or overwrite them. At least it can be done in a fairly concise manner.

I imagine that since there are no rules against multi-dimensional (4+ element) vectors, there is simply no point in trying to satisfy all possibilities. So we'll just have to do the typical hacks.

Yep, I do the same sort of thing. It would be much nicer using a function instead of a subroutine though.,

Code: (Select All)

SUB AddVector (vin AS TYPE_VECTOR, vout AS TYPE_VECTOR)

    '| Add vin to vout. vout will contain the passed back result.
    '|
    '| AddVector MouseVector, WindowLocation

    vout.x = vout.x + vin.x
    vout.y = vout.y + vin.y

END SUB

[TerryRitchie]

But I think Terry means a general conversion of any UDT into a function or something like that.

Correct.