> 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?
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?
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 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'?
>> 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)?
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. 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.
--
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
