Implementing fixed-sized vectors (using datatype algebra?)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
85 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: Re: Implementing fixed-sized vectors (using datatype algebra?)

Bugzilla from alfonso.acosta@gmail.com
On Wed, Feb 20, 2008 at 11:26 AM, Wolfgang Jeltsch
<[hidden email]> wrote:
>  Hello Fons,
>
>  why do you use the term vector?  I'd say that this term is more or less wrong
>  for what this type is about.  The distinguishing property of vectors compared
>  to lists is that there is addition and scalar multiplication for vectors.

That depends on how you interpret the word vector, which is
polysemous: http://en.wikipedia.org/wiki/Vector

You are interpreting it as "An element in a vector space, often
represented as a coordinate vector" whereas in this case I try to mean
"A one-dimensional array".

> The data type you defined is a fixed size list.

The fact that FSVec is internally implemented using lists doesn't
imply that FSVec should be interpreted as a list. FSVec is an ADT and
I could as well have used something else to implement it (inmutable
arrays for instance).
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Implementing fixed-sized vectors (using datatype algebra?)

Wolfgang Jeltsch-2
In reply to this post by Bugzilla from alfonso.acosta@gmail.com
Am Samstag, 2. Februar 2008 14:54 schrieben Sie:
> On Feb 1, 2008 10:32 PM, Wolfgang Jeltsch wrote:
> > Am Freitag, 1. Februar 2008 13:00 schrieb Alfonso Acosta:

> […]

> > > To make it friendlier for the end user I thought about defining
> > > aliases for lets say the first 10000 numbers using Template Haskell.
> > > That could even make error reports friendlier (not sure to what point
> > > though). What do you think?
> >
> > I have no clear opinion about that at the moment.  Maybe it's okay to use
> > the representation directly.  This way, we don't introduce a dependeny on
> > the Template Haskell language extension (which is only supported by GHC),
> > and the actual representation will occur in error messages anyway
> > whenever the message shows a computed number.
>
> Well, my EDSL already makes extensive use of TH. So, being selfish, it
> wouldn't be a problem for me (or any other GHC user) and I think it
> would make the library much more usable.

Hello again,

I have a feedback from my Grapefruit co-developer about those aliases in the
type-level package.  He told me that on his machine, building this package
took about 15 minutes, obviously because the machine ran out of RAM.  He also
told me that the generated object code was very large, and that loading the
documentation page generated by Haddock took very long.

And he made a very good point: Who needs aliases for *all* numbers until, say,
10000?  Who needs to hard-code the vector length 8247 in his code?  I think
that in practice, you only need very few numbers hard-coded.  So it might be
better to export a function for letting the package user generate the
necessary aliases himself.

I even think that it is probably sensible to drop the alias thing completely,
at least if you have vector lengths in mind.  What vector lengths will appear
as fixed in a real world program?  1000?  I think, usually you have only
sizes like 2 or 3 hard-coded, for vectors in the mathematical sense.  And
their representation is already very short: D2, D3, …  Remember that computed
numbers are not shown as aliases in error messages, only numbers that
directly appear in your code.

My co-author also mentioned that he doesn’t see much use for octal and
hexadecimal notation.

So I propose to drop alias support from type-level or at least let the package
user do the necessary generation.

> […]

Best wishes,
Wolfgang
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Implementing fixed-sized vectors (using datatype algebra?)

Bugzilla from alfonso.acosta@gmail.com
On Fri, Mar 14, 2008 at 5:30 PM, Wolfgang Jeltsch
<[hidden email]> wrote:
>  I have a feedback from my Grapefruit co-developer about those aliases in the
>  type-level package.  He told me that on his machine, building this package
>  took about 15 minutes, obviously because the machine ran out of RAM.  He also
>  told me that the generated object code was very large, and that loading the
>  documentation page generated by Haddock took very long.

Fair point, it akes quite some time in my machine too (not 15minutes though)

>  And he made a very good point: Who needs aliases for *all* numbers until, say,
>  10000?  Who needs to hard-code the vector length 8247 in his code?

If I remember correctly aliases are generated until decimal 5000,
which might me really long anyway.

> I think
>  that in practice, you only need very few numbers hard-coded.  So it might be
>  better to export a function for letting the package user generate the
>  necessary aliases himself.
>
>  I even think that it is probably sensible to drop the alias thing completely,
>  at least if you have vector lengths in mind.  What vector lengths will appear
>  as fixed in a real world program?  1000?  I think, usually you have only
>  sizes like 2 or 3 hard-coded, for vectors in the mathematical sense.  And
>  their representation is already very short: D2, D3, …  Remember that computed
>  numbers are not shown as aliases in error messages, only numbers that
>  directly appear in your code.
>
>  My co-author also mentioned that he doesn't see much use for octal and
>  hexadecimal notation.
>
>  So I propose to drop alias support from type-level or at least let the package
>  user do the necessary generation.
>

I think that removing aliases completely is not a good idea. How about
generating much lower aliases for decimals (lets say until 1000),
droping the other bases, and exporting a function to extended the
alias range at will? (that function could perfectly include the other
bases as well). Something called extendAliases would do.


I don't have the time to work on it now, but if you send me a patch
I'd be happy to apply it. It should be something simple to do. All the
Template Haskell machinery is already coded.




>  > […]
>
>  Best wishes,
>  Wolfgang
>
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Implementing fixed-sized vectors (using datatype algebra?)

Wolfgang Jeltsch-2
Am Freitag, 14. März 2008 17:46 schrieben Sie:
> […]

> I think that removing aliases completely is not a good idea. How about
> generating much lower aliases for decimals (lets say until 1000),

I don’t think, this is a good idea.  Like nobody will need an alias for 8247,
nobody will need an alias for 824.  The main point is that it is unnecessary
to have a continuous range of numbers for which aliases exist.  If you need
aliases, you need them for “outstanding” values.  Maybe you need aliases for
all powers of 2 up to a certain number.  Or aliases for all square numbers.

Therefore I think that if we want aliases then we should let the user and only
the user generate them.  This has also the interesting consequence that the
type-level package doesn’t need the Template Haskell language extension
anymore.  After all, using the template-haskell package doesn’t imply that
you have to have a TH-enabled compiler, as far as I know.

> droping the other bases,

That’s a good idea.

> and exporting a function to extended the alias range at will?

I’d rather propose something like this:

    $(numAliasDecls [2 ^ n | n <- 0..16])

So that numAliasDecls has a type like [Int] -> [Decl].

> (that function could perfectly include the other bases as well).

Maybe.

> […]

> I don't have the time to work on it now, but if you send me a patch
> I'd be happy to apply it. It should be something simple to do. All the
> Template Haskell machinery is already coded.

Okay, I could send you a patch realizing my above ideas but would like to hear
your opinion first.

> […]

Best wishes,
Wolfgang
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Implementing fixed-sized vectors (using datatype algebra?)

Bugzilla from alfonso.acosta@gmail.com
On Fri, Mar 14, 2008 at 9:58 PM, Wolfgang Jeltsch
<[hidden email]> wrote:

> Am Freitag, 14. März 2008 17:46 schrieben Sie:
>  > I think that removing aliases completely is not a good idea. How about
>  > generating much lower aliases for decimals (lets say until 1000),
>
>  I don't think, this is a good idea.  Like nobody will need an alias for 8247,
>  nobody will need an alias for 824.  The main point is that it is unnecessary
>  to have a continuous range of numbers for which aliases exist.  If you need
>  aliases, you need them for "outstanding" values.  Maybe you need aliases for
>  all powers of 2 up to a certain number.  Or aliases for all square numbers.
>
>  Therefore I think that if we want aliases then we should let the user and only
>  the user generate them.  This has also the interesting consequence that the
>  type-level package doesn't need the Template Haskell language extension
>  anymore.  After all, using the template-haskell package doesn't imply that
>  you have to have a TH-enabled compiler, as far as I know.

I don't agree. Not using aliases is a big pain, which means that every
user wanting to use vectors with sizes biger than 10 (i.e. all)  will
have to generate their own alias set.

It would be really annoying having to generate the aliases every time
the library is used.

Let's agree on a minimum alias set likely to be used by most of the
users, small enough to get a reasonable object code size and compile
time (we can even prevent haddock from parsing the alias module and
just write a comment indicating what aliases are and which ones are
generated if that helps). Generating type redefinitions up to decimal
500 shouldn't be such a big overhead (at least compared to the quntity
of aliases generated right now).

>
>  > droping the other bases,
>
>  That's a good idea.
>

>  > and exporting a function to extended the alias range at will?
>
>  I'd rather propose something like this:
>
>     $(numAliasDecls [2 ^ n | n <- 0..16])
>
>  So that numAliasDecls has a type like [Int] -> [Decl].

That doesn't include bases, which might be important for the end user
(for example Oleg wrote his type-evel numerical library in base 2
because it was aimed at system development).

I'd rather propose a modification of
Data.TypeLevel.Num.Aliases.genAliases which probably should be aware
of the aliases already generated in the library so that they are not
duplicated.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
12345