ANN: Ada 2005 Math Extensions 20101223
Simon Wright
http://sourceforge.net/projects/gnat-math-extn/files/20101223/
Changes:
The package is renamed to Ada_Numerics.Generic_Arrays.
An additional overloaded procedure Eigensystem returns the generalized
eigenvalues and eigenvectors of a pair of non-symmetric real matrices.
NB, this is only supported for unconstrained Float and Long_Float at
this time.
To do:
Add support for constrained floats to this Eigensystem.
Add generalized solutions for non-hermitian complex matrices.
...
Enjoy (this, and the season's festivities!)
Ada novice
> This release is now available athttp://sourceforge.net/projects/gnat-math-extn/files/20101223/
>
Thanks Simon. I was just wondering which file to compile. I opened
test_extensions.gpr as usual. I see that the file test_extensions.adb
is the same as in earlier version and this was the one that I used to
set as main. You have some file ending with _eigenvalues now and I
would like to know which one to set as the main file.
I am not familiar with AUnit.
Thanks
Best wishes for the end-of-year festivities
YC
Simon Wright
> On Dec 23, 11:21 pm, Simon Wright <si...@pushface.org> wrote:
>> This release is now available at http://sourceforge.net/projects/gnat-math-extn/files/20101223/
>>
>
> Thanks Simon. I was just wondering which file to compile. I opened
> test_extensions.gpr as usual. I see that the file test_extensions.adb
> is the same as in earlier version and this was the one that I used to
> set as main. You have some file ending with _eigenvalues now and I
> would like to know which one to set as the main file. I am not
> familiar with AUnit.
The new subprogram is in src/ada_numerics-generic_arrays.ad[bs] with the
others. Compiling test_extensions.adb using test_extensions.gpr will go
ahead and build it with the new library source.
Unfortunately I forgot to update test_extensions.adb to use the new
subprogram; so there are no hints about the calling sequence. You can
see how it works in test/real_generalized_eigenvalues.adb (eg, line
361).
As I think I've said before, test_extensions.adb should really be called
demonstrate_extensions.adb; a test program really ought to state the
expected results!
> Best wishes for the end-of-year festivities
Thanks very much! and the same to you ...
Ada novice
> Unfortunately I forgot to update test_extensions.adb to use the new
> subprogram; so there are no hints about the calling sequence. You can
> see how it works in test/real_generalized_eigenvalues.adb (eg, line
> 361).
Thanks Simon. I shall study the above fie.
Cheers
YC
Brad Moore
http://paraffin.sourceforge.net/
It provides generics for adding parallelism to loops and recursive
structures.
For iterative parallelism there are
work-sharing, work-seeking, and work-stealing forms.
For recursive parallelism there are
work-sharing and and work seeking forms.
Also, the recursive parallelism can provide stack-safe recursion that
avoids stack overflow.
The stack safe recursion generics provide this capability even if
used on a single processor.
Any feedback is greatly appreciated.
Brad Moore
R. Tyler Croy
The site has a sourceforge placeholder page in place, and the SVN repo is
empty:
http://paraffin.svn.sourceforge.net/viewvc/paraffin/
Where's the beef? :)
--
- R. Tyler Croy
--------------------------------------
Code: http://github.com/rtyler
Georg Bauhaus
>
> The site has a sourceforge placeholder page in place, and the SVN repo is
> empty:
> http://paraffin.svn.sourceforge.net/viewvc/paraffin/
> Where's the beef? :)
>
My browsing software was directed to here:
http://sourceforge.net/projects/paraffin/
and here:
http://sourceforge.net/projects/paraffin/files/
All files available in one single compressed archive,
very effective, and inclusive ;-)
R. Tyler Croy
Yes, I saw that, I was more curious why the source is only distributed via
compressed archives instead of imported into a public version control system.
Yannick Duchêne (Hibou57)
écrit:
> The initial release of paraffin is available at
>
> http://paraffin.sourceforge.net/
Thanks, this must be fun. Hope I will have some comments to send to you,
as you expressed your express enjoyment about it :)
--
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour
les chiens.
“I am fluent in ASCII” [Warren 2010]
Yannick Duchêne (Hibou57)
écrit:
> The initial release of paraffin is available at
>
> http://paraffin.sourceforge.net/
Wanted to link to that thread, but surprisingly, this one does not appears
in Google Group (strange).
Brad Moore
> Georg Bauhaus<rm-host...@maps.futureapps.de> wrote:
>> On 1/25/11 10:06 PM, R. Tyler Croy wrote:
>>
>>>
>>> The site has a sourceforge placeholder page in place, and the SVN repo is
>>> empty:
>>> http://paraffin.svn.sourceforge.net/viewvc/paraffin/
>>> Where's the beef? :)
>>>
>>
>> My browsing software was directed to here:
>> http://sourceforge.net/projects/paraffin/
>> and here:
>> http://sourceforge.net/projects/paraffin/files/
>>
>> All files available in one single compressed archive,
>> very effective, and inclusive ;-)
>
> Yes, I saw that, I was more curious why the source is only distributed via
> compressed archives instead of imported into a public version control system.
>
>
No particular reason, I suppose. This is my first release of a project
on source forge. I checked out several other Ada open source projects,
and that seemed to be the approach taken elsewhere. If it makes sense to
release in another manner, I am open to considering that. One issue I
think with releasing in a public version control system, is choosing
which one. There are a number of them out there.
Yannick Duchêne (Hibou57)
écrit:
> No particular reason, I suppose. This is my first release of a project
> on source forge. I checked out several other Ada open source projects,
> and that seemed to be the approach taken elsewhere. If it makes sense to
> release in another manner, I am open to considering that. One issue I
> think with releasing in a public version control system, is choosing
> which one. There are a number of them out there.
one (no need for a repository war the same there was a browser war). Also
an archive is better suited for personal storage (at the user side) than a
versioning system is. Unless one plan to be involved in the development, a
versioning system tree is more uselessly-heavy and encumbered than useful.
Brad Moore
> Le Wed, 26 Jan 2011 02:53:39 +0100, Brad Moore <brad....@shaw.ca> a
> écrit:
>> No particular reason, I suppose. This is my first release of a project
>> on source forge. I checked out several other Ada open source projects,
>> and that seemed to be the approach taken elsewhere. If it makes sense to
>> release in another manner, I am open to considering that. One issue I
>> think with releasing in a public version control system, is choosing
>> which one. There are a number of them out there.
> You can safely keep going with a single archive: that's handy for every
> one (no need for a repository war the same there was a browser war).
> Also an archive is better suited for personal storage (at the user side)
> than a versioning system is. Unless one plan to be involved in the
> development, a versioning system tree is more uselessly-heavy and
> encumbered than useful.
>
Good points. The single archive approach seemed easiest to me,
and it still sounds like the way to go.
R. Tyler Croy
> Le Wed, 26 Jan 2011 02:53:39 +0100, Brad Moore <brad....@shaw.ca> a
> écrit:
>> No particular reason, I suppose. This is my first release of a project
>> on source forge. I checked out several other Ada open source projects,
>> and that seemed to be the approach taken elsewhere. If it makes sense to
>> release in another manner, I am open to considering that. One issue I
>> think with releasing in a public version control system, is choosing
>> which one. There are a number of them out there.
> You can safely keep going with a single archive: that's handy for every
> one (no need for a repository war the same there was a browser war). Also
> an archive is better suited for personal storage (at the user side) than a
> versioning system is. Unless one plan to be involved in the development, a
> versioning system tree is more uselessly-heavy and encumbered than useful.
O_o
I've heard a lot of things, but I don't think I've ever heard an argument
against version control before!
I personally don't care which kind of repository somebody uses, but I've found
myself after very weary of the "just download this tarball" approach after
years of finding interesting looking projects which have stagnated and become
completely out of date that have no publicly visible source history (student or
university projects are notoriously bad on this).
I don't mean to get too far off-topic, to each their own, I just find it odd
that one would go through the trouble of creating a SourceForge project just to
distribute tarballs.
Simon Wright
> I've heard a lot of things, but I don't think I've ever heard an
> argument against version control before!
>
> I personally don't care which kind of repository somebody uses, but
> I've found myself after very weary of the "just download this tarball"
> approach after years of finding interesting looking projects which
> have stagnated and become completely out of date that have no publicly
> visible source history (student or university projects are notoriously
> bad on this).
>
> I don't mean to get too far off-topic, to each their own, I just find
> it odd that one would go through the trouble of creating a SourceForge
> project just to distribute tarballs.
I completely agree with this.
Some sort of VCS is vital in any development, even if on one machine
only; and nowadays there are distributed VCSs which give even a
single-handed development the benefit of VC both locally (eg, while
disconnected from the network) and on a network host. [Not so say there
aren't other advantages.]
SourceForge supports Mercurial (which I like) and Git; others include
Monotone and Bazaar.
Brad Moore
I also think version control is important, so I am not arguing against
it. In fact, the tar-ball approach itself can be a form of version
control, so long as the older tar balls are still accessible, and the
newer ones are numbered so that its easy to see the sequence.
I am currently using git for version control on all my stuff, so at
least I'm able to see the history of each file.
Whether the real version control should be publicly visible is another
question.
I think the benefits for that depends more on the nature of the project.
If its a larger project being developed and maintained by an active
online community then I would think a public version control would be
beneficial.
If it is a smaller project however, then it may not be worth the trouble
setting the version control up, if the only person maintaining the
software is the author.
For example if my project were to somehow pickup momentum and people
were expressing interest in getting involved then I would consider
setting up the version control for that project to facilitate the
development process. Until I see a need, I would likely opt to go with
the simpler approach.
Yannick Duchêne (Hibou57)
écrit:
>> You can safely keep going with a single archive: that's handy for every
>> one (no need for a repository war the same there was a browser war).
>> Also
>> an archive is better suited for personal storage (at the user side)
>> than a
>> versioning system is. Unless one plan to be involved in the
>> development, a
>> versioning system tree is more uselessly-heavy and encumbered than
>> useful.
>
> O_o
>
> I've heard a lot of things, but I don't think I've ever heard an argument
> against version control before!
This was not advocating against CVS in a fundamental way.