+- QB64 Phoenix Edition (https://qb64phoenix.com/forum)
+-- Forum: Chatting and Socializing (https://qb64phoenix.com/forum/forumdisplay.php?fid=11)
+--- Forum: General Discussion (https://qb64phoenix.com/forum/forumdisplay.php?fid=2)
+--- Thread: Declaring Functions AS TYPEs (/showthread.php?tid=1909)
Pages:
1
2
Declaring Functions AS TYPEs - TerryRitchie - 08-16-2023
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.
RE: Declaring Functions AS TYPEs - dbox - 08-16-2023
Wish granted…
RE: Declaring Functions AS TYPEs - mnrvovrfc - 08-16-2023
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/67564797/c-program-to-calculate-matrix-multiplication
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.
RE: Declaring Functions AS TYPEs - TerryRitchie - 08-16-2023
(08-16-2023, 02:56 AM)dbox Wrote: Wish granted…Yep, just like that
RE: Declaring Functions AS TYPEs - OldMoses - 08-16-2023
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 SUBRE: Declaring Functions AS TYPEs - mnrvovrfc - 08-16-2023
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.
RE: Declaring Functions AS TYPEs - a740g - 08-16-2023
I had added this to our ever-growing wish-list.
Allow function names using "as <type>" · Issue #30 · QB64-Phoenix-Edition/QB64pe (github.com)
RE: Declaring Functions AS TYPEs - bplus - 08-16-2023
Then fix it up again! to allow a Function to return an Array including UDT's, please.
RE: Declaring Functions AS TYPEs - TerryRitchie - 08-16-2023
(08-16-2023, 11:53 AM)OldMoses Wrote: 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.Yep, I do the same sort of thing. It would be much nicer using a function instead of a subroutine though.,
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)
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 SUBRE: Declaring Functions AS TYPEs - TerryRitchie - 08-16-2023
(08-16-2023, 12:33 PM)mnrvovrfc Wrote: But I think Terry means a general conversion of any UDT into a function or something like that.Correct.