percent! - new datatype request
[1/80] from: al::bri::xtra::co::nz at: 7-Jun-2002 4:19
percent! - new datatype request
It would be nice to see a percent datatype. It could be based on a
combination of the money! and decimal! datatype. percent! datatypes would
look like:
100%
1.23%
0.456%
I've send a copy to [feedback--rebol--com]
Andrew Martin
ICQ: 26227169 http://valley.150m.com/
[2/80] from: ammon:rcslv at: 4-Jun-2002 17:04
hi,
And with it you could do something like:
>> 100 - 50%
== 50
>> 100 + 50%
== 150
>> 100 * 50%
== 5000
Enjoy!!
Ammon
A short time ago, Andrew Martin, sent an email stating:
[3/80] from: anton:lexicon at: 7-Jun-2002 4:35
To be consistent,
100 * 50% should give 5000%.
Addition and subtraction between integer and percent
types is ambiguous. What would you expect from
200 - 50% ?
There are four different, but all, depending on your
point of view, correct, possibilities.
Just remember that % means "per cent", or "divided by 100".
So 100% is not the same as 100.
Not a bad idea overall, though.
Regards,
Anton.
[4/80] from: greggirwin:mindspring at: 6-Jun-2002 13:37
Hi Andrew,
<< percent! - new datatype request
It would be nice to see a percent datatype. It could be based on a
combination of the money! and decimal! datatype. percent! datatypes would
look like:
100%
1.23%
0.456%
>>
I've thought about that as well, but the best way I can see using them is in
a dialect (add 5% to total).
--Gregg
[5/80] from: nitsch-lists:netcologne at: 6-Jun-2002 22:26
Am Donnerstag, 6. Juni 2002 20:35 schrieb Anton:
> To be consistent,
>
> 100 * 50% should give 5000%.
should give 50.
to-percent 100 * 50% should give 5000%
> Addition and subtraction between integer and percent
> types is ambiguous. What would you expect from
>
> 200 - 50% ?
>
with-heavy-rabatt: $1999 - 30 %
> There are four different, but all, depending on your
> point of view, correct, possibilities.
<<quoted lines omitted: 37>>
> > >
> > > Andrew Martin
nice idea :)
next i want units :)
-volker
[6/80] from: ammon:rcslv at: 4-Jun-2002 20:21
hi,
Thanks for the stimulating thoughts...
I would personally expect to see the output data type be the same as the
*first* argument. I find that to be more consistent within REBOL (i.e. try
appending a path to a block, now a block to a path) so if you have an integer
and you subtract, add, divide.... it should affect the integer not the
percent. and if you are dealing with a number besides 100, it should be as
you said, "per cent" example:
>> 200 - 50%
== 100
>> 500 + 100%
== 1000
>> 100 - 75%
== 250
After all, if you don't evaluate it that way, you have lost the advantage
that you get from the datatype, or at least the most obvious reason that I
can see (what did you have in mind to use it for Andrew?).
Give me a point of view that would logically result in a different result
than I have given. (I am often too blind to the things around. ;-) and
while you are at it, please explain why 100 * 50% would result in a percent!
rather than an integer.
Thanks!!
Ammon
A short time ago, Anton, sent an email stating:
[7/80] from: ptretter:charter at: 6-Jun-2002 16:12
The question always comes to mind - do we really need one? After all, why
add more code to the binary when we already can handle percents with a few
bits of code. I think only very complex useful functions should be added to
the binary.
Paul Tretter
[8/80] from: steve:shireman:semaxwireless at: 6-Jun-2002 16:13
> nice idea :)
> next i want units :)
>
> -volker
Units! please do not take this as an insult, but you think like me...;-)
Boyles law:
3 bar * 4 liters = 4 bar * 3 liters ;I'll drink to that!!
; need a balanced-equation style, hmmmn?
Steve Shireman
PS. Cole's law = thinly sliced cabbage
[9/80] from: jason:cunliffe:verizon at: 6-Jun-2002 13:47
> And with it you could do something like:
> >> 100 - 50%
<<quoted lines omitted: 3>>
> >> 100 * 50%
> == 5000
Shouldn't that be
>> 100 - 50%
== 50%
>> 100 + 50%
== 150%
>> 100 * 50%
== 5000%
and thus
>> rate: 8.25%
== 8.25%
>> price: $100.00
== $100.00
>> tax: price * rate
== $8.25
>> taxrate: to-percent [$8.25 / $100]
== 8.25%
?? ./Jason
[10/80] from: anton:lexicon at: 7-Jun-2002 14:12
Yeah, look - we're arguing already. :)
But, I remember, to be consistent, shouldn't
the second datatype be converted to the first
before the operation takes place ?
So,
100 - 50% == 50 ; as first stated
I suppose
50% - 100 == -50% ; ? or should be illegal?
And
50% * 100 == 5000%
100 * 50% == 50
> > And with it you could do something like:
> >
<<quoted lines omitted: 21>>
> == 8.25%
> ?? ./Jason
Uh oh, so to-percent involves an implicit multiplication
by 100, then? Looks nice, though.
Anton.
[11/80] from: al:bri:xtra at: 7-Jun-2002 16:45
The email I received from Carl.
Andrew Martin
ICQ: 26227169 http://valley.150m.com/
[12/80] from: chalz:earthlink at: 7-Jun-2002 1:12
I'm coming in to this discussion a little late, but here's the way I,
personally, would see it.
> 100 - 50% == 50 ; as first stated
This, to me, would equate to:
100 - (100 * .50) == 50
Similarly:
200 - 50% == 200 - (200 * .5) == 100
> I suppose
> 50% - 100 == -50% ; ? or should be illegal?
I don't think you could really do that, because just what is that 50% *of*?
Perhaps 50% - 100% ..
> And
> 50% * 100 == 5000%
> 100 * 50% == 50
An interesting thought. Should
100 + 50% == 100 + (100 * .5)
and
100 * 50% == 100 * .5
? 50% * 100, though.. I can see where that would be believable. :/
> > Shouldn't that be
> >
> > >> 100 - 50%
> > == 50%
Not necessarily. It'd be 100 minus 50% of 100, which is 50. Otherwise, you
should stick with 100% - 50% = 50%..
> > and thus
> >
<<quoted lines omitted: 4>>
> > >> tax: price * rate
> > == $8.25
Precisely; the datatype of the first value, the value upon which the percent
is being acted, should be the returned datatype. No?
> > >> taxrate: to-percent [$8.25 / $100]
> > == 8.25%
to-percent on type block! ? I don't see why. Use parens, perhaps, if you
feel the need, but
traxrate: to-percent $8.25 / $100
should be fine. Results in (8.25E-2 * 100), more or less.
Some related, interesting behavior. You can do money! + money!, money! -
money!, money! / money!, but not money! * money!. Heh. money! / money!
results in number!. (I like how integer! and decimal! values all fall under
the category number! .. workes nicely.)
--Charles
[13/80] from: chalz:earthlink at: 7-Jun-2002 1:14
There's always the matter that the list can take up a large part of the
thought and discussion on this matter, formulate a nice proposal, submit the
proposal to the list with RFC, and once people are generally satisfied, submit
the final draft to RT. Save Carl some headache ;)
[14/80] from: jason:cunliffe:verizon at: 7-Jun-2002 1:16
> Yeah, look - we're arguing already. :)
lol
Asking not arguing.. anyway my email was slow getting posted to the list
> But, I remember, to be consistent, shouldn't
> the second datatype be converted to the first
> before the operation takes place ?
> So,
> 100 - 50% == 50 ; as first stated
I am strongly reminded of my early schooldays when our Math teacher relentelssly
brainwashed [initialized] us about percentages for whole term: "Always ask:
'percent of WHAT?'", he said.
And he was right.. I can never listen to the news or advertising or marketing
wonks wihout thinking of that man.. In which case the assumptions must be
clearly stated:
>> 100 - 50%
== 50
That says that the percent is OF the preceding value.
So what does this next one mean?
>> 50% + 100 ???
...If is truly REBOListic then % will have some suprising head tail first next
behaviors..
Meanwhile some other to ponder
>> (100 - 50%) * 10%
== 5
>> 100 * 50%
== 5000%
>> 50% * 100
== ??
> I suppose
> 50% - 100 == -50% ; ? or should be illegal?
No its an Enron hysteresis function. Negative growth.. The policicians love to
ovecome it.
..unless 50% already has some internal series value it is indexing ??
> > >> taxrate: to-percent [$8.25 / $100]
> > == 8.25%
> Uh oh, so to-percent involves an implicit multiplication
> by 100, then? Looks nice, though.
yeah aint it?
./Jason
[15/80] from: robert:muench:robertmuench at: 7-Jun-2002 14:16
> -----Original Message-----
> From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]On Behalf Of
<<quoted lines omitted: 6>>
> bits of code. I think only very complex useful functions should be added to
> the binary.
Hi, I can second this. If RT can include the datatype with some byte increase
than it's worth but if we get 5KB more... I wouldn't add it. Robert
[16/80] from: carl:cybercraft at: 8-Jun-2002 1:50
On 08-Jun-02, Robert M. Muench wrote:
>> -----Original Message----- From: [rebol-bounce--rebol--com]
>> [mailto:[rebol-bounce--rebol--com]]On Behalf Of Paul Tretter
<<quoted lines omitted: 7>>
> increase than it's worth but if we get 5KB more... I wouldn't add
> it. Robert
I think we need it, but not so much because it'd be easier (perhaps)
for programming, but because it's more descriptive. For instance, we
know what this means...
prompt-payment-discount: $5.25
but does this...
prompt-payment-discount: 5.25
mean money or percent?
If it was this though...
prompt-payment-discount: 5.25%
we would know.
Why we're on the subject of new datatypes, what others are needed?
Degrees (and minutes) perhaps?
--
Carl Read
[17/80] from: henrik:webz:dk at: 7-Jun-2002 16:48
Citat Carl Read <[carl--cybercraft--co--nz]>:
> On 08-Jun-02, Robert M. Muench wrote:
> >> -----Original Message----- From: [rebol-bounce--rebol--com]
<<quoted lines omitted: 20>>
> Why we're on the subject of new datatypes, what others are needed?
> Degrees (and minutes) perhaps?
We could go on with every single SI unit in existance?
It would be cool if Rebol knew that the unit of voltage divided with amps is
ohm. This way, certain datatypes could get much more than just descriptive, but
it would probably be too much bloat to implement that. Stupid idea, anyway. :-)
Regards,
Henrik Mikael Kristensen
[18/80] from: jason:cunliffe:verizon at: 7-Jun-2002 10:58
> Why we're on the subject of new datatypes, what others are needed?
> Degrees (and minutes) perhaps?
GPS Location = YES PLEASE!!!
Mobile com devices will increasingly include GPS in them, some by law.
Navigation, tranportation, vehicle tracking, in-built car systems, geographic
data gathering, smart-maps, web mapping, emergency services, phones, cameras,
monitoring equipemtn, land-mine detectnio, environmental mapping, urban
planningand locations systems, tourism, traffic control, postal services, wifi..
After voice, geo-referencing is among the top 5 killer apps for mobile systems.
REBOL could shine brightly in this area, playing to its strengths, opening up
new apps and services. And without falling foul of heavy established monopolies.
./Jason
[19/80] from: greggirwin:mindspring at: 7-Jun-2002 10:09
Hi Henrik, et al
<<
> Why we're on the subject of new datatypes, what others are needed?
> Degrees (and minutes) perhaps?
We could go on with every single SI unit in existance?
It would be cool if Rebol knew that the unit of voltage divided with amps is
ohm. This way, certain datatypes could get much more than just descriptive,
but
it would probably be too much bloat to implement that. Stupid idea, anyway.
:-)
>>
Not a stupid idea at all. This is where I see dialects playing an important
role, and comes back to what I said in my reply to Andrew, that this is
where I've thought percentages would fit best. You might want to make them a
compound data type, like money, with a precision component that you can
specify. Dealing with monetary values would generally require less precision
than decimal values in the context of scientific use.
I haven't thought about it enough to come up with a good design but, in the
past, I built a Percent object datatype with a number of properties for
flexibility: DecimalPlaces, Precision (i.e. interval rounding), Rounding
(up, truncate, etc), and range limits. For example, mortgages in the U.S.
are priced in eighths, so you need to specify three decimal places with a
precision of 1/8.
Because of floating point errors, you may also need to perform intermediate
smoothing of values to ensure the final outcome is what you expect. I
haven't tested the money! datatype against my other stuff to see how it
fares, but I expect I will at some point. I know there are some basic issues
affecting it already, as people have mentioned here are elsewhere.
Another thing to consider is how monetary values are changing. Eventually,
though maybe not real soon, we will see micropayments instituted. How should
money! and percent! work with .000125% of $0.0001?
--Gregg
[20/80] from: greggirwin:mindspring at: 7-Jun-2002 10:44
Charles, Andrew, et al
<< There's always the matter that the list can take up a large part of the
thought and discussion on this matter, formulate a nice proposal, submit the
proposal to the list with RFC, and once people are generally satisfied,
submit
the final draft to RT. Save Carl some headache ;) >>
Having not tried this before, here's an outline. Andrew, do you want to
maintain this, or would you like me to? Does anyone else want to? Will it
work if people post to this list with a subject starting with "RFC 001"...?
It then falls to the maintainer to make decisions it seems. Should they have
censorship authority, or include all pertintent discussion whether they
agree or not?
--Gregg
------------------------------------------------------------
RFC 001 Percent Datatype
===TITLE
Addition of percent! datatype to all versions of REBOL.
===VERSION
Maintainer: Gregg Irwin <[greggirwin--mindspring--com]>
Date: 07-Jun-2002
Version: 0.0.1
===ABSTRACT
REBOL has a large number of native datatypes, and many people feel that a
percent! datatype would a useful addition.
===DESCRIPTION
Andrew Martin <[Al--Bri--xtra--co--nz]> posted a message to mailing list
suggesting the addition of a percent! datatype to REBOL, and some discussion
followed. The suggestion was made to put together an RFC as a basis for
further discussion, and here it is.
===IMPLEMENTATION
---Declaration Syntax
The proposed syntax is simply a numeric value followed by a percent sign
(%).
100%
8.25%
---Operations against other datatypes
What other datatypes can percent! values be used against?
---Result Coercion
Does one operand or the other determine the resulting datatype?
For example, is $100 * 50% the same as 50% * $100?
---Standard notation versus dialect
Does it provide enough value to say:
$100 * 50%
versus:
$100 * .5
As someone on the list pointed out, does that lead to the question "50% of
*what*?"
It seems much clearer to say:
50% of $100
or
add 8.25% to total
but then you need some way to tell REBOL that this is a new dialect (e.g. a
CALCULATE function that takes a block, like LAYOUT does), or the REBOL lexer
needs to know about the percent! dialect, which may be impractical.
---Precision, accuracy, and rounding
How do you specify the extra information that may be useful, even required.
Two examples I can think of are precision and accuracy (I'm open to better
terms).
Accuracy refers to the number of decimal places a value should maintain.
Precision refers to an "interval" the value should be rounded to. E.g.
eighths (1/8)
Rounding refers to how values should be rounded, when rounding is required.
Examples would be STANDARD (statistical), UP, TRUNCATE, FLOOR, and CEILING.
===REFERENCES
[21/80] from: jason:cunliffe:verizon at: 7-Jun-2002 13:55
> Another thing to consider is how monetary values are changing. Eventually,
> though maybe not real soon, we will see micropayments instituted. How should
> money! and percent! work with .000125% of $0.0001?
Great points Gregg
./Jason
[22/80] from: carl:cybercraft at: 9-Jun-2002 17:56
On 08-Jun-02, Jason Cunliffe wrote:
>> Why we're on the subject of new datatypes, what others are needed?
>> Degrees (and minutes) perhaps?
> GPS Location = YES PLEASE!!!
I'd second that.
And I've been wondering why there isn't already a font! datatype.
Cross-platform issues perhaps?
--
Carl Read
[23/80] from: robbo1mark:aol at: 9-Jun-2002 15:03
In a message dated 6/7/2002 3:20:21 PM GMT Daylight Time,
[carl--cybercraft--co--nz] writes:
> Why we're on the subject of new datatypes, what others are needed?
> Degrees (and minutes) perhaps?
How about these;
complex! -1.234+567i ; complex numbers
ratio! 2/3 ; fractions
co-ord! 2.34x1.23 ; co-ordinate - more precise than pair!
octal! 377oct ; octal numbers - integers
hex! FFFFhex ; hexadecimal numbers - integers
binary! 101010bin ; binary numbers - integers note current
REBOL binary
is actually a binary-string! and not a numeric value
stack! s[ 1 2 3 4 ] ; a stack block! which grows from bottom
up and for which insert is quasi-elementary - really the opposite of a block!
ie a reverse block!
>> make stack! [ 4 3 2 1 ]
== #[stack! [1 2 3 4]]
unicode-char! #'a' ; utf unicode two byte multi-lingual
character sets
unicode-string! u"Hello" & u{Hello} ; ditto as above for uni-code strings
typed-series! vector decimal! [1.1 2.2 3.3] ; more efficient tpyed block!
storage
>> vector integer! [1 2 3 4]
== #[vector integer! [1 2 3 4]]
>> vector integer! [1 2 3 "hello"]
** script error! Value "hello" of type string! expected type of integer!
** near vector integer! [1 2 3 "hello"]
And these are only for starters - a better money! type which supports
international
currency symbols and formats would be better than the dollar centric nonsense
we
have just now.
Just my thoughts,
Mark Dickson
[24/80] from: joel:neely:fedex at: 10-Jun-2002 7:03
Hi, Gregg,
Gregg Irwin wrote:
> We could go on with every single SI unit in existance?
>
> Not a stupid idea at all. This is where I see dialects playing an
> important role, and comes back to what I said in my reply to Andrew,
> that this is where I've thought percentages would fit best.
>
I agree completely. Such things belong in a dialect, not in the
core language.
Looking back at the history of programming languages, there's an
issue of balance between
a simple language a bloated language
which is small and which is complex and
easy to learn, but and impossible to learn
too small for real because of unbridled
programming tasks feature creep
(and so never used) (and so never used)
There's a "sweet spot" in the middle, and I respectfully suggest
that REBOL/Core should seek to find (and STAY IN) that zone. The
whole idea of an extensible language is to provide the most common
and useful set of features, along with a simple means for the
programmer to add those concepts that are required for the special
circumstances of a particular task/project.
That said...
Instead of asking for specific twiddles, I'd be interested in the
response of RT to the ideas of either:
- providing a means for extending the syntax within dialects so
that new forms could be added at the mezzanine level, or
- providing a means for switching on/off classes of extensions
(perhaps coded natively) to avoid bloat and namespace collisions
for those cases where the extensions are not needed.
Thoughts, anyone?
-jn-
--
; Joel Neely joeldotneelyatfedexdotcom
REBOL [] do [ do func [s] [ foreach [a b] s [prin b] ] sort/skip
do function [s] [t] [ t: "" foreach [a b] s [repend t [b a]] t ] {
| e s m!zauafBpcvekexEohthjJakwLrngohOqrlryRnsctdtiub} 2 ]
[25/80] from: joel:neely:fedex at: 10-Jun-2002 7:08
Hi, Carl,
Carl Read wrote:
> I think we need it, but not so much because it'd be easier (perhaps)
> for programming, but because it's more descriptive. For instance, we
<<quoted lines omitted: 6>>
> prompt-payment-discount: 5.25%
> we would know.
That's what comments (or descriptive names) are for.
prompt-payment-discount-percent: 5.25
prompt-payment-discount-factor: 1.0 - (5.25 * 0.01)
or
prompt-payment-discount: 0.0525 ;; 5 1/4 percent
IMHO.
-jn-
--
; Joel Neely joeldotneelyatfedexdotcom
REBOL [] do [ do func [s] [ foreach [a b] s [prin b] ] sort/skip
do function [s] [t] [ t: "" foreach [a b] s [repend t [b a]] t ] {
| e s m!zauafBpcvekexEohthjJakwLrngohOqrlryRnsctdtiub} 2 ]
[26/80] from: joel:neely:fedex at: 10-Jun-2002 7:12
Hi, Jason,
Jason Cunliffe wrote:
> > Why we're on the subject of new datatypes, what others are needed?
> > Degrees (and minutes) perhaps?
>
> GPS Location = YES PLEASE!!!
>
...
> After voice, geo-referencing is among the top 5 killer apps for
> mobile systems. REBOL could shine brightly in this area, playing
> to its strengths, opening up new apps and services. And without
> falling foul of heavy established monopolies.
>
Having a new type (perhaps DEGREES!) which recognizes angle/lat/lon
values with degrees, minutes, and seconds, handles the conversions
and manipulation of the parts correctly/automatically would come
much close IMHO to the case of an extension which COULD be written
at mezzanine level but would greatly improve in performance if in
the native level.
That said, how many of us currently are writing code that would use
such a type? (And, yes, I know that there's a chicken/egg issue
here, but I'm still wondering...)
-jn-
--
; Joel Neely joeldotneelyatfedexdotcom
REBOL [] do [ do func [s] [ foreach [a b] s [prin b] ] sort/skip
do function [s] [t] [ t: "" foreach [a b] s [repend t [b a]] t ] {
| e s m!zauafBpcvekexEohthjJakwLrngohOqrlryRnsctdtiub} 2 ]
[27/80] from: joel:neely:fedex at: 10-Jun-2002 7:16
Hi, Mark,
I think you've made my point... ;-)
[Robbo1Mark--aol--com] wrote:
> In a message dated 6/7/2002 3:20:21 PM GMT Daylight Time,
> [carl--cybercraft--co--nz] writes:
<<quoted lines omitted: 25>>
> ** near vector integer! [1 2 3 "hello"]
> And these are only for starters ...
Is it really in the best interests of RT, REBOL the language, IOS,
or the REBOL community for RT to be dealing with everything we can
imagine????
Let's not forget that the foundation of the language something called
REBOL/Core! Provided that we have the ability to extend the language
ourselves at the mezzanine level, I respectfully suggest that RT can
be using their time more productively on other issues than shopping
lists such as the above.
-jn-
--
; Joel Neely joeldotneelyatfedexdotcom
REBOL [] do [ do func [s] [ foreach [a b] s [prin b] ] sort/skip
do function [s] [t] [ t: "" foreach [a b] s [repend t [b a]] t ] {
| e s m!zauafBpcvekexEohthjJakwLrngohOqrlryRnsctdtiub} 2 ]
[28/80] from: joel:neely:fedex at: 10-Jun-2002 7:05
Hi, Paul,
I don't normally care for "I agree" posts that add no new ideas, but
this is an important issue. Therefore I feel compelled to respond to
your POV...
Paul Tretter wrote:
> The question always comes to mind - do we really need one? After
> all, why add more code to the binary when we already can handle
> percents with a few bits of code. I think only very complex useful
> functions should be added to the binary.
>
I absolutely, completely agree, with the only exception that common
cases which could receive a performance boost from being coded in
the native layer should also be considered. (I.e. when there's a
performance payback in things we often do...)
-jn-
--
; Joel Neely joeldotneelyatfedexdotcom
REBOL [] do [ do func [s] [ foreach [a b] s [prin b] ] sort/skip
do function [s] [t] [ t: "" foreach [a b] s [repend t [b a]] t ] {
| e s m!zauafBpcvekexEohthjJakwLrngohOqrlryRnsctdtiub} 2 ]
[29/80] from: g:santilli:tiscalinet:it at: 10-Jun-2002 14:54
Hi Joel,
On Monday, June 10, 2002, 2:03:19 PM, you wrote:
JN> - providing a means for extending the syntax within dialects so
JN> that new forms could be added at the mezzanine level, or
MAKE DATATYPE! would be really cool. :) (Together with MAKE
NATIVE! ;)
Regards,
Gabriele.
--
Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer
Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r
[30/80] from: ammon:rcslv at: 8-Jun-2002 15:49
Hi again Joel,
I think that you are refering to the 'module functions that are promised for
version 3.0? If that is the case then maybe we should be patient and in the
mean time develop the dialect that effectively emulates a percent dataype, i
just wonder....
>> type? 55%
** Syntax Error: Invalid integer -- 55%
** Near: (line 1) type? 55%
>> [55%]
** Syntax Error: Invalid integer -- 55%
** Near: (line 1) [55%]
>> parse [55%] rules
** Syntax Error: Invalid integer -- 55%
** Near: (line 1) parse [55%] rules
hm... It appears that a dialect as has been described wouldn't even be
possible. Any ideas?
Enjoy!!
Ammon
A short time ago, Joel Neely, sent an email stating:
[31/80] from: robbo1mark:aol at: 10-Jun-2002 12:49
To implement a percent! datatype or any other "shopping list" of new datatypes requires
one to write an extended version of the LOAD function to parse script input and correctly
identify and make new object! instances of the percent! and other new datatypes.
You also have to extend the TYPE? function to correctly handle your special new object!
datatype representations and return your intended percent! or whatever.
Any other new methods such as arithmetic, print / output formatting etc also have to
be defined.
Basically your write another interpreter and functions on top of REBOL to handle your
new datatypes, which is certainly do-able and REBOL/Core has loads of useful functions
for implementing this.
A reader macro function like the lisp / scheme 'extend-syntax and 'syntax-rules functions
for REBOL would make this so much easier and allow for easier extensions of REBOL at
the mezzanine level as Joel would like.
Maybe it would be better if REBOL like Lisp, Scheme, Perl, PHP, Python, Ruby, TCL, OCAML,
to name but a few, could be extended at ALL levels and not just the mezzanine level but
we've done this to death before - sigh!
Mark Dickson
[32/80] from: greggirwin:mindspring at: 10-Jun-2002 10:30
Joel and Gabriele,
<<
JN> - providing a means for extending the syntax within dialects so
JN> that new forms could be added at the mezzanine level, or
MAKE DATATYPE! would be really cool. :) (Together with MAKE NATIVE!
;)
>>
That could be really cool, but don't datatypes have to fit into REBOL's
lexicon? The risk, of course, being that RT might have a very hard time
adding extensions themselves unless we had a specific namespace where user
datatypes lived. That pretty much bring us back to dialects, doesn't it?
--Gregg
[33/80] from: g:santilli:tiscalinet:it at: 10-Jun-2002 19:46
Hi Gregg,
On Monday, June 10, 2002, 6:30:03 PM, you wrote:
GI> That could be really cool, but don't datatypes have to fit into REBOL's
GI> lexicon?
Of course. But maybe having user datatypes as #[mytype! ...] is
enough for us... what do you think? Or, it could be possible to
plug in parse rules in REBOL's parser, that are used when the rest
fails; this might create problems, so maybe its better not
allowing it...
Regards,
Gabriele.
--
Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer
Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r
[34/80] from: joel:neely:fedex at: 10-Jun-2002 15:31
Hi, Gregg,
IANARTE (I Am Not A REBOL Technologies Employee... ;-) but I suspect
that data types are entangled with the lexical scanning performed
by LOAD. IOW, it might be necessary to provide a specification for
how to recognize values of a new datatype at the lexical token level,
and that might not be convenient/feasible...
Just a guess!
-jn-
Gregg Irwin wrote:
[35/80] from: carl:cybercraft at: 11-Jun-2002 20:12
On 11-Jun-02, Joel Neely wrote:
Hi Joel,
Good to have you back.
And see below...
> Carl Read wrote:
>> I think we need it, but not so much because it'd be easier
<<quoted lines omitted: 12>>
> or
> prompt-payment-discount: 0.0525 ;; 5 1/4 percent
Okay, not a good example, so you missed my point. (:
Instead, compare this...
[1.05 12.75 1.15 19.22]
with this...
[%1.05 $12.75 1.15 19.22%]
The datatypes make the data descriptive, both to people and REBOL.
VID's a good example of making use of this, where a number is treated
as width, a pair as width and height, a string as text and so on.
And because they're individual datatypes we don't have to remember a
specific order they need to be in. This doesn't of course work for
all cases as you're often going to need more than one of each
datatype, but it's a very useful feature to have. So instead of
something like this...
button label "A button" width 100 depth 50 color 255.0.0
we can have this...
button "A button" 100x50 255.0.0
I don't think new datatypes should be added willy-nilly, but percent
is definately one that should be there. They wouldn't give it a
button on nearly every calculator if it wasn't in very common use now,
would they?
--
Carl Read
[36/80] from: joel:neely:fedex at: 11-Jun-2002 6:56
Hi, Carl,
Carl Read wrote:
> Good to have you back.
>
Thanks, although I'll probably be intermittent for the next
few weeks (wedding is 6 July)...
> Okay, not a good example, so you missed my point. (:
>
I don't think so... but it's possible. My response was simply
that it's easy to deal with this issue in a variety of ways.
I'd rather see the time spent by RT (and the learning effort
by the user community) be spent on things for which there IS
NOT such an easy fix. For example:
pct: func [n [number!]] [n / 100.0]
allowing me to say
tax-rate: 8.25 ;; percent
tax: net-purchase * pct tax-rate
as one of many simple ways to handle the matter in a form
that should be obvious to most readers.
As an example on the other side of the issue, here's a very
simple (over-written, even) bit of Perl code that's much more
typical of the kinds of tasks I do day-in and day-out:
#!/usr/local/bin/perl -w
my %tally = ();
while (<>) {
tr/A-Z/a-z/;
foreach my $word (split /[^a-z]+/i) {
++$tally{$word};
}
}
foreach my $word (sort keys %tally) {
print "$tally{$word}\t$word\n";
}
(This is a complete Perl script that takes any number of
file names as command line arguments, reads each file,
splitting all input into "words" -- maximal strings of
alphabetic characters, all converted to lower-case --
and counts the number of times each word appears. The
output is a sorted list of word frequencies.)
While people poke fun at Perl's use of punctuation and other
obscure syntax, the fact remains that the notation serves as
abbreviation for a LARGE amount of (commonly-used, in my own
experience) boilerplate code, thus saving considerable effort
for the programmer. For just two examples:
tr/A-Z/a-z/
converts all (ASCII) alpha characters to the corresponding
case, and
++$tally{$word}
takes WORD as a key into the TALLY hash, and increments the
corresponding total. On the first such occurrence, the
result of looking WORD up in TALLY is the undefined value,
which Perl treats for numeric purposes as zero, therefore
no special-case code is needed for initialization. (I see
this as the numeric equivalent of the fact that REBOL views
NONE as equivalent to FALSE -- and non-NONE as TRUE -- for
the purpose of decision-making.)
Let me emphasize that I am NOT trying to turn REBOL into
Perl, but am simply trying to illustrate a conceptually
simple task that requires subtantially more coding effort
in REBOL. I fully realize that the nature of one's work
significantly influences one's view of which features are
most commonly used, but since REBOL is positioned as a
messaging language
to serve as the foundation of an
Internet Operating System, I respectfully suggest that there
would be more payback to investing effort in text processing
and efficient data structure manipulation than in helping
folks avoid remembering that
15%
can be rewritten as
.15
but that's a matter of opinion, I suppose. (And I freely
admit that I spend very little time calculating taxes and
discounts in my normal workload.)
> I don't think new datatypes should be added willy-nilly,
> but percent is definately one that should be there. They
> wouldn't give it a button on nearly every calculator if
> it wasn't in very common use now, would they?
>
Ah, but please don't forget that I can't teach my calculator
new words! There are some big differences here:
1) The calculator can ONLY do simple arithmetic;
2) It is purchased by people who need help with that very
specific task;
3) There's no way to shorten the sequence of keystrokes
required to multiply by a factor and then divide by
one hundred;
4) Many cheap numeric calculators fail to offer any means
to repeat an operation, nor to see an "audit trail" of
previous calculations; consequently undetected (and
undetectable, without repeating the calculation) errors
are much more likely;
whereas:
1) Arithmetic is only a very small fraction of what one can
accomplish with REBOL;
2) It is written by persons who presumably possess SOME
level of knowledge of arithmetic;
3) It is easy to write a trivial divide-a-number-by-100
function and then use it wherever one wishes;
4) REBOL source code can be examined, verified, debugged,
etc. and thereafter used by ... well ... "users" who
simply count on the script to continue to behave in the
same way, without their having to know anything about
how it works.
Again, (from the first point) let's consider "bang for the
buck" issues, as well as the old saying,
If you give a man a fish,
you've fed him for a day;
if you teach a man to fish,
you've fed him for a lifetime.
I'd much rather have REBOL extended with a facility that
would allow me to define lexical syntax for a new data type,
along with appropriate input/output formatting rules, than
simply to have a (no offense) trivial case like percentages
added to the core language. The latter would address only a
very narrow issue, whereas the former would extend REBOL in
a way that would allow programmers in all kinds of application
areas to benefit.
Just my $0.02...
-jn-
--
; Joel Neely joeldotneelyatfedexdotcom
REBOL [] do [ do func [s] [ foreach [a b] s [prin b] ] sort/skip
do function [s] [t] [ t: "" foreach [a b] s [repend t [b a]] t ] {
| e s m!zauafBpcvekexEohthjJakwLrngohOqrlryRnsctdtiub} 2 ]
[37/80] from: carl:cybercraft at: 12-Jun-2002 21:04
On 11-Jun-02, Joel Neely wrote:
> Hi, Carl,
>> Okay, not a good example, so you missed my point. (:
>>
> I don't think so... but it's possible.
Hi Joel,
And yes - I think you still have! (:
> My response was simply
> that it's easy to deal with this issue in a variety of ways.
<<quoted lines omitted: 7>>
> as one of many simple ways to handle the matter in a form
> that should be obvious to most readers.
Yes, but REBOL's a Net-centric language, so it's from the Net my
example come from...
<TABLE WIDTH="80">
<TABLE WIDTH="80%">
> As an example on the other side of the issue, here's a very
> simple (over-written, even) bit of Perl code that's much more
<<quoted lines omitted: 37>>
> simple task that requires subtantially more coding effort
> in REBOL.
I don't know Perl, though I think I know what you mean by the above
example, (by reading your description, not the Perl code:), and I
can't see it taking "substantially" more code, though perhaps a bit
more typing. I may have misunderstood though, so how would you do it
in REBOL? (Then I'd be sure I know what it is meant to do...)
> I fully realize that the nature of one's work
> significantly influences one's view of which features are
<<quoted lines omitted: 7>>
> can be rewritten as
> .15
Not in the above HTML example it can't be... (Says Carl, wondering
what actually is supposed to happen when a decimal value is given as
a width in HTML. His guess is it's meant to be part of a pixel...)
> but that's a matter of opinion, I suppose. (And I freely
> admit that I spend very little time calculating taxes and
> discounts in my normal workload.)
Me neither. But how much time do you spend writing View/VID code?
Because of this discussion I've started to wonder if one of the
reasons there's no book on View from RT yet is because they haven't
implimented the percent datatype yet. Without it and the appropriate
updates to View and VID it's severly crippled in the user-friendly
department. We should be able to write dynamic, auto-resizing
layouts with ease using something like this...
view/options layout [
across
box red 10% box green 20% box blue 70%
][resize]
with the boxes changing their sizes automatically when the user
resizes the window. (Obviously pairs need to be updated as well to
allow for the likes of 10%x20% and 12%x20 and so on.) Sizes then
would be measured as pixels when numbers are used and as percentages
of the width of the pane's parent when percentages are used. (Just a
simple example of how it might work. Mixing dynamic and fixed panes
within a face obviously requires more thought.)
This to my mind is the attraction of datatypes - they describe what
they are by themselves, to both the programmer and REBOL. This is
useful for a lot of reasons. In the above example for instance
where the difference between a 15 and a 15% could be easily spotted
when a layout didn't turn out how you expected. And if a function's
expecting money then it'll trip up if a decimal is given. But if you
want a function to accept a percentage value it'll happily confuse a
decimal for one in the current REBOL. Of course, we could get by
quite happily on just binary! and char! datatypes I guess. I don't
want to though...
[Snipped sidetrack about calculator buttons:]
> Again, (from the first point) let's consider "bang for the
> buck" issues, as well as the old saying,
<<quoted lines omitted: 8>>
> added to the core language. The latter would address only a
> very narrow issue,
Ah - but it wouldn't, as hopefully I've explained above. VIEW NEEDS
PERCENT! (;
> whereas the former would extend REBOL in
> a way that would allow programmers in all kinds of application
> areas to benefit.
Yes, that'd be nice. View still needs a native percent! datatype
though. (IMHO:)
> Just my $0.02...
And my 0.02... (;
--
Carl Read
[38/80] from: joel:neely:fedex at: 12-Jun-2002 7:36
Hi, Carl,
Carl Read wrote:
> Yes, but REBOL's a Net-centric language, so it's from the Net my
> example come from...
>
> <TABLE WIDTH="80">
>
> <TABLE WIDTH="80%">
>
The majority of this thread dealt with adding a data type to
REBOL. I see that as a different issue than parsing HTML.
> > ++$tally{$word}
> > takes WORD as a key into the TALLY hash, and increments the
<<quoted lines omitted: 8>>
> though, so how would you do it in REBOL? (Then I'd be sure
> I know what it is meant to do...)
Let me rephrase the problem in REBOL terms, rather than as
a proposed solution:
Write a function of two arguments,
a block named TALLY, which is expected to contain a
collection of strings/count paired values, and
a string named WORD,
which will modify the content of TALLY so that if WORD
already appears in TALLY the corresponding count is
increased by one, but if WORD does not appear in TALLY
it is added along with a count of one.
> > 15%
>
> > can be rewritten as
>
> > .15
>
> Not in the above HTML example it can't be...
>
But, as I said before, the above example is HTML, not REBOL. I
was responding to the idea of adding notation to REBOL for a
percent data type. One can already parse HTML tag attributes
whose value ends in #"%" , and use the presence or absence of that
character suffix as a bit of knowledge in subsequent processing,
without having a new data type created in REBOL.
> > but that's a matter of opinion, I suppose. (And I freely
> > admit that I spend very little time calculating taxes and
> > discounts in my normal workload.)
>
> Me neither. But how much time do you spend writing View/VID code?
>
Essentially none, for two reasons:
- Much of my work is oriented toward analysis of data or
processing of textual content. When working on something
that requires an interface for an end user, I tend to use
HTML so that my user needs nothing but a plain browser.
(I avoid complex JavaScript, Flash, etc. for the same reason.)
When working on something for myself, or for the generated
output, I am perfectly happy with a command line.
- I move among many different environments at work and home
(with a fuzzy boundary between those two...) including:
Solaris, HP-UX, Linux, w95, w2k, and Mac OS X (the personal
laptop on which I do most of my "private" thinking/writing).
I won't be using REBOL/View (or any other tool) until it is
available for all of those platforms.
> Because of this discussion I've started to wonder if one of the
> reasons there's no book on View from RT yet is because they haven't
> implimented the percent datatype yet...
>
I've always assumed a simpler reason; my pre-View experience with
Core was that RT was more busily engaged in working on the design
and implementation of the language itself than in documenting it.
There are still significant parts of Core for which folklore is the
best source of explanation/documentation available. So I'm not at
all surprised to see the same with View.
> view/options layout [
> across
> box red 10% box green 20% box blue 70%
> ][resize]
>
...
> This to my mind is the attraction of datatypes - they describe
> what they are by themselves, to both the programmer and REBOL.
>
To piggyback on a comment already made in this discussion, there
are only two ways I know of to understand a percentage value:
- as a portion of *something*, in which case it is necessary to
indicate the "something" one has in mind, or
- as a "pure" real number with the radix point left-shifted
by two digits.
Simply exhibiting a numeric string with "%" tacked on the end
doesn't automatically convey which of the above, nor in the
second case what the base "something" might be. Therefore, I
have two responses to your hypothetical (I assume) example
(and I freely confess limited exposure to View for reasons
stated above):
1) I spend a bit of time with graphics and color issues, so
my first thought on seeing the above was:
Hmmm... He's describing a box colored 10% red (25.0.0),
another box colored 20% green (0.51.0) and a third box
colored 70% blue (0.0.178).
As I'm just as comfortable using percentages to specify
colors as sizes, merely exhibiting a percentage value simply
*doesn't* "describe what they are by themselves" without more
context -- which clearly I lacked in this case.
2) If the point is to have notation to show a factor by which
something is related to something else (given the need for
the *two* somethings to be clearly understood), why couldn't
your hypothetical example have been written just as easily as:
view/options layout [
across
box red .1 box green .2 box blue .7
][resize]
or do decimal! values already have some specific meaning within
the View dialect?
> [Snipped sidetrack about calculator buttons:]
>
I guess I'm puzzled by the "sidetrack" description. IIRC you used
the existance of a "%" key on a calculator as part of your argument
for creating a new type in REBOL, so I responed with reasons why I
think calculator keyboards and REBOL are different.
> Ah - but it wouldn't, as hopefully I've explained above. VIEW NEEDS
> PERCENT! (;
>
...
> Yes, that'd be nice. View still needs a native percent! datatype
> though. (IMHO:)
>
In order to what? I've just gone back and reread the entire thread
and your last post is the only place I see part-sizing in View as
the compelling reason why a percent data type is needed. Your own
argument earlier in the thread
> I think we need it, but not so much because it'd be easier
> (perhaps) for programming, but because it's more descriptive.
<<quoted lines omitted: 6>>
> prompt-payment-discount: 5.25%
> we would know.
wasn't View-specific as far as I could tell.
I guess my point remains the same:
Within the context of RT's stated mission for REBOL/Core,
/View, and IOS, what are the highest-priority areas for
investment of RT's limited resources?
Overall, my answer would remain what it has been for quite some
time: producing comprehensive, authoritative specifications and
documentation for REBOL/Core, /View, etc... The members of this
list (and specifically those involved in existing books, the Zine,
and the REBOLforces web site) have already demonstrated that there
are several folks who could take up the torch and produce tutorial
and introductory material. However, that work would proceed much
more quickly in the presence of clear statements of what REBOL is
intended to do, avoiding the need for "particle physics" to try
to guess the intent or implementation.
If the question instead is "What feature, if added to REBOL, would
make it easier to promote widespread use of the language?" I'd
still have to say that improvements in the convenience of text and
data structure manipulation seem to me to have a higher payback than
the addition of what amounts to a variation on the decimal! type.
Just my 0.4% of $5.00 ... ;-)
-jn-
--
; Joel Neely joeldotneelyatfedexdotcom
REBOL [] do [ do func [s] [ foreach [a b] s [prin b] ] sort/skip
do function [s] [t] [ t: "" foreach [a b] s [repend t [b a]] t ] {
| e s m!zauafBpcvekexEohthjJakwLrngohOqrlryRnsctdtiub} 2 ]
[39/80] from: greggirwin:mindspring at: 12-Jun-2002 10:52
Joel, Carl, et al
The argument for percent! being useful in VID makes me think......ouch! :)
Quick thoughts:
1) VID is a dialect, so adding support for ##% syntax isn't the same as
adding a percent! datatype. I don't have a problem extending VID's syntax in
that way except that...
2) Adding that ability opens up a whole can of worms related to pair! values
which don't support even decimal components at this time, only integers.
--Gregg
[40/80] from: jason:cunliffe:verizon at: 12-Jun-2002 14:15
Hi.. Interesting the twists and turns this has taken so far..
Although I am PRO a new REBOL percentage datatype, I don't buy into this
argument that it's so essential to VID.
VID needs documentation and example. But above all it needs a stronger set of
useful modern interfaces for resizing, nesting tables, spacers, sizers, split
views etc..
They need a friendly dialect/syntax suitable for reading and writing GUI
layouts.
percent% as datatype is surely the smallest part of that problem.
Yes it might be nice, but the description of relative/absolute widths etc, could
equally well be handled by a block syntax.
Anyway, 'OF' seems like a valid addition and is very readable.
Perhaps a new operator is more important than the datatype, and thus may be also
easier to explore.
>> 50% x 20%
bothers me.. I argue don't mix pair values and percent.
>> 50% of 20% of something
ok now does make sense.
Whatever happens with implementing % percent datatype, thinking about 'OF' has
interesting consequences.. For example consider this:
>> position: 400x20
>> table: 120x30
== 120x30
>> type? table
== pair!
>> 0.4 * table
** Script Error: Cannot use multiply on decimal! value
** Near: 0.4 * table
>> 50% of xy ;<< wishful thinking
== 60x15
...or if percent is not available, we can just use
>> 0.5 of table
== 60x15
>> 0.5 of table/x
== 60
>> half: 0.5
>> half of my-profit all of my-love
>> position image-box half height of screen
In layout dialect we want to be smarter add more readable [x y width height area
margin indent]
What y'all think??
./Jason
[41/80] from: carl:cybercraft at: 13-Jun-2002 12:09
Hi Joel,
On 13-Jun-02, Joel Neely wrote:
> Carl Read wrote:
>>
<<quoted lines omitted: 7>>
> The majority of this thread dealt with adding a data type to
> REBOL. I see that as a different issue than parsing HTML.
I wasn't talking about parsing HTML, but about being expressive. That
one little "%" character makes all the difference. No need to have a
WIDTH-IN-PERCENTAGE along with WIDTH as a way of expressing table
widths. Anyone moving from HTML to REBOL would expect that kind of
ease of use in layouts and wonder why it isn't there. And the answer
is because there's no percent! datatype in REBOL yet...
>>> ++$tally{$word}
>>
<<quoted lines omitted: 21>>
> increased by one, but if WORD does not appear in TALLY
> it is added along with a count of one.
add-word: function [tally [block!] word [string!]][temp][
either temp: find/skip tally word 2 [
temp/2: temp/2 + 1
][
append tally reduce [word 1]
]
]
Seems to work...
>> test: []
== []
>> add-word test "Word A"
== ["Word A" 1]
>> add-word test "Word B"
== ["Word A" 1 "Word B" 1]
>> add-word test "Word B"
== ["Word B" 2]
>> head test
== ["Word A" 1 "Word B" 2]
>> add-word test "Word A" head test
== ["Word A" 2 "Word B" 2]
>> add-word test "Word A" head test
== ["Word A" 3 "Word B" 2]
>> add-word test "Word A" head test
== ["Word A" 4 "Word B" 2]
>> add-word test "Word C" head test
== ["Word A" 4 "Word B" 2 "Word C" 1]
though it was shorter than you English description of what you wanted,
so perhaps I'm still missing something?
>>> 15%
>>
<<quoted lines omitted: 10>>
> character suffix as a bit of knowledge in subsequent processing,
> without having a new data type created in REBOL.
But this gives us an error Joel...
>> [box 10%]
** Syntax Error: Invalid integer -- 10%
** Near: (line 1) [box 10%]
>>> but that's a matter of opinion, I suppose. (And I freely
>>> admit that I spend very little time calculating taxes and
<<quoted lines omitted: 9>>
> When working on something for myself, or for the generated
> output, I am perfectly happy with a command line.
So, because you have no need for a percent datatype, noone has?
> - I move among many different environments at work and home
> (with a fuzzy boundary between those two...) including:
> Solaris, HP-UX, Linux, w95, w2k, and Mac OS X (the personal
> laptop on which I do most of my "private" thinking/writing).
> I won't be using REBOL/View (or any other tool) until it is
> available for all of those platforms.
Fair enough. But others using other OSs and every IOS user (I assume)
are using View. And they need to be able to create dynamic layouts
with ease. A percentage datatype is the obvious way to do this.
>> Because of this discussion I've started to wonder if one of the
>> reasons there's no book on View from RT yet is because they
<<quoted lines omitted: 5>>
> best source of explanation/documentation available. So I'm not at
> all surprised to see the same with View.
And major parts of View are folklore too. (: And I can understand why
they may not have had time to do a View Guide, but I can also see
them thinking that there's no point in doing one till scalable
layouts are made simple. And, to belabour my point, it's a percent
datatype that will make them simple, and it'd be consistant with how
View/VID works now.
>> view/options layout [
>> across
<<quoted lines omitted: 26>>
> *doesn't* "describe what they are by themselves" without more
> context -- which clearly I lacked in this case.
Your lack of knowledge of VID shows there. I know on its own a
percentage doesn't convey what it's a percentage of, but neither do
any of the other values used in VID styles. What for instance do you
think the color datatype here is applied to...
view layout [box "hello" 255.0.0]
? Is it the text or the box? And what about with this example...
view layout [box 255.0.0 "hello"]
? With VID styles, the most common (in RT's eyes) use for a datatype
doesn't have to be spelt out. Styles have default settings, but add
a datatype and that'll change one of the default settings. And with
layouts, a face's size would be the obvious thing to change if we
could add percent datatype after the style's name.
> 2) If the point is to have notation to show a factor by which
> something is related to something else (given the need for
<<quoted lines omitted: 6>>
> or do decimal! values already have some specific meaning within
> the View dialect?
Not that I know of, so I guess they may be reserved for percentages.
Though it's possible a percent datatype could be used for colors and
decimals for face sizes, but I supect RT would go for using a percent
datatype for sizes. Either way, it'll be a useful addition.
>> [Snipped sidetrack about calculator buttons:]
> I guess I'm puzzled by the "sidetrack" description. IIRC you used
> the existance of a "%" key on a calculator as part of your argument
> for creating a new type in REBOL, so I responed with reasons why I
> think calculator keyboards and REBOL are different.
It was me who went up the sidetrack. It was just to show what people
expect. Like people expect a GUI, not a CLI. (;
>> Ah - but it wouldn't, as hopefully I've explained above. VIEW NEEDS
>> PERCENT! (;
<<quoted lines omitted: 25>>
>>
> wasn't View-specific as far as I could tell.
And as I said, it wasn't a good example, so you didn't get what I was
on about. My example of its use in View is a better example of what
I mean about datatypes being descriptive to both people and REBOL.
> I guess my point remains the same:
> Within the context of RT's stated mission for REBOL/Core,
<<quoted lines omitted: 15>>
> data structure manipulation seem to me to have a higher payback than
> the addition of what amounts to a variation on the decimal! type.
Well, I answered your problem regarding adding words to a list to my
satisfaction, (though perhaps not to yours), so perhaps you'd like to
show me an easy way to modify this little View layout...
view/options layout [text-list][resize]
so that when you resize the window the text-list resizes with it? My
prefered way to do it would be this...
view/options layout [text-list 100%x100%][resize]
--
Carl Read
[42/80] from: carl:cybercraft at: 13-Jun-2002 9:52
On 13-Jun-02, Gregg Irwin wrote:
> Joel, Carl, et al
> The argument for percent! being useful in VID makes me
> think......ouch! :)
> Quick thoughts:
> 1) VID is a dialect, so adding support for ##% syntax isn't the same
> as adding a percent! datatype.
Hi Gregg,
Short of puting the percent value in a string, how do you write a
dialect to get around the following? ...
>> [10%]
** Syntax Error: Invalid integer -- 10%
** Near: (line 1) [10%]
> I don't have a problem extending
> VID's syntax in that way except that...
> 2) Adding that ability opens up a whole can of worms related to
> pair! values which don't support even decimal components at this
> time, only integers.
Perhaps because they're saving decimals for percentages and didn't
want a whole heap of scripts out there already using them in pairs
when it's introduced? ie, so it /won't/ open a can of worms when
it's introduced.
--
Carl Read
[43/80] from: kemp:extelligence at: 12-Jun-2002 21:09
For my 2 cents, I'd hate to see Rebol's layout capabilities being based on
HTML -
the Net != HTML, and HTML is not the end word in layout expressiveness;
for that matter, it was originally designed to specifically AVOID layout.
- Kemp
[44/80] from: joel:neely:fedex at: 13-Jun-2002 7:45
Hi, Carl
Carl Read wrote:
> >>> ++$tally{$word}
>
vs.
> add-word: function [tally [block!] word [string!]][temp][
> either temp: find/skip tally word 2 [
<<quoted lines omitted: 3>>
> ]
> ]
Your approach is essentially the same as the one I've used for
such tasks. By my count 16 bytes versus 179 bytes, or 11 times
as much code. I know that this is a dinky example (and if I
take out all of the whitespace used to "pretty-print" the REBOL
version, it shrinks to 139 bytes -- although that renders it
significantly less readable), but here's the point I was trying
to make with this dinky example:
Manipulating non-trivial data structures in REBOL, even
something as simple as a look-up table, involves much more
code and much more intpreter overhead than with several
other languages in the same space -- 'net applications.
I truly believe that addressing that issue would be of
significant value in promoting the wider use of REBOL.
Just for the exercise, I coded the word-count problem in both
Perl (using essentially the same code previously posted) and
REBOL (using essentially the same approach you provided). I
wrote both of them to use a hard-coded file name, to avoid the
additional overhead of command-line parameter handling. For a
sample file, I used the text of "Alice in Wonderland" from the
Gutenberg Project, with the following typical results (median
of three trials):
(/export/home/jneely/try)# wc alice.txt
2415 26434 145197 alice.txt
(/export/home/jneely/try)# time tally.pl > /dev/null
real 0m0.31s
user 0m0.30s
sys 0m0.01s
(/export/home/jneely/try)# time tally.r > /dev/null
real 0m10.35s
user 0m10.24s
sys 0m0.09s
For a ~142k file, Perl produced a sorted word-count list in under
1/3 second, while REBOL required over 10 1/3 seconds for the same
data.
I'm certainly not claiming that producing a dictionary of "Alice
in Wonderland" is typical of the workload of all REBOL programmers,
but I do believe that the type of processing involved *is* typical
of many server-side scripts, whether CGI or "back-room" data
reduction -- read one or more text files, parse them down and do
some processing on the analyzed text, then spit out some results.
The trade-off between native and mezzanine code is a significant
performance factor in REBOL. The fact that I can write a
function to do some task doesn't change the fact that there's a
run-time cost influenced by how much of the work of that function
must be expressed in mezzanine/user code.
I'm certainly not ignoring the value of graphical user interfaces
(I've been a Mac user since 1984, and my primary personal box is
an iBook running Mac OS X), but I think it will be hard to sell
the idea of a GUI whose underlying data manipulation is awkward
to write and sluggish in performance. (Not to mention the fact
that performance is *T*H*E* issue in server-side programming.
Although Java was widely hyped as a universal client-side
language, most of what I'm seeing in the Java word now is on the
server side -- now that there are JVMs with adequate performance.)
Hence my personal opinion that the cause of REBOL would be more
advanced at this point by attention to facilities for working
with non-trivial data structures and performance, than by adding
another data type.
As for the /View discussion, I'll reply separately.
-jn-
--
; Joel Neely joeldotneelyatfedexdotcom
REBOL [] do [ do func [s] [ foreach [a b] s [prin b] ] sort/skip
do function [s] [t] [ t: "" foreach [a b] s [repend t [b a]] t ] {
| e s m!zauafBpcvekexEohthjJakwLrngohOqrlryRnsctdtiub} 2 ]
[45/80] from: robbo1mark:aol at: 13-Jun-2002 10:04
In a message dated Wed, 12 Jun 2002 8:17:38 PM Eastern Daylight Time, [carl--cybercraft--co--nz]
writes:
> Short of puting the percent value in a string, how do you
> write a
> dialect to get around the following? ...
>
> >> [10%]
> ** Syntax Error: Invalid integer -- 10%
> ** Near: (line 1) [10%]
No need to put the 10% in a string!.
If you are writing a dialect - in this one which
will implement a percent! datatype at the mezzanine
level - we don't have the facility to do it at the native level - you can use REBOL objects!
to simulate
datatypes.
ie 10% would be transformed into this;
percent!: make object! [ datatype: "percent!" value: 0]
make-percentage: func [ n [number!]] [
make percent! [value: n / 100]
]
>> a: make-percentage 10
>> probe a
make object! [
datatype: "percent!"
value: 0.1
]
>>
Yes your dialect has to write all the other methods so your percent! objects can interact
with all the other "native" numeric datatypes in the correct way.
With regards to 10% not generating an invalid integer! error message it's quite trivial
to write a read/load source function to parse source code input for the XX% pattern and
replace with make-percentage x functions.
Basically the dialect implements a small interpreter on top of REBOL to handle your "percentages"
or whatever other datatypes you may wish to implement correctly.
You also have to extend the TYPE? function to return to-word object/datatype == percent!
It's not that difficult, just some careful design, time and effort.
cheers,
Mark Dickson
[46/80] from: joel:neely:fedex at: 13-Jun-2002 11:38
Hi, again, Carl,
With respect to the View issues...
Carl Read wrote:
> So, because you have no need for a percent datatype, noone has?
>
I never said that. What I *did* say is that I believe RT could
do some other things that would have a bigger effect on the
widespread adoption of REBOL.
So far the "datatype as clue to View layout" is the only issue I've
seen raised in this thread that wasn't simply a matter of a shorter
(and arguably more conventional) way to write floating-point values
that indicate ratios or factors.
> Fair enough. But others using other OSs and every IOS user
> (I assume) are using View. And they need to be able to create
> dynamic layouts with ease. A percentage datatype is the obvious
> way to do this.
>
I might agree that it is *A* way to do it, but I don't think it's
the only possibility by any stretch of the imagination.
> > 1) I spend a bit of time with graphics and color issues, so
> > my first thought on seeing the above was:
>
> Your lack of knowledge of VID shows there.
>
Now, with all due respect, I must insist that you missed *my* point.
If the burning need here is to have a distinct data type so that one
can stick an unlabeled value in a layout block and have View use it
for control of scaling, then I'd still wonder whether a decimal!
value could serve that purpose.
It is certainly arguable that a string attribute of a button widget
is most reasonably assumed to be the label displayed on the button.
However, the more attributes we add to a widget, the more we have
the possibility that multiple attributes can reasonably have values
of the same type. Instead of addressing this situation by insisting
on the creation of a new data type for every attribute (or for those
attributes deemed most common for some purposes) I question whether
the "datatype as only clue" approach itself scales well.
The punch line is that I have serious reservations about a notation
that leans heavily on datatypes (and large doses of assumption about
the most likely meaning or most frequent use) to specify complex
artifacts.
> Though it's possible a percent datatype could be used for colors and
> decimals for face sizes, but I supect RT would go for using a percent
> datatype for sizes. Either way, it'll be a useful addition.
>
I'm sure some of use would consider it useful (for some definitions of
use
at least ;-). I'm just suggesting that "useful" and "most urgent
to deal with right now" are distinct concepts.
> Well, I answered your problem regarding adding words to a list to
> my satisfaction, (though perhaps not to yours), so perhaps you'd
<<quoted lines omitted: 3>>
> My prefered way to do it would be this...
> view/options layout [text-list 100%x100%][resize]
I'll be glad to respond, with a few disclaimers:
1) I make no pretense at View expertise, so it'll be easy for someone
to pick at details or inconsistencies with other View notation. I
trust that's not the purpose of your question, however.
2) I've fiddled quite a bit over the years with a variety of toolkits
for building GUIs, and have some fairly strong impressions about
what was (or was not) well done in various languages.
I believe that building a usable GUI for a non-trivial application
is a very demanding task, already difficult enough if one assumes
fixed-sized windows. If we throw resizing into the mix, then
specifying what is and isn't to flex can become *highly* complex
IMHO. Look at all of the complexity surrounding "layout managers"
in Java (and how often programmers give up on the fancier options
in favor of simplicity) as an indication of how nasty it can get.
3) I haven't thought long and hard about how I think a GUI
specification
notation should look or function, so you're getting off-the-cuff
responses here.
With that said, let me add my preference for a design strategy of
"Make simple things simple, and complicated things possible"
If I can imagine changing View to follow that principle, I would favor
something like the following. If you write
view/options layout [... some widget specs...] [resize]
then ALL enclosed widgets would scale proportionally when the container
resizes. I'd add widget-by-widget attributes of
scalex
to mean fixed-height, scaling-width,
scaley
to mean fixed-width, scaling-height, and
noscale
to mean just what it sounds like. Thus, for example, a vertical
scrollbar
would have SCALEY as an attribute to allow it to resize vertically but
not
change width, a horizontal scrollbar would have SCALEX, a thumbnail icon
could have NOSCALE, etc...
For any more complex scanarios, I'd put the monkey back on the
programmer
with something vaguely like
view/options layout [... some widget specs ...] [resizeby function]
where the offered function (by name or anonymous) would be invoked to
handle the resizing, and would be able to use some simple interface to
adjust the size of each component widget within the layout, so that a
programmer wanting a more sophisticated layout-management strategy
would have a way to implement it.
Again, let me repeat that I'm not trying to play "duelling examples"
here, but to ask the question "What could be done to make REBOL more
attractive to users and developers who currently are not aware or
interested?" I trust we all would like to see that result!
-jn-
[47/80] from: robbo1mark:aol at: 13-Jun-2002 12:57
In a message dated 13/06/02 17:46:27 GMT Daylight Time, [joel--neely--fedex--com]
writes:
> Again, let me repeat that I'm not trying to play "duelling examples"
> here, but to ask the question "What could be done to make REBOL more
> attractive to users and developers who currently are not aware or
> interested?" I trust we all would like to see that result!
>
More fast / native text processing functions like PERL has and a "shopping
list" of new rich datatypes! as well as succinct assignment op!'s for example
>> a: 5
== 5
>> a += 1 ; slightly shorter than as a: a + 1
== 6
>> a
== 6
Lots more ......
Mark Dickson
[48/80] from: greggirwin:mindspring at: 13-Jun-2002 11:35
Hi Carl,
<< Short of puting the percent value in a string, how do you write a
dialect to get around the following? ...
>> [10%]
** Syntax Error: Invalid integer -- 10%
** Near: (line 1) [10%]
>>
Yeah, that's a problem all right. The first option, which is ugly and not
VID-oriented, is to use a string for your dialect data source, rather than a
block. Blocks are awfully convenient for writing dialects though. :( The
other option, also ugly, would be to make them an issue! (e.g. #10%), but I
don't care for that much either.
In any case, I hope RT has made a note about it so they can consider it in
the grand scheme of things to come.
--Gregg
[49/80] from: kemp:extelligence at: 13-Jun-2002 13:50
>>
However, the more attributes we add to a widget, the more we have
the possibility that multiple attributes can reasonably have values
of the same type. Instead of addressing this situation by insisting
on the creation of a new data type for every attribute (or for those
attributes deemed most common for some purposes) I question whether
the "datatype as only clue" approach itself scales well.
The punch line is that I have serious reservations about a notation
that leans heavily on datatypes (and large doses of assumption about
the most likely meaning or most frequent use) to specify complex
artifacts.
<<
Well put! That was the first thing I questioned as I started working with
VID.
Too much implicit information makes for assumptions that don't scale.
- Kemp
[50/80] from: greggirwin:mindspring at: 13-Jun-2002 12:11
Hi All,
<< a += 1 ; slightly shorter than as a: a + 1 >>
How about:
incr a
It's just as concise for the default case. This is an old bias of mine
against certain operators. Without wanting to start a flame war over them, I
hope they never show their face in REBOL. :)
--Gregg
[51/80] from: ammon:rcslv at: 11-Jun-2002 18:37
<<
Make simple things simple, and complicated things possible
>>
Good philosophy!
<<
If I can imagine changing View to follow that principle, I would favor
something like the following. If you write
view/options layout [... some widget specs...] [resize]
then ALL enclosed widgets would scale proportionally when the container
resizes. I'd add widget-by-widget attributes of
scalex
to mean fixed-height, scaling-width,
scaley
to mean fixed-width, scaling-height, and
noscale
>>
Excellent! I would vote for that functionality over any that I have heard so
far, unfortunately, that is not how it works. The resize flag simply allows
the window to resize, not any of the faces within the window. It does
however trigger the 'resize event which allows you to dynamically change the
size of the faces in the layout (or do anything else you may deem neccisarry
effectively enabling the resizeby example that you gave). Thanks to this
discussion, I am lit up with all kinds of wonderful ideas of how to create
dynamically resizing faces! Now as you can see, RT has fufilled half of your
philosophy, complex things are possible. Now just to get the the simple
things simple part...
Enjoy, my 0.8% of $2.50. ;-)
Ammon
[52/80] from: joel:neely:fedex at: 13-Jun-2002 17:14
Hi, Gregg, and all,
OK... I'm shocked! (Not by Gregg's comment, but by where some of
this thinking took me!)
(Note: timings discussed below were median-of-multiple-run values
to reduce statistical variation.)
Gregg Irwin wrote:
> Hi All,
>
> << a += 1 ; slightly shorter than as a: a + 1 >>
>
> How about:
>
> incr a
>
> It's just as concise for the default case...
>
With a broad brush (in other words, I'm not trying to start a model
or terminology war ;-) let me say that REBOL has primitive types
(integer!, char!, ...) that are immutable, and has container types
which are mutable -- we can add to, remove, or replace their content.
Specifically, having said
a: 1
there's a sense in which I can't modify the value associated with
A but can only associate A with a new value. Thus when I say
a: a + 1
the fact that A: is set to the value of an expression that also
contains A is merely coincidental. Low-level languages (such as
incr #"b") assume that a "variable" is just a name for a "place",
location
, "address", "storage cell", ... which I can get at.
In REBOL, the *word* A is just a symbol, but a context associates
a collection of symbols with corresponding values. I think of a
context as analogous to a dictionary, which just relates words to
values. The concepts of "place", "address", etc... don't apply.
Now back to the word-counting problem Carl and I discussed earlier
in this thread. I reported writing scripts for that problem in
both Perl and REBOL, but didn't show the REBOL version (since it
was essentially based on the idea in one of Carl's posts). Here
is that version (renamed for contrast with some others to follow:
8<--------------------(begin tallyn.r)--------------------
#!/export/home/jneely/bin/rebol -sq
REBOL []
text: read %alice.txt
tally: []
alpha: charset [#"a" - #"z"]
word: ""
parse/all lowercase text [
any [
copy word some alpha (
either here: find/skip tally word 2 [
here/2: here/2 + 1
][
repend tally [word 1]
]
)
|
skip
]
]
foreach [word count] sort/skip tally 2 [
print [count tab word]
]
quit
8<---------------------(end tallyn.r)---------------------
The timing (this afternoon, with a different overall load on
the box) came out typically as follows:
(/export/home/jneely/try)# time tallyn.r > /dev/null
real 0m9.50s
user 0m9.44s
sys 0m0.05s
At some point in the run, the TALLY has contents that resemble
[
...
"written" 6
"wrong" 5
"wrote" 3
...
]
Of course, much of the complexity of the script above comes from
the fact that the tally values (integers) can't be modified. We
have to locate the "place" within the container (TALLY) that a
count can be found, and then replace that count with a new number.
That raises the question, "Is there another way to use containers
to represent the number of times a word appears?"
(In all of the variations below, the only change should be in the
parenthesized action after a word has been found in the input.)
Variant #1
----------
OK, don't laugh! Remember counting things in elementary school (or
later) by just making stroke marks on a piece of paper, and then
counting the stroke marks when finished? Here's a script that takes
that approach, using periods in a string instead of strokes on a
piece of paper. (The final "s" is for "string".)
8<--------------------(begin tallys.r)--------------------
#!/export/home/jneely/bin/rebol -sq
REBOL []
text: read %alice.txt
tally: []
alpha: charset [#"a" - #"z"]
word: ""
parse/all lowercase text [
any [
copy word some alpha (
either here: select tally word [
append here "."
][
repend tally [word copy "."]
]
)
|
skip
]
]
foreach [word count] sort/skip tally 2 [
print [length? count tab word]
]
quit
8<---------------------(end tallys.r)---------------------
At a corresponding point in the run, this version's TALLY has
contents that resemble
[
...
"written" "......"
"wrong" "....."
"wrote" "..."
...
]
To be honest, I created this variation as a joke. Imagine my
surprise when I checked the run time, and saw:
(/export/home/jneely/try)# time tallys.r > /dev/null
real 0m8.28s
user 0m8.21s
sys 0m0.06s
It's actually faster than the first version!!! In hindsight, there
are fewer words and less data structure juggling (although there's
memory management for the growing dot-per-occurrence strings).
Well!!! Perhaps this is worth some more experimenting!
Variant #2
----------
Another way to manage the counts is to have a block containing
the number as its only content. That leads to ("b" for "block):
8<--------------------(begin tallyb.r)--------------------
#!/export/home/jneely/bin/rebol -sq
REBOL []
text: read %alice.txt
tally: []
alpha: charset [#"a" - #"z"]
word: ""
parse/all lowercase text [
any [
copy word some alpha (
either here: select tally word [
change here here/1 + 1
][
repend tally [word copy [1]]
]
)
|
skip
]
]
foreach [word count] sort/skip tally 2 [
print [first count tab word]
]
quit
8<---------------------(end tallyb.r)---------------------
At a corresponding point in the run, this version's TALLY has
contents that resemble
[
...
"written" [6]
"wrong" [5]
"wrote" [3]
...
]
Despite the extra level of nesting, the speed improves again:
(/export/home/jneely/try)# time tallyb.r > /dev/null
real 0m5.53s
user 0m5.45s
sys 0m0.08s
Variant #3
----------
Finally, a last variation on the bare-numbers-in-the-block
version that uses a different approach to getting at the
place
to have its content changed:
8<--------------------(begin tallyz.r)--------------------
#!/export/home/jneely/bin/rebol -sq
REBOL []
text: read %alice.txt
tally: []
alpha: charset [#"a" - #"z"]
word: ""
parse/all lowercase text [
any [
copy word some alpha (
either here: find tally word [
change next here (second here) + 1
][
repend tally [word 1]
]
)
|
skip
]
]
foreach [word count] sort/skip tally 2 [
print [count tab word]
]
quit
8<---------------------(end tallyz.r)---------------------
I was yet again surprised to see the amount of improvement
(compared to the first numeric version above) resulting from
removing the /SKIP refinement from FIND (the majority of the
benefit) and replacing the path expressions with CHANGE NEXT
and SECOND, but here you have it!
(/export/home/jneely/try)# time tallyz.r > /dev/null
real 0m5.51s
user 0m5.43s
sys 0m0.08s
This gets us down to the same performance level as the nested
block version, although the notation probably looks a bit
opaque compared with the path expressions of the first version.
While there are often very nice ways to deal with the contents
of data structures, such as FIND, FOREACH, and PARSE, there are
still times when random access to, and modification of, contents
of a data structre will be necessary. Sometimes the most obvious
way to do such things is not the fastest!
-jn-
[53/80] from: rotenca:telvia:it at: 14-Jun-2002 1:55
> tally: []
Tally should be an hash! to gain speed.
tally: make hash! 10000
---
Ciao
Romano
[54/80] from: greggirwin:mindspring at: 13-Jun-2002 18:19
Hi Joel,
Excellent info! I don't want to make more work for you, but to be as
apples-to-apples as possible, could you try using a hash! for tally and see
what you get? I tried it here, with your last version, and got a pretty good
increase.
tally: make hash! []
Also, the timings exclude display of the results, correct?
--Gregg
[55/80] from: joel:neely:fedex at: 14-Jun-2002 7:05
Hi, Gregg,
Have done.
Gregg Irwin wrote:
> Excellent info! I don't want to make more work for you, but to
> be as apples-to-apples as possible, could you try using a hash!
> for tally and see what you get? I tried it here, with your last
> version, and got a pretty good increase.
>
> tally: make hash! []
>
> Also, the timings exclude display of the results, correct?
>
Right. All timings were done with a command similar to
(/export/home/jneely/try)# time tally.pl > /dev/null
real 0m0.29s
user 0m0.23s
sys 0m0.04s
which, of course, sends all script output to the bit bucket.
(Notice that finding a time when the box is lightly loaded
helps the run times...)
As before, comparable median-of-3 times are (in increasing
run-time order, the inserted "h" indicates the HASH! version
of yesterday's scripts):
tally.pl real 0m0.29s
user 0m0.23s
sys 0m0.04s
tallyhs.r real 0m1.39s
user 0m1.37s
sys 0m0.02s
tallyhb.r real 0m1.25s
user 0m1.17s
sys 0m0.08s
tallyhz.r real 0m1.68s
user 0m1.59s
sys 0m0.08s
tallyb.r real 0m5.63s
user 0m5.53s
sys 0m0.08s
tallyz.r real 0m5.82s
user 0m5.67s
sys 0m0.10s
tallys.r real 0m8.58s
user 0m8.48s
sys 0m0.08s
tallyn.r real 0m9.77s
user 0m9.63s
sys 0m0.10s
All of the times for the "h" version were obtained after
replacing the initialization of TALLY with
tally: make hash! []
(I didn't pre-allocate a large hash for the sake of fairness,
as I hadn't done so for the block version nor for the Perl
implementation.)
Notice that there's no time for TALLYHN.R for a very good/bad
reason. I wasted considerable time trying to figure out if I
had inadvertently broken it!!! I finally used top to verify
that, indeed, it was running (and eating up about 0.25 of a
CPU -- that's 25% for the REBOL/Viewtopia users ;-). Inserting
tracing output as shown below revealed that after adding 380
words, the *hn* version gets stuck, but continues to eat CPU
time. In multiple runs it gets stuck at exactly the same
place in the data, as illustrated in the following trace:
...
added turned : now 754
found a : a 23
added corner : now 756
found oh : oh 3
found my : my 2
added ears : now 758
found and : and 30
added whiskers : now 760
found how : how 5
found late : late 2
found it : it 32
found s : s 4
found getting : getting 3
found she : she 35
I added the same tracing to *hz* and captured the output:
...
added whiskers : now 760
found how : how 5
found late : late 2
found it : it 32
found s : s 4
found getting : getting 3
found she : she 35
found was : was 31
found close : close 2
added behind : now 762
...
which shows that *hn* is getting stuck trying to increment
the count for the word "was", rather than trying to add a
new word (if that matters to anybody or helps identify the
nature of the problem).
I am enclosing the code below in the hopes that someone
will see something silly that I've overlooked. Otherwise I'll
have to conclude that there's a bug involving path-based access
into a hash! value.
8<--------------------tallyhn.r--------------------
#!/export/home/jneely/bin/rebol -sq
REBOL []
text: read %alice.txt
tally: make hash! []
alpha: charset [#"a" - #"z"]
word: ""
parse/all lowercase text [
any [
copy word some alpha (
either here: find/skip tally word 2 [
here/2: here/2 + 1
print ["found" word ":" copy/part here 2]
][
repend tally [word 1]
print ["added" word ": now" length? tally]
]
)
|
skip
]
]
foreach [word count] sort/skip tally 2 [
print [count tab word]
]
quit
8<-------------------------------------------------
Incidentally, don't take the timings *too* terribly seriously;
as with all QAD benchmarks. These timings were run on a 4-CPU
Sun 4500, but a variety of factors (transient loads, other tasks,
stuff still in buffers, etc.) can introduce noticeable jitter in
the times for runs as short as these.
-jn-
--
; Joel Neely joeldotneelyatfedexdotcom
REBOL [] do [ do func [s] [ foreach [a b] s [prin b] ] sort/skip
do function [s] [t] [ t: "" foreach [a b] s [repend t [b a]] t ] {
| e s m!zauafBpcvekexEohthjJakwLrngohOqrlryRnsctdtiub} 2 ]
[56/80] from: joel:neely:fedex at: 14-Jun-2002 7:06
Hi, Romano,
Romano Paolo Tenca wrote:
> Tally should be an hash! to gain speed.
>
> tally: make hash! 10000
>
You're right, of course! Thanks!
Most of the time I'm working with small enough data structures
that the penalty isn't too severe, but that's no excuse for not
remembering this.
See my note to Gregg for results.
-jn-
--
; Joel Neely joeldotneelyatfedexdotcom
REBOL [] do [ do func [s] [ foreach [a b] s [prin b] ] sort/skip
do function [s] [t] [ t: "" foreach [a b] s [repend t [b a]] t ] {
| e s m!zauafBpcvekexEohthjJakwLrngohOqrlryRnsctdtiub} 2 ]
[57/80] from: gscottjones:mchsi at: 14-Jun-2002 7:54
From: "Joel Neely"
<snip amount=large />
> Variant #2
> ----------
<<quoted lines omitted: 29>>
> user 0m5.45s
> sys 0m0.08s
<snip amount=(to end)>
Hi, Joel, et al,
Using this version of the algorithm and using precise timing on the parsing
loop only on a Win98 deCeleron 500 and an apparently slightly different
version of alice, I obtained 0:00:11.31. Making a hash out of tally by
changing:
tally: []
to
tally: to-hash []
I obtained a time of 0:00:00.5. Unfortunately, I don't know enough Perl to
run Joel's equivalent code with the Alice file for direct comparison.
Having pointed out the significant improvement that hash provides should not
distract from one of Joel's original points that if RT's time/resources
is/are limited, it would probably be better to spend time optimizing core
functionality and making the environment more readily extensible with ad-hoc
native functionality, when needed. In other correspondence, Carl S. has
apparently indicated that he thought a percent type would be useful in gui
construction but that the ROI was not enough to spend the time to work out
the details. As always, with a little bit of cash, I suspect RT would
happily work out the details!
:-)
I wish I had 2% of $1 to give away!!! At least my ideas are *free* (0% of
$1) and easily worth every penny of it!
;-)
--Scott Jones
[58/80] from: gscottjones:mchsi at: 14-Jun-2002 8:21
Hi, All,
I posted my last post before I realized Joel had already done the hashed
versions
From: "Joel Neely"
<snip>
> ... These timings were run on a 4-CPU Sun 4500 ...
I tried to find my 4-CPU Sun 4500 for better comparisons, but couldn't find
that machine. So I settled for my 1-CPU Win98 Celeron ;-).
--Scott Jones
[59/80] from: joel:neely:fedex at: 14-Jun-2002 8:27
Hi, all,
Just to bring the sad saga to closure... ;-)
Joel Neely wrote:
> Notice that there's no time for TALLYHN.R for a very good/bad
> reason... In multiple runs it gets stuck at exactly the same
> place in the data...
>
I left it running (on the same system) for over an hour and
a quarter (125% of 3600 seconds ;-) and no further progress
occurred. Looks like there might be a loop in a structure
somewhere???
-jn-
--
; Joel Neely joeldotneelyatfedexdotcom
REBOL [] do [ do func [s] [ foreach [a b] s [prin b] ] sort/skip
do function [s] [t] [ t: "" foreach [a b] s [repend t [b a]] t ] {
| e s m!zauafBpcvekexEohthjJakwLrngohOqrlryRnsctdtiub} 2 ]
[60/80] from: greggirwin:mindspring at: 14-Jun-2002 10:21
Hi Joel,
Thanks for doing that. Your results are similar to mine (from ~3 sec. to ~.3
sec. on a W2K P900 using a ~168K %looking.txt I found).
<< I am enclosing the code below in the hopes that someone
will see something silly that I've overlooked. Otherwise I'll
have to conclude that there's a bug involving path-based access
into a hash! value. >>
It works here with the latest Core beta. I know hash! had some afflictions
in earlier releases though, which is probably what you're seeing.
--Gregg
[61/80] from: nitsch-lists:netcologne at: 14-Jun-2002 19:36
Hi Joel,
Am Freitag, 14. Juni 2002 14:05 schrieb Joel Neely:
> Hi, Gregg,
>
[snip]
> Right. All timings were done with a command similar to
> (/export/home/jneely/try)# time tally.pl > /dev/null
<<quoted lines omitted: 4>>
> (Notice that finding a time when the box is lightly loaded
> helps the run times...)
[snip]
could you give us startup-time of an empty rebol-script and empty perl?
i don't think it makes a bit difference, just curious.
> -jn-
-Volker
[62/80] from: joel:neely:fedex at: 14-Jun-2002 15:38
Hi, Volker,
Volker Nitsch wrote:
> could you give us startup-time of an empty rebol-script and empty
> perl? i don't think it makes a bit difference, just curious.
>
Gladly. Using the same highly-scientific median-of-three sampling ;-)
we get:
(/export/home/jneely/try)# time tally0.pl
real 0m0.02s
user 0m0.01s
sys 0m0.01s
(/export/home/jneely/try)# time tally0.r
real 0m0.17s
user 0m0.11s
sys 0m0.05s
where each of the above scripts was stripped down to a bare "do
nothing and quit" state.
-jn-
[63/80] from: carl:cybercraft at: 17-Jun-2002 1:50
Hi Joel,
(Note the first bit of this was written a couple of days ago.)
On 14-Jun-02, Joel Neely wrote:
>> add-word: function [tally [block!] word [string!]][temp][
>> either temp: find/skip tally word 2 [
<<quoted lines omitted: 9>>
> version, it shrinks to 139 bytes -- although that renders it
> significantly less readable),
Firstly, I don't buy the argument about the function using too many
bytes as I've not heard many complaints about REBOL scripts being too
long.
As to there being less typing to do, and hence it'll take less time to
write a script, well that may be true, if all else is equal, such as
if perl scripts take a similar amount of time as REBOL ones to debug
and maintain. I don't know if that's true - any others here with
experience of both languages care to comment?
But anyway, human-language words are the REBOL way of doing things and
I think it's a bit late to get this changed now. (;
> but here's the point I was trying
> to make with this dinky example:
> Manipulating non-trivial data structures in REBOL, even
> something as simple as a look-up table, involves much more
> code and much more intpreter overhead than with several
> other languages in the same space -- 'net applications.
I don't know about interpreter overhead, but to my mind a single
character that means the same thing as a five-letter word is the same
amount of "code". It's just that the five-letter word has a better
chance of expressing to the reader what it means. An important point
in an extensible language to my mind.
As to trying to muscle into the net applications space, well I think
REBOL will find a niche (and a big one) that's not already well
occupied. IOS (I gather) points to one such space.
> I truly believe that addressing that issue would be of
> significant value in promoting the wider use of REBOL.
<<quoted lines omitted: 25>>
> reduction -- read one or more text files, parse them down and do
> some processing on the analyzed text, then spit out some results.
I'm sure that is common, but if I was worried about performance I
would be thinking from the start that that was not a good algorithm as
for every word you're doing a find of an ever-growing word list. If
counting the words wasn't important, my REBOL approach would've been
based on using 'unique...
alice-words: sort unique parse read %alice-file.txt none
(Of course, if needs be you'd change that to a parse/all with your own
rule to handle how you'd want your words extracted if REBOL's default
wasn't good enough.)
As to what's the best way in REBOL to count the words as well I'm not
too sure off the top of my head. However, I instinctively shy
away from brute-strength aproaches even if I don't think there'll be
a performance hit. It's a bad practice to get into in my opinion.
(At about this time your post with example scripts turned up, hence
this wasn't finished and sent then. See below...)
> The trade-off between native and mezzanine code is a significant
> performance factor in REBOL. The fact that I can write a
> function to do some task doesn't change the fact that there's a
> run-time cost influenced by how much of the work of that function
> must be expressed in mezzanine/user code.
I'm sure that's true. As I'm sure RT would like to convert a lot of
that mezzanine code to native.
> I'm certainly not ignoring the value of graphical user interfaces
> (I've been a Mac user since 1984, and my primary personal box is
<<quoted lines omitted: 10>>
> another data type.
> As for the /View discussion, I'll reply separately.
And I'll answer that seperately too.
But back to your coding example with the poor performance compared to
Perl. Thinking about the find in the loop, I thought about two
alternative aproaches:
1) Create tally as a suitably sized block of nones before you parse
the file. Then, when parsing it, as the words are found generate
(somehow:) a unique number from the word and use that number as the
index into tally for storing your word and its count. As words that
were the same would generate the same numbers, that'd be how you'd be
able to count them without any need for a search.
The problem with this approach was that I couldn't think of any
sensible way to generate a unique number. It was a nice thought
though. (;
2) Parse the file into a block of words (without attempting to extract
or count them), sort this block, and then extract and count them with
one simple loop through the block. Would sorting the main file first
prove to be faster? Well, yes - and no...
First I made a copy of your (original) script to use as a benchmark.
This is it, modified to allow me to enter a file-name and to time the
test...
---8<---
REBOL []
prin "file-name: " text: read file: to-file input
time: now/time/precise
tally: []
alpha: charset [#"a" - #"z"]
word: ""
parse/all lowercase text [any [
copy word some alpha (
either here: find/skip tally word 2 [
here/2: here/2 + 1
][
repend tally [word 1]
]
) |
skip
]]
tally: sort/skip tally 2
time: now/time/precise - time
print [time "Counter-1" file length? tally]
---8<---
Now for my first script. Well, it's not my first, as all attempts to
get a version of...
parse/all lowercase text "all characters except lowercase-letters"
to properly dice up the text into words failed. Bugged I believe,
going by my memory of long-ago posts to the list. So instead I just
used a simplified version of your parse rule to build the block of
words. And this is it...
---8<---
REBOL []
prin "file-name: " text: read file: to-file input
time: now/time/precise
temp: []
alpha: charset [#"a" - #"z"]
word: ""
parse/all lowercase text [any [
copy word some alpha (append temp word) |
skip
]]
sort temp
tally: []
forall temp [
x: index? temp
while [temp/1 = temp/2][temp: next temp]
repend tally [temp/1 (index? temp) - x + 1]
]
clear head temp
time: now/time/precise - time
print [time "Counter-2" file length? tally]
---8<---
This proved to be about three times as fast as your script, though
that may vary on other systems of course. But, if hash is used with
your script as others have suggested, it's about five times as fast,
while I couldn't get hash to make any improvement on my script. (Not
that I've tried very hard, as because of the hash bug (I'm assuming)
it locked up your script when I gave it the biggest file I'd been
using for testing, so I didn't play around with hash much.) So, your
script still really wins in the speed stakes, though others may see
some room for improvement in mine of course. (: I'd be interested to
know how they compare in your tests if you've not lost interest by
now... (:
I also wrote the following, which has a bit faster first parse, though
it's also more convoluted...
---8<---
REBOL []
prin "file-name: " text: read file: to-file input
time: now/time/precise
lowercase text
alpha: charset [#"a" - #"z"]
rest: charset [#"^(00)" - #"^(60)" #"^(7B)" - #"^(ff)"]
word: ""
parse/all text [any [
some alpha |
x: copy word some rest (change/dup x " " length? word) |
skip
]]
temp: sort parse text none
tally: []
forall temp [
x: index? temp
while [temp/1 = temp/2][temp: next temp]
repend tally [temp/1 (index? temp) - x + 1]
]
clear head temp
time: now/time/precise - time
print [time "Counter-3" file length? tally]
---8<---
Thanks for the fun Joel. (:
--
Carl Read
[64/80] from: joel:neely:fedex at: 16-Jun-2002 15:52
Hi, Gregg,
Gregg Irwin wrote:
> << I am enclosing the code below in the hopes that someone
> will see something silly that I've overlooked. Otherwise I'll
<<quoted lines omitted: 3>>
> afflictions in earlier releases though, which is probably what
> you're seeing.
I guess "beta" is the operative word. I checked again to make
sure I was running an up-to-date version on the server:
REBOL/Core 2.5.0.10.1
Copyright 1997-2001 REBOL Technologies
REBOL is a Trademark of REBOL Technologies
All rights reserved.
... so the "stock" /Core 2.5 does still have some problems.
-jn-
--
; Joel Neely joeldotneelyatfedexdotcom
REBOL [] do [ do func [s] [ foreach [a b] s [prin b] ] sort/skip
do function [s] [t] [ t: "" foreach [a b] s [repend t [b a]] t ] {
| e s m!zauafBpcvekexEohthjJakwLrngohOqrlryRnsctdtiub} 2 ]
[65/80] from: joel:neely:fedex at: 16-Jun-2002 16:22
Hi to all who've been following/participating in this thread.
One or two additional random thoughts have been rolling around
in my head, so I thought I'd evict them! ;-)
Percentage
expressions
------------ -----------
I haven't heard any other comment on the question of whether
decimal! values have a pre-existing meaning when used within
LAYOUT blocks. If not, here's a potential compromise that I'd
be interested in feedback on.
I suspect that it would be easier to make a slight modification
to the lexical rules for LOAD than to implement an entire new
data type. (Notice I'm up to 2 assumptions now!)
How about adding #"%" as a valid suffix to any numeric datum,
with the meaning of "left shift the decimal point by 2 and
yield a decimal! value" ? With this lexical tweak in place,
1% would represent the same value as 0.01
3.5% 0.035
100% 1.0
and so on. This would allow those who wished to represent
factors in REBOL source (or input, or files, ...) as percentages
to get the notational convenience, but would (my guess) not take
nearly so long or as much work as a complete new datatype.
For those whose specific interest is in resizing/scaling within
View, I'd still wonder if decimal! scaling factors or some other
dialect enhancement wouldn't be just as convenient.
Other priorities
----- ----------
While thinking about how this compares with other things that I
know have been on the table for some time, I remembered another
issue that has disappeared from the radar scope -- formatting
for output.
Every language I use for real programming offers some way to
control the way in which internal values are converted to strings
for output -- except REBOL. Such capabilities include:
- left- or right-padding or truncating strings to fixed width,
- padding numeric values to specified lengths, with either
zero or blank left-padding,
- fixing total length and number of fractional digits for
floating-point values,
- collecting a series of expressions/values into a single string,
with appropriate formatting for each.
I recall some discussion quite a while back about this issue --
specifically about exposing some way to get at the underlying
printf mechanism, as REBOL is implemented in c -- and the reply
from Sterling (on or about 19 Sep 2000 16:40:32)
> A quick comment:
> I understand what you're asking for and I personally think that
<<quoted lines omitted: 6>>
> types of formatting issues within REBOL. I don't know when it'll
> happen though.
In the intervening 175% of a year, we've had numerous discussions
about how to format data for output, with decimal formatting being
one of the most common/recent (including the issue of reliably
rounding decimal values to a specified precision). Yet we still
don't have a standard means of doing this common programming
operation in REBOL.
Let me add that to my things-that-keep-coming-up list that I'd like
to see addressed before we start inventing new things to ask for
(including my lexical compromise idea above!)
-jn-
--
; Joel Neely joeldotneelyatfedexdotcom
REBOL [] do [ do func [s] [ foreach [a b] s [prin b] ] sort/skip
do function [s] [t] [ t: "" foreach [a b] s [repend t [b a]] t ] {
| e s m!zauafBpcvekexEohthjJakwLrngohOqrlryRnsctdtiub} 2 ]
[66/80] from: joel:neely:fedex at: 16-Jun-2002 15:49
Hi, Carl,
Carl Read wrote:
> >> add-word: function [tally [block!] word [string!]][temp][
> >> either temp: find/skip tally word 2 [
<<quoted lines omitted: 6>>
> many bytes as I've not heard many complaints about REBOL
> scripts being too long.
That's task- (and algorithm-) dependent, IMHO. I've said very
little about the effort of using REBOL to do complex numerical
and matrix computation because I simply don't use REBOL for
those types of tasks.
The issue, again, is "how much work/code/runtime is required
to do comparable things?"
> As to there being less typing to do, and hence it'll take less
> time to write a script...
>
> I don't know about interpreter overhead, but to my mind a single
> character that means the same thing as a five-letter word is
> the same amount of "code"...
>
Actually, we're focusing on the same issue here (IMHO) but using
different words to express it. Let me try an analogy:
When I write a program to perform some task, I'm building
a conceptual bridge between the natural terms of discourse
for the problem and the level of the concepts built into
the programming language at hand.
The further apart those two shores are, the more bridge I
have to build, even if I build it by pre-fabbing I-beams
and trusses (functions/subroutines) and then constructing
the bridge in terms of those sub-assemblies.
To my mind, handling multi-level data structures is something
that should be easy in a modern programming language (and I
agree with your comment about a single operator being a single
concept, regardless of how many characters it takes to spell
it out). So let's look at the two cases:
++$tally{$word}
to my eye parses out as follows:
++ increment (by one)
$ the value
tally in the structure named "tally"
{} at the symbolic key in
$word the variable named "word"
In contrast, the REBOL version makes me deal explicitly with
deciding whether the key is already present, handling presence
by constructing a positional reference into a data structure
so that I can replace an integer with its successor, and handling
absence by explicitly including the new key and an initial count
of one.
(For sake of space, I didn't explode the REBOL into token-by-token
annotation as I did the Perl version. But notice that I still had
to use many more words at a much more detailed implementation level
to explain what the REBOL version was doing.)
Again, I'm not trying to bash REBOL, but to point to an area where
REBOL requires much more code, time, and attention to detail than
some other languages. Since I believe that zone contains many
common sys admin, server-side programming, and general data
processing tasks, I think it would be very useful to see REBOL
extended to handle that area more effectively.
> I'm sure that is common, but if I was worried about performance
> I would be thinking from the start that that was not a good
> algorithm as for every word you're doing a find of an ever-growing
> word list. If counting the words wasn't important, my REBOL
> approach would've been based on using 'unique...
>
While I remain happy to exchange ideas about more effective ways
to do almost anything with REBOL, I really don't want to become so
focused on how to optimize a specific example that we miss the big
picture. As I said before, I believe the *types* of processing in
the word-count example were typical, not the specific task itself.
I wanted to offer a simple illustration that wouldn't take too
much explanation, and to show the performance of *comparable*
approaches.
A more realistic example (since it's real -- I recently wrote a
script for a task very similar to this ;-) would be to write a
script that would read the log file of a web server, searching
the URL fields for requests that matched certain criteria. For
each such line found, output the requesting IP or host name,
date and time (including time zone) of the request, representing
all output in XML. However, specifying all of that (including
the kinds of criteria and the XML specs) would have taken too
much time and detracted from the main point. However, this is
another example of a task that requires
* reading from a file,
* treating the content as lines,
* transforming and parsing each line,
* computing output based on the contents found,
but for which something as simple as "sort unique" would not
suffice.
> But back to your coding example with the poor performance compared to
> Perl. Thinking about the find in the loop, I thought about two
> alternative aproaches:
>
> 1) Create tally as a suitably sized block of nones before you parse
> the file...
>
Specifying "suitably-sized" would be infeasible for the typical case;
for problems of the kind I had in mind, one usually doesn't know in
advance how much data will be processed (or the size will vary from
file to file), so a "flexible" structure offers real advantages.
> Then, when parsing it, as the words are found generate
> (somehow:) a unique number from the word and use that number as the
> index into tally for storing your word and its count...
>
> The problem with this approach was that I couldn't think of any
> sensible way to generate a unique number. It was a nice thought
> though. (;
>
A home-grown hashing algorithm, perhaps? Something based on the
result of CHECKSUM/SECURE (scaled down drastically)? Of course the
trick would be to handle collisions gracefully...
>
> 2) Parse the file into a block of words (without attempting to
> extract or count them), sort this block, and then extract and
> count them with one simple loop through the block. Would sorting
> the main file first prove to be faster? Well, yes - and no...
>
As for the ultimate relevance of continuing to redesign this
intentionally simple problem, see above. (However, I can't resist
one further bit of off-topic tweakage... ;-)
> Now for my first script. Well, it's not my first, as all attempts
> to get a version of...
>
> parse/all lowercase text "all chars except lowercase-letters"
>
> to properly dice up the text into words failed. Bugged I believe,
> going by my memory of long-ago posts to the list...
>
Which is why I'd also put "fixing all known bugs" as a higher
priority than adding *any* new features at this point.
> ... So instead I just used a simplified version of your parse rule
> to build the block of words. And this is it...
<<quoted lines omitted: 20>>
> print [time "Counter-2" file length? tally]
> ---8<---
I took your solution above, restored the hard-coded file name,
eliminated internal time capture, and wrote word/count pairs to
standard out (instead of appending them to another block) so
that I could compare it to the tests I've got on the 4500.
The "c" is in honor of "Carl", of course!
8<--------------------begin tallyc0.r--------------------
#!/export/home/jneely/bin/rebol -sq
REBOL []
text: read %alice.txt
tally: []
alpha: charset [#"a" - #"z"]
word: ""
temp: []
parse/all lowercase text [
any [
copy word some alpha (append temp word)
|
skip
]
]
sort temp
forall temp [
x: index? temp
while [temp/1 = temp/2][temp: next temp]
print [(index? temp) - x + 1 tab temp/1]
]
quit
8<---------------------end tallyc0.r---------------------
I then applied a standard file-processing trick to simplify
the processing of the sorted block-o-words, and got this
minor variation:
8<--------------------begin tallyc1.r--------------------
#!/export/home/jneely/bin/rebol -sq
REBOL []
text: read %alice.txt
tally: []
alpha: charset [#"a" - #"z"]
word: ""
temp: []
parse/all lowercase text [
any [
copy word some alpha (append temp word)
|
skip
]
]
oldword: none
count: none
foreach word sort temp [
either word = oldword [
count: count + 1
][
if count [
print [count tab oldword]
]
oldword: word
count: 1
]
]
quit
8<---------------------end tallyc1.r---------------------
I made corresponding changes to your last script (the one with
the "modify-in-place" parse rule) to create tallyc2.r and
tallyc3.r
Finally, if we're going to do fair apples-to-apples, we need
to apply the same (highly ad hoc) optimization hacks to the
Perl version (reading the entire file at once, breaking that
single string into a collection of words, sorting them, and
just tallying up the occurrences in a single pass). Doing so
gives us this (in case anybody cares to see what it looks
like...):
8<--------------------begin tally1.pl--------------------
#!/usr/local/bin/perl -w
open (TEXT, "< alice.txt") or die "Can't open 'alice.txt'\n";
undef $/;
my $text = <TEXT>;
close (TEXT);
my ($oldword, $count) = ("", 0);
foreach my $word (sort split /[^a-z]+/, lc $text) {
if ($word eq $oldword) {
++$count;
} else {
print "$count\t$oldword\n" if $count;
($oldword, $count) = ($word, 1);
}
}
exit (0);
8<---------------------end tally1.pl---------------------
I reran the benchmark for tallyn.r, tallyz.r, tallyhb.r,
tallyhs.r, and the variations described above.
NOTE: The server has a different overall load right now, so the
numbers should only be compared among each other, not
directly with numbers from other runs on another day.
The median-of-three results are:
tallyn.r real 0m11.41s
user 0m11.35s
sys 0m0.05s
tallyz.r real 0m7.20s
user 0m7.11s
sys 0m0.08s
tallyc0.r real 0m4.76s
user 0m4.76s
sys 0m0.39s
tallyc1.r real 0m4.25s
user 0m3.80s
sys 0m0.40s
tallyc2.r real 0m3.97s
user 0m3.86s
sys 0m0.10s
tallyc3.r real 0m3.47s
user 0m3.32s
sys 0m0.14s
tallyhs.r real 0m3.25s
user 0m3.18s
sys 0m0.06s
tallyhb.r real 0m3.12s
user 0m3.03s
sys 0m0.10
tally.pl real 0m0.71s
user 0m0.68s
sys 0m0.02s
tally1.pl real 0m0.50s
user 0m0.48s
sys 0m0.01s
A few observations:
- Clearly, the more ad hoc (in the sense of specialized tuning for
a specific situation) we make our algorithms, the more we would
expect to improve performance. However, notice that this is
language- and design-specific. tallyhb.r and tallyhs.r both
still beat tallyc*.r despite the fact that tallyc*.r threw out
the construction of the word/count table. (Thus we see that
maintaining the hash-based data structure can be faster than
sorting a block of all keys -- including duplicates -- for at
least some input data cases.)
- The other side of that coin is that more ad hoc (specialized)
algorithms usually lose flexibility. If the "customer" came
back and said ...
Oh, I meant that I wanted it in frequency order (most common
words first) not alphabetically by words!
... then either tally.pl or tallyn.r could be changed more
quickly and easily than their specialized cousins.
- Using path notation for random access of values within a block
is surprisingly costly. This was seen earlier in the difference
between tallyn.r and tallyz.r , where
either here: find/skip tally word 2 [
here/2: here/2 + 1
][
repend tally [word 1]
]
required way substantially more time than
either here: find tally word [
change next here (second here) + 1
][
repend tally [word 1]
]
This same issue is most of the reason that c1 and c3 were able
to outperform c0 and c2, IMHO.
- Performance is still an issue worth remembering when deciding
whether to use REBOL for some task of significant size.
Remember that "Alice" was a small text file (a little over 140K),
while the web log processing I alluded to was chomping through
many megabytes and doing much more processing per line.
The first brute-force Perl version (tally.pl) was coded about as
fast as I could type, and outperformed the brute-force REBOL
versions significantly. After several of us have tried various
ideas for streamlining the REBOL version, the fastest one tried
to date is still 4-5 times slower than the QAD Perl version.
When we throw the same speed-up tweaks at Perl (to get tally1.pl)
it moves up to about 6 times as fast as the fastest REBOL model.
Not complaining, just observing...
The performance issues above are certainly not the only issue when
comparing REBOL with other options, but we shouldn't pretend that
they don't exist, either!
Thanks to all for the interesting ideas/challenges/comments!
-jn-
--
; Joel Neely joeldotneelyatfedexdotcom
REBOL [] do [ do func [s] [ foreach [a b] s [prin b] ] sort/skip
do function [s] [t] [ t: "" foreach [a b] s [repend t [b a]] t ] {
| e s m!zauafBpcvekexEohthjJakwLrngohOqrlryRnsctdtiub} 2 ]
[67/80] from: g:santilli:tiscalinet:it at: 17-Jun-2002 0:54
Hi Joel,
On Sunday, June 16, 2002, 11:22:26 PM, you wrote:
JN> While thinking about how this compares with other things that I
JN> know have been on the table for some time, I remembered another
JN> issue that has disappeared from the radar scope -- formatting
JN> for output.
I have the feeling that Carl adds things to REBOL as soon as he
needs them. Probably he never needed formatting yet, so it's not
here...
Regards,
Gabriele.
--
Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer
Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r
[68/80] from: greggirwin:mindspring at: 17-Jun-2002 11:04
Hi Joel,
<< How about adding #"%" as a valid suffix to any numeric datum,
with the meaning of "left shift the decimal point by 2 and
yield a decimal! >>
I'd have to think about that for a while. I do think it could be a handy
notation, but it would also tighten the lexical rules a bit more, which
could have side effects on future development.
Re: formatting for output.
I agree that this is an important, and missing, piece of the REBOL puzzle. I
have JUSTIFY and ROUND functions that I use, but only a few notes about a
FORMAT function and dialect. Eric Long's format.r dialect didn't resonate
with me, but that's just me.
--Gregg
[69/80] from: enter:your:email:address:here:rebol:(example: at: 15-Jun-2002 19:19
Hi,
I perfectly agree with your proposal on the percent! type. It would do
exactly what is necisary, and propably behave the 'nicest'
I am with you on the formatting request as well, either in this post or
another one ( i do not recall) you have mentioned that REBOL lacks some
serious Server Maintainance type functions. I too would like to see these
implimented before version 3.0. Let's create a list of those that would be
most helpful and see what we can get...
Enjoy, my $0.04 - 50%
Ammon
On Sunday 16 June 2002 05:22 pm, you wrote:
[70/80] from: carl:cybercraft at: 18-Jun-2002 17:46
Hi Joel,
Seems a while since you wrote this now, but I've been a bit snowed
under with stuff. Anyway...
On 14-Jun-02, Joel Neely wrote:
> Hi, again, Carl,
> With respect to the View issues...
<<quoted lines omitted: 4>>
> do some other things that would have a bigger effect on the
> widespread adoption of REBOL.
This may be true. Actually, everything else has muddied the issue to
my way of thinking. The question should be whether having a percent
datatype is a good idea or not. If it isn't (and RT agrees:) then
the issue of whether it should be implimented before other stuff is
no longer a question. If it is a good idea though, then how high it
should be on the to-do list is open to debate.
> So far the "datatype as clue to View layout" is the only issue I've
> seen raised in this thread that wasn't simply a matter of a shorter
> (and arguably more conventional) way to write floating-point values
> that indicate ratios or factors.
Well, consider these two, (no, make it three), hypothetical
functions...
add-tax: func [price [number!] tax [number!]][price * tax + price]
add-tax: func [price [money!] tax [number!]][price * tax + price]
add-tax: func [price [money!] tax [percent!]][price * tax + price]
The first two we can already do in REBOL. However, using the money
datatype as with the second example has the advantage of built-in
error-detection if a money-datatype isn't supplied to the function...
>> add-tax $10 .10
== $11.00
>> add-tax 10 .10
** Script Error: add-tax expected price argument of type: money
** Near: add-tax 10 0.1
So to the third example with the percent datatype. This would also
have the advantage of built-in error detection if a percent value
wasn't surplied, plus there'd be no need for converting the percentage
values supplied by users to 100th of their value before they were
used. That means there's extra chances for errors in our code as we
think "ten percent" but have to use "point one". For instance, which
of these two is the correct way to do things...
tax-percent: 12
tax-percent: .12
? Then consider 12.5%... So much easier with...
tax: 12%
or...
tax: 12.5%
>> Fair enough. But others using other OSs and every IOS user
>> (I assume) are using View. And they need to be able to create
<<quoted lines omitted: 3>>
> I might agree that it is *A* way to do it, but I don't think it's
> the only possibility by any stretch of the imagination.
And I didn't say it was the only way, just the obvious way. (:
>>> 1) I spend a bit of time with graphics and color issues, so
>>> my first thought on seeing the above was:
<<quoted lines omitted: 14>>
> attributes deemed most common for some purposes) I question whether
> the "datatype as only clue" approach itself scales well.
It doesn't, (lots on a GUI having at least two colours for instance),
but there's 3 (I guess) levels of convenience with VID. The first is
to use the style's default settings, the next is to alter those
settings by just adding a datatype to the style with the datatype
determining which of the settings will be altered, and the third is
to figure out from the available docs, examinations of mezzanine code
and questions to this list how to alter anything else you need to! (:
The point with the datatypes though is when you want a GUI fast, as
apposed to the perfect GUI for the job, they make it very easy to
create a GUI in a hurry. An example...
view layout [across text-list "aa" "bb" "cc" 100x300 area 300x300]
The pair datatypes there are a good example of how datatypes are
useful when you want a quick and easy way to build a GUI. Without it
we'd need to either specifically indicate what we mean by (say) width
and height words, or assume that two integers represented them. The
latter is perhaps as efficient, but those "x"s make all the
difference when it comes to clarity. As would a "%" on the numbers.
> The punch line is that I have serious reservations about a notation
> that leans heavily on datatypes (and large doses of assumption about
> the most likely meaning or most frequent use) to specify complex
> artifacts.
As I pointed out above, it's just for convenience. The rest is
possible to get at one way or another.
>> Though it's possible a percent datatype could be used for colors
>> and decimals for face sizes, but I supect RT would go for using
<<quoted lines omitted: 3>>
> of "use" at least ;-). I'm just suggesting that "useful" and "most
> urgent to deal with right now" are distinct concepts.
I agree, but what is most urgent is a bit subjective and depends on
the individual's point of view. Mine is that designing GUIs with VID
is quite close to being good but is seriously let down by how
difficult it is to make them scalable. Execution speed is an issue
with REBOL, but it isn't the usual reason you choose a high-level
language, is it? Or more correctly, execution speed isn't, but
developement speed probably is, as is ease of maintainance. All the
better if the execution speed is good, but if a high-level language
isn't easy to develope in, where's the advantage in chosing a
high-level language over a lower-level one?
>> Well, I answered your problem regarding adding words to a list to
>> my satisfaction, (though perhaps not to yours), so perhaps you'd
<<quoted lines omitted: 31>>
> With that said, let me add my preference for a design strategy
> of "Make simple things simple, and complicated things possible"
I actually think that's how it is with VID now. Just that there's
some simple things that still need to be made simple - and the rest
of it just needs to be doccumented...
> If I can imagine changing View to follow that principle, I would
> favor something like the following. If you write
<<quoted lines omitted: 10>>
> vertically but not change width, a horizontal scrollbar would
> have SCALEX, a thumbnail icon could have NOSCALE, etc...
Using my example above as a template for a test of this, we get...
view layout/options [
across
text-list "aa" "bb" "cc" 100x300 scaley
area 300x300
][resize]
Which is quite nice, and some might say better than using percentages
without automatic scaling of everything, (my prefered option), which
would look like this...
view layout/options [
across
text-list "aa" "bb" "cc" 100x100%
area 100%x100%
][resize]
A percentage value would mean the percentage of the space left by the
parent face after the sizes of the fixed panes had been deducted.
Same as with HTML table sizing. (I think.)
Why I don't like the idea of resize turning every pane into a scalable
one is you have the likes of buttons and so on which in most cases
you wouldn't want to scale. They could have their defaults set to
noscale though, which would be consistant with the current VID way of
doing things.
> For any more complex scanarios, I'd put the monkey back on the
> programmer with something vaguely like
> view/options layout [... some widget specs ...] [resizeby
> function]
> where the offered function (by name or anonymous) would be invoked
> to handle the resizing,
A good idea.
> and would be able to use some simple
> interface to adjust the size of each component widget within the
> layout, so that a programmer wanting a more sophisticated
> layout-management strategy would have a way to implement it.
As we're really talking about every face here, ie, faces within faces
and not just the outer, window-level face, that level of control
would be a byproduct of implimenting either of our methods.
Incidently, minimum and maximum sizes I guess will need to be catered
for too.
> Again, let me repeat that I'm not trying to play "duelling examples"
> here, but to ask the question "What could be done to make REBOL more
> attractive to users and developers who currently are not aware or
> interested?" I trust we all would like to see that result!
Indeed. Users do judge stuff on the GUI though. Being different to
what they're used to is a big enough hurdle for them to get over,
(hence the need for decent skins), and they certainly aren't
impressed by less functionality than they're used to. As for
developers, well you can never please them - they wouldn't keep
looking at new languages if that was the case. (;
Anyway, I can't see any major advantage in using percentages over your
suggested method, so I grant you you may be right here. That said,
the real test would be in the using. I wonder though whether adding
a new datatype and updating VID would take much longer than just
updating VID in the way you envisage?
Now, just to muddy the waters even more, I've remembered there's this
from the old View Beta docs...
---8<---
Virtual Coordinate Space (not working in beta 4 release)
A virtual coordinate space makes it possible to develop a visual
interface without needing to know the actual display size. This is to
say, it is possible to use a virtual pixel space for aligning face
objects. So, the resolution of a user's display does not need to be
known before designing a visual interface. For instance, if you want
to create a visual interface that will look the same between systems
with a display resolution of 320x240 and systems with resolutions of
1280x1024 and greater. This can be done with View's virtual
coordinate space capabilities.
---8<---
That's an extra layer on top of the resizable windows we're talking
about. Anyone know if that's been dropped or just on the
back-burner?
--
Carl Read
[71/80] from: carl:cybercraft at: 18-Jun-2002 21:07
Hi Joel,
I think we've nearly done the perl vs REBOL thing to death, but just a
few comments.
Firstly, thanks for doing the script comparisons. They were
surprisingly close to the results I was getting. And as your noted
too, using hash was still a bit faster.
On 17-Jun-02, Joel Neely wrote:
> While I remain happy to exchange ideas about more effective ways
> to do almost anything with REBOL, I really don't want to become so
<<quoted lines omitted: 4>>
> much explanation, and to show the performance of *comparable*
> approaches.
I realise that. But different languages perform differently, so I was
trying to think of how best to approach the problem from a REBOL
point of view. For instance, if the roles were reversed and Perl was
the newer language for you and you'd been using REBOL as often and
for as long as you've been using Perl, do you think you would've
overlooked the use of hash? (Other than because it's bugged:) It
takes a while for the best approaches to become second nature.
That said, Perl at this stage is obviously the better choice for the
kind of processing you're talking about when speed's an issue.
--
Carl Read
[72/80] from: anton:lexicon at: 18-Jun-2002 20:36
That's what face/span is hanging around for,
if I remember correctly.
Anton.
[73/80] from: joel:neely:fedex at: 18-Jun-2002 7:04
HI, Carl,
Carl Read wrote:
> Hi Joel,
>
> Seems a while since you wrote this now, but I've been a bit snowed
> under with stuff. Anyway...
>
I know the feeling!!!
> Well, consider these two, (no, make it three), hypothetical
> functions...
>
> add-tax: func [price [number!] tax [number!]][price * tax + price]
>
> add-tax: func [price [money!] tax [number!]][price * tax + price]
>
> add-tax: func [price [money!] tax [percent!]][price * tax + price]
>
...
> So to the third example with the percent datatype. This would also
> have the advantage of built-in error detection if a percent value
> wasn't surplied, plus there'd be no need for converting the percentage
> values supplied by users to 100th of their value before they were
> used...
>
I'd only add (PTP;-) that
add-tax: func [price [money!] tax [decimal!]] [tax + 1.0 * price]
would work just fine with my later suggestion regarding #"%" as a
numeric suffix, allowing
add-tax $14.95 8.5%
or
add-tax $238.15 5%
because (in that proposal) the "scale-radix-left-by-two" meaning of
the trailing #"%" would always yield a decimal! value. Thus we get
notational benefit (for those who think that's a benefit) and type
checking with this approach as well.
> I agree, but what is most urgent is a bit subjective and depends
> on the individual's point of view. Mine is that designing GUIs
> with VID is quite close to being good but is seriously let down
> by how difficult it is to make them scalable.
>
If I may ask, what do you really mean by "scalable"? Is the issue
to allow a user to arbitrarily change window size at any time for
whatever reason, or is it to allow a user to adjust the display to
fit the size of the monitor (e.g. closer to a "set it once and
forget it" scenario)?
If the latter, what about having a set of choices (based on the
common monitor sizes) from which the user can select? In that
case the UI designer can make sure that each is appropriately
laid out and all the positioning/scaling is "right" for each
but consistent in overall "feel" across all choices. The app
should remember the selection in a config file so that, once
set, it will present the same size every time (unless/until the
user explicitly overrides it).
A user behavior I've seen repeatedly is to size one or more app
windows to (nearly) the size of the available display, then use
window switching to move between apps. Some users like to keep
the resolution low to make the text large and easily readable
(or readable from further away) while others prefer to maximize
the resolution to get as much content on the screen as possible.
Providing pre-defined settings for common monitor sizes (e.g.,
800x600, 1024x768, 1200x1024 (?), 1600x1200), initially auto-
detecting the available real estate and picking the largest that
will fit, and allowing the user a simple way to try other sizes
(e.g., "small, medium, large, huge" or something else without
lots of scary numbers) might be an approach that could actually
simplify life for the users.
Of course, I'm assuming in the above that users are treating
their computers as tools to do some task, and the focus is on
the task, not on playing around with the computer itself. That's
not true for all computer users, obviously.
Anyway, I guess I'm dancing around the underlying questions:
- Why do windows need to be scalable?
- Do all windows need that feature?
- What problem are we really solving?
- Are we playing with symptoms, or is there a real "root-cause"
issue involved here?
> Execution speed is an issue with REBOL, but it isn't the usual
> reason you choose a high-level language, is it? Or more correctly,
<<quoted lines omitted: 3>>
> where's the advantage in chosing a high-level language over a
> lower-level one?
Good questions, all.
I tend to see language selection (regardless of "high" versus "low")
as a complicated balancing act in which one tries to find a happy
compromise among a large number of factors (in no particular order):
1) Ease of development
2) Ease of maintenance
3) Availability within the target environment/platform
4) Skillset of the professionals who will do (1) and (2)
5) Access to more professionals who already have skills with
the language/environment/platform
6) Interoperability with existing systems
7) Ability to re-use existing code/components
8) Run-time performance (both for current and projected loads)
9) Cost and availability of tools/training/learning
and (not because I've exhausted the issue, but just worn out my
fingers and your eyes... ;-)
10) The nature of the project (one-shot ad-hoc task, prototype,
proof-of-concept, research, 24x7 dark room production, etc.)
as it interacts with all of the above.
I certainly don't believe that run-time performance is the most
important issue in most cases (as long as it is adequate for the
task at hand!), but it is one of the easier factors to measure!
That means that, until REBOL can provide performance that is
roughly comparable to some other widely-used tools, it's going to
have a hard time elbowing its way into application areas where
those tools are already in use.
> > If I can imagine changing View to follow that principle, I would
> > favor something like the following. If you write
<<quoted lines omitted: 24>>
> area 100%x100%
> ][resize]
Although I now have to point out that you are assuming TWO new types:
a percent! type, and a percent-pair! type. Scope creep rears its
ugly head once again! ;-)
> Why I don't like the idea of resize turning every pane into a scalable
> one is you have the likes of buttons and so on which in most cases
> you wouldn't want to scale. They could have their defaults set to
> noscale though, which would be consistant with the current VID way of
> doing things.
>
Which is exactly what I had in mind (although I used icons as the
example of a non-scaling widget rather than buttons). I can also
imagine having a button that e.g. spans the width of a display across
the bottom having a SCALEX attribute.
-jn-
--
; Joel Neely joeldotneelyatfedexdotcom
REBOL [] do [ do func [s] [ foreach [a b] s [prin b] ] sort/skip
do function [s] [t] [ t: "" foreach [a b] s [repend t [b a]] t ] {
| e s m!zauafBpcvekexEohthjJakwLrngohOqrlryRnsctdtiub} 2 ]
[74/80] from: carl:cybercraft at: 21-Jun-2002 15:02
Hi Joel,
On 19-Jun-02, Joel Neely wrote:
>> I agree, but what is most urgent is a bit subjective and depends
>> on the individual's point of view. Mine is that designing GUIs
<<quoted lines omitted: 3>>
> to allow a user to arbitrarily change window size at any time for
> whatever reason,
Yes, that. I should've said resizable, not scalable.
> or is it to allow a user to adjust the display to
> fit the size of the monitor (e.g. closer to a "set it once and
<<quoted lines omitted: 7>>
> set, it will present the same size every time (unless/until the
> user explicitly overrides it).
No, that's much too much work for the programmer, and they'll
invariably get it wrong for every second user, if they bother to
attempt it at all. I think what RT mentioned in the beta docs about
their "Virtual Coordinate Space" would be a better way than that.
Another quote from it...
---8<---
Virtual coordinates are defined in the span facet of a window's top
level face. To set the span, use the /span and /size refinements with
layout to display a new face. The /span will indicate the virtual
coordinate space while /size specifies the actual pixel size of the
window.
layout/span/size face 4096x3072 341x25
| |
Virtual Coordinate Space |
Window's Size (real pixel space)
The top level face is inherited from the global face object. Using the
/span and /size refinement with layout will set the span and size
facets within the top level face as it is inherited. The /size
refinement must be used with the /span refinement to set the actual
pixel size of the window. If the real pixel space window size is not
set in this way, undesirable results may occur.
---8<---
The full docs can be found in the Rebol Forces archives...
http://www.rebolforces.com/archive/view099users.html
> A user behavior I've seen repeatedly is to size one or more app
> windows to (nearly) the size of the available display, then use
> window switching to move between apps. Some users like to keep
> the resolution low to make the text large and easily readable
> (or readable from further away) while others prefer to maximize
> the resolution to get as much content on the screen as possible.
Ideally they should be able to choose the fonts they're using on an
apps by apps and windows by windows basis, overiding their default
REBOL skin.
> Providing pre-defined settings for common monitor sizes (e.g.,
> 800x600, 1024x768, 1200x1024 (?), 1600x1200), initially auto-
<<quoted lines omitted: 3>>
> lots of scary numbers) might be an approach that could actually
> simplify life for the users.
Just resize and snapshot a window seems the simpliest approach to me.
(Of course, you're thinking scaling there, but anyway...) I've done
something like this with some of my view scripts. ie...
rebol []
win-size: 300x200
win-offset: 50x50
lo: layout [
across
vh2 "Window Title"
snap: button 20 "S" [
; Clicking the button saves the window's size and offset.
]
return
stuff: area
]
resize-response: does [
snap/offset/x: lo/size/x - 40
stuff/size: lo/size - 40x80
show lo
]
resize-response
view layout [
button "Test" [
view/new/offset/options lo win-offset [resize]
lo/feel: make out/feel [
detect: func [face event][
if event/type = 'resize [resize-response]
event
]
]
]
]
That keeps the snapshot button in the top right of the window when you
resize it. (The need for the window with the "Test" button is
because you have to setup the event routine after the window has
opened to capture a resize. So you have to use view/new for this to
work - which doesn't work if it's the first window you open in
View...)
> Of course, I'm assuming in the above that users are treating
> their computers as tools to do some task, and the focus is on
> the task, not on playing around with the computer itself.
Of course. (;
> Anyway, I guess I'm dancing around the underlying questions:
> - Why do windows need to be scalable?
Because if not, your average programmer assumes everyone has a
1024x768 display or better...
> - Do all windows need that feature?
It should perhaps be the default, but probably a bit late to introduce
it as the default now.
> - What problem are we really solving?
Different sized displays - from 320x200 (cell-phones and the like)
upwards...
> - Are we playing with symptoms, or is there a real "root-cause"
> issue involved here?
Root cause is different sized displays.
But that's with scaling. Resizing's different...
--- Why do windows need to be resizable?
1) Because sometimes the same window will have different amounts of
content. Text in an area is an obvious example. It's nicer to avoid
scrolling if you can, and enlarging the window can do that in some
cases.
2) And because sometimes you like to shrink a window just to give you
more deskspace to get at other stuff. If the contents don't resize
with the window, shrinking the window can mean you can't see some of
it. A shrunken text-box which you can still see and scroll through
is better than one you can't see at all.
--- Do all windows need that feature?
Probably not. A...
view layout [banner "Quit?" 210 across button "Yes" button "No"]
is better without resizing I think.
--- What problem are we really solving?
Insufficient space to have all the information you want on screen at
once.
--- Are we playing with symptoms, or is there a real "root-cause"
issue involved here?
The root cause is room-wide screens cost too much. (; And they also
can't fit in your pocket.
[snip comments about percent datatypes]
> Although I now have to point out that you are assuming TWO new
> types: a percent! type, and a percent-pair! type. Scope creep rears
> its ugly head once again! ;-)
Actually, I was just thinking of a modified pair. Pair was added with
pixel coordinates in mind I believe, hence it only accepts integers,
not numbers. So adding percentage support shouldn't break any
existing scripts. (He guessed wildly:)
--
Carl Read
[75/80] from: joel:neely:fedex at: 21-Jun-2002 11:31
Hi, again, Carl,
On Thursday, June 20, 2002, at 10:02 PM, Carl Read wrote:
>> - Why do windows need to be scalable?
>
> Because if not, your average programmer assumes everyone has a
> 1024x768 display or better...
>
Yow! Any programmer who would make such an assumption (or assume that
everybody is running a particular browser, or has millions of colors, or
a 1.2 GHz processor, or ...) needs some professional experience (unless,
of course, (s)he is working in a closed environment where all resources
are centrally controlled.
>> - What problem are we really solving?
>
> Different sized displays - from 320x200 (cell-phones and the like)
> upwards...
>
YMMV; but my experience is that when I'm designing a palm-top-sized
display, I'll want to lay out a screen in a totally different way that
I would for a desktop-/laptop-sized screen.
Of course, that's just me...
> Because sometimes the same window will have different amounts of
> content. Text in an area is an obvious example. It's nicer to avoid
> scrolling if you can, and enlarging the window can do that in some
> cases.
>
That assumes that making the window larger keeps the font sizes the same.
It seems to me that sometimes that would be the desired effect, but that
sometimes one would like the fonts to scale up with the window. Just an
observation that we have one more moving part here.
>> Although I now have to point out that you are assuming TWO new
>> types: a percent! type, and a percent-pair! type. Scope creep rears
<<quoted lines omitted: 3>>
> not numbers. So adding percentage support shouldn't break any
> existing scripts. (He guessed wildly:)
But IIRC the two elements of a pair are defined as integral. Having a
modified pair
that has non-integral elements sounds like a different
data type to me.
-jn-
[76/80] from: greggirwin:mindspring at: 21-Jun-2002 12:08
Hi Carl,
<< Pair was added with pixel coordinates in mind I believe, hence it only
accepts integers, not numbers. So adding percentage support shouldn't break
any
existing scripts. (He guessed wildly:) >>
As a side note, pairs don't allow you to use a separator, like regular
integers so there may be more to these lexical limits than we think.
>> p: 100x100
== 100x100
>> p: 1'000x1'000
** Syntax Error: Invalid pair -- 1'000x1'000
** Near: (line 1) p: 1'000x1'000
--Gregg
[77/80] from: greggirwin:mindspring at: 21-Jun-2002 12:44
<< Yow! Any programmer who would make such an assumption (or assume that
everybody is running a particular browser, or has millions of colors, or
a 1.2 GHz processor, or ...) needs some professional experience...>>
True, but I'd bet money there are a *lot* of developers out there, even good
ones, that design and test on a single machine. I know I've seen a fair
amount of software that had quite obviously never been tested on more than a
single configuration.
View has a great 24 bit compositing engine built in, but I can tell you that
gradients can look pretty darn ugly at low color depths.
The common "out" is to define "minimum system requirements". My experience
is that product managers (excluding, perhaps, large horizontal market apps)
will gladly put that kind of disclaimer out there to save time and effort.
<< YMMV; but my experience is that when I'm designing a palm-top-sized
display, I'll want to lay out a screen in a totally different way that
I would for a desktop-/laptop-sized screen. >>
That assumes you know where your app is running. :) Historically, this would
be true because you would have to port your app to those platforms. So, I
guess another question is: Should we continue down the path of
platform-specific designs or try to create cross platform UIs? Lots of gray
areas in there as I see it. I think it will depend on the app and the
platforms it runs on.
<< That assumes that making the window larger keeps the font sizes the same.
It seems to me that sometimes that would be the desired effect, but that
sometimes one would like the fonts to scale up with the window. Just an
observation that we have one more moving part here. >>
Resizing and scaling are two completely distinct features/behaviors. Scaling
implies that *everything* scales uniformly. Mixing the two behaviors is a
design error IMO.
--Gregg
[78/80] from: joel:neely:fedex at: 21-Jun-2002 17:34
Hi, Gregg,
Noooooo!!!!
Gregg Irwin wrote:
> << YMMV; but my experience is that when I'm designing a palm-top-sized
> display, I'll want to lay out a screen in a totally different way that
<<quoted lines omitted: 3>>
> guess another question is: Should we continue down the path of
> platform-specific designs or try to create cross platform UIs?
My choice of wording was deliberate:
... a palm-top-SIZED display ... desktop-/laptop-SIZED screen ...
I did not say I wanted to know where my app was running, but was talking
about the design characteristics of the user interface vis-a-vis the
SIZE of the current display environment.
Having designed apps that would run on very small and very large screen
sizes, I have seen many cases in which I do not believe that the same
widget layout could be scaled sucessfully from 240 pixels wide up to
1024 or 1600 pixels wide.
I suggest that the program should be able to inquire of its current
execution environment for the dimensions of the current display, and
then select a layout (or chioce of layouts) that the application,
workflow, or GUI designer(s) have prepared for displays in that range.
> << That assumes that making the window larger keeps the font sizes the same.
> It seems to me that sometimes that would be the desired effect, but that
<<quoted lines omitted: 3>>
> implies that *everything* scales uniformly. Mixing the two behaviors is a
> design error IMO.
I simply meant that there's a need for both, although often under
different
circumstances (but not always). For example:
- I often use a particular 3270 emulator that knows that it can only
display 25x80 characters, so when the window is stretched the fonts
scale proportionately.
- I was recently giving a presentation in a large room using a video
projector on my laptop. I popped up a terminal window to one of our
hosts to show ... something or other. I normally use fairly small
font sizes to allow me to have as much content as possible on my
screen, but the audience had trouble reading the window. I wanted
both the window and the fonts to enlarge.
- Sometimes when I enlarge a terminal window its because I want more
lines
(or wider lines, or both), but in this scenario I want everything
zoomed
up. Also, sometimes (e.g. when my eyes are tired) I'll enlarge a
term
window and the fonts so I can lean back in my chair and look at the
screen for a while from a longer distance than usual.
Having both as choices to be exercised appropriately is A Good Thing
IMHO.
-jn-
[79/80] from: carl:cybercraft at: 23-Jun-2002 23:09
On 22-Jun-02, Joel Neely wrote:
> On Thursday, June 20, 2002, at 10:02 PM, Carl Read wrote:
>>> - Why do windows need to be scalable?
<<quoted lines omitted: 6>>
> experience (unless, of course, (s)he is working in a closed
> environment where all resources are centrally controlled.
Well, I've seen plenty of View scripts with windows that won't fit on
an 800x600 screen, never mind smaller ones... (:
>>> - What problem are we really solving?
>>
>> Different sized displays - from 320x200 (cell-phones and the like)
>> upwards...
> YMMV;
That one I don't know. (:
> but my experience is that when I'm designing a palm-top-sized
> display, I'll want to lay out a screen in a totally different way
> that I would for a desktop-/laptop-sized screen.
> Of course, that's just me...
I wouldn't think so. Whether we're talking scaling or resizing a
window, it is a problem that needs to be addressed. However, bigger
screens are usually used for having more windows open, not more stuff
in a window. Gadgets seem to be a big waster of window space. (He
says, just thinking out aloud...)
>> Because sometimes the same window will have different amounts of
>> content. Text in an area is an obvious example. It's nicer to avoid
>> scrolling if you can, and enlarging the window can do that in some
>> cases.
> That assumes that making the window larger keeps the font sizes the
> same.
Yes, resizing, not scaling.
> It seems to me that sometimes that would be the desired effect, but
> that sometimes one would like the fonts to scale up with the window.
> Just an observation that we have one more moving part here.
I agree that it's desirable to both resize and scale windows. It
could be made simple and intuitive for the user too. Resize by
dragging on the windows' edges or corners as we're used to now, (and
which is done outside of a View window anyway - we just have to watch
for a resize event), and scale by clicking on "+" or "-" buttons,
(just a suggestion for how it could be done), which would need to be
part of our layouts. If RT do add scaling to View, then to get that
working would be trivial. I suspect fonts are the big problem with
getting scaling to work though.
--
Carl Read
[80/80] from: joel:neely:fedex at: 23-Jun-2002 21:38
Hi, Carl,
Carl Read wrote:
> > YMMV;
>
> That one I don't know. (:
>
Your Mileage May Vary
(mine usually does... ;-)
-jn-
--
; Joel Neely joeldotneelyatfedexdotcom
REBOL [] do [ do func [s] [ foreach [a b] s [prin b] ] sort/skip
do function [s] [t] [ t: "" foreach [a b] s [repend t [b a]] t ] {
| e s m!zauafBpcvekexEohthjJakwLrngohOqrlryRnsctdtiub} 2 ]
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted