Re: [GNHLUG] MerriLUG: April 2nd 2013 - Bitcoin
On Thu, Apr 4, 2013 at 5:27 PM, David Rysdam wrote: >> Peer-to-peer is two guys meeting on a street corner and saying "Hey, >> wanna buy some Bitcoins?" :) > > What if 100 guys meet on a street corner? Umm... then there's more of them? :) It doesn't inherently affect the peer-to-peer nature, if that's what you're asking. > And what if that street corner is then blocked, "DoS'd" if you will, > by a rival gang? Isn't that exactly what happened here? I guess so... I get the feeling this analogy has gotten out-of-control. :) -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Any Octave users? What is this code snippet actually doing?
If I knew how to debug in octave I'd tell you. Maybe tonight I'll brush up on octave... So far my python script runs but outputs 0. Kfactor seems to be evaluated as 0. I bet it would work better if kfactor != 0... On Apr 6, 2013 4:59 PM, "Michael ODonnell" wrote: > > > > kmax=1; > > kfactor=(kmax-1.0)/delta/(orderbc+1.0)/delbc^orderbc; > > > Unless matlab treats floats and ints differently than most other > > languages, I'd say its a bug because zero over anything is always zero. > > > Shame on anybody who'd intentionally code something like > that without also providing a comment about such a seemingly > counterintuitive approach. >-/ Let's hope it's simply a bug... > > Out of morbid curiosity, how does Octave report the value of > kfactor after > >kmax=1 >kfactor=(kmax-1.0) > > ?? > > ___ > gnhlug-discuss mailing list > gnhlug-discuss@mail.gnhlug.org > http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/ > ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Any Octave users? What is this code snippet actually doing?
> kmax=1; > kfactor=(kmax-1.0)/delta/(orderbc+1.0)/delbc^orderbc; > Unless matlab treats floats and ints differently than most other > languages, I'd say its a bug because zero over anything is always zero. Shame on anybody who'd intentionally code something like that without also providing a comment about such a seemingly counterintuitive approach. >-/ Let's hope it's simply a bug... Out of morbid curiosity, how does Octave report the value of kfactor after kmax=1 kfactor=(kmax-1.0) ?? ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Any Octave users? What is this code snippet actually doing?
On Sat, 06 Apr 2013 14:34:27 -0400, Bruce Labitt wrote: > On 04/06/2013 02:21 PM, David Rysdam wrote: > > On Sat, 06 Apr 2013 14:03:58 -0400, Bruce Labitt > > wrote: > >> I'm trying to understand a chunk of 3D FDTD code that I downloaded from > >> the publisher of the book, "Computational Electrodynamics". > > I can't answer your question, but I may enjoy an elaboration of the > > above. Years ago I started some simple-minded electrodynamic simulations > > and gave up when it got hard. I wanted to simulate a "Farnsworth fusor"[1] > > absent a means of actually building one. > > > > [1] http://en.wikipedia.org/wiki/Farnsworth_fusor > > > > > Well I have to admit, this stuff *is* hard, at least for me it is. I > think you ought to try again on the fusor! You are smarter now, right. :P I think I'm probably not much dumber ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Any Octave users? What is this code snippet actually doing?
On 04/06/2013 02:21 PM, David Rysdam wrote: > On Sat, 06 Apr 2013 14:03:58 -0400, Bruce Labitt > wrote: >> I'm trying to understand a chunk of 3D FDTD code that I downloaded from >> the publisher of the book, "Computational Electrodynamics". > I can't answer your question, but I may enjoy an elaboration of the > above. Years ago I started some simple-minded electrodynamic simulations > and gave up when it got hard. I wanted to simulate a "Farnsworth fusor"[1] > absent a means of actually building one. > > [1] http://en.wikipedia.org/wiki/Farnsworth_fusor > > Well I have to admit, this stuff *is* hard, at least for me it is. I think you ought to try again on the fusor! You are smarter now, right. :P ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Any Octave users? What is this code snippet actually doing?
Unless matlab treats floats and ints differently than most other languages, I'd say its a bug because zero over anything is always zero. But, I have no clue as to what context its running in, so it may be deliberate. --Bruce On 04/06/2013 02:03 PM, Bruce Labitt wrote: > I'm trying to understand a chunk of 3D FDTD code that I downloaded > from the publisher of the book, "Computational Electrodynamics". It > is in matlab, so I tried to run it in Octave. Something is not quite > right, so it doesn't execute. That doesn't matter to me right now. > The piece of code is: > > //start snippet > % x-varying material properties > delbc=upml*delta; > sigmam=-log(rmax)*(orderbc+1.0)/(2.0*eta*delbc); > sigfactor=sigmam/(delta*(delbc^orderbc)*(orderbc+1.0)); > kmax=1; > kfactor=(kmax-1.0)/delta/(orderbc+1.0)/delbc^orderbc; > //end snippet > > It would seem to me that kfactor is always zero, since kmax is set to > 1 in the line above. That probably is not the intent, I think. > kfactor does not seem to be updated later in the code. > > Is this just a bug? Or what does the last line do? The author of the > code is a long graduated PhD student from UWisc. Just contact UW? > > URL of actual code: > http://www.artechhouse.com/static/downloads/fdtd3D_UPML.zip > > It doesn't matter if it executes in octave. (It would be nice, though > - it currently runs, plots a little, then seg faults) > > octave:1> fdtd3D_UPML > error: base_graphics_object::get_properties: invalid graphics object > panic: Segmentation fault -- stopping myself... > attempting to save variables to `octave-core'... > save to `octave-core' complete > Segmentation fault > > I tested the code in Matlab, and it executes. Can't really say if the > code is doing everything right, but it runs and vaguely does things > sort of ok. The simulation is kind of coarse, but one can see an > electric field starting to radiate from a dipole. > > I'm porting it to python/scipy and maybe later to pycuda, once I get > it working. Then maybe I can do some cool stuff with it. > > Thanks in Advance > -Bruce > > > > > ___ > gnhlug-discuss mailing list > gnhlug-discuss@mail.gnhlug.org > http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/ ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Any Octave users? What is this code snippet actually doing?
On Sat, 06 Apr 2013 14:03:58 -0400, Bruce Labitt wrote: > I'm trying to understand a chunk of 3D FDTD code that I downloaded from > the publisher of the book, "Computational Electrodynamics". I can't answer your question, but I may enjoy an elaboration of the above. Years ago I started some simple-minded electrodynamic simulations and gave up when it got hard. I wanted to simulate a "Farnsworth fusor"[1] absent a means of actually building one. [1] http://en.wikipedia.org/wiki/Farnsworth_fusor ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Any Octave users? What is this code snippet actually doing?
I'm trying to understand a chunk of 3D FDTD code that I downloaded from the publisher of the book, "Computational Electrodynamics". It is in matlab, so I tried to run it in Octave. Something is not quite right, so it doesn't execute. That doesn't matter to me right now. The piece of code is: //start snippet % x-varying material properties delbc=upml*delta; sigmam=-log(rmax)*(orderbc+1.0)/(2.0*eta*delbc); sigfactor=sigmam/(delta*(delbc^orderbc)*(orderbc+1.0)); kmax=1; kfactor=(kmax-1.0)/delta/(orderbc+1.0)/delbc^orderbc; //end snippet It would seem to me that kfactor is always zero, since kmax is set to 1 in the line above. That probably is not the intent, I think. kfactor does not seem to be updated later in the code. Is this just a bug? Or what does the last line do? The author of the code is a long graduated PhD student from UWisc. Just contact UW? URL of actual code: http://www.artechhouse.com/static/downloads/fdtd3D_UPML.zip It doesn't matter if it executes in octave. (It would be nice, though - it currently runs, plots a little, then seg faults) octave:1> fdtd3D_UPML error: base_graphics_object::get_properties: invalid graphics object panic: Segmentation fault -- stopping myself... attempting to save variables to `octave-core'... save to `octave-core' complete Segmentation fault I tested the code in Matlab, and it executes. Can't really say if the code is doing everything right, but it runs and vaguely does things sort of ok. The simulation is kind of coarse, but one can see an electric field starting to radiate from a dipole. I'm porting it to python/scipy and maybe later to pycuda, once I get it working. Then maybe I can do some cool stuff with it. Thanks in Advance -Bruce ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/