Re: Charts

[Ben Pfaff]

John Darrington <address@hidden> writes:

> Basically, if the dots follow the line, then the data is normally
> distributed.
>
> try it with the following : 
>
> INPUT PROGRAM.
>         LOOP #I=1 TO 50.
>              COMPUTE X=UNIFORM(10).
>              END CASE.
>         END LOOP.
>         END FILE.
> END INPUT PROGRAM.
>
>
> EXAMINE /x
>         /STATISTICS=DESCRIPTIVES
>         /PLOT = NPPLOT
>         .
>
> and then try again substituting NORMAL for UNIFORM.

Thanks.  I can see the difference better with 5000 points.  With
50000 points I get an immediate segfault, by the way.  From the
valgrind backtrace it looks like it might be my fault:

==29693== Invalid write of size 4
==29693==    at 0x8075696: write_case_to_disk (case.h:136)
==29693==    by 0x80759F3: casefile_to_disk (casefile.c:401)
==29693==    by 0x8075537: casefile_append (casefile.c:295)
==29693==    by 0x80C3278: write_case (vfm.c:264)
==29693==    by 0x809C060: input_program_source_read (inpt-pgm.c:220)
==29693==    by 0x80C3018: internal_procedure (vfm.c:165)
==29693==    by 0x80C4301: multipass_procedure_with_splits (vfm.c:931)
==29693==    by 0x8055060: cmd_examine (examine.q:153)
==29693==    by 0x8077026: cmd_parse (command.c:207)
==29693==    by 0x809F33B: execute_command (main.c:124)
==29693==    by 0x809F2EC: parse_script (main.c:94)
==29693==    by 0x809F28E: main (main.c:81)
==29693==  Address 0x1C700948 is 0 bytes after a block of size 8192 alloc'd
==29693==    at 0x1B904EDD: malloc (vg_replace_malloc.c:131)
==29693==    by 0x80706A6: xmalloc (alloc.c:39)
==29693==    by 0x807593B: casefile_to_disk (casefile.c:392)
==29693==    by 0x8075537: casefile_append (casefile.c:295)
==29693==    by 0x80C3278: write_case (vfm.c:264)
==29693==    by 0x809C060: input_program_source_read (inpt-pgm.c:220)
==29693==    by 0x80C3018: internal_procedure (vfm.c:165)
==29693==    by 0x80C4301: multipass_procedure_with_splits (vfm.c:931)
==29693==    by 0x8055060: cmd_examine (examine.q:153)
==29693==    by 0x8077026: cmd_parse (command.c:207)
==29693==    by 0x809F33B: execute_command (main.c:124)
==29693==    by 0x809F2EC: parse_script (main.c:94)
==29693==    by 0x809F28E: main (main.c:81)

I don't have time to investigate now so I'll file a bug.  It's
#11307.

> Regarding getting 15GB of output, do you think it would be a good idea
> to have a SET subcommand to limit the amount of output that can be
> created?

I don't know if there'd be a reasonable way to set a default
maximum size, and I'm not sure it would be a common problem.
-- 
"The fact is, technical people are better off not looking at patents. If
 you don't know what they cover and where they are, you won't be knowingly
 infringing on them. If somebody sues you, you change the algorithm or you
 just hire a hit-man to whack the stupid git." --Linus Torvalds