CTABLES

[John Darrington]

Funding the implementation of a fully blown CTABLES at commercial rates,
I think would cost well into 5 figures.

However, it is perhaps possible, that a smaller subset of CTABLES could
be undertaken by an altruistic programmer who has some time on his
hands and wishes to earn a bit of money for a few months.

The problem, is (and this is where big companies have the advantage) most
programmers are not good administrators. To crowdfund such an exercise
one would first have to agree on which subset of CTABLES to undertake.
That means, a detailed specification, with examples showing exactly what
would be expected, which features of CTABLES should be included, and perhaps
more importantly, which are not expected. Once that has been agreed,
an estimate of the time and cost could be prepared an appeal for funds could begin.
This kind of organisation, takes skill and effort, and would probably
have no tangible reward, unless some percentage of the total was agreed
beforehand.

J'


--
Avoid eavesdropping. Send strong encryted email.
PGP Public key ID: 1024D/2DE827B3
fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.

[Matthias Faeth]

I think we have to find somebody who has done that kind of project steering
before (I haven't). Can everybody look into their contacts to find somebody
who would have the skills and will to steer such a project?

However I'd volunteer to participate in the workgroup defining the priority
of the functions of the CTABLES command. Maybe Frans and Alan would want to
join?

I agree with John that a commercial implementation would produce 5 figured
cost. I've already talked to a programmer on this and he came up with the
same estimate. So doing it commercially seems to be no way forward.

Matthias FÀth
Im Mediapark 12
50670 Köln
t: 0221-2907973
m: 0171-9832175
e: ***@gmx.de

2015-11-07 7:19 GMT+01:00 John Darrington <***@darrington.wattle.id.au>:

> Funding the implementation of a fully blown CTABLES at commercial rates,
> I think would cost well into 5 figures.
>
> However, it is perhaps possible, that a smaller subset of CTABLES could
> be undertaken by an altruistic programmer who has some time on his
> hands and wishes to earn a bit of money for a few months.
>
> The problem, is (and this is where big companies have the advantage) most
> programmers are not good administrators. To crowdfund such an exercise
> one would first have to agree on which subset of CTABLES to undertake.
> That means, a detailed specification, with examples showing exactly what
> would be expected, which features of CTABLES should be included, and
> perhaps
> more importantly, which are not expected. Once that has been agreed,
> an estimate of the time and cost could be prepared an appeal for funds
> could begin.
> This kind of organisation, takes skill and effort, and would probably
> have no tangible reward, unless some percentage of the total was agreed
> beforehand.
>
> J'
>
>
> --
> Avoid eavesdropping. Send strong encryted email.
> PGP Public key ID: 1024D/2DE827B3
> fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3
> See http://sks-keyservers.net or any PGP keyserver for public key.
>
>
> _______________________________________________
> Pspp-users mailing list
> Pspp-***@gnu.org
> https://lists.gnu.org/mailman/listinfo/pspp-users
>
>

[Charles Johnson]

If the developers agree, it could generate a funding campaign to implement the command CTABLES on PSPP.

While donations are received, a team can define the characteristics to be implemented and its estimated price.


CJT


________________________________
> Date: Sat, 7 Nov 2015 12:22:10 +0100
> Subject: Re: CTABLES
> From: ***@gmx.de
> To: ***@darrington.wattle.id.au; pspp-***@gnu.org
>
> I think we have to find somebody who has done that kind of project
> steering before (I haven't). Can everybody look into their contacts to
> find somebody who would have the skills and will to steer such a
> project?
>
> However I'd volunteer to participate in the workgroup defining the
> priority of the functions of the CTABLES command. Maybe Frans and Alan
> would want to join?
>
> I agree with John that a commercial implementation would produce 5
> figured cost. I've already talked to a programmer on this and he came
> up with the same estimate. So doing it commercially seems to be no way
> forward.
>
> Matthias Fäth
> Im Mediapark 12
> 50670 Köln
> t: 0221-2907973
> m: 0171-9832175
> e: ***@gmx.de<mailto:***@gmx.de>
>
> 2015-11-07 7:19 GMT+01:00 John Darrington
> <***@darrington.wattle.id.au<mailto:***@darrington.wattle.id.au>>:
> Funding the implementation of a fully blown CTABLES at commercial rates,
> I think would cost well into 5 figures.
>
> However, it is perhaps possible, that a smaller subset of CTABLES could
> be undertaken by an altruistic programmer who has some time on his
> hands and wishes to earn a bit of money for a few months.
>
> The problem, is (and this is where big companies have the advantage) most
> programmers are not good administrators. To crowdfund such an exercise
> one would first have to agree on which subset of CTABLES to undertake.
> That means, a detailed specification, with examples showing exactly what
> would be expected, which features of CTABLES should be included, and perhaps
> more importantly, which are not expected. Once that has been agreed,
> an estimate of the time and cost could be prepared an appeal for funds
> could begin.
> This kind of organisation, takes skill and effort, and would probably
> have no tangible reward, unless some percentage of the total was agreed
> beforehand.
>
> J'
>
>
> --
> Avoid eavesdropping. Send strong encryted email.
> PGP Public key ID: 1024D/2DE827B3
> fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3
> See http://sks-keyservers.net or any PGP keyserver for public key.
>
>
> _______________________________________________
> Pspp-users mailing list
> Pspp-***@gnu.org<mailto:Pspp-***@gnu.org>
> https://lists.gnu.org/mailman/listinfo/pspp-users
>
>
>
> _______________________________________________ Pspp-users mailing list
> Pspp-***@gnu.org https://lists.gnu.org/mailman/listinfo/pspp-users

[Alan Mead]

What does CTABLES do? And what aspects of CTABLES would be critical for
users? I think a plan should be the first step. If CTABLES were part of
PSPP, is the output OK? Or would that be the next hurdle to using PSPP
that the output isn't the same as SPSS (e.g., I find it harder to
copy-and-paste from PSPP into LibreOffice than SPSS; when you copy a
chart from SPSS for Windows, it's actually placing several versions of
the chart in the paste buffer). If the output won't ultimately be
useable, that makes adding CTABLES a waste of time...

Also, I'm sure CTABLES is very important to some people but a lot of
SPSS users probably have never used CTABLES (just like they've never
used any of the other special modules SPSS publishes or even the new
features like python scripting). I think that contributes to its absence
in PSPP.

Finally, I know how statistics are calculated, but not only don't I know
what CTABLES does but I understand that the emphasis is on simply
tallies across complex breakdowns... I don't have any feel for how one
efficiently does this in code.

BTW, I think a better big project would be to enable PSPP to read the
SPSS output format. I know Ben enjoys reverse engineering things.
Thanks largely to Ben and PSPP contributors, the SPSS file format is
widely read (e.g., the R foreign package is based on Ben's code to read
SPSS .SAV files) but the output is completely opaque to all programs
except SPSS. In fact, it's worse than that because there are versions of
SPSS that won't read other versions. That's actually a huge problem for
people who used SPSS to analyze data and all they kept was the output
files or anyone who ever saved the output in the hope that they could
read it years later....

-Alan


On 11/7/2015 5:22 AM, Matthias Faeth wrote:
> I think we have to find somebody who has done that kind of project
> steering before (I haven't). Can everybody look into their contacts to
> find somebody who would have the skills and will to steer such a project?
>
> However I'd volunteer to participate in the workgroup defining the
> priority of the functions of the CTABLES command. Maybe Frans and Alan
> would want to join?
>
> I agree with John that a commercial implementation would produce 5
> figured cost. I've already talked to a programmer on this and he came
> up with the same estimate. So doing it commercially seems to be no way
> forward.
>
> Matthias Fäth
> Im Mediapark 12
> 50670 Köln
> t: 0221-2907973
> m: 0171-9832175
> e: ***@gmx.de <mailto:***@gmx.de>
>
> 2015-11-07 7:19 GMT+01:00 John Darrington
> <***@darrington.wattle.id.au <mailto:***@darrington.wattle.id.au>>:
>
> Funding the implementation of a fully blown CTABLES at commercial
> rates,
> I think would cost well into 5 figures.
>
> However, it is perhaps possible, that a smaller subset of CTABLES
> could
> be undertaken by an altruistic programmer who has some time on his
> hands and wishes to earn a bit of money for a few months.
>
> The problem, is (and this is where big companies have the
> advantage) most
> programmers are not good administrators. To crowdfund such an
> exercise
> one would first have to agree on which subset of CTABLES to undertake.
> That means, a detailed specification, with examples showing
> exactly what
> would be expected, which features of CTABLES should be included,
> and perhaps
> more importantly, which are not expected. Once that has been agreed,
> an estimate of the time and cost could be prepared an appeal for
> funds could begin.
> This kind of organisation, takes skill and effort, and would probably
> have no tangible reward, unless some percentage of the total was
> agreed
> beforehand.
>
> J'
>
>
> --
> Avoid eavesdropping. Send strong encryted email.
> PGP Public key ID: 1024D/2DE827B3
> fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3
> See http://sks-keyservers.net or any PGP keyserver for public key.
>
>
> _______________________________________________
> Pspp-users mailing list
> Pspp-***@gnu.org <mailto:Pspp-***@gnu.org>
> https://lists.gnu.org/mailman/listinfo/pspp-users
>
>
>
>
> _______________________________________________
> Pspp-users mailing list
> Pspp-***@gnu.org
> https://lists.gnu.org/mailman/listinfo/pspp-users

--

Alan D. Mead, Ph.D.
President, Talent Algorithms Inc.

science + technology = better workers

+815.588.3846 (Office)
+267.334.4143 (Mobile)

http://www.alanmead.org

Announcing the Journal of Computerized Adaptive Testing (JCAT), a
peer-reviewed electronic journal designed to advance the science and
practice of computerized adaptive testing: http://www.iacat.org/jcat

[Frans Houweling]

_______________________________________________
Pspp-users mailing list
Pspp-***@gnu.org
https://lists.gnu.org/mailman/listinfo/pspp-users

[Charles Johnson]

@Frans
I do not think the discussion here is about other features. I think there's a group of people who could organize and work for CTABLES in PSPP.
Moreover, the macros are not an agnostic solution ... may be different languages to choose from and for the end user means learning more than SPSS / PSPP to use a special function.

@Alan
Agree with you, the work done by Ben  is magnificent. If I'm not mistaken, only lack support for SPSS production job  and SPV files. Under the same argument, it would be very useful for all PSPP command had its counterpart in PSPPire.
But I insist that if there is a group interested in operating CTABLES, we must support it. Any further new feature compatible with SPSS should be welcomed.

Info: http://www-01.ibm.com/support/knowledgecenter/SSLVMB_21.0.0/com.ibm.spss.statistics.help/syn_ctables.htm


CJT


________________________________
> Subject: Re: CTABLES
> To: pspp-***@gnu.org
> From: ***@email.it
> Date: Sat, 7 Nov 2015 23:31:41 +0100
>
> Forgive me if I insist: (C)TABLES belongs to a time when we delivered
> mass "big banner" cross tabulations in an appendix for an end user who
> had no access to the data. I almost dare say it encourages bad
> practice.
> Since all of us seem to agree that aesthetics are not the reason for
> wanting CTABLES, why not concentrate on implementing macros instead? I
> believe it is possible to create tables of any complexity, through
> various stages of AGGREGATE.
> That's a pain, I agree, and that's where macros come in. Macros would
> allow dummies like me to contribute table formats (that's a promise),
> and to exchange contributions with the SPSS community.
> Last but not least, macros would be useful for a lot of other reasons
> anyway (as an example see the WRITE / INCLUDE in
> http://spsstools.net/en/syntax/24/).
> Regards
> frans
>
>
>
> On 07/11/2015 21:49, Alan Mead wrote:
> What does CTABLES do? And what aspects of CTABLES would be critical
> for users? I think a plan should be the first step. If CTABLES were
> part of PSPP, is the output OK? Or would that be the next hurdle to
> using PSPP that the output isn't the same as SPSS (e.g., I find it
> harder to copy-and-paste from PSPP into LibreOffice than SPSS; when you
> copy a chart from SPSS for Windows, it's actually placing several
> versions of the chart in the paste buffer). If the output won't
> ultimately be useable, that makes adding CTABLES a waste of time...
>
> Also, I'm sure CTABLES is very important to some people but a lot of
> SPSS users probably have never used CTABLES (just like they've never
> used any of the other special modules SPSS publishes or even the new
> features like python scripting). I think that contributes to its
> absence in PSPP.
>
> Finally, I know how statistics are calculated, but not only don't I
> know what CTABLES does but I understand that the emphasis is on simply
> tallies across complex breakdowns... I don't have any feel for how one
> efficiently does this in code.
>
> BTW, I think a better big project would be to enable PSPP to read the
> SPSS output format. I know Ben enjoys reverse engineering things.
> Thanks largely to Ben and PSPP contributors, the SPSS file format is
> widely read (e.g., the R foreign package is based on Ben's code to read
> SPSS .SAV files) but the output is completely opaque to all programs
> except SPSS. In fact, it's worse than that because there are versions
> of SPSS that won't read other versions. That's actually a huge problem
> for people who used SPSS to analyze data and all they kept was the
> output files or anyone who ever saved the output in the hope that they
> could read it years later....
>
> -Alan
>
>
> On 11/7/2015 5:22 AM, Matthias Faeth wrote:
> I think we have to find somebody who has done that kind of project
> steering before (I haven't). Can everybody look into their contacts to
> find somebody who would have the skills and will to steer such a
> project?
>
> However I'd volunteer to participate in the workgroup defining the
> priority of the functions of the CTABLES command. Maybe Frans and Alan
> would want to join?
>
> I agree with John that a commercial implementation would produce 5
> figured cost. I've already talked to a programmer on this and he came
> up with the same estimate. So doing it commercially seems to be no way
> forward.
>
> Matthias Fäth
> Im Mediapark 12
> 50670 Köln
> t: 0221-2907973
> m: 0171-9832175
> e: ***@gmx.de<mailto:***@gmx.de>
>
> 2015-11-07 7:19 GMT+01:00 John Darrington
> <***@darrington.wattle.id.au<mailto:***@darrington.wattle.id.au>>:
> Funding the implementation of a fully blown CTABLES at commercial rates,
> I think would cost well into 5 figures.
>
> However, it is perhaps possible, that a smaller subset of CTABLES could
> be undertaken by an altruistic programmer who has some time on his
> hands and wishes to earn a bit of money for a few months.
>
> The problem, is (and this is where big companies have the advantage) most
> programmers are not good administrators. To crowdfund such an exercise
> one would first have to agree on which subset of CTABLES to undertake.
> That means, a detailed specification, with examples showing exactly what
> would be expected, which features of CTABLES should be included, and perhaps
> more importantly, which are not expected. Once that has been agreed,
> an estimate of the time and cost could be prepared an appeal for funds
> could begin.
> This kind of organisation, takes skill and effort, and would probably
> have no tangible reward, unless some percentage of the total was agreed
> beforehand.
>
> J'
>
>
> --
> Avoid eavesdropping. Send strong encryted email.
> PGP Public key ID: 1024D/2DE827B3
> fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3
> See http://sks-keyservers.net or any PGP keyserver for public key.
>
>
> _______________________________________________
> Pspp-users mailing list
> Pspp-***@gnu.org<mailto:Pspp-***@gnu.org>
> https://lists.gnu.org/mailman/listinfo/pspp-users
>
>
>
>
>
> _______________________________________________
> Pspp-users mailing list
> Pspp-***@gnu.org<mailto:Pspp-***@gnu.org>
> https://lists.gnu.org/mailman/listinfo/pspp-users
>
>
>
> --
>
> Alan D. Mead, Ph.D.
> President, Talent Algorithms Inc.
>
> science + technology = better workers
>
> +815.588.3846 (Office)
> +267.334.4143 (Mobile)
>
> http://www.alanmead.org
>
> Announcing the Journal of Computerized Adaptive Testing (JCAT), a
> peer-reviewed electronic journal designed to advance the science and
> practice of computerized adaptive testing: http://www.iacat.org/jcat
>
>
>
> _______________________________________________
> Pspp-users mailing list
> Pspp-***@gnu.org<mailto:Pspp-***@gnu.org>
> https://lists.gnu.org/mailman/listinfo/pspp-users
>
>
>
> _______________________________________________ Pspp-users mailing list
> Pspp-***@gnu.org https://lists.gnu.org/mailman/listinfo/pspp-users

[Ben Pfaff]

On Sun, Nov 08, 2015 at 12:00:49AM +0000, Charles Johnson wrote:
> Agree with you, the work done by Ben  is magnificent. If I'm not
> mistaken, only lack support for SPSS production job  and SPV
> files. Under the same argument, it would be very useful for all PSPP
> command had its counterpart in PSPPire. But I insist that if there is
> a group interested in operating CTABLES, we must support it. Any
> further new feature compatible with SPSS should be welcomed.

I've done a lot of the work needed to figure out the format of SPV
files. I'm working on publishing a format specification. Then I'll
work on implementing a reader for it.

Would it be useful to add support for SPSS production job files? That
would not be hard (much easier than SPV files or CTABLES). I'd need a
bunch of examples of the format.

Thanks,

Ben.

[Charles Johnson]

----------------------------------------
> Date: Sat, 7 Nov 2015 17:03:01 -0800
> From: ***@cs.stanford.edu
> To: ***@outlook.com
> CC: ***@email.it; ***@gmx.de; ***@darrington.wattle.id.au; ***@consumerscan.ca; ***@free.fr; ***@alanmead.org; pspp-***@gnu.org
> Subject: Re: CTABLES
>
> I've done a lot of the work needed to figure out the format of SPV
> files. I'm working on publishing a format specification. Then I'll
> work on implementing a reader for it.
>

That is great news. If you need more files of type SPV/SPO could ask another topic of discussion.

> Would it be useful to add support for SPSS production job files? That
> would not be hard (much easier than SPV files or CTABLES). I'd need a
> bunch of examples of the format.
>

From my point of view, production jobs are very useful to automate lengthy and complex processes that are made recurrently. As PSPP add more commands, the more useful they will be in the future.

However, I think it may only be used interactively and locally directly or by creating a external automation script, and the second way is through the use of IBM SPSS Statistics Server.

Cheers

CJT

[Ben Pfaff]

On Sun, Nov 08, 2015 at 01:36:01AM +0000, Charles Johnson wrote:
> > Date: Sat, 7 Nov 2015 17:03:01 -0800
> > From: ***@cs.stanford.edu
> > To: ***@outlook.com
> > CC: ***@email.it; ***@gmx.de; ***@darrington.wattle.id.au; ***@consumerscan.ca; ***@free.fr; ***@alanmead.org; pspp-***@gnu.org
> > Subject: Re: CTABLES
> >
> > I've done a lot of the work needed to figure out the format of SPV
> > files. I'm working on publishing a format specification. Then I'll
> > work on implementing a reader for it.
>
> That is great news. If you need more files of type SPV/SPO could ask
> another topic of discussion.

At some point I'll need some more to answer a few lingering questions,
but I can already extract all of the important content.

> > Would it be useful to add support for SPSS production job files? That
> > would not be hard (much easier than SPV files or CTABLES). I'd need a
> > bunch of examples of the format.
>
> From my point of view, production jobs are very useful to automate
> lengthy and complex processes that are made recurrently. As PSPP add
> more commands, the more useful they will be in the future.

OK.

[Matthias Faeth]

I'm not sure if I get the discussion under the label CTABLES here: why
should "production jobs" replace CTABLES?

Or is it just that there are 3 open topics by now
1. CTABLES
2. Production jobs
3. Reading .spv files

and the discussion is on which to focus time and energy?

Anybody give me a hint, please.

Matthias

Matthias FÀth
Im Mediapark 12
50670 Köln
t: 0221-2907973
m: 0171-9832175
e: ***@gmx.de

2015-11-08 8:25 GMT+01:00 Ben Pfaff <***@cs.stanford.edu>:

> On Sun, Nov 08, 2015 at 01:36:01AM +0000, Charles Johnson wrote:
> > > Date: Sat, 7 Nov 2015 17:03:01 -0800
> > > From: ***@cs.stanford.edu
> > > To: ***@outlook.com
> > > CC: ***@email.it; ***@gmx.de; ***@darrington.wattle.id.au;
> ***@consumerscan.ca; ***@free.fr; ***@alanmead.org;
> pspp-***@gnu.org
> > > Subject: Re: CTABLES
> > >
> > > I've done a lot of the work needed to figure out the format of SPV
> > > files. I'm working on publishing a format specification. Then I'll
> > > work on implementing a reader for it.
> >
> > That is great news. If you need more files of type SPV/SPO could ask
> > another topic of discussion.
>
> At some point I'll need some more to answer a few lingering questions,
> but I can already extract all of the important content.
>
> > > Would it be useful to add support for SPSS production job files? That
> > > would not be hard (much easier than SPV files or CTABLES). I'd need a
> > > bunch of examples of the format.
> >
> > From my point of view, production jobs are very useful to automate
> > lengthy and complex processes that are made recurrently. As PSPP add
> > more commands, the more useful they will be in the future.
>
> OK.
>

[Crichton, Ronald]

I’m posting this from what you might consider ‘bystander status’ only. I read the posts because I once used PSPP regularly. I never used PSPP as a statistical tool but used it to assist me in manipulating data. I work at an educational institution and my job as statistics officer is more about passing on student data than doing any research. (I suspect most of the people I provide information to would not know a statistical test if it got off the paper and bit them on the bum.) As part of the job I need summary information of our enrolments for my own needs and in response from requests from others (mainly counts or sums, sometimes means or percentages) and never more sophisticated than that.

PSPP has limited capability to summarise data in the way I need it. It worked very well to manipulate data. Consequently, I persuaded my boss to buy SPSS. I wanted SPSS because of my previous experience in SPSS using TABLES, and that was the prime reason form moving away from PSPP to SPSS. Unfortunately, SPSS does not offer TABLES and has implemented CTABLES instead.

I have to admit to not being particularly impressed by CTABLES. Perhaps I just need more practice using it as some of the SPSS gurus think it’s the bees knees. I much preferred the old TABLES that I used to use with SPSS v10. I prefer to write code that point and click, and CTABLES is bit of a challenge in that regard whereas TABLES was quite simple.

I will move back to PSPP when a version of (C)TABLES is installed.

Regards, Ron

From: pspp-users-bounces+ronald.crichton=***@gnu.org [mailto:pspp-users-bounces+ronald.crichton=***@gnu.org] On Behalf Of Matthias Faeth
Sent: Monday, 9 November 2015 4:20 AM
To: Ben Pfaff
Cc: pspp-***@gnu.org
Subject: Re: CTABLES

I'm not sure if I get the discussion under the label CTABLES here: why should "production jobs" replace CTABLES?
Or is it just that there are 3 open topics by now
1. CTABLES
2. Production jobs
3. Reading .spv files
and the discussion is on which to focus time and energy?
Anybody give me a hint, please.
Matthias

Matthias FÀth
Im Mediapark 12
50670 Köln
t: 0221-2907973
m: 0171-9832175
e: ***@gmx.de<mailto:***@gmx.de>

2015-11-08 8:25 GMT+01:00 Ben Pfaff <***@cs.stanford.edu<mailto:***@cs.stanford.edu>>:
On Sun, Nov 08, 2015 at 01:36:01AM +0000, Charles Johnson wrote:
> > Date: Sat, 7 Nov 2015 17:03:01 -0800
> > From: ***@cs.stanford.edu<mailto:***@cs.stanford.edu>
> > To: ***@outlook.com<mailto:***@outlook.com>
> > CC: ***@email.it<mailto:***@email.it>; ***@gmx.de<mailto:***@gmx.de>; ***@darrington.wattle.id.au<mailto:***@darrington.wattle.id.au>; ***@consumerscan.ca<mailto:***@consumerscan.ca>; ***@free.fr<mailto:***@free.fr>; ***@alanmead.org<mailto:***@alanmead.org>; pspp-***@gnu.org<mailto:pspp-***@gnu.org>
> > Subject: Re: CTABLES
> >
> > I've done a lot of the work needed to figure out the format of SPV
> > files. I'm working on publishing a format specification. Then I'll
> > work on implementing a reader for it.
>
> That is great news. If you need more files of type SPV/SPO could ask
> another topic of discussion.

At some point I'll need some more to answer a few lingering questions,
but I can already extract all of the important content.

> > Would it be useful to add support for SPSS production job files? That
> > would not be hard (much easier than SPV files or CTABLES). I'd need a
> > bunch of examples of the format.
>
> From my point of view, production jobs are very useful to automate
> lengthy and complex processes that are made recurrently. As PSPP add
> more commands, the more useful they will be in the future.

OK.



CIT is the ACT Large Training Provider of the Year.
Subscribe to CIT Industry Connection - CIT's free, bi monthly publication:
http://cit.edu.au/industry_business/industry_connection/

-----------------------------------------------------------------------
This email, and any attachments, may be confidential and also privileged. If you are not the intended recipient, please notify the sender and delete all copies of this transmission along with any attachments immediately. You should not copy or use it for any purpose, nor disclose its contents to any other person.
-----------------------------------------------------------------------

[Ben Pfaff]

On Sun, Nov 08, 2015 at 06:20:25PM +0100, Matthias Faeth wrote:
> I'm not sure if I get the discussion under the label CTABLES here: why
> should "production jobs" replace CTABLES?
>
> Or is it just that there are 3 open topics by now
> 1. CTABLES
> 2. Production jobs
> 3. Reading .spv files
>
> and the discussion is on which to focus time and energy?

Production jobs are a separate topic, and John has changed the subject
for the emails that focus on production jobs (thanks, John).

SPV files have more to do with CTABLES than you may realize. CTABLES is
a heavy-duty application of pivot tables. It relies on a lot of
features that aren't well documented for SPSS; the various SPSS
explanations of pivot tables are terribly vague. The SPV file format,
however, is a pretty clear specification for how SPSS pivot tables
really work, and once I came to learn about it in detail I understood
much better how output formatting really works. So this is an essential
building block for CTABLES and will be important for eventually
implementing it.

[Matthias Faeth]

Hi Ben

Thanks for the comprehensive explanation why CTABLES depend on the ability
to read SPV files. Do I understand correctly that this dependency comes
only from the pivot-function in the SPV file - meaning that you doubleclick
on a table to change pages?

I mean by that the following: The syntax of CTABLES is:
"CTABLES downvariable BY acrossvariable BY pagevariable"
Pages are shown in the SPV file only by doubleclicking and choosing another
page.

The function is a pain anyway because it is uncomfortable and also (at
least for me) not working under all circumstances. So I can confirm Alans
arguments on this although I have no idea why rendering a new page is not
always working.

To come back to the topic of implementing CTABLES:
1. Can we avoid the dependency on understanding SPV if we strip the CTABLES
command of the page function? So to support only 2 dimensions in the
output? This is probably what most users need.

2. Or do you think that is not worth to do, because once the SPV issue is
solved the whole CTABLES output would have to be reprogrammed? Or are there
other functions of the CTABLES command (like plots or graphs) that depend
on the SPV issue, too?

3. As I do not have any knowledge about TABLES: does TABLES have the same
dependencies on pivot and SPV? Would it be a solution to come back to the
proposal of ftr and Frans to opt for TABLES instead of CTABLES?

Matthias FÀth
Im Mediapark 12
50670 Köln
t: 0221-2907973
m: 0171-9832175
e: ***@gmx.de

2015-11-08 23:54 GMT+01:00 Ben Pfaff <***@cs.stanford.edu>:

> On Sun, Nov 08, 2015 at 06:20:25PM +0100, Matthias Faeth wrote:
> > I'm not sure if I get the discussion under the label CTABLES here: why
> > should "production jobs" replace CTABLES?
> >
> > Or is it just that there are 3 open topics by now
> > 1. CTABLES
> > 2. Production jobs
> > 3. Reading .spv files
> >
> > and the discussion is on which to focus time and energy?
>
> Production jobs are a separate topic, and John has changed the subject
> for the emails that focus on production jobs (thanks, John).
>
> SPV files have more to do with CTABLES than you may realize. CTABLES is
> a heavy-duty application of pivot tables. It relies on a lot of
> features that aren't well documented for SPSS; the various SPSS
> explanations of pivot tables are terribly vague. The SPV file format,
> however, is a pretty clear specification for how SPSS pivot tables
> really work, and once I came to learn about it in detail I understood
> much better how output formatting really works. So this is an essential
> building block for CTABLES and will be important for eventually
> implementing it.
>

[Ben Pfaff]

On Mon, Nov 09, 2015 at 10:28:30AM +0100, Matthias Faeth wrote:
> Thanks for the comprehensive explanation why CTABLES depend on the ability
> to read SPV files. Do I understand correctly that this dependency comes
> only from the pivot-function in the SPV file - meaning that you doubleclick
> on a table to change pages?
>
> I mean by that the following: The syntax of CTABLES is:
> "CTABLES downvariable BY acrossvariable BY pagevariable"
> Pages are shown in the SPV file only by doubleclicking and choosing another
> page.
>
> The function is a pain anyway because it is uncomfortable and also (at
> least for me) not working under all circumstances. So I can confirm Alans
> arguments on this although I have no idea why rendering a new page is not
> always working.
>
> To come back to the topic of implementing CTABLES:
> 1. Can we avoid the dependency on understanding SPV if we strip the CTABLES
> command of the page function? So to support only 2 dimensions in the
> output? This is probably what most users need.

Pivot tables are a lot more than just pages, and CTABLES is pretty tied
up with the pivot functionality.

> 2. Or do you think that is not worth to do, because once the SPV issue is
> solved the whole CTABLES output would have to be reprogrammed? Or are there
> other functions of the CTABLES command (like plots or graphs) that depend
> on the SPV issue, too?

This may be an issue, too, although I doubt that plots or graphs would
be in a first draft of the CTABLES functionality.

> 3. As I do not have any knowledge about TABLES: does TABLES have the same
> dependencies on pivot and SPV? Would it be a solution to come back to the
> proposal of ftr and Frans to opt for TABLES instead of CTABLES?

I haven't studied TABLES in the way I have CTABLES. I suspect that
users are more interested in the latter, because it's come up again and
again over the last few years, whereas the former has hardly been
mentioned.

[Matthias Faeth]

ok. That means for me, that we should abort the request for CTABLES until
the SPV issue is solved.

1. Has anybody a different opinion?
2. Ben, do you have any idea about the time needed so that we do not rise
the issue with CTABLES again and again?
3. Maybe Frans idea about implementing !Macros could serve as a workaround.
I think that might be worthwhile to discuss. Any opinions on that?



Matthias FÀth
Im Mediapark 12
50670 Köln
t: 0221-2907973
m: 0171-9832175
e: ***@gmx.de

2015-11-09 16:06 GMT+01:00 Ben Pfaff <***@cs.stanford.edu>:

> On Mon, Nov 09, 2015 at 10:28:30AM +0100, Matthias Faeth wrote:
> > Thanks for the comprehensive explanation why CTABLES depend on the
> ability
> > to read SPV files. Do I understand correctly that this dependency comes
> > only from the pivot-function in the SPV file - meaning that you
> doubleclick
> > on a table to change pages?
> >
> > I mean by that the following: The syntax of CTABLES is:
> > "CTABLES downvariable BY acrossvariable BY pagevariable"
> > Pages are shown in the SPV file only by doubleclicking and choosing
> another
> > page.
> >
> > The function is a pain anyway because it is uncomfortable and also (at
> > least for me) not working under all circumstances. So I can confirm Alans
> > arguments on this although I have no idea why rendering a new page is not
> > always working.
> >
> > To come back to the topic of implementing CTABLES:
> > 1. Can we avoid the dependency on understanding SPV if we strip the
> CTABLES
> > command of the page function? So to support only 2 dimensions in the
> > output? This is probably what most users need.
>
> Pivot tables are a lot more than just pages, and CTABLES is pretty tied
> up with the pivot functionality.
>
> > 2. Or do you think that is not worth to do, because once the SPV issue is
> > solved the whole CTABLES output would have to be reprogrammed? Or are
> there
> > other functions of the CTABLES command (like plots or graphs) that depend
> > on the SPV issue, too?
>
> This may be an issue, too, although I doubt that plots or graphs would
> be in a first draft of the CTABLES functionality.
>
> > 3. As I do not have any knowledge about TABLES: does TABLES have the same
> > dependencies on pivot and SPV? Would it be a solution to come back to the
> > proposal of ftr and Frans to opt for TABLES instead of CTABLES?
>
> I haven't studied TABLES in the way I have CTABLES. I suspect that
> users are more interested in the latter, because it's come up again and
> again over the last few years, whereas the former has hardly been
> mentioned.
>

[Charles Johnson]

________________________________
> Date: Mon, 9 Nov 2015 16:53:41 +0100
> Subject: Re: CTABLES
> From: ***@gmx.de
> To: ***@cs.stanford.edu
> CC: ***@outlook.com; ***@email.it;
> ***@darrington.wattle.id.au; ***@consumerscan.ca;
> ***@free.fr; ***@alanmead.org; pspp-***@gnu.org
>
> ok. That means for me, that we should abort the request for CTABLES
> until the SPV issue is solved.
>
> 1. Has anybody a different opinion?

I think we should take this issue calmly. The SPV format is a way of showing the results dynamically allowing it to be edited later form or convert them to another format, etc. If it's just a broad topic.
I think the important thing here is to collect information relevant to the implementation of CTABLES and also encouraging support for the work that needs PSPP project.
Hands who can write code is needed.

> 3. Maybe Frans idea about implementing !Macros could serve as a
> workaround. I think that might be worthwhile to discuss. Any opinions
> on that?

From my point of view, the implementation of macro is very different and deserves a discussion in itself.
I imagine PSPP priorities are implementing more compatible SPSS commands that equate to the basic package. I think at this point, is unproductive talk about macros.

CJT

[Crichton, Ronald]

The value of (C)TABLES for me was the ability to publish the output without making edits, and that was always a 2-dimensional table. Never a 3-dimensional table. (More gimmick than value.) An additional value of (C)TABLES was also the ability to nest variables and include sub-totals, often 2 deep, sometimes 3 (but not often). Seldom used statistics. Mostly count and sum.

-----Original Message-----
From: pspp-users-bounces+ronald.crichton=***@gnu.org [mailto:pspp-users-bounces+ronald.crichton=***@gnu.org] On Behalf Of Charles Johnson
Sent: Tuesday, 10 November 2015 4:02 AM
To: Matthias Faeth; Ben Pfaff
Cc: pspp-***@gnu.org
Subject: RE: CTABLES

________________________________
> Date: Mon, 9 Nov 2015 16:53:41 +0100
> Subject: Re: CTABLES
> From: ***@gmx.de
> To: ***@cs.stanford.edu
> CC: ***@outlook.com; ***@email.it;
> ***@darrington.wattle.id.au; ***@consumerscan.ca;
> ***@free.fr; ***@alanmead.org; pspp-***@gnu.org
>
> ok. That means for me, that we should abort the request for CTABLES
> until the SPV issue is solved.
>
> 1. Has anybody a different opinion?

I think we should take this issue calmly. The SPV format is a way of showing the results dynamically allowing it to be edited later form or convert them to another format, etc. If it's just a broad topic.
I think the important thing here is to collect information relevant to the implementation of CTABLES and also encouraging support for the work that needs PSPP project.
Hands who can write code is needed.

> 3. Maybe Frans idea about implementing !Macros could serve as a
> workaround. I think that might be worthwhile to discuss. Any opinions
> on that?

From my point of view, the implementation of macro is very different and deserves a discussion in itself.
I imagine PSPP priorities are implementing more compatible SPSS commands that equate to the basic package. I think at this point, is unproductive talk about macros.

CJT

_______________________________________________
Pspp-users mailing list
Pspp-***@gnu.org
https://lists.gnu.org/mailman/listinfo/pspp-users

CIT is the ACT Large Training Provider of the Year.
Subscribe to CIT Industry Connection - CIT's free, bi monthly publication:
http://cit.edu.au/industry_business/industry_connection/
-----------------------------------------------------------------------
This email, and any attachments, may be confidential and also privileged. If you are not the intended recipient, please notify the sender and delete all copies of this transmission along with any attachments immediately. You should not copy or use it for any purpose, nor disclose its contents to any other person.
-----------------------------------------------------------------------

[Barry Kiefl]

Coincidentally, I just joined the list today to try and understand how one
can duplicate SPSS Tables. I need to generate sums of certain variables in
tables and I have not been able to do so thus far.
Regards.

-----Original Message-----
From: pspp-users-bounces+bkiefl=***@gnu.org
[mailto:pspp-users-bounces+bkiefl=***@gnu.org] On Behalf Of
Crichton, Ronald
Sent: Monday, November 09, 2015 2:53 PM
To: pspp-***@gnu.org
Subject: RE: CTABLES

The value of (C)TABLES for me was the ability to publish the output without
making edits, and that was always a 2-dimensional table. Never a
3-dimensional table. (More gimmick than value.) An additional value of
(C)TABLES was also the ability to nest variables and include sub-totals,
often 2 deep, sometimes 3 (but not often). Seldom used statistics. Mostly
count and sum.

-----Original Message-----
From: pspp-users-bounces+ronald.crichton=***@gnu.org
[mailto:pspp-users-bounces+ronald.crichton=***@gnu.org] On Behalf Of
Charles Johnson
Sent: Tuesday, 10 November 2015 4:02 AM
To: Matthias Faeth; Ben Pfaff
Cc: pspp-***@gnu.org
Subject: RE: CTABLES

________________________________
> Date: Mon, 9 Nov 2015 16:53:41 +0100
> Subject: Re: CTABLES
> From: ***@gmx.de
> To: ***@cs.stanford.edu
> CC: ***@outlook.com; ***@email.it;
> ***@darrington.wattle.id.au; ***@consumerscan.ca;
> ***@free.fr; ***@alanmead.org; pspp-***@gnu.org
>
> ok. That means for me, that we should abort the request for CTABLES
> until the SPV issue is solved.
>
> 1. Has anybody a different opinion?

I think we should take this issue calmly. The SPV format is a way of showing
the results dynamically allowing it to be edited later form or convert them
to another format, etc. If it's just a broad topic.
I think the important thing here is to collect information relevant to the
implementation of CTABLES and also encouraging support for the work that
needs PSPP project.
Hands who can write code is needed.

> 3. Maybe Frans idea about implementing !Macros could serve as a
> workaround. I think that might be worthwhile to discuss. Any opinions
> on that?

From my point of view, the implementation of macro is very different and
deserves a discussion in itself.
I imagine PSPP priorities are implementing more compatible SPSS commands
that equate to the basic package. I think at this point, is unproductive
talk about macros.

CJT

_______________________________________________
Pspp-users mailing list
Pspp-***@gnu.org
https://lists.gnu.org/mailman/listinfo/pspp-users

CIT is the ACT Large Training Provider of the Year.
Subscribe to CIT Industry Connection - CIT's free, bi monthly publication:
http://cit.edu.au/industry_business/industry_connection/
-----------------------------------------------------------------------
This email, and any attachments, may be confidential and also privileged. If
you are not the intended recipient, please notify the sender and delete all
copies of this transmission along with any attachments immediately. You
should not copy or use it for any purpose, nor disclose its contents to any
other person.
-----------------------------------------------------------------------

[Ben Pfaff]

On Mon, Nov 09, 2015 at 05:01:43PM +0000, Charles Johnson wrote:
> > 3. Maybe Frans idea about implementing !Macros could serve as a
> > workaround. I think that might be worthwhile to discuss. Any opinions
> > on that?
>
> From my point of view, the implementation of macro is very different
> and deserves a discussion in itself.

The implementation of macros is a big project but I'd say that it's
simpler than SPV or CTABLES. It's also completely independent of either
of those.

[Alan Mead]

Ben,

When we use modern versions of SPSS, I often scroll down to elements of
the SPV file and that element is replaced by a message like "Please
wait - computing" and then after a few seconds, the content replaces
this message. Is this something that you've encountered and
successfully understood? If so, what's SPSS doing? Is it really
re-computing the element? That would imply that it saved all the data
into the SPV file, which seems like an odd and potentially sensitive
issue. I cannot say what elements do this, but I can recall seeing it
occur for graphs.

I've also heard, but cannot confirm first-hand, that when there are
added modules in SPSS and those modules have been used to create
oiutput, that the viewer of the SPV file must also have those modules or
else the computing message never goes away (because the viewer doesn't
have the correct code to replicate the analysis). This also seems like
extraordinarily bad thinking (or at least has extraordinarily bad
outcomes for users). But, again, I cannot say I've seen this first-hand
nor do I know if that applies to all modules.

-Alan


On 11/8/2015 1:25 AM, Ben Pfaff wrote:
> On Sun, Nov 08, 2015 at 01:36:01AM +0000, Charles Johnson wrote:
>>> Date: Sat, 7 Nov 2015 17:03:01 -0800
>>> From: ***@cs.stanford.edu
>>> To: ***@outlook.com
>>> CC: ***@email.it; ***@gmx.de; ***@darrington.wattle.id.au; ***@consumerscan.ca; ***@free.fr; ***@alanmead.org; pspp-***@gnu.org
>>> Subject: Re: CTABLES
>>>
>>> I've done a lot of the work needed to figure out the format of SPV
>>> files. I'm working on publishing a format specification. Then I'll
>>> work on implementing a reader for it.
>> That is great news. If you need more files of type SPV/SPO could ask
>> another topic of discussion.
> At some point I'll need some more to answer a few lingering questions,
> but I can already extract all of the important content.

--

Alan D. Mead, Ph.D.
President, Talent Algorithms Inc.

science + technology = better workers

+815.588.3846 (Office)
+267.334.4143 (Mobile)

http://www.alanmead.org

Announcing the Journal of Computerized Adaptive Testing (JCAT), a
peer-reviewed electronic journal designed to advance the science and
practice of computerized adaptive testing: http://www.iacat.org/jcat

[Ben Pfaff]

On Sun, Nov 08, 2015 at 02:42:40PM -0600, Alan Mead wrote:
> When we use modern versions of SPSS, I often scroll down to elements of
> the SPV file and that element is replaced by a message like "Please
> wait - computing" and then after a few seconds, the content replaces
> this message. Is this something that you've encountered and
> successfully understood? If so, what's SPSS doing? Is it really
> re-computing the element? That would imply that it saved all the data
> into the SPV file, which seems like an odd and potentially sensitive
> issue. I cannot say what elements do this, but I can recall seeing it
> occur for graphs.

I haven't used modern versions of SPSS, so I can't say how the user
interface behaves, but an SPV file does contain all of the data that
appears in the output. (Otherwise it would not be possible to
distribute an SPV file independent of the SPS or SAV files.)

If I had to guess what happens when you see that message, I'd say that
it's closer to SPSS "rendering" the output element than "computing"
anything. Because an SPV file is a fairly abstract representation of
output, something analogous to an HTML table plus CSS styling, a program
that displays an SPV file has to do a lot of work to render it in a
pretty way.

> I've also heard, but cannot confirm first-hand, that when there are
> added modules in SPSS and those modules have been used to create
> oiutput, that the viewer of the SPV file must also have those modules or
> else the computing message never goes away (because the viewer doesn't
> have the correct code to replicate the analysis). This also seems like
> extraordinarily bad thinking (or at least has extraordinarily bad
> outcomes for users). But, again, I cannot say I've seen this first-hand
> nor do I know if that applies to all modules.

I bet that applies only to specialized forms of output. All pivot
tables in an SPV file share a common format, which does not require the
viewer software to recompute anything from the original data (only to
render the table), so there would be no reason for it otherwise (unless
SPSS restricts it for business reasons, to sell more of the extra
modules).

[John Darrington]

On Sun, Nov 08, 2015 at 01:36:01AM +0000, Charles Johnson wrote:

From my point of view, production jobs are very useful to automate lengthy and complex processes that are made recurrently. As PSPP add more commands, the more useful they will be in the future.


How would they be more useful than any general method of automation?

For example, if you wanted to automatically download a file from a
location on the web, and analzse that, you could write a 3 line shell
script using wget and pspp. You could even have cron run it every
day/hour/minute and upload the results somewhere.

I'm sure it would also be possible with "production jobs", but I wonder
what the utility is, reinventing the wheel to do something which can
already be done.

J'



--
Avoid eavesdropping. Send strong encryted email.
PGP Public key ID: 1024D/2DE827B3
fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.

[Charles Johnson]

I agree with you, however, a few years ago when I had no more knowledge of computers, I would not have said the same.

This is not to reinvent the wheel, but to offer a method that many users already know. 
Such functionality in PSPP, could be available on any platform, and you have a group of users who would know how to use it and also count with SPJ files they did or their companies gave them, saying, "with that file, analyze X data with Y statistical".

Everything depends on the perspective.

Cheers
CJT


----------------------------------------
> Date: Sun, 8 Nov 2015 10:10:43 +0100
> From: ***@darrington.wattle.id.au
> To: ***@outlook.com
> CC: pspp-***@gnu.org
> Subject: Production Jobs
>
> On Sun, Nov 08, 2015 at 01:36:01AM +0000, Charles Johnson wrote:
>
> From my point of view, production jobs are very useful to automate lengthy and complex processes that are made recurrently. As PSPP add more commands, the more useful they will be in the future.
>
>
> How would they be more useful than any general method of automation?
>
> For example, if you wanted to automatically download a file from a
> location on the web, and analzse that, you could write a 3 line shell
> script using wget and pspp. You could even have cron run it every
> day/hour/minute and upload the results somewhere.
>
> I'm sure it would also be possible with "production jobs", but I wonder
> what the utility is, reinventing the wheel to do something which can
> already be done.
>
> J'
>
>
>
> --
> Avoid eavesdropping. Send strong encryted email.
> PGP Public key ID: 1024D/2DE827B3
> fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3
> See http://sks-keyservers.net or any PGP keyserver for public key.
>

[Roberto Gil Saura [UV]]

Hi Charles and John. I'm very sad with this answer.

I have general knowledge about computers, linux, cron and others, but I
think that my collegues at the University dont't share this knowledge. Easy
is better, and if the automation is in the same environment, these is the
best.

*Roberto Gil Saura * <https://twitter.com/robertogilsaura>
<http://es.linkedin.com/in/robertogilsaura>
Profesor Asociado
Departament de Comercialització i Investigació de Mercats
Facultat d'Economia
Universitat de ValÚncia
---
CLÀUSULA DE CONFIDENCIALITAT
Aquest missatge ha estat generat des d'un compte de la Universitat de
ValÚncia per a les finalitats pròpies de la institució. El seu contingut es
considera confidencial i, llevat que la seua naturalesa així ho exigisca,
no se’n permet la reproducció o distribució sense autorització expressa. Si
heu rebut indegudament el correu, us demanem que advertiu d'aquest fet al
remitent i que l’elimineu. En el lloc web institucional de la Universitat
de ValÚncia podeu consultar les nostres condicions d'ús i polítiques de
privacitat pel que fa a l'enviament de correu electrònic (
http://links.uv.es/E0GKasq, http://links.uv.es/26uC3dX). Podeu comunicar
qualsevol incidÚncia relacionada amb la recepció dels nostres correus
electrònics, i en particular aquelles que es relacionen amb la seguretat i
la confidencialitat, mitjançant ***@uv.es.

CLÁUSULA DE CONFIDENCIALIDAD
Este mensaje ha sido generado desde una cuenta de la Universitat de
ValÚncia para los fines propios de la institución. Su contenido se
considera confidencial y, salvo que la naturaleza del mismo así lo exija,
no está permitida su reproducción o distribución sin la autorización
expresa. Si Vd. ha recibido indebidamente el correo le rogamos que advierta
de ello al remitente y proceda a su eliminación. En el sitio web
institucional de la Universitat de ValÚncia puede consultar nuestras
condiciones de uso y políticas de privacidad en el envío de correo
electrónico (http://links.uv.es/ZkR7Dsl, https://links.uv.es/9yrTPmm).
Cualquier incidencia relacionada con la recepción de nuestros correos
electrónicos y en particular las relativas a la seguridad y
confidencialidad pueden ser comunicadas a ***@uv.es.

On 8 November 2015 at 17:13, Charles Johnson <***@outlook.com>
wrote:

> I agree with you, however, a few years ago when I had no more knowledge of
> computers, I would not have said the same.
>
> This is not to reinvent the wheel, but to offer a method that many users
> already know.
> Such functionality in PSPP, could be available on any platform, and you
> have a group of users who would know how to use it and also count with SPJ
> files they did or their companies gave them, saying, "with that file,
> analyze X data with Y statistical".
>
> Everything depends on the perspective.
>
> Cheers
> CJT
>
>
> ----------------------------------------
> > Date: Sun, 8 Nov 2015 10:10:43 +0100
> > From: ***@darrington.wattle.id.au
> > To: ***@outlook.com
> > CC: pspp-***@gnu.org
> > Subject: Production Jobs
> >
> > On Sun, Nov 08, 2015 at 01:36:01AM +0000, Charles Johnson wrote:
> >
> > From my point of view, production jobs are very useful to automate
> lengthy and complex processes that are made recurrently. As PSPP add more
> commands, the more useful they will be in the future.
> >
> >
> > How would they be more useful than any general method of automation?
> >
> > For example, if you wanted to automatically download a file from a
> > location on the web, and analzse that, you could write a 3 line shell
> > script using wget and pspp. You could even have cron run it every
> > day/hour/minute and upload the results somewhere.
> >
> > I'm sure it would also be possible with "production jobs", but I wonder
> > what the utility is, reinventing the wheel to do something which can
> > already be done.
> >
> > J'
> >
> >
> >
> > --
> > Avoid eavesdropping. Send strong encryted email.
> > PGP Public key ID: 1024D/2DE827B3
> > fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3
> > See http://sks-keyservers.net or any PGP keyserver for public key.
> >
>
> _______________________________________________
> Pspp-users mailing list
> Pspp-***@gnu.org
> https://lists.gnu.org/mailman/listinfo/pspp-users
>

[Ben Pfaff]

On Sun, Nov 08, 2015 at 10:10:43AM +0100, John Darrington wrote:
> On Sun, Nov 08, 2015 at 01:36:01AM +0000, Charles Johnson wrote:
>
> From my point of view, production jobs are very useful to
> automate lengthy and complex processes that are made
> recurrently. As PSPP add more commands, the more useful they will
> be in the future.
>
>
> How would they be more useful than any general method of automation?

I would guess that SPSS users are used to them and that they may have
some that they consider valuable.

[Matthias Faeth]

I personally never use production jops and also never save .spv files but
export results to excel. But I might be untypical.

Matthias FÀth
Im Mediapark 12
50670 Köln
t: 0221-2907973
m: 0171-9832175
e: ***@gmx.de

2015-11-08 18:15 GMT+01:00 Ben Pfaff <***@cs.stanford.edu>:

> On Sun, Nov 08, 2015 at 10:10:43AM +0100, John Darrington wrote:
> > On Sun, Nov 08, 2015 at 01:36:01AM +0000, Charles Johnson wrote:
> >
> > From my point of view, production jobs are very useful to
> > automate lengthy and complex processes that are made
> > recurrently. As PSPP add more commands, the more useful they will
> > be in the future.
> >
> >
> > How would they be more useful than any general method of automation?
>
> I would guess that SPSS users are used to them and that they may have
> some that they consider valuable.
>
> _______________________________________________
> Pspp-users mailing list
> Pspp-***@gnu.org
> https://lists.gnu.org/mailman/listinfo/pspp-users
>

[Matthias Faeth]

Correction: Do I understand correctly "production job" = "marco
functionality"? Than I use that.

Matthias FÀth
Im Mediapark 12
50670 Köln
t: 0221-2907973
m: 0171-9832175
e: ***@gmx.de

2015-11-08 18:21 GMT+01:00 Matthias Faeth <***@gmx.de>:

> I personally never use production jops and also never save .spv files but
> export results to excel. But I might be untypical.
>
> Matthias FÀth
> Im Mediapark 12
> 50670 Köln
> t: 0221-2907973
> m: 0171-9832175
> e: ***@gmx.de
>
> 2015-11-08 18:15 GMT+01:00 Ben Pfaff <***@cs.stanford.edu>:
>
>> On Sun, Nov 08, 2015 at 10:10:43AM +0100, John Darrington wrote:
>> > On Sun, Nov 08, 2015 at 01:36:01AM +0000, Charles Johnson wrote:
>> >
>> > From my point of view, production jobs are very useful to
>> > automate lengthy and complex processes that are made
>> > recurrently. As PSPP add more commands, the more useful they will
>> > be in the future.
>> >
>> >
>> > How would they be more useful than any general method of automation?
>>
>> I would guess that SPSS users are used to them and that they may have
>> some that they consider valuable.
>>
>> _______________________________________________
>> Pspp-users mailing list
>> Pspp-***@gnu.org
>> https://lists.gnu.org/mailman/listinfo/pspp-users
>>
>
>

[Roberto Gil Saura [UV]]

ISO 20252 on market research "forces" to save all the processes have been
executed in a database so someone else could repeat exactly the same
processes as the first time.
This forces to save the syntax of all the processes running. Each process
that can be used in "production jobs" will be welcome, especially those
that affect the transformation of the database.

[Matthias Faeth]

Syntax is saved anyway. Furthermore, it is no bad idea to save a "program"
(=clean set of syntax) for all transformations and tables in case you find
errors in the data after you have done tabulation and want to start anew.
But this is probably not what Alan and John were up to discuss?

Matthias FÀth
Im Mediapark 12
50670 Köln
t: 0221-2907973
m: 0171-9832175
e: ***@gmx.de

2015-11-08 18:38 GMT+01:00 Roberto Gil Saura [UV] <***@uv.es>:

>
> ISO 20252 on market research "forces" to save all the processes have been
> executed in a database so someone else could repeat exactly the same
> processes as the first time.
> This forces to save the syntax of all the processes running. Each process
> that can be used in "production jobs" will be welcome, especially those
> that affect the transformation of the database.
>

[ftr]

Same with me. In survey analysis you have more ad-hoc analyses , so less
repetition.

I am far more interested in using MR and CTABLES.
- ftr


On 08/11/2015 18:21, Matthias Faeth wrote:
> I personally never use production jops and also never save .spv files
> but export results to excel. But I might be untypical.
>
> Matthias Fäth
> Im Mediapark 12
> 50670 Köln
> t: 0221-2907973
> m: 0171-9832175
> e: ***@gmx.de <mailto:***@gmx.de>
>
> 2015-11-08 18:15 GMT+01:00 Ben Pfaff <***@cs.stanford.edu
> <mailto:***@cs.stanford.edu>>:
>
> On Sun, Nov 08, 2015 at 10:10:43AM +0100, John Darrington wrote:
> > On Sun, Nov 08, 2015 at 01:36:01AM +0000, Charles Johnson wrote:
> >
> > From my point of view, production jobs are very useful to
> > automate lengthy and complex processes that are made
> > recurrently. As PSPP add more commands, the more useful
> they will
> > be in the future.
> >
> >
> > How would they be more useful than any general method of automation?
>
> I would guess that SPSS users are used to them and that they may have
> some that they consider valuable.
>
> _______________________________________________
> Pspp-users mailing list
> Pspp-***@gnu.org <mailto:Pspp-***@gnu.org>
> https://lists.gnu.org/mailman/listinfo/pspp-users
>
>
>
>
> _______________________________________________
> Pspp-users mailing list
> Pspp-***@gnu.org
> https://lists.gnu.org/mailman/listinfo/pspp-users

[Charles Johnson]

Please do not confuse the topics of discussion. Currently PSPP developers donate their time voluntarily. They decide on what functions/features can (and want to) work.

No more we ask, they will perform.


Those interested in adding the "CTABLES" command, can contribute to the discussion on the mailing list for that issue, adding useful information to begin work collecting money, incentives, company that could do the job, etc.
Moreover, if anyone is interested in SPSS production jobs, you can send sample files (SPJ and SPS files).

Thanks

CJT


________________________________
> Subject: Re: Production Jobs
> To: pspp-***@gnu.org
> From: ***@free.fr
> Date: Sun, 8 Nov 2015 21:03:21 +0100
>
> Same with me. In survey analysis you have more ad-hoc analyses , so
> less repetition.
>
> I am far more interested in using MR and CTABLES.
> - ftr
>
>
> On 08/11/2015 18:21, Matthias Faeth wrote:
> I personally never use production jops and also never save .spv files
> but export results to excel. But I might be untypical.
>
> Matthias Fäth
> Im Mediapark 12
> 50670 Köln
> t: 0221-2907973
> m: 0171-9832175
> e: ***@gmx.de<mailto:***@gmx.de>
>
> 2015-11-08 18:15 GMT+01:00 Ben Pfaff
> <***@cs.stanford.edu<mailto:***@cs.stanford.edu>>:
> On Sun, Nov 08, 2015 at 10:10:43AM +0100, John Darrington wrote:
> > On Sun, Nov 08, 2015 at 01:36:01AM +0000, Charles Johnson wrote:
> >
> > From my point of view, production jobs are very useful to
> > automate lengthy and complex processes that are made
> > recurrently. As PSPP add more commands, the more useful they will
> > be in the future.
> >
> >
> > How would they be more useful than any general method of automation?
>
> I would guess that SPSS users are used to them and that they may have
> some that they consider valuable.
>
> _______________________________________________
> Pspp-users mailing list
> Pspp-***@gnu.org<mailto:Pspp-***@gnu.org>
> https://lists.gnu.org/mailman/listinfo/pspp-users
>
>
>
>
> _______________________________________________
> Pspp-users mailing list
> Pspp-***@gnu.org<mailto:Pspp-***@gnu.org>
> https://lists.gnu.org/mailman/listinfo/pspp-users
>
>
>
> _______________________________________________ Pspp-users mailing list
> Pspp-***@gnu.org https://lists.gnu.org/mailman/listinfo/pspp-users