Project

Module for working with Vectors

Started by brianc on .

Sign in or create an account to join the conversation.

38 posts

Macciza wrote:Hi Brian
I just meant that add function as '+' was already there, which is at he used then 'wrap'ed to the shorter length - I guess I'm used to MutableArrays . . .
I was not sure if you realised the maths operators +-/* already worked on arrays but at longer length making AB code that much simpler as {array}+{array} is already standard within Lemur, rather then iterating though.
I guess ultimately the fact that it is 'add' as opposed to '+' it probably ok - I guess I just wanted the built-in Lemur array maths operators where not thought to be missing or inapplicabble to arrays.
The code optimisation thing was just that there are the inbuilt functions which may be faster, more so than the one-liner thing
I agree with you that duplication is usually useless (whether add truncates or not). If anything, I like having the functions because I think they add some consistency: if I want the distance between two vectors, I use distance(). If I want the dot product, I use dot(). So if I wanted to add two vectors, I think the first thing I'd think of would be to look for a function that does that. Whatever happens with the function names, I'll be sure to be clear that the arithmetic functions truncate.

Thanks, though, for pushing me to think about this stuff. Since my goal is for modules like this to be useful to more people than just me, it's tremendously helpful to get other perspectives.
Hi All

Aah you edited the post whilst I was writing . . .

The is_subset(a,b) of or whatever it was probably should have been the other way is b part of a to maintain consistency ie array , val
I think it is best to keep everything fairly basic - ie fundamentals So I'm not sure about your change to contains() now
it is now contains all as opposed to contains any - and is that contains in order or not ?
Will have a bit of a look at what changes you made later

Also there may be possible variation on the equation that are far easier - I just need to check a few things first

MM
Hey Brianc

yeah, this forum does not subscribe you automatically, you have to edit the settings in the Control Panel
Same happened to me on many threads before this one.

I see what you mean about contains()

Suggestion: I still think it is useful, though I suggest you clarify what exactly the outcome is based on. Apparently, this is like this by default in Lemur/programming environments. I was banging my head because, to me, whether a vector or a singleton, a value should not be validated as "contained" unless the exact value or series of values are in fact contained. But this is not a problem really. I was approaching the problem using common logic, instead of programming logic.

good talking to you man, and thanks for your quality reply.
Macciza wrote:The is_subset(a,b) of or whatever it was probably should have been the other way is b part of a to maintain consistency ie array , val
I think it is best to keep everything fairly basic - ie fundamentals So I'm not sure about your change to contains() now
it is now contains all as opposed to contains any - and is that contains in order or not ?
Yeah, I figured is_subset made the most sense for what that function does and made contains an alias of that, but I now realize that's not the best approach either. What do you think makes the most sense? contains() could do what it did before and return whether or not a single value is in the given vector? My original idea was to pass it a vector and return which of those is in the other vector, but Lemur doesn't have empty vectors, so if there are no matches, there's a problem.

I was back and forth on the order for the arguments to is_subset(), and I think you're right. I'll switch it.
Macciza wrote:Also there may be possible variation on the equation that are far easier - I just need to check a few things first
Excellent. Now that documentation will primarily go elsewhere, I'm ok with making the code more concise now. I'll start condensing things, and I'd be happy to take suggestions.
m127 wrote:Suggestion: I still think it is useful, though I suggest you clarify what exactly the outcome is based on. Apparently, this is like this by default in Lemur/programming environments. I was banging my head because, to me, whether a vector or a singleton, a value should not be validated as "contained" unless the exact value or series of values are in fact contained. But this is not a problem really. I was approaching the problem using common logic, instead of programming logic.
Sorry, just to make sure I get what your perspective was: by "exact value or series of values" do you mean the ordering as well? Like {1,2,3,4,5} contains {1,2,3}, but not {3,2,1}? I suppose by default I look at a vector as a set of values and that ordering doesn't matter, but that's definitely not always the case.
brianc wrote:
m127 wrote:Suggestion: I still think it is useful, though I suggest you clarify what exactly the outcome is based on. Apparently, this is like this by default in Lemur/programming environments. I was banging my head because, to me, whether a vector or a singleton, a value should not be validated as "contained" unless the exact value or series of values are in fact contained. But this is not a problem really. I was approaching the problem using common logic, instead of programming logic.
Sorry, just to make sure I get what your perspective was: by "exact value or series of values" do you mean the ordering as well? Like {1,2,3,4,5} contains {1,2,3}, but not {3,2,1}? I suppose by default I look at a vector as a set of values and that ordering doesn't matter, but that's definitely not always the case.
No, in my case scenario, order was irrelevant (though it is relevant strictly speaking).

If you take a close look at my "solution" script and probably even make an example of your own, you will see how variable 'a' gets filled with 1's and 0's on every loop pass (true or false respectively).
Since we set 'i' to 0 since the beginning, I think arrays are checked in order starting from 0 anyway.

What I was finding amusing, and also was contributing to my pulling my hair, was that in Lemur, apparently (only apparently, not sure), the order does not matter either.


The point of the matter is though that the manual says

==

means EQUAL TO.


I might be crazy, but to me: vectorA is NOT equal to vector B if vectorA is {1,2,3,4,5} and vectorB is {2,3,4}; however, to Lemur those two are equal. Have you tried this?

do something with those same values like:

if (vectorA==vectorB){something;}







.
Hi again
A few comments . . .
I will also alert some of the devs to this thread to offer official clarification
Put {1,2,3,4,5}=={1,2,3} as the value for a Monitor and what do you get? That is the key here,
you are not actually comparing the arrays as such but are in fact comparing each index, and carrying any excess indexs (indices) - I don't think of them as padded even though in maths they can be viewed that way . . .
So taking that into account and refactoring - if (wrap(vectorB==vectorA,sizeof(vectorB))){ } which is correct for what it is doing, the first three vals don't match each other . . .

So as you can see 'order is important' - also it may be that because the array is being reduced to a 0/1 by the 'if' that only the first value is relevant in the end . . .

Anyway another option for a 'contains_val(array,val)' function but still not 'array-safe' but easily iterated - firstof(array/val==1)<sizeof(array)?1:0

Also Brian, remember angle() already exists as a builtin function - in fact due to many of them being pretty standard words they may be used at sometime in the standard Lemur library . . .
Also for optimisation notice that append and prepend are both just versions of {{A},{B}} -but reordered . . .

Cheers
MM
Just a quick suggestion about how you can see if two vectors are exactly equal (same values, same order). You can do something like:
SLVector.distance(vec1,vec2)==0 && sizeof(vec1)==sizeof(vec2)
That checks to see if the distance between the two vectors is 0 and that they're the same size (to make sure truncation isn't an issue). In "pure" Lemur, you can make a function to compare two input vectors a and b:
decl i, lenA=sizeof(a), lenB=sizeof(b);

if(lenA != lenB) return 0;

for(i=0; i<lenA; i++) if(a[i] != b[i]) return 0;

return 1;
yeah, totally right on all counts.

bottom line though, how would a new user ever grasp all that from the manual?

Quote from manual:
Comparison

== equal to

ie, not questioning whether the function outcome is correct or not. If == really means "equal to dinosaurs", fine; any outcome will be equal to dinosaurs, and it would be correct because such is the native design of the function.

I had to do a lot of troubleshooting to actually see what was really being compared.
m127 wrote:bottom line though, how would a new user ever grasp all that from the manual?
Yeah, who knows :) I guess since I'm just used to using vectors for sets of things and for ordered sequences of data, I think whenever I think about these things it's in a specific context, but new users don't have that same context.

I don't have any say in the Lemur documentation, but if you end up using SLVector and have any feedback for the README, I'd be happy to have it.
oh come on. :lol:

I also don't get it with this array arithmetic, but one day it might be valuable for me and I will be glad that other users have already done some work on this topic.

Patience my friend, patience.
Hi
I think 'context' is important and you should try thinking more Lemur rather than try making Lemur think elsewise . . .
Arrays don't truncate to shortest when operated upon - because of the context in which they are used, a row of switches, lights etc

The best debugging method is simply to put parts of your equation into a Monitor.value
then you see vec1==vec2 returns an array {vec1-vec2} not simply a binary 0-1, T/F . . .

Comparisons can be done in many ways, without iterating as well, avoiding the loops
if x-y=0 then x=y
(firstof(vec1-vec2)==sizeof(vec1))&&(sizeof(vec1)==sizeof(vec2)) -
I find that you use too many loops in your functions for my liking . . .

Another option is conversion
arraytostring(vec1) == arraytostring(vec2) works a charm . . .

Cheers
MM
Macciza wrote:Hi
I think 'context' is important and you should try thinking more Lemur rather than try making Lemur think elsewise . . .
Arrays don't truncate to shortest when operated upon - because of the context in which they are used, a row of switches, lights etc

The best debugging method is simply to put parts of your equation into a Monitor.value
then you see vec1==vec2 returns an array {vec1-vec2} not simply a binary 0-1, T/F . . .

Comparisons can be done in many ways, without iterating as well, avoiding the loops
if x-y=0 then x=y
(firstof(vec1-vec2)==sizeof(vec1))&&(sizeof(vec1)==sizeof(vec2)) -
I find that you use too many loops in your functions for my liking . . .

Another option is conversion
arraytostring(vec1) == arraytostring(vec2) works a charm . . .

Cheers
MM


Excellent. Thanks much.
Updated to Version 1.5. Includes new functions:

count(a,val) - Return the number of elements in vector a whose value equals val (a singleton)
minval(a) - Return the minimum value in vector a
maxval(a) -Return the maximum value in vector a

I was surprised to see that the built-in min() and max() functions work with 2 arguments as is done in most languages instead of using vectors.