1. Defining long constants - do-able but not exactly elegant
After a few test runs with my fledgling cipher program, my source
contains something like this:
--constant ts1="idfursf ujbdoc ujy negnxdnown idfu fun cxjkgdoc ",
-- ts2="joy rggxnkkdbn ajo in wjoorf jggxnwdjfn fun ",
-- ts3="jzzjhdmdfl rz fun uronkf joy cnonxrsk ",
-- testset=ts1&ts2&ts3
--constant ts1="b hcn fba ioa caxw pbxlsbw ramc mpj scchk ",
-- ts2="blmji mpbm pj rk ioaaran com cl mpj scchk",
-- testset=ts1&ts2
--constant ts1="zaxabaprsanl cdrlt znlzdlsersanl nq zbntd ",
-- ts2="fsabaprsanl nq skd brlu twedru nq habu baqd rhrv",
-- testset=ts1&ts2
constant ts1="ktj uz wjiwnlufza rnujw fv nyywzqfbnujcp zaj iztwug ",
ts2="kjjyjw ugna fu nyyjnwv uz mj rgja czzdfah fauz fu",
testset=ts1&ts2
Obviously, I coded it that way because of line length problems, then
just carried on. I'd rather have one big constant & a loop.
Unfortunately Euphoria doesn't support \<eol>
I have a work-round (below), but before you read it, ask yourself how
you would do it, elegantly.
A gut of mine tells me that is not the best way to do it.
It's not very readable, really, & easy to make small slips, especially
when the set gets fairly large.
By the time you read this, I'll have coded:
testset={
t11&t12&t13,
t21&t22,
t31&t32,
t41&t42}
but I don't like all those extra names cluttering up my code. Was
there a t33, or not, t84? etc
Pete
PS I chopped a few of those ciphers to tidy up the post a bit.
Don't use em, if you want the originals I'll mail them direct.
2. Re: Defining long constants - do-able but not exactly elegant
On Thu, 14 Mar 2002 09:57:35 +1100, Derek Parnell
<ddparnell at bigpond.com> wrote:
>
>What's wrong with :
Ah, not a lot. I tried
>constant testset=
> "idfursf ujbdoc ujy negnxdnown idfu fun cxjkgdoc ", &
> "joy rggxnkkdbn ajo in wjoorf jggxnwdjfn fun "
Euphoria gave me an error message (a name is expected here), pointing
at the & so I assumed it didn't work, not spotting the comma I had
left behind.
Cheers
Pete (feeling sheepish, again)
3. Re: Defining long constants - do-able but not exactly elegant
On Wed, 13 Mar 2002 18:36:31 -0600, Kat <gertie at PELL.NET> wrote:
>What's wrong with simply gets()ing a text file of any length you want, edited
>any way you want, and displayed any way you want, in any editor you
>want, rather than cluttering up the code files?
>
One thing I never can quite get is the way windows does the default
directory handling. The editor I'm using opens the files from the last
session automatically, so *I guess* the windows API never gets to set
a "current" directory in the way it would if I double clicked a file
in Explorer or used the standard open file dialogue. The upshot of
which is that I either have to hard code a directory in my program,
which I am loathe to do, or open a random file from the right
directory & shut it. before windows can find the file my program is
trying to open.
Pete
4. Re: Defining long constants - do-able but not exactly elegant
- Posted by tone.skoda at siol.net
Mar 14, 2002
This works fast:
buffer = append (buffer, gets (fn))
This very very slow:
buffer [1] = append (buffer [1], gets (fn))
I guess interpreter creates a copy of buffer [1] every time it is used as
parameter in append().
----- Original Message -----
From: "Kat" <gertie at PELL.NET>
To: "EUforum" <EUforum at topica.com>
Sent: Thursday, March 14, 2002 7:43 PM
Subject: RE: Defining long constants - do-able but not exactly elegant
>
> On 14 Mar 2002, at 8:07, bensler at mail.com wrote:
>
> >
> > What are you using to read in the file data?
> > get(), gets() or getc()?
>
> I tried all 3.
>
> > Can you give an example of what is taking so long?
>
> dictionary = repeat({},200) -- we are going to organize the words by size
> time1 = time()
> for ocindex = 1 to length(ocypher) do
> if length(ocypher[ocindex]) then
> junk_i = length(ocypher[ocindex])
> if not equal(ocypher[ocindex],{}) and equal(dictionary[junk_i],{})
then
> dfilename =
"D:\\Gertie\\decypher\\dfile"&sprintf("%d",junk_i)&".txt"
> puts(1,sprintf("%d",ocindex)&" "&dfilename&"\n")
> readfile = open(dfilename,"r")
> if not equal(readfile,-1) then
> readline = gets(readfile)
> while not equal(readline,-1) do
> dictionary[junk_i] =
append(dictionary[junk_i],readline[1..length(readline)-1])
> readline = gets(readfile)
> end while
> close(readfile)
> end if
> end if
> end if
> end for
> time2 = time()
> puts(1,"dfile load time: "&sprintf("%d",time2-time1)&" seconds\n")
>
> > I used to play with Eu on my 486DX 100mhz, and I never noticed any
> > significant file loading times. Granted, I never tried opening any 50Mb
> > files.
>
> In this case, i premunged the dictionary to separate word-sized files and
> used gets() for each word. I had made one file using printf(), and one
get(),
> which took longer and made a *much* bigger file. The getc() version ran
the
> slowest.
>
> Kat
>
> >
> > Chris
> >
> >
> > Kat wrote:
> > > On 14 Mar 2002, at 0:55, Andy Serpa wrote:
> > >
> > > >
> > > > Kat wrote:
> > > > >
> > > > > What's wrong with simply gets()ing a text file of any length you
want,
> > > > > edited any way you want, and displayed any way you want, in any
editor you
> > > > > want, rather than cluttering up the code files?
> > > > >
> > > >
> > > > Yeah, that's what I was gonna say. The rules for #3 don't preclude
you from
> > > > loading in any file you want (except machine code, or something like
that).
> > > > The program I'm working on loads in a "pre-hashed" dictionary, along
with
> > > > some other stuff, instead of wasting time on that
> > > >
> > > > everytime it starts....
> > >
> > > I found loading the pre-munged data took way longer than grabbing the
> > > plain
> > > dictionary. Near as i can tell, it's the stuffing into 3-deep nested
> > > sequences
> > > that is eating the time. Maybe i should try making them a set length
in
> > > each
> > > nest with the repeat() from the start. But munging dictionaries took
> > > forever
> > > too. Anyhoo, like i said, i am out of the contest, i can write the
code, but
> > > it won't execute in time. It's so wierd, because the grammar parser
runs
> > > faster than loading the dictionary for this contest.
> > >
> > > What bugs me a little about real-world apps using these cypto-solvers
is that
> > > anyone with a reason to use them would have more than one paragraph to
solve,
> > > and loading and dictionary munging time would be inconsequential,
> > >
> > > because they'd be turned on and left running, looking for input. (I
> > > leave one
> > > mining program running sometimes, it goes active when the other
programs
> > >
> > > feed it an url.) But then, these guys have load time down to
sub-second
> > > times, so,, errr, nevermind.
> > >
> > > Kat
> > >
> > >
>
>
>
5. Re: Defining long constants - do-able but not exactly elegant
On 15 Mar 2002, at 3:24, tone.skoda at siol.net wrote:
>
> This works fast:
>
> buffer = append (buffer, gets (fn))
>
> This very very slow:
>
> buffer [1] = append (buffer [1], gets (fn))
>
> I guess interpreter creates a copy of buffer [1] every time it is used as
> parameter in append().
I thought the whole point of using append() is that Rob optimised it to not
make copies?
Kat
6. Re: Defining long constants - do-able but not exactly elegant
Kat writes:
> I thought the whole point of using append() is that Rob
> optimised it to not make copies?
The simple, common case:
x = append(x, something)
is highly optimized for use in a loop.
More complicated things like:
x[i] = append(x[i], something)
are not.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
