On 29 September 2017 at 07:36, oldk1331 <[email protected]> wrote:
> Benchmarks:
>
> Memory usage:
> I measured it with ')lisp (sb-ext:get-bytes-consed)'
>
> When storing 100K "failed" values in List,
> Union(Integer, "failed") takes 3.2MB memory
> Maybe Integer takes 1.6MB memory
>
> I think the "failed" is alloced as String multiple times.
No, in Lisp a string is allocated only once after which only pointers
are involved. The extra space is because the rep of Union requires
both a tag and a pointer to a value. FriCAS Integer (mutliprecision)
is allocated in a similar way. In most Lisps I think a single
precision integer occupies the same space as a pointer. Your new Maybe
uses exactly and only the same space as the underlying domain.
>
> Also see the generated lisp code for subtractIfCan$NNI:
>
> Maybe version, no extra CONS:
>
> (SDEFUN |NNI;subtractIfCan;2$M;4| ((|x| $) (|y| $) ($ |Maybe| $))
> (SPROG ((|c| (|Integer|)))
> (SEQ (LETT |c| (- |x| |y|) |NNI;subtractIfCan;2$M;4|)
> (EXIT (COND ((< |c| 0) *MAYBEFAIL*) ('T |c|))))))
>
> Union version, with extra CONS:
> ...
I think this new generated code is excellent.
On 27 September 2017 at 22:53, oldk1331 <[email protected]> wrote:
> ,,,
> However your suggestion is against another FriCAS spirit:
> the ability to avoid type in interpreter. You can simply right
> 'wrap 1', but 'coerce 1' has so many different meanings.
>
The goal in the interpreter is to relieve the user of having to
explicitly specify types in many common situations by applying some
heuristic inferences. It is not a goal to avoid specifying types
altogether. It seems to me that directly construct values in some
'Maybe' domain will not be common operation for FriCAS interpreter
users. However it is possible that they might end up obtaining such a
value as an exceptional result of an operation. That is why I thought
it was important that the interpreter try to do something "sensible"
with a value from a Maybe domain by automatically attempting to
retract the value to the underlying domain - something that the
interpreter will do for values in any domain that satisfies
RetractableTo.
>> If I were to accept your argument this would imply that we should
>> try to reduce this sort of polymorphism in many other existing
>> uses of coerce/retract and in the case of other similar operators.
>
> It does not hurt to have synonym, I support to have both 'coerce'
> and 'wrap'.
Well, it does hurt a little to have to recall the name of a
special-case operator when reading unfamiliar code. But I admit that
my point is only about a minor cognitive dissonance. My only reason
for persisting in this discussion is that now seems like the only
opportunity we will have to avoid it. But if you insist of course it
will not be worse than any of the many other issues already
irrevocably embedded in the FriCAS/SPAD language.
>
>>> As for 'retract', because 'retractIfCan' should return a Maybe,
>>> that makes Maybe more fundamental than RetractableTo.
>>
>> ?? RetractableTo is a category constructor, Maybe is a domain.
>> Maybe is not more fundamental than RetractableTo. I do not see
>> any problem that in the case of Maybe retractIfCan would become
>> an identity.
>
> If Maybe R has RetractableTo R, I find this signature a little funny:
>
> retractIfCan : Maybe R -> Maybe R
>
Identities of this sort are very natural and indeed even critical in
an algebraic design.
> But it won't hurt to have RetractableTo/retract, but follow the
> same reasoning above, I (and others) should prefer 'unwrap'
> over 'retract'.
>
>>> And for the same reason, one can use 'unwrap' to avoid to
>>> specify type.
>>>
Why avoid specifying type?
>
> OK, let me persuade you in this way, Maybe is a Monad, and
> so is List. Do you wish to have these signature ONLY for List
> (and every possible Monad):
>
> coerce : S -> List S
> retract : List S -> S
>
> For List, the signature 'S -> List S' is named 'list', and
> the signature 'List S -> S' is named 'first'.
>
The essential export of Monad (if this concept existed in FriCAS) is
'map'. A Monad need not satisfy RetractableTo(R). 'Maybe' is a very
special Monad that satisfies both.
I would be happy if the 'list' operation was eliminated from FriCAS.
List values are normally and more natural constructed using
'construct', aka. [ ... ]
Bill Page.
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
