Re: Odd [math] behavior

This WebDNA talk-list message is from

2003


It keeps the original formatting.
numero = 52821
interpreted = N
texte = On Thursday, September 11, 2003, at 01:53 PM, Scott Anderson wrote: >> What if you allowed a Format specification in the Math context? > Well....that IS what the [format] context is for. I generally see > nothing > wrong with redundancy, just that adding new parameters does cost more > parsing overhead. WebDNA...LEAN and MEAN ;) > Curious on the parsing overhead of the implementation. Would implementing an optional format parameter increase processing overhead even when the parameter is not provided, or only if the programmer specified a format parameter? And if a format parameter was provided in the math context, wouldn't that be faster for parsing than specifying an enclosing format context? (i.e. "[math format=1.2f]17/7[/math]" vs. "[format 1.2f][math]17/7[/math][/format]"). From my observations and performance tests, the fewer contexts we use the faster the performance of the page. Thus being able to get more done with fewer contexts leads to more code executed in the compiled WebDNA module rather than the interpreted page source and makes the world a better place. A couple related thoughts - the "date" and "time" parameters for math would need a parameter label, but would still need to be handled as unlabeled parameters to avoid breaking existing code. Examples that should work if format were added as a math parameter: [math date]...[/math] [math type=date]...[/math] [math format=1.2f]...[/math] [math type=date&format=%m/%d/%y]...[/math] While we're talking math, it sure would be nice to have max() and min() functions that accepted multiple values (e.g. [math]min(2,6,3)[/math] would return 2). Also an int() or round() function that rounded the expression to the nearest integer. - brian > > -----Original Message----- > From: Brian Fries [mailto:webdna@brainscansoftware.com] > Sent: Thursday, September 11, 2003 1:44 PM > To: WebDNA-Talk@talk.smithmicro.com > Subject: Re: Odd [math] behavior > > > What if you allowed a Format specification in the Math context? > > [math format=1.2f]17/7[/math] > > This could be combined with an OPTIONAL default precision pref, but I > wouldn't want an upgrade installation to break any of my existing math, > some of which is pretty complicated and needs a high precision. > > - brian > > On Thursday, September 11, 2003, at 01:15 PM, Scott Anderson wrote: > >> >> I cringed when I saw this thread, knowing that it would lead to a >> discussion >> of the inaccuracies of binary representation of decimal numbers. >> >> I got a kick out of the following quote (taken from one of the links >> John >> provided - Thanks, John!). >> >> "Floating point is by its nature inexact. It is probably best if you >> imagined that after every floating point operation, a little demon >> came in >> and added or subtracted a tiny number to fuzz the low order bits of >> your >> result..." >> >> I am sure that even the most experienced programmer has gotten 'bit' > by >> this. >> >> So, I think the lesson here is to ALWAYS keep in mind the desired >> 'precision' when performing floating point arithmetic and use the >> [format >> x.xf] to ensure that you get what you expect. >> >> >> FEEDBACK REQUEST: Given that most WebDNA programmers would not expect > >> to >> have to deal with those 'fuzzy' low order bits, perhaps we should >> build in a >> more user-friendly default precision for the MATH context. Maybe have > >> it >> controlled via a new WebDNA pref? Any thoughts? >> >> >> >> >> >> >> -----Original Message----- >> From: John Peacock [mailto:jpeacock@rowman.com] >> Sent: Thursday, September 11, 2003 12:23 PM >> To: WebDNA-Talk@talk.smithmicro.com >> Subject: Re: Odd [math] behaviour >> >> >> Paul Willis wrote: >> >>> I fully agree, I don't understand why any calculations or formatting >> are >>> required. This is simple subtraction. 6000.4-5300.3 is 700.1 a small >>> child could do it. >>> >> >> Unfortunately, computers are far stupider than even the smallest > child. >> The >> advantage of using a computer over a child is that the computer >> actually >> does >> what you tell it to do and does it quickly (no "In a minute Daddy!"). >> >> A quick Google yielded a few useful pages: >> >> http://www.python.org/doc/current/tut/node14.html >> http://mindprod.com/jgloss/floatingpoint.html >> http://www.rwc.uc.edu/koehler/comath/14.html >> >> HTH >> >> John ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/ Associated Messages, from the most recent to the oldest:

    
  1. Re: Odd [math] behavior ( Brian Fries 2003)
  2. Re: Odd [math] behavior ( Glenn Busbin 2003)
  3. Re: Odd [math] behavior ( "Scott Anderson" 2003)
  4. Re: Odd [math] behavior ( John Peacock 2003)
  5. Re: Odd [math] behavior ( Brian Fries 2003)
  6. Re: Odd [math] behavior ( Chris List Recipient 2003)
  7. Re: Odd [math] behavior ( "Scott Anderson" 2003)
On Thursday, September 11, 2003, at 01:53 PM, Scott Anderson wrote: >> What if you allowed a Format specification in the Math context? > Well....that IS what the [format] context is for. I generally see > nothing > wrong with redundancy, just that adding new parameters does cost more > parsing overhead. WebDNA...LEAN and MEAN ;) > Curious on the parsing overhead of the implementation. Would implementing an optional format parameter increase processing overhead even when the parameter is not provided, or only if the programmer specified a format parameter? And if a format parameter was provided in the math context, wouldn't that be faster for parsing than specifying an enclosing format context? (i.e. "[math format=1.2f]17/7[/math]" vs. "[format 1.2f][math]17/7[/math][/format]"). From my observations and performance tests, the fewer contexts we use the faster the performance of the page. Thus being able to get more done with fewer contexts leads to more code executed in the compiled WebDNA module rather than the interpreted page source and makes the world a better place. A couple related thoughts - the "date" and "time" parameters for math would need a parameter label, but would still need to be handled as unlabeled parameters to avoid breaking existing code. Examples that should work if format were added as a math parameter: [math date]...[/math] [math type=date]...[/math] [math format=1.2f]...[/math] [math type=date&format=%m/%d/%y]...[/math] While we're talking math, it sure would be nice to have max() and min() functions that accepted multiple values (e.g. [math]min(2,6,3)[/math] would return 2). Also an int() or round() function that rounded the expression to the nearest integer. - brian > > -----Original Message----- > From: Brian Fries [mailto:webdna@brainscansoftware.com] > Sent: Thursday, September 11, 2003 1:44 PM > To: WebDNA-Talk@talk.smithmicro.com > Subject: Re: Odd [math] behavior > > > What if you allowed a Format specification in the Math context? > > [math format=1.2f]17/7[/math] > > This could be combined with an OPTIONAL default precision pref, but I > wouldn't want an upgrade installation to break any of my existing math, > some of which is pretty complicated and needs a high precision. > > - brian > > On Thursday, September 11, 2003, at 01:15 PM, Scott Anderson wrote: > >> >> I cringed when I saw this thread, knowing that it would lead to a >> discussion >> of the inaccuracies of binary representation of decimal numbers. >> >> I got a kick out of the following quote (taken from one of the links >> John >> provided - Thanks, John!). >> >> "Floating point is by its nature inexact. It is probably best if you >> imagined that after every floating point operation, a little demon >> came in >> and added or subtracted a tiny number to fuzz the low order bits of >> your >> result..." >> >> I am sure that even the most experienced programmer has gotten 'bit' > by >> this. >> >> So, I think the lesson here is to ALWAYS keep in mind the desired >> 'precision' when performing floating point arithmetic and use the >> [format >> x.xf] to ensure that you get what you expect. >> >> >> FEEDBACK REQUEST: Given that most WebDNA programmers would not expect > >> to >> have to deal with those 'fuzzy' low order bits, perhaps we should >> build in a >> more user-friendly default precision for the MATH context. Maybe have > >> it >> controlled via a new WebDNA pref? Any thoughts? >> >> >> >> >> >> >> -----Original Message----- >> From: John Peacock [mailto:jpeacock@rowman.com] >> Sent: Thursday, September 11, 2003 12:23 PM >> To: WebDNA-Talk@talk.smithmicro.com >> Subject: Re: Odd [math] behaviour >> >> >> Paul Willis wrote: >> >>> I fully agree, I don't understand why any calculations or formatting >> are >>> required. This is simple subtraction. 6000.4-5300.3 is 700.1 a small >>> child could do it. >>> >> >> Unfortunately, computers are far stupider than even the smallest > child. >> The >> advantage of using a computer over a child is that the computer >> actually >> does >> what you tell it to do and does it quickly (no "In a minute Daddy!"). >> >> A quick Google yielded a few useful pages: >> >> http://www.python.org/doc/current/tut/node14.html >> http://mindprod.com/jgloss/floatingpoint.html >> http://www.rwc.uc.edu/koehler/comath/14.html >> >> HTH >> >> John ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/ Brian Fries

DOWNLOAD WEBDNA NOW!

Top Articles:

Talk List

The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...

Related Readings:

Date Time Oddness (1999) [no_cache]?! (2000) Attn: Bug in GeneralStore example b15 (1997) More than one db with the same namn (was: WC2f3) (1997) Protect vs Authenicate (1997) # fields limited? (1997) PSC recommends what date format yr 2000??? (1997) textarea question (1998) Upload Graphic Problem (2004) My slower response (1997) WebCat2 beta 11 - new prefs ... (1997) HTML encoding in URLs (1997) Secure Server (1997) Searching Numbers (ZIP Code, Distance-based, Store (2004) Email encryption (1998) Date format (2000) RE: Problems with shopping cart (1997) Updating a database once per day - An example (1998) [WebDNA] Froala Editor working with WebDNA (2016) absolute paths for databases? (1997)