3:38 p.m.
Hi,
I'm wondering what the value added of 'inbundle' over 'exists' is. In
principle both check for the existence of an object and return a type
code if yes.
I know that currently where inbundle(b, "m") returns 0 because m isn't
there, exists(b.m) instead yields an error. But I guess that could be
changed if wanted.
And vice versa: inbundle(a, "x") yields an error if there is no bundle
a, whereas exists(a.x) just returns 0. But are those differences really
by design or just by historical coincidence?
thanks
sven
3:06 p.m.
On Wed, 8 Apr 2020, Sven Schreiber wrote:
I'm wondering what the value added of 'inbundle' over
'exists' is. In
principle both check for the existence of an object and return a type
code if yes.
I know that currently where inbundle(b, "m") returns 0 because m isn't
there, exists(b.m) instead yields an error. But I guess that could be
changed if wanted.
And vice versa: inbundle(a, "x") yields an error if there is no bundle
a, whereas exists(a.x) just returns 0. But are those differences really
by design or just by historical coincidence?
Good points. There's some redundancy here (particularly if we throw
in typeof() as well). We probably don't want to remove any of these
functions but some tweaking is in order. On the inconsistencies you
mention:
* I think it's OK that inbundle(a, "x") fails when there's no bundle
a -- the way I see it you're kind of committing to the existence of
the bundle in question when calling this function.
* However, exists(b.m) should be non-committal, so should return 0
if either b doesn't exist or it doesn't have anything under the key
"m". That's now fixed in git.
As for exists() vs typeof() -- they're basically the same thing
under two names: the same back-end, and exists() returns the same
codes as typeof(), though the help text is a little coy about that!
Perhaps exists() should just be documented as an alias.
Now talking of typeof(): it returns numeric type codes, which
typestr() can "translate". Not all that convenient. We recently
introduced the symbolic constants TRUE and FALSE. Would it be
overkill to introduce a few more: NULL, SCALAR, SERIES, MATRIX,
STRING, BUNDLE, ARRAY? In that case you could do things like
if typeof(b.m) == MATRIX
...
endif
(Maybe we could get away with using the same lower-case forms that
appear in declarations, but only if we can rule out syntactic
ambiguity.)
Allin
10:28 a.m.
Am 19.04.20 um 17:06 schrieb Allin Cottrell:
On Wed, 8 Apr 2020, Sven Schreiber wrote:
> I know that currently where inbundle(b, "m") returns 0 because m isn't
> there, exists(b.m) instead yields an error. But I guess that could be
> changed if wanted.
> And vice versa: inbundle(a, "x") yields an error if there is no bundle
> a, whereas exists(a.x) just returns 0. But are those differences really
> by design or just by historical coincidence?
Good points. There's some redundancy here (particularly if we throw in
typeof() as well).
Ah I hadn't even thought of typeof().
* However, exists(b.m) should be non-committal, so should return 0 if
either b doesn't exist or it doesn't have anything under the key "m".
That's now fixed in git.
OK, good.
As for exists() vs typeof() -- they're basically the same thing under
two names: the same back-end, and exists() returns the same codes as
typeof(), though the help text is a little coy about that!
Perhaps exists() should just be documented as an alias.
Yes, probably. I guess it
wouldn't hurt to be explicit in the
documentation about the construction 'if exists()' without checking the
return code in detail.
Now talking of typeof(): it returns numeric type codes, which
typestr() can "translate". Not all that convenient. We recently
introduced the symbolic constants TRUE and FALSE. Would it be overkill
to introduce a few more: NULL, SCALAR, SERIES, MATRIX, STRING, BUNDLE,
ARRAY? In that case you could do things like
if typeof(b.m) == MATRIX
Spontaneously I'm not sure if that's necessary. OTOH if something like
that is done I think it should go all the way and also differentiate
different types of arrays. Maybe typeof() could just accept an optional
second string literal argument which then triggers such an equality check:
if typeof(b.m, "matrix") # returns 1 if b.m is a matrix
or:
typeof(bb, "bundles") # checks if bb is an array of bundles
cheers
sven
7:06 p.m.
Hi,
Am 20.04.20 um 12:28 schrieb Sven Schreiber:
Am 19.04.20 um 17:06 schrieb Allin Cottrell:
> On Wed, 8 Apr 2020, Sven Schreiber wrote:
>
>> I know that currently where inbundle(b, "m") returns 0 because m
isn't
>> there, exists(b.m) instead yields an error. But I guess that could be
>> changed if wanted.
>> And vice versa: inbundle(a, "x") yields an error if there is no bundle
>> a, whereas exists(a.x) just returns 0. But are those differences really
>> by design or just by historical coincidence?
>
> Good points. There's some redundancy here (particularly if we throw in
> typeof() as well).
Ah I hadn't even thought of typeof().
>
> * However, exists(b.m) should be non-committal, so should return 0 if
> either b doesn't exist or it doesn't have anything under the key
"m".
> That's now fixed in git.
OK, good.
Ah, this is good to know! Very convenient.
>
> As for exists() vs typeof() -- they're basically the same thing under
> two names: the same back-end, and exists() returns the same codes as
> typeof(), though the help text is a little coy about that!
> Perhaps exists() should just be documented as an alias.
Yes, probably. I guess it wouldn't hurt to be explicit in the
documentation about the construction 'if exists()' without checking the
return code in detail.
>
> Now talking of typeof(): it returns numeric type codes, which
> typestr() can "translate". Not all that convenient. We recently
> introduced the symbolic constants TRUE and FALSE. Would it be overkill
> to introduce a few more: NULL, SCALAR, SERIES, MATRIX, STRING, BUNDLE,
> ARRAY? In that case you could do things like
>
> if typeof(b.m) == MATRIX
>
Spontaneously I'm not sure if that's necessary. OTOH if something like
that is done I think it should go all the way and also differentiate
different types of arrays. Maybe typeof() could just accept an optional
second string literal argument which then triggers such an equality
check:
if typeof(b.m, "matrix") # returns 1 if b.m is a matrix
or:
typeof(bb, "bundles") # checks if bb is an array of bundles
In Python
there exists the isinstance() function taking 2 arguments,
namely the object itself and the string of a data type being checked --
so similar what Sven has in mind:
https://docs.python.org/3/library/functions.html#isinstance
However, I don't think it's clean to "augment" the typeof() function in
Sven's proposed way. Returning the type of some 'object' and checking
whether some 'object' is of a specified type are two different issues.
And I think it's much cleaner to have two separate functions for two
different issues.
Artur
9:28 a.m.
Am 21.04.2020 um 21:06 schrieb Artur Tarassow:
Am 20.04.20 um 12:28 schrieb Sven Schreiber:
> Am 19.04.20 um 17:06 schrieb Allin Cottrell:
>> Now talking of typeof(): it returns numeric type codes,
which
>> typestr() can "translate". Not all that convenient. We recently
>> introduced the symbolic constants TRUE and FALSE. Would it be overkill
>> to introduce a few more: NULL, SCALAR, SERIES, MATRIX, STRING, BUNDLE,
>> ARRAY? In that case you could do things like
>>
>> if typeof(b.m) == MATRIX
>>
> Spontaneously I'm not sure if that's necessary. OTOH if something like
> that is done I think it should go all the way and also differentiate
> different types of arrays. Maybe typeof() could just accept an optional
> second string literal argument which then triggers such an equality
> check:
>
> if typeof(b.m, "matrix") # returns 1 if b.m is a matrix
...
However, I don't think it's clean to "augment" the
typeof() function in
Sven's proposed way. Returning the type of some 'object' and checking
whether some 'object' is of a specified type are two different issues.
And I think it's much cleaner to have two separate functions for two
different issues.
Reviving this thread and these ideas: Point taken by Artur, OK.
The most important gap IMO is the missing differentiation between
different array types (matrices, strings, etc.). And using the first
array element of an array wouldn't work in the case of an empty array.
(As in 'matrices M = array(0)'.)
So here's another idea: Extend the typeof() function to spit out new
codes for matrices, strings, lists, bundles (and "arrays" I guess?)
instead of just 6 which stands for array. For example 10 + the
individual code for the object:
- 13 for matrices
- 14 for strings
- 15 for bundles
- 16 for arrays
- 17 for lists
An optional argument could be introduced for that such that:
- typeof(M) gives 6
- typeof(M, TRUE) gives 13
And then typestr() would have to understand these new codes, of course.
Personally I think having to type typestr(typeof( ...)) isn't so bad,
although of course there's also room for improvement.
cheers
sven
1316
days inactive
1472
days old
4 comments
3 participants
participants (3)
-
Allin Cottrell -
Artur Tarassow -
Sven Schreiber