[REBOL] Re: percent! - new datatype request
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? 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. 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 -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: percent! - new datatype request
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 ]
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with unsubscribe in the
subject, without the quotes.
[REBOL] Re: percent! - new datatype request
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 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:) 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- -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: percent! - new datatype request
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 -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: percent! - new datatype request
Hi, Gregg, Noo 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 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? 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 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. 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- -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: percent! - new datatype request
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 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, 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 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). 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- 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. 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
[REBOL] Re: percent! - new datatype request
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 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. 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 -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: percent! - new datatype request
That's what face/span is hanging around for, if I remember correctly. Anton. 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? -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: percent! - new datatype request
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, 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? 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
[REBOL] Re: percent! - new datatype request
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 [ temp/2: temp/2 + 1 ][ append tally reduce [word 1] ] ] 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), 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. 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 real0m0.31s user0m0.30s sys 0m0.01s (/export/home/jneely/try)# time tally.r /dev/null real0m10.35s user0m10.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. 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 an iBook running Mac OS X), but I think it will be hard to sell
[REBOL] Re: percent! - new datatype request
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
real0m0.29s
user0m0.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.plreal0m0.29s
user0m0.23s
sys 0m0.04s
tallyhs.r real0m1.39s
user0m1.37s
sys 0m0.02s
tallyhb.r real0m1.25s
user0m1.17s
sys 0m0.08s
tallyhz.r real0m1.68s
user0m1.59s
sys 0m0.08s
tallyb.rreal0m5.63s
user0m5.53s
sys 0m0.08s
tallyz.rreal0m5.82s
user0m5.67s
sys 0m0.10s
tallys.rreal0m8.58s
user0m8.48s
sys 0m0.08s
tallyn.rreal0m9.77s
user0m9.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.
8tallyhn.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 ]
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with unsubscribe in the
subject, without the quotes.
[REBOL] Re: percent! - new datatype request
Hi, Romano,
Romano Paolo Tenca wrote:
Tally should be an hash! to gain speed.
tally: make hash! 1
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 ]
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with unsubscribe in the
subject, without the quotes.
[REBOL] Re: percent! - new datatype request
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 -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: percent! - new datatype request
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 ]
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with unsubscribe in the
subject, without the quotes.
[REBOL] Re: percent! - new datatype request
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 -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: percent! - new datatype request
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 real0m0.29s user0m0.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...) [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 -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: percent! - new datatype request
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 real0m0.02s user0m0.01s sys 0m0.01s (/export/home/jneely/try)# time tally0.r real0m0.17s user0m0.11s sys 0m0.05s where each of the above scripts was stripped down to a bare do nothing and quit state. -jn- -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: percent! - new datatype request
Hi, Carl
Carl Read wrote:
++$tally{$word}
vs.
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]
]
]
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
real0m0.31s
user0m0.30s
sys 0m0.01s
(/export/home/jneely/try)# time tally.r /dev/null
real0m10.35s
user0m10.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 ]
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with unsubscribe in the
subject, without the quotes.
[REBOL] Re: percent! - new datatype request
In a message dated Wed, 12 Jun 2002 8:17:38 PM Eastern Daylight Time, [EMAIL PROTECTED] 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 -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: percent! - new datatype request
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 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] 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
[REBOL] Re: percent! - new datatype request
In a message dated 13/06/02 17:46:27 GMT Daylight Time, [EMAIL PROTECTED] 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 -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: percent! - new datatype request
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 -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: percent! - new datatype request
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 -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: percent! - new datatype request
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 -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: percent! - new datatype request
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 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- -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: percent! - new datatype request
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 real0m9.50s user0m9.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 real0m8.28s user0m8.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 -
[REBOL] Re: percent! - new datatype request
tally: [] Tally should be an hash! to gain speed. tally: make hash! 1 --- Ciao Romano -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: percent! - new datatype request
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 -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: percent! - new datatype request
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.
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.
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
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 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
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
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
[REBOL] Re: percent! - new datatype request
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
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 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...)
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
[REBOL] Re: percent! - new datatype request
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 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 -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: percent! - new datatype request
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 -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: percent! - new datatype request
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
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Carl Read
Sent: June 12, 2002 8:10 PM
To: [EMAIL PROTECTED]
Subject: [REBOL] Re: percent! - new datatype request
Hi Joel,
On 13-Jun-02, Joel Neely wrote:
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.
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}
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 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...)
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.
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%
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 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
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.
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
[REBOL] Re: percent! - new datatype request
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 (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. 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 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 -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: percent! - new datatype request
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
[REBOL] Re: percent! - new datatype request
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 andwhich is complex and
easy to learn, but and impossible to learn
too small for realbecause of unbridled
programming tasksfeature 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 ]
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with unsubscribe in the
subject, without the quotes.
[REBOL] Re: percent! - new datatype request
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
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.
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 ]
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with unsubscribe in the
subject, without the quotes.
[REBOL] Re: percent! - new datatype request
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 ]
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with unsubscribe in the
subject, without the quotes.
[REBOL] Re: percent! - new datatype request
Hi, Mark,
I think you've made my point... ;-)
[EMAIL PROTECTED] wrote:
In a message dated 6/7/2002 3:20:21 PM GMT Daylight Time,
[EMAIL PROTECTED] 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! hex ; 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! uHello 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 ...
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 ]
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with unsubscribe in the
subject, without the quotes.
[REBOL] Re: percent! - new datatype request
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 ]
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with unsubscribe in the
subject, without the quotes.
[REBOL] Re: percent! - new datatype request
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: 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 andwhich is complex and easy to learn, but and impossible to learn too small for realbecause of unbridled programming tasksfeature 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- -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: percent! - new datatype request
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 -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: percent! - new datatype request
Joel and Gabriele, JN - providing a means for extending the syntax within dialects so JNthat 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 -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: percent! - new datatype request
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 [EMAIL PROTECTED] -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: percent! - new datatype request
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: Joel and Gabriele, JN - providing a means for extending the syntax within dialects so JNthat 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 -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes. -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: percent! - new datatype request
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 -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: percent! - new datatype request
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Paul Tretter Sent: Thursday, June 06, 2002 11:13 PM To: [EMAIL PROTECTED] Subject: [REBOL] Re: percent! - new datatype request 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. 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 -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: percent! - new datatype request
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 -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: percent! - new datatype request
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 -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: percent! - new datatype request
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 -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: percent! - new datatype request
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: 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 [EMAIL PROTECTED] Andrew Martin ICQ: 26227169 http://valley.150m.com/ -- -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: percent! - new datatype request
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. 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: 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 [EMAIL PROTECTED] Andrew Martin -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: percent! - new datatype request
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 -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: percent! - new datatype request
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. 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. 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: 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 [EMAIL PROTECTED] Andrew Martin nice idea :) next i want units :) -volker -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: percent! - new datatype request
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: 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. 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: 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 [EMAIL PROTECTED] Andrew Martin -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: percent! - new datatype request
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 -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: percent! - new datatype request
And with it you could do something like: 100 - 50% == 50 100 + 50% == 150 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 -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: percent! - new datatype request
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: 100 - 50% == 50 100 + 50% == 150 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 Uh oh, so to-percent involves an implicit multiplication by 100, then? Looks nice, though. Anton. -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: percent! - new datatype request
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 rate: 8.25% == 8.25% price: $100.00 == $100.00 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 -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
