Mixing APL and strongly typed variables; philosophy, details

General discussions related to APLNext's VisualAPL.

Moderators: Tech Support, phpbb_admin

Mixing APL and strongly typed variables; philosophy, details

Postby Chris McIntosh » August 5th, 2011, 2:18 pm

I'll try to explain the issue I'm currently having without writing a book. It mainly concerns mixing APL variables with strongly typed variables.

My issue is that when using strongly typed variables, sometimes things work. Sometimes things don't work and give error messages. Sometimes things don't work, and give incorrect (or unexpected) results. So far, I haven't been able to determine any pattern in results, so I could more reliably predict how I should be programming.

It is possible that in some cases, there are bugs in VisualAPL which can/will be fixed. It's possible that in other cases, I'm expecting things from VisualAPL it was not designed to do. I think it would be helpful for me to have some principles to work from, so I can more easily determine some "best practices".

I'm starting to think I should avoid strongly typed variables at all costs, however there are some exceptions. I need to take in strongly typed variables from other languages, and I need to return them to other languages. In some (rare?) cases, as in for loops, the use of strongly typed counter variables is encouraged to help with performance.

With that introduction, here are some specifics. I won't put all my examples in this message, but will add one example per post in this thread.

Example 1:

// Assigning strongly typed variables.
// Declarations.
string[] TestString
int[] TestInt
float[] TestFloat
double[] TestDouble

// Assignments.
TestStringâ†
Chris McIntosh
 

Postby Chris McIntosh » August 5th, 2011, 2:59 pm

Example 2, comparisons involving strongly typed variables.

// Declarations.
int[] TestInt
int LimitIntTyped
float LimitFloatTyped
double LimitDoubleTyped

// Try some assignments.
LimitFloatTypedâ†
Chris McIntosh
 

Postby Chris McIntosh » August 5th, 2011, 3:08 pm

Example 3 (very minor update to example 2):

In example 2, TestDouble was untyped. If it is strongly typed and declared as: double[] TestDouble, then the results are identical to Example 2 results EXCEPT that the value of Bool6 changes from true to false.

Chris

P.S. I should add that in these examples, problems are probably largely irrelevant. It's unlikely anyone will strongly type variables internally assigned and used in a VisualAPL program.

These problems become an issue when VisualAPL is passed in strongly typed input arguments, which are then used with comparison (and other) operators, and don't give expected results or errors.
Chris McIntosh
 

Postby Chris McIntosh » August 5th, 2011, 3:50 pm

As mentioned as a P.S. (added after the initial post) in Example 3, so far these examples might be largely irrelevant. It's unlikely anyone will strongly type variables internally assigned and used in a VisualAPL program.

These problems become an issue when VisualAPL is passed in strongly typed input arguments, which are then used with comparison (and other) operators, and don't give expected results or errors. The following examples illustrate some of these problems.

Example 4:

public static void AplTests(float[] inputVec, float[,] inputMat, string[] inputString, string[,] inputStringMat, double[] inputDoubleVec, double[,] inputDoubleMat)
{
// Try assigning from input.
string[] TestString2
string[,] TestStringMat
float[] TestFloatVec
float[,] TestFloatMat
TestString2â†
Chris McIntosh
 

Type casting between .Net value type array & VisualAPL c

Postby joe_blaze » August 5th, 2011, 5:13 pm

There are no 'untyped' objects in .Net and hence there are no 'untyped' objects (variables) in VisualAPL.

VisualAPL incorporates a .Net datatype called 'cvar' which is used as the data type argument to APL operators and many quad-functions. The cvar data type has additional properties which are analogous to traditional APL properties, e.g. []dr values. Even though an object of cvar .Net type might have have a []dr result of 323 (integer), that object's .Net type is cvar and not Int32.

When .Net value types, e.g. Int32, double, string, etc. are passed by the VisualAPL programmer to an APL operator, the arguments are generally first cast (i.e. coerced, if possible and if necessary) to cvar data types and then the APL operator method is applied to those cvar arguments. The result has .Net type cvar. This process is especially necessary for cvar array objects.

Only if the APL programmer explicitly casts a cvar result to a .Net value type will the .Net type of the result be changed from .Net cvar type.

The casting (directly or implicitly) of .Net value types to .Net cvar type is implemented in VisualAPL only for a selection of .Net value types. For example a recent version update of VisualAPL implemented an additional cast option (See http://forum.apl2000.com/viewtopic.php?t=710).

VisualAPL uses the underlying .Net operators and methods whenever possible, so, for example, 1+ 1.234 56.789 in VisualAPL iterates thruough the elements of the array utilizing the .Net arithmetic operator plus on scalar doubles.

Providing an argument to an APL operator of a .Net type which cannot be implicitly cast to cvar will result in an error. For example:

X = (decimal) 1.234
X.GetTypeCode()
X+1 2 3 4 //Returns bad args to this method <method: op_Addition on System.Decimal> because an implicit cast from decimal[] to cvar array is not currently implemented in VisualAPL

On the other hand:

X=1.234
X.GetType() //Returns in System.Double
X+1 2 3 4 //Returns in 2.234 3.234 4.234 5.234
(X+1 2 3 4).GetType() //Returns in VisualCielo.Numeric.DataObjects.cvar

If the VisualAPL programmer wants to return a .Net type of array of double (i.e. double[]):
(double[])(X+1 2 3 4) //Returns Unable to cast object of type 'VisualCielo.Numeric.DataObjects.cvar' to type 'System.Double[]' because an implicit cast from double[] to cvar array is not currently implemented in VisualAPL.
Casting the result (X+1 2 3 4) to double[] can be done by the VisualAPL programmer by assigning the result to a variable name and iterating through the elements and individually assigning them to the elements of a pre-defined variable of .Net type double[].

Casting arguments to APL operators as .Net cvar types is done only when necessary. Scalar operator methods are generally performed using the .Net value types without conversion to .Net cvar type. For example:

X=1.2345 //Note that VisualAPL assumes that this is a double and not decimal .Net value type.
X.GetType() //Returns System.Double, so X=(double)1.2345 would be superfluous
(1+X).GetType() //The result of this scalar operator is System.Double


String and Char[] Specification:
'abcd'.GetType() //Returns System.Char[], an array of characters
"abcd".GetType() //Returns System.String
Traditional APL only supports the Char[] data type with the enclose/disclose operator used to emulate the string datatype and may permit ' and " pairs to be interchanged.

Some implicit casting of .Net (scalar) value types is done because it is inherently available in .Net:
f=(float) 1.234
1+f //Returns 2.234
(1+f).GetType() //Returns System.Single
d=(double)100.0001
d.GetTypeCode() //Returns Double

(1+d).GetType() //Returns System.Double

(f+d) //Returns 101.23409996757

(f+d).GetType() //Returns System.Double

Limits upon the implicit and explicit casting of .Net types is not unusual in .Net. When such methods are not available in .Net, an exception is thrown. VisualAPL follows this style. For example, .Net collections contain many special methods for conversion between collection types and arrays rather than providing implicit casting. These methods use iteration through the elements to perform the type casting to and from arrays. In addition these conversion methods illustrate that there are different needs, such as extensions to the conversions related to sorting and selecting, which implicit coercion would not satisfy.

Analogously whenever VisualAPL does not provide an implicit cast to or from cvar arrays, the VisualAPL programmer can use iteration through the array elements to perform the cast. Such casting methods can be developed within a separate VisualAPL .Net 'utility' assembly and referenced for use in many VisualAPL projects.

Use Interfaces:
When programming in VisualAPL and working with .Net assemblies developed in other .Net languages, a suggested approach is to clearly define the interface between the two code bases. Required datatype conversions are explicitly performed within interface methods in the VisualAPL code base which represent the methods of the 'external' assemblies. In the VisualAPL code base strong typing can then be avoided except in these interface methods.

Depending on customer support for VisualAPL, enhancements for implicit casting of arrays of .Net value types to cvar arrays can be considered for a future release. Limitations on implicit casting of arrays are not structural in VisualAPL, but represent the limits on implementation costs which are imposed by the product's current customer base.
joe_blaze
 
Posts: 384
Joined: February 11th, 2007, 3:09 am
Location: Box 361 Brielle, NJ 08730-0361

Postby Chris McIntosh » August 5th, 2011, 6:08 pm

Hi, Joe,

Thanks very much for your quick and thorough answer, and also correcting some of my statements regarding "untyped" objects. You are right. There are no untyped objects in .NET. What I meant was "non-strongly typed" VisualAPL variables, but of course that is not the same as an untyped variable.

I'm beginning to strongly suspect that most (if not all) of my problems with .NET strongly typed variables are due to my not being aware of or not understanding implicit and explicit conversions availble.

I've just found the implicit and explicit conversion tables around pages 110-111 of your VisualAPL manual. HOWEVER these tables seem to describe only conversions from .Net to .Net types. Is there any table describing what .Net types are supported for implicit casts to VisualAPL cvar types? I think that would be very helpful for me.

Your examples are very helpful, but I do have a couple of questions.

The example of wanting to return a .Net type of array of double[] from VisualAPL is extremely relevant to me.

The error you gave was "Unable to cast object of type '....cvar' to type 'System.Double[]'. I can understand this, because the statement is trying to cast a cvar to a double[].

However I'm not sure I understand your explanation. You say an implicit cast from double[] to cvar array is not currently implemented. But unless I'm missing something, I don't see that is what the statement is trying to do. It seems to me the statement is trying to do the reverse - cast from cvar to double[]. Unless of course if an implicit cast isn't supported in one direction (double[] to cvar) that means it's not supported in the reverse direction either (cvar to double[]).

But again, I think I might be a little confused. When typing (double[])(X + 1 2 3 4), to me that doesn't seem like an implicit cast. It seems like an explicit cast.

I'm speculating that if an implicit cast isn't supported, then probably an explicit cast isn't supported either. Is that the case?

Thank you very much for your "best practices" suggestions in the Use Interfaces section of your e-mail. I think this is extremely helpful.

I'm not sure at this point whether I need any changes to your current support of implicit casting. I think first I need to understand the conversions you currently do and do not support, and work within them. Then, I'll be in a better position to say.

I definitely did very much need the ability to cast to string[,] arrays in the past, and appreciate your quick implementation of that requirement.

Thanks again for your quick help.

Chris
Chris McIntosh
 

Implicit/Explicit Cast

Postby joe_blaze » August 16th, 2011, 1:20 am

Chris:
Is there any table describing what .Net types are supported for implicit casts to VisualAPL cvar types?

Joe: No, but I agree it would be helpful. I will create one and add it to the VisualAPL documentation in the future. It will require research and testing which will take some time.

Additional note:

In my response, I used the words implicit and explicit in a confusing way.

I would consider the following an implicit cast, i.e. one in which VisualAPL converted from cvar to the desired datatype without the programmer doing much.

double[] DV
DV #is 1.2345 6.789

I would consider the following an explicit cast:

DV #is (double[]) 1.2345 6.789

where #is is the assignment (by value or by reference) operator[/i]
joe_blaze
 
Posts: 384
Joined: February 11th, 2007, 3:09 am
Location: Box 361 Brielle, NJ 08730-0361

Postby Chris McIntosh » August 16th, 2011, 4:19 pm

Hi, Joe,

Thanks for your reply to this and my other posts.

Thanks for agreeing to create a table describing what .Net types are suported for implicit casts to VisualAPL cvar types.

I understand this will take time. I appreciate your efforts, and will look forward to revised documentation when it is available.

Chris
Chris McIntosh
 


Return to VisualAPL

Who is online

Users browsing this forum: No registered users and 3 guests

cron