It sounds like a good Idea to me since some time in the near future I hope to
have a " PDL::QC " module or Quantum Chemistry Module
and it would allow it to be tested before moving to the core for different
operating systems,
I really hope that chemist's experimenters in the real world, can help me to
refine it by giving me feed back on
the predictions, and how close they were , which I hope might work it's way
into another part of the PDL::Xprt::QC
so that they can upload results,.. from experiments and simulations probably in
Parallel Coordinates system
just cause it would be easier for my brain to think about , and the system
could be almost automated that way
I hope I can get some BioPerl people to do some experiments too, with the
module, I dont know what there using now
but I know that it would probably need Cuda or Tesla support, ... as my
Optical FPU, is still a baby...
any word on the Sprite3D() functionality ???
Cheers
Mark R Baker
________________________________
From: David Mertens <[email protected]>
To: Joel Berger <[email protected]>
Cc: [email protected]
Sent: Thursday, December 22, 2011 10:52 AM
Subject: Re: [Perldl] other PDL modules for PDL-2.4.10 docs
/me opens can of worms
Joel -
We discussed lowering the barrier of of distributing user code a couple
of years back. The relevant discussion can be found here:
http://mailman.jach.hawaii.edu/pipermail/perldl/2010-April/002796.html. (Note
that clicking 'Next Message' does not go in chronological order, so the
messages may be a bit confusing.)
My half-implemented solution that arose from this discussion was PDL::Expt.
Check out https://github.com/run4flat/PDL-Expt, especially
https://github.com/run4flat/PDL-Expt/blob/master/lib/PDL/Expt.pm and
https://github.com/run4flat/PDL-Expt/blob/master/lib/PDL/Expt/Philosophy.pod.
The difference, of course, is that your distribution is on CPAN and my
distribution never actually reached the point of working. :-)
Which brings me to a proposal. Perhaps I could finally polish up PDL::Expt and
get it working. People could submit their ideas to PDL::Expt, the only
requirement being that their code works and it has documentation. If their
ideas turn out to be really useful, we could bring them into PDL::Utils, which
would also require a full test suite and a soft commitment to a stable API. If
a function in PDL::Util has proven it can pass its tests, the author can
request that it be brought into PDL's core, with the additional requirement
that the module's API will be fixed forever. This would make PDL::Utils the
intermediate stepping-stone to getting something into the core, with maximum
flexibility at the start and maximum stability for the core. The goal is that
by the time the module reaches core, (1) it is well documented, (2) it has a
well-developed test suite, and (3) it has a stable, well-thought out API.
Thoughts?
On Thu, Dec 22, 2011 at 8:57 AM, Joel Berger <[email protected]> wrote:
I appologize, one thing slipped through my copy-paste from L::MU, here
>is the corrected snippet.
>
>
>L<PDL::Util> provides convenient utility functions and methods for use
>with PDL. Much like its inspiration L<List::MoreUtils>, it is intended
>to provide some trivial but commonly needed functionality on PDL objects
>
>which is not going to go into the PDL core. The author intends this to
>be a community module; if you find yourself often using a certain
>hand-rolled PDL method or function, consider submitting it for
>inclusion at L<http://github.com/jberger/PDL-Util>. The community will
>benefit and you can stop repeating yourself! Futher, it can be an easy
>way for new PDL/Perl/Open Source programmers to get their feet wet in
>contributing code.
>
>Ok so I added a sentance at the end too, is it good should it stay?
>
>Cheers (again),
>Joel
>
>
>On Thu, Dec 22, 2011 at 8:52 AM, Joel Berger <[email protected]> wrote:
>> Here's a blub on PDL::Util. Note that I am considering removing
>> PDL::IO::Export2D entirely, so perhaps it ought not to be mentioned at
>> all.
>>
>> L<PDL::Util> provides convenient utility functions and methods for use
>> with PDL. Much like its inspiration L<List::MoreUtils>, it is intended
>> to provide some trivial but commonly needed functionality on lists
>> which is not going to go into the PDL core. The author intends this to
>> be a community module; if you find yourself often using a certain
>> hand-rolled PDL method or function, consider submitting it for
>> inclusion at L<http://github.com/jberger/PDL-Util>. The community will
>> benefit and you can stop repeating yourself!
>>
>> Cheers,
>> Joel Berger
>>
>> On Tue, Dec 20, 2011 at 7:37 AM, chm <[email protected]> wrote:
>>> On 12/20/2011 6:25 AM, Bryan Jurish wrote:
>>>>
>>>> morning all,
>>>>
>>>> On 2011-12-18 22:56, chm wrote:
>>>>>
>>>>> For the PDL-2.4.10 release, I would like to add
>>>>> documentation on PDL modules that are not part of
>>>>> the main PDL distribution. The idea is to make
>>>>> it easier for PDL users to find the modules they
>>>>> need to get things done.
>>>>
>>>>
>>>> Sounds like a good idea to me.
>>>>
>>>>> Fails tests:
>>>>>>
>>>>>> MOOCOW/PDL-CCS-1.14.tar.gz (requires PDL::VectorValued)
>>>>
>>>>
>>>> Should be fixed (band-aided) in newest PDL::CCS on CPAN
>>>> (MOOCOW/PDL-CCS-1.15.tar.gz). The culprit seems to have been a change
>>>> in the PDL core's handling of Nx0 piddles somewhere between 2.4.9 and
>>>> 2.4.9_015. Report filed as sourceforge bug #3462924
>>>>
>>>> (https://sourceforge.net/tracker/?func=detail&aid=3462924&group_id=612&atid=100612).
>>>> This is a degenerate case, but it can easily happen in PDL::CCS (sparse
>>>> piddles) as a result of run-of-the-mill internal index-piddle twiddling.
>>>
>>>
>>> Hi Bryan-
>>>
>>> I'm not sure I comprehend what a [2,0] shaped
>>> piddle means. My first thought is that it
>>> should not be returned by dice_axis at all.
>>>
>>> There have been some changes to PDL since 2.4.9
>>> in *exactly* those edge cases. But the previous
>>> handling caused segfaults in perl. I would like
>>> for some feedback from the range-master based
>>> on further discussion.
>>>
>>> Maybe you could post separately to the mailing
>>> list with some examples showing where non-trivial
>>> 0 length dimensions were supported, how they
>>> arise in practice... In particular, is there
>>> different code approaches that could work?
>>>
>>>
>>>>> For the upcoming PDL-2.4.10 release, I ask the
>>>>> authors for a brief write-up/example/intro to
>>>>> their module.
>>>>
>>>>
>>>> Sure. Assumedly as POD? Would you like descriptions sent straight to
>>>> you, posted to the list, or checked in to e.g. sourceforge git somewhere?
>>>
>>>
>>> POD would be good. Haven't set things up yet but
>>> if you wish to send it to me, I'll be sure to get
>>> it up when that happens.
>>>
>>> Look forward to the separate list discussion of
>>> [2,0] shaped piddles to come. This is important
>>> to resolve before PDL-2.4.10.
>>>
>>> Cheers,
>>> Chris
>>>
>>>> marmosets,
>>>> Bryan
>>>>
>>>
>>>
>>> _______________________________________________
>>> Perldl mailing list
>>> [email protected]
>>> http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
>
>_______________________________________________
>Perldl mailing list
>[email protected]
>http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
>
--
Sent via my carrier pigeon.
_______________________________________________
Perldl mailing list
[email protected]
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
_______________________________________________
Perldl mailing list
[email protected]
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
