mode (or why BASIC-like thinking is not enough) 
Author Message
 mode (or why BASIC-like thinking is not enough)

Ok, this is Microworlds code:

to mode :list
make "nameList []
dolist [e :list] [
 make "elemName word "c :e
 ifelse member? :elemName :nameList [
  make :elemName (thing :elemName) + 1
 ] [
  make :elemName 1
  make "nameList fput :elemName :nameList
 ]
]

make "maxValue 0
dolist [n :nameList] [
 if :maxValue < thing :n [
  make "maxValue thing :n
  make "maxName :n
 ]
]

output butfirst :maxName
end

show mode [-1 -1 1 2 -1 5 5 8 1]
-1

show names
make "maxName "c-1
make "c-1 3
make "nameList [c8 c5 c2 c1 c-1]
make "elemName "c1
make "maxValue 3
make "c5 2
make "c1 2
make "c8 1
make "c2 1

Daniel

To unsubscribe from this group, send an email to:

LogoForum messages are archived at:
http://www.*-*-*.com/

Your use of Yahoo! Groups is subject to http://www.*-*-*.com/



Sun, 02 May 2004 13:20:50 GMT  
 mode (or why BASIC-like thinking is not enough)

Quote:

> A general O(N) solution along Dench's approach can be produced using
>hashing -

using indices of items in the hash table as values..

That is what this is, isn't it?:


Quote:
> Ok, this is Microworlds code:

> to mode :list
> make "nameList []
> dolist [e :list] [
>  make "elemName word "c :e
>  ifelse member? :elemName :nameList [
>   make :elemName (thing :elemName) + 1
>  ] [
>   make :elemName 1
>   make "nameList fput :elemName :nameList
>  ]
> ]

> make "maxValue 0
> dolist [n :nameList] [
>  if :maxValue < thing :n [
>   make "maxValue thing :n
>   make "maxName :n
>  ]
> ]

> output butfirst :maxName
> end

Are "property lists" implemented as hash tables?

Daniel

To unsubscribe from this group, send an email to:

LogoForum messages are archived at:
http://groups.yahoo.com/group/LogoForum

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/



Sun, 02 May 2004 13:28:05 GMT  
 mode (or why BASIC-like thinking is not enough)
Yes property lists are implemented as hash tables. The problem with property
lists is that it's in the global namespace. Your sample below suffers from
the same problem, and worse... (more name conflicts).

TKTS Logo (I'll get it out soon I promise :-) has a gensym that is
guarenteed to generate a unique symbol at the time that it's called. It
still doesn't stop the symbol being used after it's called, but more usable
to provide a proplist name.

Another option is to save the property list at the start of the function and
restore it afterwards. This will still cause problems if another thread/task
is using the same property.

Hohum.

Jamie

Quote:
-----Original Message-----


Sent: Tuesday, November 13, 2001 10:27 AM

Subject: [LogoForum] Re: mode (or why BASIC-like thinking is not enough)


> A general O(N) solution along Dench's approach can be produced using
hashing -
using indices of items in the hash table as values..

That is what this is, isn't it?:


> Ok, this is Microworlds code:

> to mode :list
> make "nameList []
> dolist [e :list] [
>  make "elemName word "c :e
>  ifelse member? :elemName :nameList [
>   make :elemName (thing :elemName) + 1
>  ] [
>   make :elemName 1
>   make "nameList fput :elemName :nameList
>  ]
> ]

> make "maxValue 0
> dolist [n :nameList] [
>  if :maxValue < thing :n [
>   make "maxValue thing :n
>   make "maxName :n
>  ]
> ]

> output butfirst :maxName
> end

Are "property lists" implemented as hash tables?

Daniel

To unsubscribe from this group, send an email to:

LogoForum messages are archived at:
http://groups.yahoo.com/group/LogoForum

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

To unsubscribe from this group, send an email to:

LogoForum messages are archived at:
http://groups.yahoo.com/group/LogoForum

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/



Sun, 02 May 2004 13:29:26 GMT  
 mode (or why BASIC-like thinking is not enough)

Quote:

>Are "property lists" implemented as hash tables?

Depends on the implementation.  Not in UCBLogo; the only built-in hash
table is the one that holds name and {variable,procedure,proplist} bindings.
Typically in Logo the data aren't big enough to worry about efficiency,
I think.  So proplists are lists.


Mon, 03 May 2004 03:03:01 GMT  
 mode (or why BASIC-like thinking is not enough)
There I go again, assuming the way I do something is the way most people do
:-) I just naturally related proplists to be implemented as either hash
tables or binary trees.

Jamie

Quote:
> -----Original Message-----
> From: Brian Harvey
> Sent: Wednesday, November 14, 2001 8:21 PM

> Subject: Re: [LogoForum] Re: mode (or why BASIC-like thinking is not
> enough)

> The message below is being cross-posted from comp.lang.logo.
> Please reply



> >Are "property lists" implemented as hash tables?

> Depends on the implementation.  Not in UCBLogo; the only built-in hash
> table is the one that holds name and {variable,procedure,proplist}
> bindings.
> Typically in Logo the data aren't big enough to worry about
> efficiency,
> I think.  So proplists are lists.

> To unsubscribe from this group, send an email to:

> LogoForum messages are archived at:
> http://groups.yahoo.com/group/LogoForum

> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/

To unsubscribe from this group, send an email to:

LogoForum messages are archived at:
http://groups.yahoo.com/group/LogoForum

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/



Mon, 03 May 2004 21:43:16 GMT  
 mode (or why BASIC-like thinking is not enough)

Quote:

> There I go again, assuming the way I do something is the way most people do
> :-) I just naturally related proplists to be implemented as either hash
> tables or binary trees.

> Jamie

> > -----Original Message-----
> > From: Brian Harvey
> > Sent: Wednesday, November 14, 2001 8:21 PM

> > Subject: Re: [LogoForum] Re: mode (or why BASIC-like thinking is not
> > enough)

> > Depends on the implementation.  Not in UCBLogo; the only built-in hash
> > table is the one that holds name and {variable,procedure,proplist}
> > bindings.
> > Typically in Logo the data aren't big enough to worry about
> > efficiency,
> > I think.  So proplists are lists.

Now I understand why LOOPS has worse than is to be expected performance. All
virtual objects are properties, so obviously, Logo wastes a lot of time
finding them, before it is able to execute them.


Tue, 04 May 2004 03:43:27 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. Why I am not enthusiatic about OO COBOL

2. Why I am not reaching callbacks ?

3. To think or not to think ;-)

4. Why not Visual Basic?

5. Basic (Was:Re: Why is Ada NOT ... )

6. I am not deaf, but am I mute?

7. Basic enough questions..

8. Sun compiler not liking X in format statements

9. Why Python is like BASIC (and why this is a good thing)

10. I am thinking about becoming a Head Hunter

11. I am thinking of if this is possible

12. Enough is Enough

 

 
Powered by phpBB® Forum Software