I'm happy to announce that Frink can now draw graphics!  This is
probably the largest single update of Frink ever, and it adds the
ability to easily draw high-quality, resizable graphics, print them, or
save them to files.  Here are some of the features:

     * Flexible coordinate system: You can draw your graphics to any
coordinates you wish, and Frink will, by default, automatically scale
and center them in your display device, eliminating the tedium and error
of manual coordinate conversions, adjustment for different window or
printer sizes, etc.

     * Dimensioned drawings: Graphics can be specified with explicit
lengths (such as "3 cm",) so exactly-sized drawings can be printed.
(Well, as accurately as your printer's driver allows them to be!)

     * Infinitely scalable: Frink's graphics are primarily designed to
work with shapes, not individual pixels, so they can be re-scaled
perfectly to display with full resolution on printers, in resizable
graphics windows, in image files, or in rescalable vector formats.

     * High-quality shapes: Polygons and polylines are drawn with
properly-joined, angled corners.

     * Anti-Aliasing: Lines and shapes are anti-aliased, eliminating
jagged edges. (When running under Java 1.2 or later. Frink's graphics
will also run on Java 1.1, but without antialiased edges.)

     * Transparency (alpha channel): Allows transparent shapes and lines,
and see-through shapes to be drawn on top of other shapes.  Anti-aliased
edges are drawn with proper transparency so they can be overlaid on any
background color or image. (Requires Java 1.2 or later for transparency.)

     * Easy writing to files: Graphics can be easily written to various
file formats, including JPEG, PNG, and Scalable Vector Graphics (SVG)
formats.  PNG supports transparency (alpha channel) and allows
antialiased, semi-transparent lines and shapes to be overlaid over other
backgrounds or layers. SVG format allows infinite rescaling and perfect
rendering to high-resolution devices such as printers, and perfect
import into other vector graphics programs.

     * Easy display on different devices: The same graphics object can be
created and then displayed on screen, printed to a printer, or written
to a file, using a single command.

    Please see the Graphics section of the documentation (
http://futureboy.us/frinkdocs/#Graphics ) for detailed information on
this major update, including sample programs.  This update consists of
over 7000 lines of new code, with a large number of new features and
capabilities.

    Also, please feel free to contribute interesting graphical programs,
suggestions, or complaints!  Or, if everything is perfect, you can just
make a donation!   http://futureboy.us/frinkdocs/donate.html  :)

--
   Alan Eliasen              |  "Furious activity is no substitute
   eliasen@...    |    for understanding."
   http://futureboy.us/      |           --H.H. Williams

gyrof wrote:
> I just purchased an ipod touch and was looking for a good unit
> converter for scientific and engineering applications. The current
> applications available for this platform are pretty pathetic. Has any
> though been given to porting Frink to this platform and/or writing a
> bonafide application for the Apple appstore? I think that an
> incredibly flexible unit converter based in Frink would be very popular.

     In short, it's up to the management at Apple.  Frink is written in
Java and requires a Java Virtual Machine (JVM) to run in.  (A JVM is
just another piece of software.)  Sun's engineers (and companies like
InnaWorks) have demonstrated a working JVM for the iPhone and iPod
Touch, but Apple's draconian licensing terms prevent anyone from getting it.

     Specifically, Apple's license prohibits any *non-Apple* product from
downloading or launching code from the network, and they prohibit Java
because it *could* theoretically do these things if you didn't secure
it.  Of course, since day one, Java was designed with a security model
that can finely control what an application is allowed to do, and could
prevent such things, so that's a bit of a red herring.

     There are hints that Sun is still in negotiations with Apple on this
issue, but it's up to Apple to reverse this decision.  Frink runs fine
on a lot of phones and other handheld devices like the Sharp Zaurus,
Symbian devices, or anything that runs Java 1.1 or higher, and has for
years.  Even on platforms with hardware and memory *much* weaker than
the iPhone.

     When phones and other devices start shipping with Google's "Android"
platform, which is highly Java-centered, that may change Apple's mind.
That will probably produce a lot of handheld-friendly Java applications.

     If Apple ever allows Java on the iPhone/Touch, Frink will follow
shortly, perhaps at the very same instant.  The exact same .jar file
runs without modification on any non-micro JVM, after all...

     More info about licensing in the Slashdot article:
http://apple.slashdot.org/article.pl?sid=08/03/11/1216211

--
    Alan Eliasen              |  "Furious activity is no substitute
    eliasen@...    |    for understanding."
    http://futureboy.us/      |           --H.H. Williams

Hi,
I just purchased an ipod touch and was looking for a good unit
converter for scientific and engineering applications. The current
applications available for this platform are pretty pathetic. Has any
though been given to porting Frink to this platform and/or writing a
bonafide application for the Apple appstore? I think that an
incredibly flexible unit converter based in Frink would be very popular.

-gf

Ryan Voots wrote:
> I would certainly be interested in any documentation on this, i
> currently planned on using chroots and resource limits to prevent this
> (ain't unix grand?) but if i can do it inside of frink i could
> probably have things much more useful.

     I've added a single convenience method to easily enable the most
restrictive security measures on a Frink interpreter.  This should be
called before parsing untrusted input.  Details have been added to the
"Embedding Frink" section of the document:

http://futureboy.us/frinkdocs/#EmbeddingFrink

    and to the "Frink" class in the javadocs:

http://futureboy.us/frinkdocs/integrate/

     Of course, setting up a chroot environment and resource limits are
also good ideas.  You could alternatively do something similar using
Java's SecurityManager classes, and, of course, most Java VMs allow you
to set the maximum amount of memory that the VM can use.  Several layers
of security couldn't ever hurt, though.

     Please let me know if you have any questions.  You'll need to
download the latest version of Frink (2008-09-07) of course.

--
    Alan Eliasen              |  "Furious activity is no substitute
    eliasen@...    |    for understanding."
    http://futureboy.us/      |           --H.H. Williams

--- In frink@yahoogroups.com, Alan Eliasen <eliasen@...> wrote:
>     Yes, there is a way to embed Frink into a Java program.  The
section
> of the documentation entitled "Embedding Frink" is a good place to
start:
>
>      http://futureboy.us/frinkdocs/#EmbeddingFrink

I don't know how i've overlooked that all of last night.

> That's why Frink has its own
> security manager framework, which prevents insecure operations from
> being performed on your system, but you have to enable that security
> manager, which is not well-documented.  I'll have to improve that.
>
>     Think about: what if someone executes:
>     read["file:///etc/passwd"]
>
>     Having a good security manager is the reason that I can allow
people
> to type in arbitrary Frink programs in my web interface and execute
them
> on my computer.
>

I would certainly be interested in any documentation on this, i
currently planned on using chroots and resource limits to prevent this
(ain't unix grand?) but if i can do it inside of frink i could
probably have things much more useful.

Ryan Voots wrote:
> I've been wanting to use frink for doing calculations internally in a
> program and I'm wondering if there is a supported way to do this? (its
> for an IRC bot).

     Yes, there is a way to embed Frink into a Java program.  The section
of the documentation entitled "Embedding Frink" is a good place to start:

      http://futureboy.us/frinkdocs/#EmbeddingFrink

     By the way, I've already built my own Frink IRC bot; it listens for
calculation requests and returns the answers.  It's built around the
PIRCbot framework, which is excellent, but I haven't bothered to add a
lot of features to it.  If you're interested in the code, let me know
and I'll clean it up a bit and make it available.

     One thing you should consider when making a Frink bot is that Frink
is a Turing-complete programming language.  A Frink interpreter normally
has the ability to read your filesystem, call arbitrary Java code,
execute infinite loops, allocate infinite amounts of memory, write
programs that cause your bot to produce lots of output and get itself
banned from IRC channels for "flooding", and do other things which may
compromise your security.  (By the way, this is not a problem unique to
Frink; even your web browser has these issues.  It's trivial to write
JavaScript that performs infinite loops, allocates more memory than you
have, opens tons of windows, etc.)  That's why Frink has its own
security manager framework, which prevents insecure operations from
being performed on your system, but you have to enable that security
manager, which is not well-documented.  I'll have to improve that.

     Think about: what if someone executes:
     read["file:///etc/passwd"]

     Having a good security manager is the reason that I can allow people
to type in arbitrary Frink programs in my web interface and execute them
on my computer.

     I'll write more about this later if there's interest.

--
    Alan Eliasen              |  "Furious activity is no substitute
    eliasen@...    |    for understanding."
    http://futureboy.us/      |           --H.H. Williams

I've been wanting to use frink for doing calculations internally in a
program and I'm wondering if there is a supported way to do this? (its
for an IRC bot).

Roedy Green wrote:
> The link to what google considers the main Frink page at
> http://futureboy.homeip.net/frinkdocs/
> has not been functioning for 4 days.
>
> Is there a replacement link?

     Augh.  Thanks for letting me know.  It's now back up.  The preferred
URL is:

http://futureboy.us/frinkdocs/

     which points to the same machine, and was working.  I did a (not
exactly willing) upgrade (well, let's call it an update at best) of my
operating system on that machine (following a kernel update that broke
my bootloader) and it looks like some of the libraries used my homemade
Perl script that monitors my IP address changes got lost in the update.

     Thanks for bringing this to my attention.  The futureboy.us domain
is preferred for the future.

--
    Alan Eliasen              |  "Furious activity is no substitute
    eliasen@...    |    for understanding."
    http://futureboy.us/      |           --H.H. Williams

The link to what google considers the main Frink page at
http://futureboy.homeip.net/frinkdocs/
has not been functioning for 4 days.

Is there a replacement link?

-------------- Original message ----------------------
From: Alan Eliasen <eliasen@...>
>
> Thus, the time #1582-10-04 23:59:59 UTC# (Julian) is followed
> immediately by #1582-10-15 00:00:00 UTC# (Gregorian)  Note that if a
> date is specified between these dates, behavior will be undefined.

But those intervening dates are not undefined.  They all have the same value. 
All of the dates in that rangebut after 1582-10-04 23:59:59 have the same offset
of the beginning of the epoch.  So converting the external representation of
those dates to the internal representation should produce the internal
representation for 1582-10-15 00:00:00.

Note also that when you add locales (e.g., C++) you will need to vary the
internal representation for the tick on which the transition occurred.  The date
of the adoption of the new calendar depended upon the national jurisdiction.  So
some official records will have been created using the old calendar, but after
the first valid date in the new calendar.  Thus there exist valid old-calendar
dates after 1582-10-15.

Consistently,

Lee Winter
NP Engineering
Nashua, New Hampshire
603-595-2608

I have fixed the calculation of Julian Day in Frink for dates B.C.,
including dates in the very distant past.  Because Frink internally uses
Julian Day to represent dates and perform date/time math, this vastly
improves the handling of dates in the distant past.  (Note:  A Julian
day is a single number, counting the number of days elapsed since
January 1, 4713 BC at 12:00 (noon) UTC.)

     In addition, the handling of the switch from the Julian calendar
(which is something very different from the Julian day) to the Gregorian
calendar was made more uniform and consistent.  By default, this switch
happens between October 4, 1582 (Julian) which was followed immediately
by October 15, 1582 (Gregorian).  Frink's algorithms use a Julian
Calendar date before this date and a Gregorian Calendar date after this
date.  Frink also displays dates in the Julian calendar before this
date. Thus, the time #1582-10-04 23:59:59 UTC# (Julian) is followed
immediately by #1582-10-15 00:00:00 UTC# (Gregorian)  Note that if a
date is specified between these dates, behavior will be undefined.

     Note that these rules for switching between calendars, parsing, and
representing dates reflects what most/all Java Virtual Machines do by
default, so passing dates between Java programs and Frink does not
involve a change of representation.

     There are more notes about the details here:
http://futureboy.us/frinkdocs/index.html#NotesOnDates

     If you're doing calculations with dates before 1583 AD, it is very
highly recommended that you update!

     As always, more details about the latest developments in Frink are
noted here:

     http://futureboy.us/frinkdocs/whatsnew.html

--
    Alan Eliasen              |  "Furious activity is no substitute
    eliasen@...    |    for understanding."
    http://futureboy.us/      |           --H.H. Williams

--- In frink@yahoogroups.com, Alan Eliasen <eliasen@...> wrote:
>    Thanks!  I agree that writing interfaces to Frink as Frink Server
> Pages gives you some large advantages:
>
>    * The ability to use all the power of HTML (and optionally
> Javascript) to create powerful user interfaces.
>
>    * Allows fancy text formatting, graphics, and extended markup.
>
>    * The calculations can be instantly shared to anyone in the world
> without them installing any new software.

Well said, to the point.

>    I had an idea today about distributing a simple pre-configured
>Tomcat engine with a Frink Server Pages distribution all set up
>within it.  It would make it easy for someone to start writing Frink
>Server Pages, without going through the difficulty of setting up
>Tomcat.  I'll see if the Apache licenses allow this.

Sounds good.

>By the way, the "Programming Mode" in the GUI is very, very simple,
>and doesn't do much.  If you are doing more serious Frink
>programming, I suggest using the Frink mode for Emacs/XEmacs, which
>does automatic indenting, code highlighting, etc., and makes life
>quite a bit easier.
> It's available here:  http://futureboy.us/frinkdocs/#EditingFrink

I must confess that I prefer vi, but I use it only in a limited way.
And I'm not really up to more serious Frink programming, at least not
to your standards. I might finish a simple implementation of the
KML/Google Earth project, hopefully.
An Eclipse plugin/editor for the fsp mode would be nice. For syntax
checking and statement completion. Writing fsps in eclipse, one can
comfortably deploy to tomcat. Is there an easy way to tweak eclipse to
do syntax check for frink? If you don't use eclipse, never mind.

> > How can I round the output of the DM[] function? Does it "conforms" to
> > anything?
> > 52 degrees, 22.822396234874070424 arcmin
>
>    Since the output of the function is a string, there's no way to
round its output, and rounding its input doesn't always work either
due to floating-point error.  So, using the function as written,
there's no good way to round.  You might want to consider writing your
own function, or simply display the result in decimal degrees, which
are easier to work with anyway.  For example, this rounds the value of
d to
> 6 decimal places:
>
>    format[d, "degrees", 6]
>

> your distances, especially nearest stars, to my calculator.  Let me
know if this is okay.

Sure go right ahead, but you might need to check the wikipedia facts
again. For instance, I used a "betacentauri" label but this is
deprecated at best. The correct name is Alpha Centauri B.

Knut

knbknb00 wrote:
> Previously I thought fsps were just another nice-to-have. However, I
> am positively surprised - FSPs make playing with frink much more
> enjoyable.  In my humble opinion it's similar to, but more comfortable
> than, the "Programming Mode" in the frink AWT GUI.

    Thanks!  I agree that writing interfaces to Frink as Frink Server
Pages gives you some large advantages:

    * The ability to use all the power of HTML (and optionally
Javascript) to create powerful user interfaces.

    * Allows fancy text formatting, graphics, and extended markup.

    * The calculations can be instantly shared to anyone in the world
without them installing any new software.

    I had an idea today about distributing a simple pre-configured Tomcat
engine with a Frink Server Pages distribution all set up within it.  It
would make it easy for someone to start writing Frink Server Pages,
without going through the difficulty of setting up Tomcat.  I'll see if
the Apache licenses allow this.

    By the way, the "Programming Mode" in the GUI is very, very simple,
and doesn't do much.  If you are doing more serious Frink programming, I
suggest using the Frink mode for Emacs/XEmacs, which does automatic
indenting, code highlighting, etc., and makes life quite a bit easier.
It's available here:  http://futureboy.us/frinkdocs/#EditingFrink

> How can I round the output of the DM[] function? Does it "conforms" to
> anything?
> 52 degrees, 22.822396234874070424 arcmin

    Since the output of the function is a string, there's no way to round
its output, and rounding its input doesn't always work either due to
floating-point error.  So, using the function as written, there's no
good way to round.  You might want to consider writing your own
function, or simply display the result in decimal degrees, which are
easier to work with anyway.  For example, this rounds the value of d to
6 decimal places:

    format[d, "degrees", 6]

> To the format[unit] function I added a "default"
> return unit
> (unaltered), in case the input is not handled by the if statements.
>
> I hope yahoo does not cripple the html code in this post...

    Thanks for your additions!  Yahoo did wrap the Frink code, which
would require fixing.  If you don't mind, I would like to add some of
your distances, especially nearest stars, to my calculator.  Let me know
if this is okay.

--
   Alan Eliasen              |  "Furious activity is no substitute
   eliasen@...    |    for understanding."
   http://futureboy.us/      |           --H.H. Williams

Everything works fine now in my Tomcat 5.5.17.
Naturally, the NullPointerExceptions on your webserver disappeared
after I submitted my last post.

Previously I thought fsps were just another nice-to-have. However, I
am positively surprised - FSPs make playing with frink much more
enjoyable.  In my humble opinion it's similar to, but more comfortable
than, the "Programming Mode" in the frink AWT GUI.

>
>    I have written several libraries and sample programs that may help
> you in this:
>
>    High-accuracy navigation libraries for lat/long manipulation,
> including very accurate algorithms for navigation on an ellipsoidal
earth:
> http://futureboy.us/fsp/colorize.fsp?fileName=navigation.frink
>
>    A web page that uses this library (and draws maps in Google Maps and
> Google Earth once you put numbers into the forms.)  Use the "view
> source" link at bottom.)
> http://futureboy.us/fsp/geocaching.fsp
>
>    Program to write very simple Google Earth .kml files (currently just
> one point.)
> http://futureboy.us/fsp/colorize.fsp?fileName=GoogleEarth.frink
>
>    And a FSP page that uses the above library to render the kml file:
> http://futureboy.us/fsp/highlight.fsp?fileName=GoogleEarth.fsp
> (this is called from geocaching.fsp)

Nice - I'll have a look at this, or try it ASAP.

>> So, maybe I'll create a ajax-y Google maps App that calls my custom
fsp behind the scenes. Fun!

Maybe I'll write/generate some javascript right inside the FSP. Maybe
I'll write another non-fsp page that consumes the results from the FSP.

>
>    I wish you luck on it!  I'd be interested in seeing it!
>

FYI: Now I have this ... a customized solar.fsp
Sun diameter: 2m.
The Coordinates are chosen so that the scaled inner solar system can
be aligned along a N-S passing street in Potsdam, Germany. Does not
have to be high accuracy.
The FSP is 95% your code, but it does almost everything what I wanted
in the first place. The coordinates of the sun are hard-wired, yes.
Dwarf planet data are from wikipedia. I hope I got them right. Sedna's
orbit is extremely elliptical and not well-known.

How can I round the output of the DM[] function? Does it "conforms" to
anything?
52 degrees, 22.822396234874070424 arcmin


To the format[unit] function I added a "default"
return unit
(unaltered), in case the input is not handled by the if statements.

I hope yahoo does not cripple the html code in this post...

Knut

##########################

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
             "http://www.w3.org/TR/html4/strict.dtd">
<HTML LANG="en">
  <HEAD>
   <TITLE>Model Solar System</TITLE>
   <META HTTP-EQUIV="Default-Style" CONTENT="Spaceship">
   <LINK REL="StyleSheet" HREF="/frinkdocs/spaceship.css"
         TYPE="text/css" TITLE="Spaceship">
   <LINK REL="Alternate StyleSheet" HREF="/frinkdocs/apeairy.css"
         TYPE="text/css" TITLE="APE Airy">
   <LINK REL="Alternate StyleSheet" HREF="/frinkdocs/style.css"
TYPE="text/css"
         TITLE="APE Classic">
   <LINK REL="Alternate StyleSheet" HREF="/frinkdocs/style2.css"
TYPE="text/css"
         TITLE="Compact">
   <LINK REL="icon" HREF="/images/futureboyicon.png" TYPE="image/png">
  </HEAD>

  <BODY>
   <H1>Model Solar System</H1>

   <%
   ceresdist = 2.77 au
   ceresradius = 975 km  / 2

   orcusdist =  39.34 au
   orcusradius =  946.3 km  / 2
   quaoardist = 43.607 au
   quaoarradius = 1260 km / 2
   erisdist =  67.7 au
   erisradius = 2400 km / 2
   sednadist = 525.86 au
   sednaradius = 1500 km / 2

   proximacentauridist = 4.22 ly
   proximacentauriradius = 0.145 sunradius
   betacentauridist = 4.36 ly
   betacentauriradius =  0.865 sunradius
   alphacentauridist = 4.37 ly      // 277600 au
   alphacentauriradius = 1.227 sunradius

   barnardstardist = 5.98 ly
   barnardstarradius = 0.2 sunradius

   planets = [["Mercury",mercurydist,2
mercuryradius],["Venus",venusdist,2 venusradius],["Earth",earthdist,2
earthradius],["Mars",marsdist,2 marsradius],["Ceres",ceresdist,2
ceresradius],["Jupiter",jupiterdist,2
jupiterradius],["Saturn",saturndist,2
saturnradius],["Uranus",uranusdist,2
uranusradius],["Neptune",neptunedist,2
neptuneradius],["Pluto",plutodist,2 plutoradius],
["Orcus",orcusdist,2 orcusradius],
["Quaoar",quaoardist,2 quaoarradius],
["Eris",erisdist,2 erisradius],
["Sedna",sednadist,2 sednaradius],
["ProximaCentauri",proximacentauridist,2 proximacentauriradius],
["BetaCentauri",betacentauridist,2 betacentauriradius],
["AlphaCentauri",alphacentauridist,2 alphacentauriradius],
["BarnardsStar",barnardstardist,2 barnardstarradius]]

   names = dict[]
   names@"scaledSundiam" = 2 sunradius
   for [name, dist, diam] planets
   {
      names@"scaled${name}dist" = dist
      names@"scaled${name}diam" = diam
   }

      scale = undef
      for [name] keys[names]
      {
         enteredscale = eval[name]

         if enteredscale
            scale = eval[enteredscale] / names@name
      }

      if (scale != undef)
      {
         if ! (scale conforms 1)
        println["<P CLASS=\"warning\">Error: You must enter a length
<EM>including</EM> the units of measure, like <CODE CLASS=\"input\">1
foot</CODE>.</P>"]
         else
         {
            println["<H3>Scale Sizes</H3>"]
            println["<P>Scale is 1:" + round[1/scale,1] + "</P>"]
   %>

   <TABLE BORDER=1 CELLPADDING=4>
     <TR><TH>Name</TH><TH>Distance from
Sun</TH><TH>Diameter</TH><TH>Geogr. Coord.
     <TR><TD>Sun</TD><TD></TD>
      <TD><%= format[2 sunradius scale] %></TD>
      <TD>(52&deg; 22' 46.65'' N,  13&deg; 03' 57.32 E)</TD>
     <%
       for [name, dist, diam] planets
       {
          println["<TR><TD>$name"]
          println["<TD>"+ format[dist scale]]
          println["<TD>"+ format[diam scale]]
          geolat = DM[DMS[52, 22, 46.65] + dist/earthradius * scale]
       if (dist * scale conforms meter)
       {
            println["<TD>" + format[geolat] + " N, 13&deg; 03' 57.32 E
</TD>" ]
       }
       } %>
     </TABLE>

     <P><B>Scaled speed of light: </B> <%= format[c scale] %></P>
      <HR>
<%
      }
   }

    format[unit] :=
    {
       if (unit conforms meter)
       {
          if (unit > 1 km)
             return round[unit, .0001 km] -> ["km", "m"]
          if (unit > 1 m)
             return round[unit, .001 m] -> ["m", "cm"]
          if (unit > .1 m)
             return round[unit, .0001 m] -> ["cm"]
          return round[unit, .001 mm] -> "mm"
       }

       if (unit conforms mph)
       {
          if (unit > 0.1 mph)
             return format[unit, "km/hour", 3]
          return format[unit, "km/hour", 3]
       }

       return unit
    }

	 //from the units.txt file
	 //DMS[d,m=0,s=0] :=
	 //{
	 //   if d<0 degrees
	 //   -(-d degrees + m arcmin + s arcsec)
	 //   else
	 //   d degrees + m arcmin + s arcsec
	 //}


   %>

   <H3>Define Your Scale</H3>
   <P>
    This page calculates the sizes of objects in a
    model solar system.</A>
   </P>

   <P>
    To determine a scale, enter a scaled size in <B>only one</B> of the
boxes
    below.  The size should be entered <EM>both</EM> as the number
<EM>and</EM>
    its units of measurement, for example, if you want Jupiter to be 6
feet 6
    inches in diameter, enter <B>6.5 feet</B> or, alternately, <B>6
feet + 6
    in</B> (the plus sign is necessary) in the box for Jupiter's diameter.
   </P>

   <P>
    You can use just about any length (usually in lowercase) in singular or
    plural, such as foot, feet, meter, meters, m, inch, inches, in, miles,
    yards, cm, mm, millimeters, centimeters, cm, micrometers,
nanometers, nm,
    gigameters, Gm, rods, furlongs, kilometers, km, league, <A
    HREF="solar.fsp?scaledPlutodist=marathon">marathon</A>, etc.
   </P>

   <FORM ACTION="solar.fsp" METHOD="POST">
    <TABLE BORDER=0>
      <TR><TH>Name<TH>Distance from Sun<TH>Diameter
      <TR><TD>Sun<TD><TD><INPUT TYPE="TEXT" NAME="scaledSundiam">
    <% for [name, dist, diam] planets
          println["<TR><TD>$name<TD><INPUT TYPE=\"TEXT\"
NAME=\"scaled${name}dist\"><TD><INPUT TYPE=\"TEXT\"
NAME=\"scaled${name}diam\">"]
     %>
    </TABLE>
    <INPUT TYPE="SUBMIT" VALUE="Calculate">
   </FORM>


  </BODY>
</HTML>

knbknb00 wrote:
> Thanks for providing a fix, (and the other ingenious features of the
> new release, mentioned in the other posting from yesterday)!
> Can deploy the frink.war file now.
>
> However, on my Tomcat, the resource FrinkServletDispatcher (or so)
> cannot be loaded. I am not sitting at that computer right now. So I
> can't give you the true error message.

    Okay, I've once again changed the structure of the .war file so that
all classes go into the internal .jar file, instead of having some in
the classes/ directory and some in the lib/ directory.  This should
hopefully eliminate potential classloader problems, and it fixes another
problem that probably made the war file not work anyway.  It now works
on an older Tomcat installation where it didn't before.  Please give it
another try and let me know.  Sorry about the problems.

> By the way, your fsps on the futureboy.us site give
> FrinkEvaluationException: java.lang.NullPointerExceptions.

    I think one of my servlet environments was having similar problems.
I didn't see the problem occurring, but since I have load-balancing and
failover on my servers, it's possible that the requests were going to
one of the malfunctioning servers, which wasn't malfunctioning badly
enough for it to be taken out of service.  :|

> Indeed, considering only the inner solar system, aligned along a
> linear feature, such as a street in my neighborhod, the planets seem
> to be pretty close together, and this is probably slightly misleading.
>
> Today I had another idea while thinking about this little project, as
> follows : the script might optionally accept another parameter, of
> geographic coordinates (longitude, latitude) which could indicate the
> the location of the sun model. The relative positions of the planets
> would be calculated as well, and their corresponding geographic
> coordinates (either on a straight line or the true current positions
> on their scaled-down elliptical model orbits).
> Then let the script write the whole thing out as a .kml File to show
> in Google Earth. Yesterday I already tried plotting the planetary
> distances manually, using Google Earth's line/path tool. Takes too
> much time, though. (And manually, anything else other than aligning
> them along a straight line is infeasible).

    I have written several libraries and sample programs that may help
you in this:

    High-accuracy navigation libraries for lat/long manipulation,
including very accurate algorithms for navigation on an ellipsoidal earth:
http://futureboy.us/fsp/colorize.fsp?fileName=navigation.frink

    A web page that uses this library (and draws maps in Google Maps and
Google Earth once you put numbers into the forms.)  Use the "view
source" link at bottom.)
http://futureboy.us/fsp/geocaching.fsp

    Program to write very simple Google Earth .kml files (currently just
one point.)
http://futureboy.us/fsp/colorize.fsp?fileName=GoogleEarth.frink

    And a FSP page that uses the above library to render the kml file:
http://futureboy.us/fsp/highlight.fsp?fileName=GoogleEarth.fsp
(this is called from geocaching.fsp)

> So, maybe I'll create a ajax-y Google maps App that calls my custom
> fsp behind the scenes. Fun!

    I wish you luck on it!  I'd be interested in seeing it!

--
   Alan Eliasen              |  "Furious activity is no substitute
   eliasen@...    |    for understanding."
   http://futureboy.us/      |           --H.H. Williams

Thanks for providing a fix, (and the other ingenious features of the
new release, mentioned in the other posting from yesterday)!
Can deploy the frink.war file now.

However, on my Tomcat, the resource FrinkServletDispatcher (or so)
cannot be loaded. I am not sitting at that computer right now. So I
can't give you the true error message.

By the way, your fsps on the futureboy.us site give
FrinkEvaluationException: java.lang.NullPointerExceptions.


>    Very nice!  I have been considering making a version of the model
> solar system that works in 2 dimensions and displays the actual
> distances and locations of the planets for any given date.  When people
> build model solar systems, they're usually in a straight line, which
> helps to underestimate true distances in our solar system!
>

Indeed, considering only the inner solar system, aligned along a
linear feature, such as a street in my neighborhod, the planets seem
to be pretty close together, and this is probably slightly misleading.

Today I had another idea while thinking about this little project, as
follows : the script might optionally accept another parameter, of
geographic coordinates (longitude, latitude) which could indicate the
the location of the sun model. The relative positions of the planets
would be calculated as well, and their corresponding geographic
coordinates (either on a straight line or the true current positions
on their scaled-down elliptical model orbits).
Then let the script write the whole thing out as a .kml File to show
in Google Earth. Yesterday I already tried plotting the planetary
distances manually, using Google Earth's line/path tool. Takes too
much time, though. (And manually, anything else other than aligning
them along a straight line is infeasible).
So, maybe I'll create a ajax-y Google maps App that calls my custom
fsp behind the scenes. Fun!

Knut

I've made a lot of changes to Frink recently, probably too many to
mention here.  As always, the "what's new" file contains the most detail
about all new changes:

http://futureboy.us/frinkdocs/whatsnew.html

    Among other things, here are some bigger changes:

    * Frink can now handle fractional exponents in base dimensions, (so
you can say things like m^(1/2) and do quantum-mechanical calculations
or work with systems of units that have weird fractional exponents like
Gaussian units or Heaviside-Lorentz units.)

    * Frink now makes more suggestions if you try to convert units to
other units with different dimensions.

    * Historical British price data is fixed.

    * Various improvements to numerics.

    * Fixes for some new object-oriented constructs.

    By the way, I've been working very hard at making math on large
integers go much faster, but in a way that benefits all Java programs.
Since Sun open-sourced Java, I've been able to contribute significantly
faster algorithms to Sun's BigInteger classes, including much faster
multiplication (I've implemented Karatsuba multiplication, 3-way
Toom-Cook multiplication and faster squaring algorithms, faster
exponentiation, etc.)  This will make Frink (and all Java programs)
significantly faster for very large integers, but the Sun reviewers
haven't reviewed them yet.  Hopefully these changes will be in Java 1.7.

--
   Alan Eliasen              |  "Furious activity is no substitute
   eliasen@...    |    for understanding."
   http://futureboy.us/      |           --H.H. Williams

knbknb00 wrote:
> Hi Alan,
>
> today I tried to install the frink.war web application into my tomcat
> server. In contrast to the description on the web page,
> http://futureboy.us/frinkdocs/fspdocs.html
> There seems to be no web.xml in the war file. Is this intentional? has
> it been obfuscated, too?

    Oops!  No, it was supposed to be in there, but i had a problem in the
building process.  It's fixed now.  I changed the way the war file was
built, so please let me know if you have any problems or if it appears
that anything else is missing.  Thanks for letting me know.

> My final goal is to build a customized version of the Model Solar
> System fsp.
>
> I want the output in km, and also add some more distances (to Quaoar,
> Sedna and Eris, maybe to Alpha Centauri).

    Very nice!  I have been considering making a version of the model
solar system that works in 2 dimensions and displays the actual
distances and locations of the planets for any given date.  When people
build model solar systems, they're usually in a straight line, which
helps to underestimate true distances in our solar system!

--
   Alan Eliasen              |  "Furious activity is no substitute
   eliasen@...    |    for understanding."
   http://futureboy.us/      |           --H.H. Williams

Hi Alan,

today I tried to install the frink.war web application into my tomcat
server. In contrast to the description on the web page,
http://futureboy.us/frinkdocs/fspdocs.html
There seems to be no web.xml in the war file. Is this intentional? has
it been obfuscated, too?

Quote
"In the .war file's web.xml file, there's a fsp-root initialization
parameter indicating where Frink Server Pages should be loaded from.
You'll probably need to modify this."



My final goal is to build a customized version of the Model Solar
System fsp.

I want the output in km, and also add some more distances (to Quaoar,
Sedna and Eris, maybe to Alpha Centauri).

Best regards,

Knut

Those fellows at Rolling Rock, not being content with merely brewing
skunky beer, have created a clearly hoaxish ad campaign to make people
believe that they're going to shine a laser on the moon with their logo.

    They've apparently hired the great engineers of the fabled
spaceship that visited the sun (but did so safely because they did it at
night,) in that they plan on shining their message on the full moon.
Yes, the full moon that's illuminated by the full force of the sun,
which shines every bit as bright on the moon as it does on earth.  (A
bit brighter on the moon, actually.)  I understand that Rolling Rock
treats their employees to drive-in movies during the day, too.

    Just for argument's sake, let's see how much power they'd have to
expend to make this happen.  The following calculations are Frink
notation ( http://futureboy.us/frinkdocs/ ):

    The moon (and the earth) both receive about 1372 watts per square
meter of energy from the sun.  (The derivation of that is in the Frink
documentation here: http://futureboy.us/frinkdocs/#Superman )

    Of course, it's hard to project an image in direct sunlight.  Go try
it.  The sun is bloody bright.  Let's give them the benefit of the doubt
and pretend that we could actually detect their lasers on the moon if
they were only 10% as bright as the light from the sun, though.  That's
generous.  The calculations are:

    sunpower = 1372 W/m^2
    logopower = sunpower * 10 percent

    Now, the moon presents a face to us that's:

    moonarea = pi moonradius^2

    which gives about 3.66 million square miles.  This is very close to
the area of the contiguous 48 United States.  And they're saying they'll
project an image that lights that whole thing up, which is visible ...
in direct sunlight?  Think about the sun beating down on the entire
country and think about some projector from the sky trying to project an
image on top of that.  Across the whole country.  Is this starting to
sound feasible?

    Let's say that they're only going to light up 5% of the surface of
the moon with their logo at any time.  Thus, the lit area is only:

    litarea = moonarea * 5 percent

    So, the total amount of power their laser will have to deliver is:

    laserpower = litarea * logopower

    So, the amount of power they'd have to deliver is 65 TRILLION watts.

   (This is equal to the power of detonating one Hiroshima-sized nuclear
weapon every 0.8 seconds constantly for as long as you're going to run
the laser.  If your laser's not perfectly efficient, it's going to dump
  much more than that amount of power as heat.  You don't want to be
standing around it.)

    65 trillion watts is about 80 times as much electrical power as every
electrical power plant in the U.S. can generate, put together.  I'm not
sure where they're going to plug in their laser.  Maybe they have
awesome batteries.  This may get expensive.

    How expensive would it be?  Well, Pennsylvania electricity rates in
December 2007 were about 10.6 cents/kWh.

    electricity = 10.6 cents/kWh

    So, if they kept the display on for just 5 minutes, it would cost:

    electricity * laserpower * 5 minutes

    Which would give a cost of 575 million dollars.  Well, we'd have to
expect that prices would have to go up, considering they'd have to build
79 times more electric plants than the U.S. already *has*, just to power
that laser.

    Oh, and consider that Rolling Rock was bought by Anheuser-Busch for
only 82 million dollars.  So, for the value of the whole worth of the
company, they could only run the display for:

    82 million dollars / (laserpower electricity) -> sec

    Which gives 42.7 seconds.

    So, in a nutshell, don't bother looking up.

    Perhaps if they used some of that wonderful optical technology to
keep ultraviolet light out of their beer bottles (hint: try brown glass,
geniuses) then it wouldn't taste like wet dead skunk we found under our
porch once.  Actually, the skunk was less skunky.  And he'd been dead a
while.

--
   Alan Eliasen              |  "Furious activity is no substitute
   eliasen@...    |    for understanding."
   http://futureboy.us/      |           --H.H. Williams

There have been a variety of improvements to Frink, including one
rather important bug.

    The most important bug occurred when when dividing some integer
expressions a/b where the numerator was a large integer (magnitude
greater than 2^31).  Due to the way that Frink simplifies expressions,
this case did not happen often, but occurred when more complex
expressions involving uncommon operators or functions were encountered,
like 2^40 / 40!.

    The error manifested itself by printing "NotAnIntegerException" and
halting the program.  This bug did *not* cause silent errors, nor did it
ever produce incorrect answers; if you encountered it, the program
halted with this error message.  Please update your version of Frink at
the usual location:

    http://futureboy.us/frinkdocs/

    In addition, there have been a lot of little improvements and new
features:

    * Added a new "multi-line" input mode to the AWT GUI.  This allows
you to easily write multi-line functions, loops, or control flow
statements without being confined to the single-line input field.  To
access this, select "Multi-Line" from the "Mode" menu or use the
accelerator key listed in that menu.  This may undergo changes in the
handling of the up and down keys, which is currently non-optimal.   Also
note that multi-line mode requires that you click the "Go" button to
execute the statement. Hitting the return key just moves the cursor to a
new line.

    * Fixed an error message that may have incorrectly claimed "No
function match found for function name" when the error was actually an
undefined method call *somewhere in the body of that function*.

    * Improved error messages when attempting to call methods on an
object that really isn't an object.

    * Added various functions and methods for manipulating arrays, such
as array.pushFirst[x] and array.popFirst[] methods to allow pushing and
popping from the front of an array, and array.lexicographicPermute[]  to
produce all the permutations of the elements in the array in
lexicographical order. This is in contrast to the array.permute[] method
which returns the permutations in no particular order (and does thus not
require them to be comparable.)

    * Improved Frink-to-Java introspection and mapping of types between
Frink types and Java types.

    * Improved many functions in the sun.frink astronomical library,
including adding functions to predict moon phases, and the position of
the moon's crescent.  See:
      http://futureboy.us/fsp/colorize.fsp?fileName=sun.frink

      These were used to enhance the "Moon Locator" web page, to show
many more details about the moon, including the position of its
crescent, its distance from earth, and even its velocity towards earth.
  (Right now, the moon is receding from earth at a velocity of 104 mph.)

    * Added a new "guitools" library to Frink for easy building of
graphical user interfaces.  This is still experimental and everything
about it may change, but there's a quick sample of building a GUI with
overloaded paint methods in the guitoolstest.frink file:

    http://futureboy.us/fsp/colorize.fsp?fileName=guitoolstest.frink


    I do not usually announce all minor releases to this list, but I do
announce them to the Freshmeat list:
    http://freshmeat.net/projects/frinklang/

    (Follow the "subscribe to new releases" link to get on this list.)

    I will probably create a poll for this list to find out if most
people would rather have every minor release announced to this list as well.

    As always, a detailed list of changes is available at:
    http://futureboy.us/frinkdocs/whatsnew.html

--
   Alan Eliasen              |  "Furious activity is no substitute
   eliasen@...    |    for understanding."
   http://futureboy.us/      |           --H.H. Williams

Mike Zraly wrote:
> An interesting alternative to interval arithmetic is something called
> "affine arithmetic".  It models measurements as a center value +/- a
> random value - which is basically the same thing as an interval.

    Thanks very much for the references!  I've had several rather lengthy
e-mail discussions with people who have encountered interval arithmetic
for the first time in Frink and have thought that the two most common
problems in interval analysis: 1.) the dependence problem and 2.) the
problem of overestimation were due to bugs in my implementation.  :)
These problems are, in fact, common to all interval analysis in any
language (or in pencil-and-paper interval calculations.)  It's common
enough that I need to take these discussions and add them to the Frink FAQ.

    I have looked into affine arithmetic in the past, but never
implemented it or worked with it in any depth.  It has some quite nice
properties and may give more tightly bounded results than interval
arithmetic in some cases.  It's certainly more difficult to implement
than interval arithmetic, and would likely be significantly slower
(although that's often not a problem.)  One sees a lot of the same
issues when trying to generalize intervals to complex numbers, which
Frink hasn't attempted yet (and is not well standardized in the field.
For instance, does one represent a complex interval as a rectangular box
or as a rotated rectangle or as an ellipse with certain axis lengths and
some rotation?)

    One large issue, it seems, is that very many (most?) operations are
*not* affine (even multiplication isn't) so one must choose some affine
approximation to *every* non-affine operation and then add an additional
error term to that approximation.  Are there a standard set of affine
approximations that are usually chosen for common operations?  I've
never seen an enumeration of them.

    If you, say, have a large number of multiplications, the potential
number of error terms in the affine representation of each number may
become *huge*, which may or may not be a problem.

    Even printing out a human-comprehensible value of an affine number
may be difficult, as the result of an affine operation will very often
be a complicated polygon (or n-dimensional polytope!)  This is a human
limitation of being able to understand the results, not a limitiation of
affine numbers, I guess.  But if humans can't understand the answer, the
answer becomes of diminishing value.  Intervals, for their perhaps wider
bounds, might be more comprehensible.

    You may be interested in some discussions that took place a while
back about interval arithmetic vs. affine arithmetic vs. automatic
differentiation, with some application to their implementation in Frink:

http://lambda-the-ultimate.org/node/1301#comment-14660

>  If
> you create two new affine measurements
>
> a = 10 +/- 1 // internally 10 + 0.5 * r1, r1 being [-1,1]
>
> b = 10 +/- 1 // internally 10 + 0.5 * r2, r2 being [-1,1]
>
> then a+b and a-b produce the same results as interval arithmetic.
> However, if you subtract an object from itself, e.g. a-a or b-b, you
> get 0 +/- 0 because the random parts cancel out.

    This property is indeed quite nice.  This is very useful to reduce
the impact of the "dependence problem" which is common in interval
analysis.  In some interval implementations (such as Sun's in their
Fortran and C++ products,) there's a "dependent subtraction" (and
dependent division, etc.) operator (in Fortran, I think it's called
.DSUB.) that subtracts an interval from another interval, with the
assumption that the interval being subtracted was already added to the
original interval, allowing for a zero result as above.  The compilers
don't do this for you automatically, though.  That requires human-level
knowledge to determine when using those operators are appropriate.  I've
considered adding these to Frink, but have been reticent, partially
because they're sorta rarely applicable and subject to misuse.

    It's thus left to the programmer to algebraically simplify their
expressions, when possible and reasonable, to minimize dependence.
Sometimes you can eliminate dependence entirely and get perfectly sharp
bounds using interval arithmetic, just by rearranging your equations.
For example, (x-y)/(x+y) can be written as the form  1 - 2/(1 + x/y).
Since each variable occurs only once in the latter expression,
dependence is eliminated and the bounds will likely be narrower when
doing interval calculations.  There will be *no* overestimation due to
dependence in the latter case.

    This is presumably why mathematicians still make the big bucks.  It's
hard to know what reformulation might achieve the tightest bounds.

> Jorge Stolfi's project page describing [affine arithmetic] is here:
>
> http://www.ic.unicamp.br/~stolfi/EXPORT/projects/affine-arith/

    Thanks!  From what I've heard, Stolfi's is one of the very few
implementations of affine arithmetic to round quantities properly;
handling rounding in affine arithmetic appears to be much more difficult
than in interval analysis.  Is it?  Without proper rounding, interval
arithmetic and affine arithmetic's ability to give guaranteed bounds
(their raison d'etre) rapidly approaches zero.

> This might be an interesting addition to frink.

    It certainly would be!  I've thought about it, but haven't found very
good in-depth books on the topic.  Can you recommend any?  Contribute
any?  :)

    I'd have to admit that it would probably be pretty low on the
priority list, though, unless it really captured my attention and I
found a reference that dealt with the tricky problems.  I'm still
researching the state of the art in interval analysis, after all.  I'm
currently working on extending Frink's numerical classes to handle:

    * Infinities (positive and negative, and possibly complex)
    * Extension of intervals to include infinities
    * Extension of intervals to include unions of disjoint intervals
    * Optional, user-selectable features like "divide by zero returns
interval, or infinities" instead of producing an error, etc.

    Other extensions to numerical types (with higher priorities on my
to-do list) include:

    * added interval operators (intersection, union, hull, etc.)
    * Vectors
    * n-dimensional Matrices
    * quaternions (octonions, sedenions?)

    Note that there's a lot of difficulty and problems with doing
symbolic manipulation or automatic simplification of equations (which
was first introduced in Frink several months back) *and* doing many of
these types of numeric operations.  For example, performing the
simplification x-x = 0 might be true for the real numbers, but is not
necessarily valid for intervals (think about replacing both instances of
x with the interval [1,2]).  Or even for numbers containing units of
measure!   Intervals are no longer distributive.  Quaternions are no
longer commutative.  So you have to know the kind of numbers that *may
someday be* contained in your variables to do the right thing.  Sigh.

    I'll look into affine arithmetic more.  The citations were useful.
If you have recommendations for books, please let me know!

--
   Alan Eliasen              |  "Furious activity is no substitute
   eliasen@...    |    for understanding."
   http://futureboy.us/      |           --H.H. Williams

An interesting alternative to interval arithmetic is something called
"affine arithmetic".  It models measurements as a center value +/- a
random value - which is basically the same thing as an interval.  If
you create two new affine measurements

a = 10 +/- 1 // internally 10 + 0.5 * r1, r1 being [-1,1]

b = 10 +/- 1 // internally 10 + 0.5 * r2, r2 being [-1,1]

then a+b and a-b produce the same results as interval arithmetic.
However, if you subtract an object from itself, e.g. a-a or b-b, you
get 0 +/- 0 because the random parts cancel out.

The nice thing about affine arithmetic is that it allows you to treat
variables as measurements of physical quantities and in many cases
compute tighter bounds on their results.

There's a good description of affine arithmetic here:

http://www.sbmac.org.br/tema/seletas/docs/v4_3/101_01summary.pdf

Jorge Stolfi's project page describing it is here:

http://www.ic.unicamp.br/~stolfi/EXPORT/projects/affine-arith/

This might be an interesting addition to frink.

- Mike

I've just released a new version of Frink that fixes foreign language
translations to work again.  Downloading the new version is highly
recommended.  (If you use Java Web Start, you should get the new version
automatically.)

    In addition, there were a few small changes to defining multi-line
anonymous functions/"procedure blocks", as well as adding a few
functions like isInteger[x].

    Also, if you'd like to download all of the current Frink sample
programs in one file, it's available here:

    http://futureboy.us/frinksamp/sample.zip

    As always, detailed discussions of the changes can be found at:

    http://futureboy.us/frinkdocs/whatsnew.html

--
   Alan Eliasen              |  "Furious activity is no substitute
   eliasen@...    |    for understanding."
   http://futureboy.us/      |           --H.H. Williams

If you do any sort of calculations that involve air, you might be
interested in my recent implementation of the U.S. Standard Atmosphere,
1976 (up to 86 km).  This allows easy calculation of many atmospheric
parameters at varying altitudes. (By the way, the U.S. Standard
Atmosphere is identical to the international ICAO Standard Atmosphere in
this range. The U.S. Standard Atmosphere is just defined to higher
altitudes.)

It now supports calculation of the following:

     * Temperature
     * Pressure
     * Molar volume
     * Number Density
     * Mean air particle speed
     * Mean free path
     * Mean collision frequency
     * Speed of sound
     * Dynamic viscosity
     * Kinematic viscosity

http://futureboy.us/fsp/colorize.fsp?fileName=StandardAtmosphere.frink

For examples of how to use this class, see:

http://futureboy.us/fsp/colorize.fsp?fileName=StandardAtmosphereTest.frink

--
   Alan Eliasen              |  "Furious activity is no substitute
   eliasen@...    |    for understanding."
   http://futureboy.us/      |           --H.H. Williams

The latest release of Frink fixes a bug in labeled/unlabeled "break"
statements to break out of loops.  When adding labeled break statements,
I had inadequate logic to handle all of the cases correctly.   D'oh!
This manifested itself as a "Break statement used outside a loop" error
when using an unlabeled break.

    There have been several other improvements that I haven't reported on
this list, such as the eval[] statement being able to evaluate an array
of items, the ability to create arrays of Java objects (including
primitives like byte[] and int[]), and changes to interval arithmetic.

    As always, detailed discussions of the changes can be found at:

    http://futureboy.us/frinkdocs/whatsnew.html

--
   Alan Eliasen              |  "Furious activity is no substitute
   eliasen@...    |    for understanding."
   http://futureboy.us/      |           --H.H. Williams

Mike Crowe wrote:
> Alan,
>
> Excellent points.  As I was reading your thoughts, it occurred to
> me:  Am I really asking for an array and for you to sum the specific
> parameters for objects in the array?
>
> I have an array of bulbs:
>
> bulbs = new array
> // build the collection here
> bulbs -> dollars
>
> Would this work?

    Unfortunately, it won't work right now (and will probably never work
automatically) for the same reasons that we discussed before.  Whether
you're summing items that happen to be in an array, or items that are
discrete, you'd still have the same issues of "what does it mean to sum
two objects" that I discussed here, for which there is no
always-meaningful procedure.

    If you want to sum some feature of a bunch of items, it will have to
be done manually.  For example, if the variable "bulbs" contains an
array of the bulbs you talk about, you could do it something like:

sum = 0 dollars
for b = bulbs
    sum = sum + b.cost

--
   Alan Eliasen              |  "Furious activity is no substitute
   eliasen@...    |    for understanding."
   http://futureboy.us/      |           --H.H. Williams

Alan,

Excellent points.  As I was reading your thoughts, it occurred to
me:  Am I really asking for an array and for you to sum the specific
parameters for objects in the array?

I have an array of bulbs:

bulbs = new array
// build the collection here
bulbs -> dollars

Would this work?

Mike

--- In frink@yahoogroups.com, Alan Eliasen <eliasen@...> wrote:
>
> Mike Crowe wrote:
> > I came across a problem that I think Frink would be ideal for.
> > However, I don't know if it has this capability or not.
>
>    There are perhaps two different issues in what you've discussed.
> I'll address them below.
>
> > What I need is to describe an object that has multiple dimensions
> > that are NOT related:
> >
> > class bulb {
> >   var brighness is wattage // (I'm making this up as I go)
> >   var cost is currency
> >   var wavelength is length // enter the wavelength of the bulb
> >   ...
> > }
> >
> > red is bulb = new bulb["red",10 watts,1 dollar,500 nm]
> > green is bulb = new bulb["green",5 watts,0.5 dollar,400 nm]
>
>     The above is all fine (assuming a suitable class definition and
> constructor.)  There are some minor issues like this should use
"power"
> for wattage, etc.
>
> > display = 10 red + 20 green
>
>    This is issue 1:  overloaded operators for user-defined types.
This
> allows you to define what, say, the "+" operator will mean when
adding
> two (possibly different) class types, or what it means to multiply a
> class type by a numeric type (as in "10 red") above.  There are at
least
> two different overloaded operators in the above example.
> Unfortunately, Frink doesn't have the capability to define
> user-overloaded operators at all right now, so there's no way to do
this
> as written.  You could, however, do the less satisfactory function
> definition:
>
> add[a is bulb, b is bulb] :=
> {
>    ... add field members here...
>    ... and return something (but of what type?) ...
> }
>
>    However, the obvious question is "what do you do with each
field?"
> Do you add the brightnesses?  (Mmm... maybe.  You might add the
power
> consumptions, but the *brightnesses* might not be additive.)  Add
the
> costs?  (Maybe.)  Add the wavelengths?  (Never!)  This reminds me
of the
> story in Richard Feynman's autobiography where science textbooks
asked
> kids to *add* star temperatures, which has little or no physical
> meaning, (other than if you were going to later, say, take an
average,)
> that caused him so much annoyance.  See
> http://www.textbookleague.org/103feyn.htm
>
>    Also, what is the return type?  (10 bulbs is not an object of
type
> bulb, for instance, and ten cats is not a cat, with a height and an
a
> name, etc.) so a new type would likely have to be created.)
>
>    There are other questions, like "can you have a fractional bulb",
> "can you have a complex number of bulbs like 6i", "what do you put
into
> the 'name' field", etc.
>
>    Then there are things like temperature, where if you add 100
gallons
> of water at 280 K and 1 gallon at 250 K, what temperature (or even
> volume or density) do you get?  (There are multiple subtleties
there.)
>
>    So, I doubt that addition or multiplication of class items can or
> should be done automatically.  The programmer will probably have to
> specify what it means to add or multiply two classes, and explicitly
> define what the return type will be.
>
>    I have overloaded operators on my "to-do" list, but I don't know
when
> I'll be able to get to it.  It's a fair amount of work.
>
> > print display -> dollars     // this would then total the
currency
> > portion of the class (10*$1 + 20*$0.50) or $20 total
> >
> > print display -> wattage     // this would total the wattage of
all
> > bulbs (10*10 + 20*5 = 200 watts)
>
>    This is a second issue.  I think what you're asking is for Frink
to
> look into the internal fields of a class and, when applying a
conversion
> operator, see if there's any field that has the dimensions that
you're
> requesting, and return that field.
>
>    There are problems, of course, if there are two or more (or zero)
> fields with the same dimensions.  Which one do you use?
>
>    I've thought about this one in the past, and what I think I'd do
> would be to only *suggest* the one or more internal fields that
*might*
> be the one you're looking for, and produce that as an error/helpful
> hint, like when is done now when you have a conformance error in a
> calculation:
>
> gravity foot -> joules
>
>  Conformance error
>    Left side is: 2.98906692 m^2 s^-2 (specific_energy)
>   Right side is: 1 m^2 s^-2 kg (energy)
>      Suggestion: multiply left side by mass
>
>  For help, type: units[mass]
>                    to list known units with these dimensions.
>
>
>
>    So the error would probably say something like:
> -----------------------------------------------------------
> display -> dollars
>
>    Field error.
>    The object "display" is an object of type "bulb".  Its value is:
> bulb
> {
>    brightness = 100 W
>    cost = 1.07 dollars
>    wavelength = 550e-9 m
> }
>
>    The field "cost" has the dimensions you're looking for.  Perhaps
you
> should be asking for "display.cost"?
> --------------------------------------------------------------
>
>    Or something like that.  I really want to avoid too much "guess
what
> I mean" behavior, because sometimes I'll silently guess quite
wrong, or
> there might be a field that matches by accident, which is not the
field
> you intended (because you may have forgotten to multiply by a
constant
> or something.)  I'd rather that the programmer make explicit what
they
> mean, especially in a program (as opposed to interactive
calculations.)
>
>    This second feature will probably happen sometime to help
interactive
> calculations and give better error messages.  It's easier, so it
may get
> done sooner than overloaded operators.
>
> --
>   Alan Eliasen              |  "Furious activity is no substitute
>   eliasen@...    |    for understanding."
>   http://futureboy.us/      |           --H.H. Williams
>

Mike Crowe wrote:
> I came across a problem that I think Frink would be ideal for.
> However, I don't know if it has this capability or not.

    There are perhaps two different issues in what you've discussed.
I'll address them below.

> What I need is to describe an object that has multiple dimensions
> that are NOT related:
>
> class bulb {
>   var brighness is wattage // (I'm making this up as I go)
>   var cost is currency
>   var wavelength is length // enter the wavelength of the bulb
>   ...
> }
>
> red is bulb = new bulb["red",10 watts,1 dollar,500 nm]
> green is bulb = new bulb["green",5 watts,0.5 dollar,400 nm]

     The above is all fine (assuming a suitable class definition and
constructor.)  There are some minor issues like this should use "power"
for wattage, etc.

> display = 10 red + 20 green

    This is issue 1:  overloaded operators for user-defined types.  This
allows you to define what, say, the "+" operator will mean when adding
two (possibly different) class types, or what it means to multiply a
class type by a numeric type (as in "10 red") above.  There are at least
two different overloaded operators in the above example.
Unfortunately, Frink doesn't have the capability to define
user-overloaded operators at all right now, so there's no way to do this
as written.  You could, however, do the less satisfactory function
definition:

add[a is bulb, b is bulb] :=
{
    ... add field members here...
    ... and return something (but of what type?) ...
}

    However, the obvious question is "what do you do with each field?"
Do you add the brightnesses?  (Mmm... maybe.  You might add the power
consumptions, but the *brightnesses* might not be additive.)  Add the
costs?  (Maybe.)  Add the wavelengths?  (Never!)  This reminds me of the
story in Richard Feynman's autobiography where science textbooks asked
kids to *add* star temperatures, which has little or no physical
meaning, (other than if you were going to later, say, take an average,)
that caused him so much annoyance.  See
http://www.textbookleague.org/103feyn.htm

    Also, what is the return type?  (10 bulbs is not an object of type
bulb, for instance, and ten cats is not a cat, with a height and an a
name, etc.) so a new type would likely have to be created.)

    There are other questions, like "can you have a fractional bulb",
"can you have a complex number of bulbs like 6i", "what do you put into
the 'name' field", etc.

    Then there are things like temperature, where if you add 100 gallons
of water at 280 K and 1 gallon at 250 K, what temperature (or even
volume or density) do you get?  (There are multiple subtleties there.)

    So, I doubt that addition or multiplication of class items can or
should be done automatically.  The programmer will probably have to
specify what it means to add or multiply two classes, and explicitly
define what the return type will be.

    I have overloaded operators on my "to-do" list, but I don't know when
I'll be able to get to it.  It's a fair amount of work.

> print display -> dollars     // this would then total the currency
> portion of the class (10*$1 + 20*$0.50) or $20 total
>
> print display -> wattage     // this would total the wattage of all
> bulbs (10*10 + 20*5 = 200 watts)

    This is a second issue.  I think what you're asking is for Frink to
look into the internal fields of a class and, when applying a conversion
operator, see if there's any field that has the dimensions that you're
requesting, and return that field.

    There are problems, of course, if there are two or more (or zero)
fields with the same dimensions.  Which one do you use?

    I've thought about this one in the past, and what I think I'd do
would be to only *suggest* the one or more internal fields that *might*
be the one you're looking for, and produce that as an error/helpful
hint, like when is done now when you have a conformance error in a
calculation:

gravity foot -> joules

  Conformance error
    Left side is: 2.98906692 m^2 s^-2 (specific_energy)
   Right side is: 1 m^2 s^-2 kg (energy)
      Suggestion: multiply left side by mass

  For help, type: units[mass]
                    to list known units with these dimensions.



    So the error would probably say something like:
-----------------------------------------------------------
display -> dollars

    Field error.
    The object "display" is an object of type "bulb".  Its value is:
bulb
{
    brightness = 100 W
    cost = 1.07 dollars
    wavelength = 550e-9 m
}

    The field "cost" has the dimensions you're looking for.  Perhaps you
should be asking for "display.cost"?
--------------------------------------------------------------

    Or something like that.  I really want to avoid too much "guess what
I mean" behavior, because sometimes I'll silently guess quite wrong, or
there might be a field that matches by accident, which is not the field
you intended (because you may have forgotten to multiply by a constant
or something.)  I'd rather that the programmer make explicit what they
mean, especially in a program (as opposed to interactive calculations.)

    This second feature will probably happen sometime to help interactive
calculations and give better error messages.  It's easier, so it may get
done sooner than overloaded operators.

--
   Alan Eliasen              |  "Furious activity is no substitute
   eliasen@...    |    for understanding."
   http://futureboy.us/      |           --H.H. Williams

Hi folks,

I came across a problem that I think Frink would be ideal for.
However, I don't know if it has this capability or not.

What I need is to describe an object that has multiple dimensions
that are NOT related:

class bulb {
   var brighness is wattage // (I'm making this up as I go)
   var cost is currency
   var wavelength is length // enter the wavelength of the bulb
   ...
}

red is bulb = new bulb["red",10 watts,1 dollar,500 nm]
green is bulb = new bulb["green",5 watts,0.5 dollar,400 nm]
...

display = 10 red + 20 green

print display -> dollars     // this would then total the currency
portion of the class (10*$1 + 20*$0.50) or $20 total

print display -> wattage     // this would total the wattage of all
bulbs (10*10 + 20*5 = 200 watts)

etc.

Is this possible?

TIA
Mike