Qbasicnews.com

Full Version: function (poly AND iso)morphism and variable inheritance.
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
I used to think that these were bad things.

Now I know.

They were only perceived as bad because they are implemented badly in all languages.

What do you think?
Me and google don't know what "function isomorphism" is.

If by "variable inheritance" you mean "inheriting variables" in object oriented languages, then of course it is a good thing.
Maybe he means Polymorphism. Ya never know with Aga...
isomorphism: A one-to-one correspondence between the elements of two sets 'such that the result of an operation on elements of one set corresponds to the result of the analogous operation on their images in the other set.

or...

Polymorphism: ((Has no mathematical defination i believe))

All definitions from dictionary.com have a nice day =)

And...

I have no clue what each of these things are ((Help me))
Oh ok, I can explain one-to-one. Basically, it goes like this:

If I give you a number and say I added 42 to it, you can find out what number I started with. So f(x)=(x+42) is a one-to-one function.

But if I give you a number and say I rounded off to the 10th place, there's no way you can figure out what I started with.

For every one rounded-off number I might give you, there are more than one possible cooresponding starting numbers, so rounding off is not one-to-one.

I have no idea how this would apply to programming languages though....
ERM! Isomorphism and polymorphism!

EDITs:

Let's call it like graph isomorphism, except apply it to functions.

http://www.cs.sunysb.edu/~algorith/files...hism.shtml

You can think of it like a way to do a function in more than one way:

DO...LOOP or FOR...NEXT (bad example)

Here is another example I came up with: (not implemented in QB, but could be)

Code:
i% = 2
blah(i%).blah2% = 5
'With isomorphism, blah(i%).blah2% can be expressed as blah.blah2(i%). ['course, the array/type definitions get mixed up, but that's OK.. it's what I want.]

PRINT blah.blah2(i%) 'should print 5.
----------------------------

Quote:If by "variable inheritance" you mean "inheriting variables" in object oriented languages, then of course it is a good thing.

I mean like this, and it isn't strictly applied to OOP, and it isn't always a good thing (if it isn't necessary):

Code:
TYPE animal
skinColor AS INTEGER
DEFAULT skinColor = 3
END TYPE

TYPE elephant
SUBSET_OF Animal
DEFAULT skinColor = 7
trunkSize AS INTEGER
END TYPE

'thus, elephant inherits the skinColor variable. Also, the default value can change too.
you're going to create terrible confusion with the first code example =(.
=?
Quote:Here is another example I came up with: (not implemented in QB, but could be)
Code:
i% = 2
blah(i%).blah2% = 5
'With isomorphism, blah(i%).blah2% can be expressed as blah.blah2(i%). ['course, the array/type definitions get mixed up, but that's OK.. it's what I want.]

PRINT blah.blah2(i%) 'should print 5.

Err, what? If your code looks like this (assuming arrays are allowed inside types):
Code:
TYPE blahType
  blah2(10) AS INTEGER
END TYPE

DIM blah(10) AS blahTYPE

Then blah(i).blah2(j) != blah(j).blah2(i).

Two things are isomorphic if they are mathmatically the same, they dont necessarily need to look the same. The input and output graphs in the link you posted are isomorphic because each node is connected to the same set of other nodes via the same set of edges on both sides. The graphs do not look the same.

I dont understand how you can have a function that is mathmatically the same as another function but looks the same, and if you could, what use would it be for programming?

You can do weird tricks that are similar to your example in C:
Code:
a[i] == *(a + i) == *(i + a) == i[a]

Using the rules for array indexing and commutitive addition.
>>>>>>>>>>>>>>>>>>

Code:
blah(i).blah2% = blah.blah2%(i)

Shall I say it again?

Quote:Two things are isomorphic if they are mathmatically [or functionally] the same, they dont necessarily need to look the same. The input and output graphs in the link you posted are isomorphic because each node is connected to the same set of other nodes via the same set of edges on both sides. The graphs do not look the same.

Exactly my point. They don't look the same, but just assume that the result is the same in an alternate QB compiler...

Quote:I dont understand how you can have a function that is mathmatically the same as another function but looks the same

Err.. what? :???: :???: :???:
They look different, not the same, and functionally the same...

Quote:... what use would it be for programming?

The advantage is that it can be accessed differently for people with different styles. Take another example in qb4.5:

Code:
CALL sub1(blah%)
sub1 blah%

They are functionally the same, but some people like it one way, some people like it another way.
Pages: 1 2