Christopher2222

5100 Reputation

24 Badges

11 years, 362 days

MaplePrimes Activity


These are replies submitted by Christopher2222

@acer Yes 2D input mode and I believe I had the panel closed. If it happens again I'll keep tabs.

Yes appears to be the java.  I couldn't type anything, nothing worked.  It happened when I typed into where the mouse pointer was and Maple popped up what it think I might have wanted to type, it was at that point it froze with the suggested word.  I had to start tas k manager in windows 7 and stop the java process which I think was consuming about 1.6 Gb of memory.  Happened twice on me last night while working with image Arrays.

@dharr It appears grayscale is the culprit?

Maybe if we change the 8bit grayscale in Maple to 1bit black and white scale.  Getting it to one bit is harder than I thought.

I attempted a Threshold(a,method=both) to get rid of the .999999999's to 1.0

Then did a

b:=Array(a,datatype=integer[1])

So then I'm left with ones and zeros only but I can't write it as an image file.

For example using this zipped file of a TIF file

G31DS.zip

When I read the 124kb file in then write it, it becomes 133kb - a minor discrepancy but larger nonetheless.

This just brought me to another question.  Preview the image doesn't show a clean image within Maple (that is when I zoom in the lettering gets fuzzy.  However I can zoom in on the written file and original file in windows photo viewer nice a clear.  Is this an image limitation in Maple?  (I've never noticed that before) - Why is that? 

I'm not sure what compression format they would have.  I thought the file saved from Maple would be the same size.  The one file I used turned out 30% larger but a file I just tested was only 7% larger -- still larger nonetheless. 

If I Write("c:/test.jpg",testfile) then of course because the extension is jpg it will be smaller but saving extensions exactly the same produces different file sizes.  I suppose not all programs save the same files exactly the same way.

However, reading and writing the same file sequentially through maple a few times doesn't change the file size, which does suggest the way the original file was saved is not done the same way Maple saves it. 

So this brings up another question, does this mean that Maple does not save files in the most efficient way?

@Carl Love Ok, yes of course the files both represented by n x m matricies saving the files won't change the size.

I did try using winrar and there was no appreciable differences.  The SVD'd file was still larger than the original. 

I am missing something.  When I save the SVD'd file it's actually larger than the original. 

I've made a mistake above, originally I said from 17 to 18 but actually from 18 to 19 clearly shows the bug in FormatTime

@acer No I did not consider.  I was thinking of backwards compatibility so some earlier versions of maple would not have access to calendar.  I did think of some work arounds but then came across another issue (time travel bug?) which I mention above.

@Carl Love ah, from GMT ok thanks.

I believe there is also a bug in FormatTime

FormatTime("%Y-%m-%d",365*60*60*24*18)
                                               

FormatTime("%Y-%m-%d",365*60*60*24*19)
                                                

By increasing the number of seconds we go backwards in time.  A time warp in Maple?  Anyways, a bug.

You state " While I'm sure maple sucks for IFS "  How do you sure? 

Iterated Function Systems (IFSs) are a method of constructing fractals.  Resulting fractals are often self-similar. IFS fractals are more related to set theory than fractal geometry.

@shkarah , just add the variable

cat("",V,Z,".xls")

@Ronan Thanks for that.  Didn't even realize the option.  It was indeed checked.  I would have thought it would be unchecked by default.

How about the case of some driven oscillating force on the ball?

2 3 4 5 6 7 8 Last Page 4 of 139