Background:
As part of the Gonum dev team, I have an interest in using Go for
scientific computing. This stems from long experience with unsafe
computing environments often used in, particularly, bioinformatics
(perl, python and R being standouts in the field, with packages that
often use dubious
Just a silly idea: what if you make the dimensions (m,n) part of the type, not
just T, somehow?
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsub
On Mon, Nov 26, 2018 at 6:15 PM Dan Kortschak
wrote:
>
> Background:
>
> As part of the Gonum dev team, I have an interest in using Go for
> scientific computing. This stems from long experience with unsafe
> computing environments often used in, particularly, bioinformatics
> (perl, python and R
Yes, this was raised as a possibility by Ian. But this negates a very
valuable aspect of matrices that I completely failed to consider in
writing the question: the issue of submatrices and how these are
valuable.
On Mon, 2018-11-26 at 20:49 -0800, Tamás Gulácsi wrote:
> Just a silly idea: what if
Hi Dan,
What you are referring to is called *behavioral types* (see, *e.g., *
https://www2.ccs.neu.edu/racket/pubs/fse01-flf.pdf).
If you want to go that route, you need (usually arbitrarily complex)
behavioral contracts (not to be mistaken with the term type contracts used
here) and static checks
@Dan: P.S. Sorry, I probably should have addressed the email to Tamas
Gulacsi.
On Tue, 27 Nov 2018 at 10:41, Dan Kortschak
> wrote:
>
>> Yes, this was raised as a possibility by Ian. But this negates a very
>> valuable aspect of matrices that I completely failed to consider in
>> writing the qu
Odd that the paper you chose to link to is one specifically addressing a
difficulty integrating the ideas with Java's class hierarchies -- while
the broader subject may be relevant to Go, I don't think that paper is.
Wrt Dan's question of doing static checks, I'll quote the paper:
> In principle,
Hi Ian,
I'm actually not in favor of dependent types -- this might have come wrong
"over the line". I find them limiting and confusing in practice (but I have
limited experience, mostly in C++ if you could call template hacks really
dependent types...).
I expect most applications to need wider fam
Quoting Marko Ristin-Kaufmann (2018-11-27 10:29:15)
> if you could call template hacks really dependent types...
You really couldn't, they're entirely different beasts.
>I expect most applications to need wider family of behavioral contracts
>-- and I doubt that Go would ever support the
>
> What is the zero value of a
> non-optional pointer? (If I were doing a clean-slate Go, I'd probably
> leave zero-values out, but I'm not).
>
I haven't really spent much thought about it. I suppose that would also
fall in the realm of static or run-time checks of behavioral contracts.
>
--
Y
P.S. given that many functions return a tuple (pointer, error) where the
pointer is nil if error is not and vice versa, I actually also doubt the
usefulness of the Optional type. On the other hand, that makes behavioral
contracts (static or run-time) more relevant.
Le mar. 27 nov. 2018 à 18:05, Ma
On Nov 26, 2018, at 8:46 PM, Ian Lance Taylor wrote:
>
> On Mon, Nov 26, 2018 at 5:14 PM Dan Kortschak
> wrote:
>>
>>
>> Question:
>>
>> One of the areas where we do this is in the mat package for matrix
>> arithmetic and linear algebra. We use panics in lieue of a compile-time
>> type check
12 matches
Mail list logo
