Raul Miller-4 wrote:
>
>> Here is where ADT show some power in reasoning about data,
>> because we can ask what does it mean for instance, "everything
>> is array". Well, as I wrote some time ago, to me in J scalars are
>> not arrays because the equation
>> a-:a,x
>> has no solution for any scalar a, but has solution for an array a.
>> So, ADT could be helpful in sorting this type of questions with
>> some rigour.
>
> But why is the ',' operation the determining issue, here? Is your
> reasoning based on the existence of the ',' verb?
>
Indeed. But this existence is not accidental---pretty much every
programming language has some sort of append, concatenate, etc.
It's as far as J primitives go, pretty primitive operation, also
frequently used.
Furthermore, I'd like to put "everything is array" to the test: are
scalars arrays? Is there any way to decide or test it or is it a mere
conventional saying?
Then I said scalars are not arrays because I don't have a noun in J
that I can append to a scalar and get that same scalar, but I have
such nouns in the case of arrays. Sounds somewhat arbitrary? I'll
come back to this question from the perspective of ADT.
First, the way you circumvent the problem:
> If so, let's say I defined:
>
> viktor=:4 :0
> R=. x,y
> if. (1-:#R) *. 0 e. x ,&(#@$) y do. {.R end.
> )
>
> ..and let's say that I use this 'viktor' operation in place of ',' --
> has the definition of "Array" changed?
>
Array hasn't changed, but append *has* changed to accommodate
the exception. Equivalently,
p =: *.&(''&-:) $@]
append =: ,`[@.(p~)`]@.p
(x p y is the predicate: is x scalar and y empty array?)
> Is your argument that , is a language primitive where 'viktor' is not
> a language primitive? If so, does that mean that
>
> i.2 2
> 0 1
> 2 3
>
> is not a matrix, because +/ .* is not a primitive?
>
I think that if , were defined as you suggest or in a similar way
we would have had somewhat better definition of append, more
attuned to the 'everything is array' statement.
ADT let us see better where is the problem.
I begin with the following definition of the type of integer J arrays as:
Jarr = [int]*[int]
The first list is the rank, the second elements. Clearly, scalars fit into
this type---number 5 would be represented as []*[5], number 2 as []*[2]
5 + 2 as []*[5] + []*[2] = []*[7], and appending is done as:
[]*[5] , []*[2] = [2]*[5 2]. So far so good, everything is array,
and we actually formulated ADT that accurately describes J int arrays, no?
Well, the problem is that Jarr type, together with operations + and ,
is isomorphic to (which roughly means "the same as" or "equivalent to"
or "structurally same as") the following type:
Jarr' = int + [int]*[int]
where the list representing rank is now further constrained to
*non-empty* ranks, while operations + and , now work as:
2 + 5 = 7
2 , 5 = [2]*[2,5]
2 , [1]*[5] = [3]*[2,1,5]
etc
We *explicitly* discriminate between scalars and arrays that are
not scalars at the type level. So which one is the correct type?
Jarr or Jarr'? Both are equivalent at the level of J, since J does not
insist on either Jarr or Jarr' representation of arrays. Insisting on Jarr
would have been pointless, because definition of J as we know it
would not have changed if we used Jarr' to implement it.
but this also means that the question "is everyting array in J?"
is a mute point, almost an arbitrary qualification. It's nothing
wrong with it, there are very nice things in J like identity functions,
but how can it be justified from the perspective of ADT?
Here neither yours nor mine augmentation of , would make
any difference, because if we program them using Jarr type,
then we still dynamically check whether something is scalar or
not, and if we program them using Jarr' type, we'd end up
most likely defining a polymorphic function/procedure that
discriminates between int and [int]*[int] types from Jarr'.
>
> I am trying to make sense of your reasoning, and I am struggling.
>
>>> But a bigger problem is that we don't really have a good definition of
>>> "type". And by "good" I mean:
>>>
>>> a. concise,
>>> b. accurate, and
>>> c. consistent.
>>>
>> I don't know what's wrong with types as we use it today,
>> either in simplest cases or in some deep theoretical sense.
>
> That sounds excellent -- but what is this definition for 'type'?
>
We gather some things together and give them a common name:
like numbers 1,2,3,4,5 and call them int1to5, or True and False
and call them Bool, or all 32 bit machine integers and call them Int32,
all possible lists of ints, including empty list, and call them [int] etc.
There also have to be some operations available and/or definable
in order to make programs, and it is often that types are chosen
according to operations that are to be done with values of a given
type.
>>> Note also that i. i. 4 has 0 ints... and a shape of four. So the type
>>> here might be "1" though if you also consider the shape information
>>> the type here might be int*int*int*int.
>>>
>> oh, I see where you're headed. You're asking for type
>> representation for arrays including empty ones of arbitrary
>> shape. Well, ADT might be simply:
>> [int]*[int]
>> so your array would be represented as [0,1,2,3]*[]
>
> Ok, though this leaves me with issues like: what is the type of the array
> (0 1)?
>
Its type is [int]*[int] (this is Jarr), and concrete value that represents
the array is [2]*[0 1].
It could be also of type Jarr' and the same representation just as well,
as I discussed moment ago.
> Hypothetically, I could see a J array being: T*[int]*[atom] where T
> matches the type of the atoms and product([int]) matches the number of
> atoms.
>
Sure thing (just the type would be more like T*[int]*[T], and my
previous example with Jarr' would now become T*(T+[int]*[T]).)
> But the underlying values here seem to be near-infinities, and
> I am not certain how I could work with them. Or, if I take their base
> 2 log, they seem to be a [relatively bland] restatement of the numbers
> used by memory management.
>
I'm not sure what you mean: when we define type, we haven't really
constructed a single instance of the type, just constructively described
(finite or potentially infinite) collection of values that belong to the
type.
When the program rolls on, 0 or more instances of defined types are
created, depending on program.
> --
> Raul
>
> On Mon, Feb 6, 2012 at 8:57 PM, Viktor Cerovski
> <[email protected]> wrote:
>> On Sun, Feb 5, 2012 at 6:54 PM, Viktor Cerovski
>> <[email protected]> wrote:
>>> Raul Miller-4 wrote:
>>>> http://blog.lab49.com/archives/3011
>>>> It's amusing to try to think of how to characterize J arrays using
>>>> that methodology.
>>>>
>>>> Conceptually speaking, J has one type: array, and it's statically
>>>> typed.
>>>>
>>> In other words, we are having here dynamic type.
>>
>> This is a matter of perspective.
>>
>> It's also a single static type.
>>
>> More importantly, J's operations on this type do not, as a general
>> rule, exhibit "polymorphism", where we have conflicting definitions
>> which we choose from depending on the type of the data.
>>
>> [There are exceptions to this rule, especially if we include bugs,
>> where the implementation conflicts with the dictionary.)
>>
>>
>>
>>> But a bigger problem is that we don't really have a good definition of
>>> "type". And by "good" I mean:
>>>
>>> a. concise,
>>> b. accurate, and
>>> c. consistent.
>>>
>> I don't know what's wrong with types as we use it today,
>> either in simplest cases or in some deep theoretical sense.
>>
>> [...]
>>
>>
>>> Note also that i. i. 4 has 0 ints... and a shape of four. So the type
>>> here might be "1" though if you also consider the shape information
>>> the type here might be int*int*int*int.
>>>
>> oh, I see where you're headed. You're asking for type
>> representation for arrays including empty ones of arbitrary
>> shape. Well, ADT might be simply:
>> [int]*[int]
>> so your array would be represented as [0,1,2,3]*[]
>>
>> Here is where ADT show some power in reasoning about data,
>> because we can ask what does it mean for instance, "everything
>> is array". Well, as I wrote some time ago, to me in J scalars are
>> not arrays because the equation
>> a-:a,x
>> has no solution for any scalar a, but has solution for an array a.
>> So, ADT could be helpful in sorting this type of questions with
>> some rigour.
>>
>>
>>
>>> But there's a bigger fallacy here -- and that fallacy is the idea I
>>> introduced, which is that algebraic data types can be used to describe
>>> individual values. They can't. A value only has one possible value
>>> -- itself -- so its algebraic representation would be 1.
>>>
>> Yes, indeed, but why is that problem at all?
>>
>>
>>> Algebraic
>>> data types maybe describe regions of memory (or other concepts which
>>> can be used to represent multiple values...)
>>>
>>>>> So the value representing the type of an
>>>>> empty array is 1, and the type of a bit is 2, and the type of 2 bits
>>>>> is 4...
>>>
>>>> What you're doing here, and then continue with more examples,
>>>> is to try to build the type system starting from bits. That's not
>>>> how we would like to use types however, but rather to just specify
>>>> explicitly some types called, say, Int32, Int64, Word32, SingleFloat,
>>>> etc.
>>>
>>> Yes, though my "doing here" is largely motivated by the structure of
>>> algebraic data types.
>>>
>>>> Types are only half of the story---there are also operations over
>>>> types,
>>>> and that's also what we need to take into account when talking about
>>>> types.
>>>
>>> That sounds good, though this also introduces other issues. For
>>> example, every operation needs at least two types (an argument type --
>>> the domain -- and a result type -- the range). Also, the types which
>>> are associated with operations are often "smaller" than the underlying
>>> type systems. (I remember the terms "one-to-one" and "onto"
>>> describing the exceptional cases -- where the full range of a "type"
>>> would be used.)
>>>
>> Again, I don't see problem here with ADT. Also, don't forget that
>> one type ("dynamic" type, or, for example, strings) suffices to have
>> arbitrarily interesting programs. ADT merely tries to systematically
>> breaks down, or builds up, all the interesting values that
>> we can make or use in programs into separate classes of values,
>> which are individual types.
>>
>>
>>>> We should be provided with some operation like + that sums Ints,
>>>> etc, and it is not necessary to have them defined at the bit level at
>>>> all.
>>>
>>> I do not know what this sentence means. But I will agree that in the
>>> general case of mathematical work we often work with entities which
>>> have no concrete, finite representation.
>>>
>> All I'm saying is that types describe data, and we also need
>> operations that do something with that data to get to programs.
>> So when we talk about ADT only and exclusively, we still don't
>> do programming unless we talk about functions/procedures that
>> use them.
>>
>>
>>>> So we start with some number of types and operations, and then
>>>> algebraically build new types as well as operations, but the starting
>>>> choice of types and corresponding operations is not necessarily fixed.
>>>
>>> This sounds contextual. In some contexts this would be true, in other
>>> contexts it would be false.
>>>
>>>> More importantly, there is no some canonical choice of starting types
>>>> from which everything else could be built up.
>>>
>>> Here, I imagine you are talking about the general case of mathematics
>>> rather than the specific case of a programming language
>>> implementation?
>>>
>> Well, you're free to start with any number of any types you want,
>> bit or Int32 or tree, list, house, *, whatever, so long as you can
>> construct
>> values of the(se) type(s) and have something that transforms values into
>> values. That's the starting point. In the case of programming languages
>> we might as well assume that we have some type Int64 with operations
>> like + as given. It certainly would depend on what we are trying to
>> describe, but in any case it is not necessary to always start with bits.
>>
>> --
>> View this message in context:
>> http://old.nabble.com/algebraic-data-types-tp33260423s24193p33276054.html
>> Sent from the J Chat mailing list archive at Nabble.com.
>>
>> ----------------------------------------------------------------------
>> For information about J forums see http://www.jsoftware.com/forums.htm
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
>
--
View this message in context:
http://old.nabble.com/algebraic-data-types-tp33260423s24193p33281600.html
Sent from the J Chat mailing list archive at Nabble.com.
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
